From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 00:45:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F95106566B for ; Sun, 15 Aug 2010 00:45:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 24DEE8FC08 for ; Sun, 15 Aug 2010 00:45:15 +0000 (UTC) Received: (qmail 26101 invoked by uid 399); 15 Aug 2010 00:45:14 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2010 00:45:14 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C673898.2080609@FreeBSD.org> Date: Sat, 14 Aug 2010 17:45:12 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ivan Voras References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 00:45:15 -0000 Ivan, I know that you mean this at least semi-humorously, however I'm going to provide a dead-serious reply below. On 08/14/2010 16:04, Ivan Voras wrote: > On 13.8.2010 11:34, Doug Barton wrote: > >> To be fair, I didn't notice a performance difference either until I >> started revamping this code that calls my parse_index() for every single >> installed port. Given a 22,042 line INDEX file, that's enough to add up >> to something noticeable. > > Wouldn't this might, just might, be an indication that one of the > following is true: > > 1) writing complex performance-sensitive utilities in shell code simply > sucks because it's too sensitive to issues like borderline behaviours of > utilities As someone who used to make a pretty good living writing highly performance-oriented CGI applications in perl I would agree with you here to some extent. The original version of what could reasonably be called an antecedent to what is now portmaster was 102 lines, but only 49 were actual code (the rest were comments or whitespace). The current behemoth (my dev version that is) is 3,702 lines, 3,069 of which is actual code. So yes, there is an element of insanity here (and yes, the current code is under-commented, for those keeping score at home). > 2) implementing complex data structures that might save you reparsing on > the order of complexity of O(npkg * nlines) is too demanding in shell > code and this means it's not exactly the best tool for the job Again, partial agreement. One of the reasons I resisted INDEX support for so long was that my original idea of it was to do exactly what you suggest here, parse it once then look up the data internally. However even though I _can_ do this in shell it actually makes the performance worse since now I've got his huge memory footprint to pass around every time portmaster calls itself recursively (which for those who don't know is portmaster's entire model of operation). BUT, none of that is germane to my actual argument. I was very careful to NOT say, "BSD grep is slow, which screws up portmaster, so the default has to change." What I said was, "BSD grep is anywhere from 6 to 15 TIMES slower than GNU grep in all cases, so the default needs to change." If you insist on applying that directly to portmaster, I will say that implementing it in shell is a very conscious design tradeoff. If I hadn't already observed the hilarity ensuing around portupgrade/ruby updates, and I was sitting down today to design a "ports management tool" from scratch, I'd use perl, no question. Even without its own db everything that portmaster does could be done more easily and faster in perl. However, even granting THIS point the fact remains that the previous status quo was 1) a text file data store with a known, (mostly) easy to parse structure, and 2) an easy to use, fast tool to access that data with. Your line of reasoning boils down to, "You shouldn't object to the new tool being slower because you are doing things you shouldn't have been doing with the old tool in the first place." Even IF I were willing to grant you that point inre portmaster (I'm not, but let's just say ...) are you willing to tell every user of grep for every other purpose (including all the many places it's used in the base, like /etc, /etc/rc.d, the build ....), "You have to put up with a slow grep because ....?" Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 01:12:37 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B4410656A3 for ; Sun, 15 Aug 2010 01:12:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C02D78FC16 for ; Sun, 15 Aug 2010 01:12:36 +0000 (UTC) Received: (qmail 24313 invoked by uid 399); 15 Aug 2010 01:12:36 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2010 01:12:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C673F02.8000805@FreeBSD.org> Date: Sat, 14 Aug 2010 18:12:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Gabor Kovesdan References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> In-Reply-To: <4C66C010.3040308@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: delphij@FreeBSD.org, core@FreeBSD.org, current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 01:12:37 -0000 On 08/14/2010 09:10, Gabor Kovesdan wrote: > Em 2010.08.13. 10:52, Roman Divacky escreveu: >> what about optimizing BSD grep instead? >> > [... picking one mail from the many that suggest this ...] ... and responding to your message for the same reason ... :) [Snipping the bit about why it's a hard problem not likely to be solved in the next few weeks.] > If you can make suggestions to make BSD grep faster without touching the > regex library please do it and if we can get a performance that is > acceptable, we can reconsider leaving it the default if nobody objects. > I'll check Sean's suggestions and make some measures how much does that > help. As I posted to you privately, the results I got with JUST Sean's patch on the test case I posted previously were: GNU grep Elapsed time: 2 seconds BSD grep Elapsed time: 31 seconds With the more complete patch you provided me privately I was able to shave one more second off the BSD grep case. So that's a lot better than the 47 seconds it was previously, but still a long way to go. I also have a new test case script which actually IS something that portmaster does, and in fact is the ugliest and most difficult search that it has to perform, finding an installed port based on grep'ing +CONTENTS files for an ORIGIN pattern: http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt Typical times for me, with 489 ports: GNU grep Elapsed time: 3 seconds BSD grep Elapsed time: 17 seconds (And before anyone bothers to reply saying "Use pkg_info -O for that" I'll save you the trouble. My version is from 10-20% faster. Not sure why, don't really care.) :) For those whose line of reasoning was, "But this is -current, so it's ok for things to be screwed up" my response is, only to a point. In the real world, people who don't care about performance and/or don't use grep in interesting and imaginative ways aren't going to mind BSD grep as the default, but also don't provide really useful test cases. "It works fine up to the 80'th percentile" has already been demonstrated by various pointyhat runs, etc. Sophisticated users who DO care about performance and/or DO use grep in interesting and creative ways will put up with the breakage for a while, then switch their make.conf to use GNU grep, usually silently. Therefore they stop providing ANY test data at all, never mind useful. However, given the very small number of people who actually test -current in the first place, the population I am really concerned about is the group of people who casually try -current, see that "It's really slow sometimes," don't/can't figure out why, and then get discouraged and just stop using -current at all. Now you might reply, "Great! Good riddance to those dilettantes!" However I believe rather strongly that we want to make the -current environment MORE friendly to users, even casual users. Who do you think is actually going to test "What will become 9.0-RELEASE" if we don't? OTOH, leaving it in, but switching the default gives those who are highly motivated to test and/or improve it a very easy way to do so, without causing problems for anyone else. It also makes it that much easier to make it the default again when it IS ready for prime time. Meanwhile, in response to everyone else, a simple question. How many TIMES (not percentages, multiples) slower is it Ok for BSD grep to be in comparison to GNU grep and stay the default? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 01:34:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C641C1065695; Sun, 15 Aug 2010 01:34:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id A74518FC12; Sun, 15 Aug 2010 01:34:38 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o7F1YcGU009072; Sat, 14 Aug 2010 18:34:38 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o7F1Yc3N009071; Sat, 14 Aug 2010 18:34:38 -0700 (PDT) (envelope-from sgk) Date: Sat, 14 Aug 2010 18:34:38 -0700 From: Steve Kargl To: Doug Barton Message-ID: <20100815013438.GA8958@troutmask.apl.washington.edu> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C673F02.8000805@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 01:34:38 -0000 On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote: > > Sophisticated users who DO care about performance and/or DO use grep in > interesting and creative ways will put up with the breakage for a while, > then switch their make.conf to use GNU grep, usually silently. Therefore > they stop providing ANY test data at all, never mind useful. > Whereas switching the default back to GNU grep *guarantees* neither unsophisticated nor sophosticated user will test BSD grep. It seems that you are letting a poor design decision with respect to portmaster impair others contribution to FreeBSD. I suspect that you could have added a USE_GREP knob to the port infrastructure and updated your port to use ports/textproc/gnugrep in the time that you have used to post and reply here. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 01:56:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2E01065672 for ; Sun, 15 Aug 2010 01:56:00 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1912A8FC08 for ; Sun, 15 Aug 2010 01:55:58 +0000 (UTC) Received: (qmail 5751 invoked by uid 399); 15 Aug 2010 01:55:58 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2010 01:55:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C67492C.5020206@FreeBSD.org> Date: Sat, 14 Aug 2010 18:55:56 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Steve Kargl References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> In-Reply-To: <20100815013438.GA8958@troutmask.apl.washington.edu> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 01:56:00 -0000 On 08/14/2010 18:34, Steve Kargl wrote: > On Sat, Aug 14, 2010 at 06:12:34PM -0700, Doug Barton wrote: >> >> Sophisticated users who DO care about performance and/or DO use >> grep in interesting and creative ways will put up with the breakage >> for a while, then switch their make.conf to use GNU grep, usually >> silently. Therefore they stop providing ANY test data at all, never >> mind useful. >> > > Whereas switching the default back to GNU grep ... until the performance is acceptably comparable ... > *guarantees* neither unsophisticated nor sophosticated user will > test BSD grep. ... except for those who are already highly motivated to do so. > It seems that you are letting a poor design decision with respect to > portmaster impair others contribution to FreeBSD. I was hoping to avoid commenting on this, but my feeling (and I would be glad to be wrong about it) from reading the responses is that there is a fair degree of knee-jerk reaction to what seems to be "There's big bad dougb picking on some poor innocent developer again!" going on here; and criticizing MY development skills either A) makes you feel better, B) makes you think that you're dishing out to me a little of what you think I'm dishing out to Gabor, or both. Well fine, hope you're feeling good about yourself, and you made me feel really small and bad. Good on you. Meanwhile, substitute my stupid way of doing things and defective programming skills for any other workload of your choice. Are you really going to tell me you've never had to grep a 20,000 line file? Are you really going to tell me that you've never had to grep something the size of the FreeBSD source and/or ports trees for all the instances of $FOO? And you didn't answer either of the questions I had in the post you responded to, so let me make it easier for you. Our default grep should be significantly slower than the old grep because: I think that new grep which is ____ times slower than the old grep is still in the acceptable range. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 01:57:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469711065673 for ; Sun, 15 Aug 2010 01:57:38 +0000 (UTC) (envelope-from echotty3@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F17388FC08 for ; Sun, 15 Aug 2010 01:57:37 +0000 (UTC) Received: by vws7 with SMTP id 7so2851581vws.13 for ; Sat, 14 Aug 2010 18:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=5u1sYub2pWhlhFYMiA67dqYHBthdQIct6SRmV3KoSL4=; b=Vrt5m8C9qnkTvcDb5JzH5pqjxOhhSg/O2Smtzo8ivioeWaO+cIEV+0WlT5ZYaFCdqB zi4o1HJUmldAC9oFbcxXVVERtzIMzLeh+b26GGjxgGgJBjiCYKkRyh9fXdousefEiAqz fJT/fp9czWEv65NqRSFuWgtEkfrtSg19sDqFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sgfQ0MTJtMJAKxOHDXuJuoH/V7AoFyyYtKBMq2Xk5Ii/Ahy134Db4jzbjW/doBKnWd HP4/IOLLETaGbTEQi9AOBalCVexvJ2HtVGRNa46N+RTaX8pjpXAlSgdSPdQW1AWPxSOQ MqMPMFEWr5MFr2kJojoLEZ9JdoRjSvca0ZW+4= MIME-Version: 1.0 Received: by 10.220.124.211 with SMTP id v19mr2033882vcr.184.1281836102510; Sat, 14 Aug 2010 18:35:02 -0700 (PDT) Received: by 10.220.190.5 with HTTP; Sat, 14 Aug 2010 18:35:02 -0700 (PDT) Date: Sun, 15 Aug 2010 02:35:02 +0100 Message-ID: From: =?UTF-8?Q?=C3=81lvaro_Castillo?= To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 01:57:38 -0000 Hello all I installed the FreeBSD/amd64 8.0 and updated to 9-CURRENT with csup Following... # cp /usr/share/examples/cvsup/standard-supfile /root && cd /root && sed -ie 's/CHANGE_THIS/cvsup.de/g' standard-supfile && sed -ie 's/CHANGE_THIS/./g' standard-supfile && csup -g -L 2 /root/standard-supfile Downloaded files... # cd /usr/src && make buildworld All good, now, i compiled the kernel with my conf # cd /usr/src/sys/amd64/conf && mdkir /root/kernels && cp GENERIC /root/kernels/SPACE && ee /root/kernels/SPACE && ln -s /root/kernels/SPACE && cd /usr/src && make buildkernel KERNCONF=SPACE && make installkernel KERNCONF=SPACE This is my kernel http://pastebin.com/1NpvzNp6 $ dmesg (cut) panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 cpuid = 0 Uptime: 3m35s Dump failed. Partition too small. Automatic reboot in 15 seconds - press a key on the console to abort panic: bufwrite: buffer is not busy??? cpuid = 0 Uptime: 3m35s Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Sat Aug 14 19:58:17 WEST 2010 tty3@x0term.lan:/usr/obj/usr/src/sys/SPACE amd64 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3015.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Family = f Model = 43 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 4294967296 (4096 MB) vgapci0: port 0xec00-0xec7f mem 0xfd000000-0xfdffffff,0xf0000000-0xf7ffffff,0xfa000000-0xfbffffff irq 21 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] I compiled to nvidia-driver next to install kernel, and i charge to this, here good, work, but i try $ startx with Driver "nvidia" on xorg.conf and the pc is not responding, screen is black. With nv and vesa work. I dont understand this -> Dump failed. Partition too small. -> My root partition has got a 435GB only ocupated 17GB and swap 512MB Can help me? This is a primary failed to nvidia-driver From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 02:02:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63414106566B; Sun, 15 Aug 2010 02:02:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4FD8FC0C; Sun, 15 Aug 2010 02:02:09 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OkSY4-000Nca-Ml; Sun, 15 Aug 2010 02:02:08 +0000 Date: Sun, 15 Aug 2010 11:02:07 +0900 Message-ID: From: Randy Bush To: Doug Barton In-Reply-To: <4C67492C.5020206@FreeBSD.org> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: core@freebsd.org, current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 02:02:09 -0000 > I think that new grep which is ____ times slower than the old grep is > still in the acceptable range. you are forcing more time to be spent on the mailing list than working the code. and many of us have to care about the license issue. randy From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 02:13:20 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21896106566B for ; Sun, 15 Aug 2010 02:13:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A03FA8FC12 for ; Sun, 15 Aug 2010 02:13:19 +0000 (UTC) Received: (qmail 25859 invoked by uid 399); 15 Aug 2010 02:13:18 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2010 02:13:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C674D3D.3090402@FreeBSD.org> Date: Sat, 14 Aug 2010 19:13:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Randy Bush References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: core@freebsd.org, current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 02:13:20 -0000 On 08/14/2010 19:02, Randy Bush wrote: >> I think that new grep which is ____ times slower than the old grep is >> still in the acceptable range. > > > > you are forcing more time to be spent on the mailing list than working > the code. Not my intention at all, but I feel your pain. I really thought this was a slam dunk or I wouldn't have even brought it up. > and many of us have to care about the license issue. But you're covered on the license issue. The code is in the base already, and no one is suggesting removing it (as Warner pointed out earlier today). What I REALLY don't want to see happen here is a "religious fervor about the license is more important than performance" situation. If I wanted that kind of drama I'd use linux. (OTOH religious fervor about proving me wrong is almost as amusing as it is unfortunate, but that doesn't negatively impact our users.) Meanwhile, I'm pretty confident this is my last post on the issue of changing the default. I've said everything I wanted to say, and obviously it's not as clear cut as I thought it was. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 02:16:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0566A1065698 for ; Sun, 15 Aug 2010 02:16:26 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 6067414E6D1 for ; Sun, 15 Aug 2010 02:16:25 +0000 (UTC) Received: (qmail 35808 invoked from network); 15 Aug 2010 02:16:25 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 15 Aug 2010 02:16:25 -0000 Message-ID: <4C674DF8.4020105@freebsd.org> Date: Sat, 14 Aug 2010 19:16:24 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100803 Thunderbird/3.0.6 MIME-Version: 1.0 To: current@freebsd.org References: <4C6505A4.9060203@FreeBSD.org> In-Reply-To: <4C6505A4.9060203@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: core@freebsd.org Subject: TIMEOUT (was: Re: Official request: Please make GNU grep the default) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 02:16:26 -0000 Hi all, Over the past 18 hours, I've received 22 emails in this thread. In email number 5, sent a mere 25 minutes after the thread started, gabor@ said that he agreed that the performance penalty in BSD grep compared to GNU grep was excessive and that he was going to revert back to having GNU grep as the default. Why are we still discussing this? If and when gabor@ (or someone else) has improved BSD grep performance and thinks that it's time to flip the switch back again, I'm sure there will be ample opportunity for everybody to run their favourite grep benchmarks, report numbers, and discuss the performance differences before BSD grep is (re-)made the default. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 02:30:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6CF2106566B; Sun, 15 Aug 2010 02:30:40 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 928B88FC14; Sun, 15 Aug 2010 02:30:40 +0000 (UTC) Received: by iwn10 with SMTP id 10so421238iwn.13 for ; Sat, 14 Aug 2010 19:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.139.212 with SMTP id f20mr3289746ibu.166.1281837908262; Sat, 14 Aug 2010 19:05:08 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.231.187.6 with HTTP; Sat, 14 Aug 2010 19:05:08 -0700 (PDT) In-Reply-To: <4C67492C.5020206@FreeBSD.org> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> Date: Sun, 15 Aug 2010 14:05:08 +1200 X-Google-Sender-Auth: wWqdymdgDh8gdGSmndUFsnACgTM Message-ID: From: Andrew Thompson To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: delphij@freebsd.org, core@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 02:30:41 -0000 On 15 August 2010 13:55, Doug Barton wrote: > Our default grep should be significantly slower than the old grep because: > > I think that new grep which is ____ times slower than the old grep is still > in the acceptable range. I think that new grep which is 1000 times slower than the old grep is still in the acceptable range. Can we drop this now. From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 02:44:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 019EF10656A4; Sun, 15 Aug 2010 02:44:16 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1F08FC0C; Sun, 15 Aug 2010 02:44:14 +0000 (UTC) Received: by qyk11 with SMTP id 11so2282035qyk.13 for ; Sat, 14 Aug 2010 19:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=0zL1hC91kDNdlEGCRxNPiRVolP6JQql8dHtvs3tfdQQ=; b=i3tyLYuOmjkwxJGZz8u3K3G6c5wb8Iv4XtplPWqSYA+4kHlkcLyV0xldiXVu+2rnrd krxMpGn1Qu2JCDgGavnct6/saCiDmZfpXZwqC0bjfF8owFzgebGXu2wuffJWD29VNqPu 4cp4iTf79+nuD7GsrgP8waQjyjiqIkunp7Y/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=cX5qwv0AbHRc51iAig+7vHYY7pdsaVmfhQ1I3xqnWibhuAp+i2uiuO2ZEvRKBLEeV5 Daw+DqegnKiPKwEKK4iCr7Jx6gIwB4SSwnN0U2zPjlohyjak2GZiyR7cJbm+P6aliAgT vFzdFsfvCE/Tdn65DaZYi4gB3uwaJipbkup0I= Received: by 10.229.212.11 with SMTP id gq11mr2508889qcb.78.1281838559984; Sat, 14 Aug 2010 19:15:59 -0700 (PDT) Received: from [192.168.1.23] (216-164-48-50.c3-0.gth-ubr1.lnh-gth.md.cable.rcn.com [216.164.48.50]) by mx.google.com with ESMTPS id l8sm5495104qck.6.2010.08.14.19.15.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Aug 2010 19:15:59 -0700 (PDT) Message-Id: From: Justin Hibbits To: Doug Barton In-Reply-To: <4C67492C.5020206@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Aug 2010 22:14:42 -0400 References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sun, 15 Aug 2010 02:53:59 +0000 Cc: delphij@freebsd.org, core@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 02:44:16 -0000 My $0.02 may not be worth much, but ... On Aug 14, 2010, at 9:55 PM, Doug Barton wrote: > I was hoping to avoid commenting on this, but my feeling (and I > would be glad to be wrong about it) from reading the responses is > that there is a fair degree of knee-jerk reaction to what seems to > be "There's big bad dougb picking on some poor innocent developer > again!" going on here; and criticizing MY development skills either > A) makes you feel better, B) makes you think that you're dishing out > to me a little of what you think I'm dishing out to Gabor, or both. > Well fine, hope you're feeling good about yourself, and you made me > feel really small and bad. Good on you. > > Meanwhile, substitute my stupid way of doing things and defective > programming skills for any other workload of your choice. Are you > really going to tell me you've never had to grep a 20,000 line file? > Are you really going to tell me that you've never had to grep > something the size of the FreeBSD source and/or ports trees for all > the instances of $FOO? And you didn't answer either of the questions > I had in the post you responded to, so let me make it easier for you. > > Our default grep should be significantly slower than the old grep > because: > > I think that new grep which is ____ times slower than the old grep > is still in the acceptable range. > > > Doug Why not perform a run or two with portmaster and bsdgrep with profiling, and send Gabor those results? It would certainly help pinpoint the slowdown, and you would have something to point to to say "X in bsdgrep is slow, so we should switch back to GNU grep until that's fixed" rather than just "bsdgrep is slow, fix it". Like most people here, I agree that such a performance difference is rather unacceptable for a production system, but since this is -current, fixing the performance issue should be done rather than casting the whole thing aside until it's up to par. There are 28 messages in this thread already, with no consensus in sight. - Justin From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 03:30:47 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD556106567A for ; Sun, 15 Aug 2010 03:30:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7477C8FC12 for ; Sun, 15 Aug 2010 03:30:47 +0000 (UTC) Received: (qmail 12572 invoked by uid 399); 15 Aug 2010 03:30:46 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2010 03:30:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C675F64.9080205@FreeBSD.org> Date: Sat, 14 Aug 2010 20:30:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "b. f." Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 03:30:47 -0000 On 08/14/2010 09:54, b. f. wrote: >> My "runaway intr" problem with flash has been continuing all >> along, but since no one has been interested in helping with it I >> haven't reported it for a while. However, today, for the first >> time, it happened when I had not run flash at all since I booted. >> >> My system: Dell D620, C2D, i386, SMP, r210908 >> >> swi4: clock is the culprit again this time, but when flash >> triggers this problem I sometimes see hdac as the culprit, FYI. > > I wouldn't say that no one is interested in helping. Yes, that was perhaps too strongly worded, sorry. What I meant to say was something more along the lines of, "Since I've tried everything that everyone has suggested so far, and none of it has helped, and no new suggestions have magically appeared, but I'm still having the same problem ...." > (And I think you've received a few more suggestions than your other > recent message to freebsd-developers suggests.) For my part, I find > it a bit difficult to track the status of your interrupt problem, and > the interactivity problem, which may or may not be related. Sorry that I'm making your life difficult. :) I have actually tried to report stuff that people have asked for, but I'll give you the full status update here. Before I answer all your questions below though, I wanted to say something about why I don't think it's hardware related (although none of this is conclusive, and I agree I could be wrong). The problem happens MOST often when I'm viewing a flash video, but it can also happen other times. Interestingly, what often happens is that everything is fine while I'm viewing the video, but intr runs away after I close the window. I was sort of surprised by this myself, but now I have verified it numerous times. It happens without running flash (as I pointed out in this message) and last night I was able to trigger it several times without running X at all. It DOESN'T happen with loads that produce a lot more heat than my typical desktop workloads (like say, make -j2 buildworld). The usual device that runs away is the clock, but sometimes (about 1 in 20) it's hdac. Back to flash, for a while I couldn't get it to work at all from the browser, but the hulu desktop binary worked great. Right now, the hulu desktop app causes the runaway almost immediately, but flash is working great in the browser. To me this sounds a lot like software, not hardware. > --Have you ruled out any contribution from overheating, like I think > you were experiencing before with this machine? I think so, yes. I've been keeping a very close eye on the heat, and blowing out the heat sink a lot more often. Also, see above about the fact that higher-heat loads don't make the problem happen more often. > At one point, you were following some of mav@'s suggestions for > power-saving, but then you posted a configuration that suggested > that you had abandoned some of these settings and returned to the > defaults. Right, the problem was happening with those settings, and I wanted to make sure that those weren't the cause. I didn't experience any more heat problems with the defaults, so I left it alone. > So are you running hot, or being throttled now? No, and yes. :) I'm still using powerd, and it seems to be working as expected. > Have you tried running at a kern.hz< 1000, with throttling disabled, > to see if that ameliorates the problem? That's how I was running with the settings mav suggested. I just tried reducing back to 100, but didn't adjust the throttling settings. We'll see how that works. > --What graphics driver are you using? For X, the nv driver from xorg. When I was on the console last night I was using the xterm console driver. > You were using x11/nvidia-driver, but then after the kib@ and alc@'s > vm changes that led to problems with that driver, I thought you were > using x11-drivers/xf86-video-nv -- is that still the case? Does > switching drivers seem to influence the frequency or severity of the > problems? I've tried numerous versions of the nvidia driver over the last several months, with various locking patches to make them work on -current, and they introduce their own problems (generally freeze ups, or random panics, as I've reported previously). Therefore I haven't been using the nvidia driver at all recently. > --When do you experience these problems? Do they ever occur when you > are _not_ running X? Yes. > Have you tried temporarily disabling your usb and network devices, to > see if they are contributing to the problem? I haven't tried the usb driver, but I have tried using a different network card (and turning off the built-in version with the hardware switch), no help there. > Are you able to watch flash videos from local media, as opposed to > those from a remote site, without problems? I haven't tried that, but I will, thanks. > --Did you follow mav@'s suggestion to use something other than your > hpet for the eventcounter and timecounter? The possible use of the > hpet is one of the main differences between the new and old timing > code, and you reported some problems with your hpet earlier. Yes, I tried his suggestions, didn't help. If anyone has other suggestions I'd be glad to try them. > --Did you follow attilio@'s suggestion to obtain scheduling traces > for the interactivity problem, as described in > src/tools/sched/schedgraph.py? IIRC when I asked him about that Attilio said that I was actually better off with the dtrace suggestion I also received, but it's possible that I misunderstood. I'll take another look at this. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 03:34:05 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED33A1065672 for ; Sun, 15 Aug 2010 03:34:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA8F8FC0A for ; Sun, 15 Aug 2010 03:34:05 +0000 (UTC) Received: (qmail 15157 invoked by uid 399); 15 Aug 2010 03:34:04 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2010 03:34:04 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C67602B.6040707@FreeBSD.org> Date: Sat, 14 Aug 2010 20:34:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: bf1783@gmail.com References: <4C675F64.9080205@FreeBSD.org> In-Reply-To: <4C675F64.9080205@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, "b. f." Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 03:34:06 -0000 On 08/14/2010 20:30, Doug Barton wrote: > I'm still using powerd, and it seems to be working as expected. Sorry, I should have added here that I've also tried running WITHOUT powerd, and the runaway intr problem still happens. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 06:45:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A5410656A3; Sun, 15 Aug 2010 06:45:31 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8538FC0A; Sun, 15 Aug 2010 06:45:30 +0000 (UTC) Received: by wwb24 with SMTP id 24so1909454wwb.31 for ; Sat, 14 Aug 2010 23:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=6IYG0IUNoTzDtcK2RTE7YTAqB1K1eaFc9UTmqmSYUCA=; b=BCeq2BLAXucj9bMYy/boQULtiqtwF3V+/SqRbCevzqm4kLShq46Hj2i++qg0HxgQEp p9TEJQxGfAoL+slit7Zt86dsr4Si6IpFKmILW1rgLyZSaqT1kIpdUjD2LobRBFvShXRC Lc9MfVGk/mYYqN/mjDl/l5ZY46N/qS3p/Zn6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=TZpEbhFdoV9bnR8hb33fNcHp132n3TW+7GBZrY3vBWXWKLeY0LUTkmYeule03R463I K/rw37JtKuQYEBAU+R/ZBxfT9oY8jM3PtwPTZ1YbtjPNAx+uoiDnIu6yOdUU4G6adNkN Jn8vjEFM3zqCGeNIEkwECX2a3dfA0c9IhsMxg= MIME-Version: 1.0 Received: by 10.216.231.25 with SMTP id k25mr3136330weq.2.1281854729117; Sat, 14 Aug 2010 23:45:29 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Sat, 14 Aug 2010 23:45:28 -0700 (PDT) In-Reply-To: <4C675F64.9080205@FreeBSD.org> References: <4C675F64.9080205@FreeBSD.org> Date: Sun, 15 Aug 2010 06:45:28 +0000 Message-ID: From: "b. f." To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 06:45:31 -0000 On 8/15/10, Doug Barton wrote: > On 08/14/2010 09:54, b. f. wrote: >>> My "runaway intr" problem with flash has been continuing all >>> along, but since no one has been interested in helping with it I >>> haven't reported it for a while. However, today, for the first >>> time, it happened when I had not run flash at all since I booted. >>> >>> My system: Dell D620, C2D, i386, SMP, r210908 >>> >>> swi4: clock is the culprit again this time, but when flash >>> triggers this problem I sometimes see hdac as the culprit, FYI. > The problem happens MOST often when I'm viewing a flash video, but it > can also happen other times. Interestingly, what often happens is that > everything is fine while I'm viewing the video, but intr runs away after > I close the window. I was sort of surprised by this myself, but now I > have verified it numerous times. > > It happens without running flash (as I pointed out in this message) and > last night I was able to trigger it several times without running X at all. > > The usual device that runs away is the clock, but sometimes (about 1 in > 20) it's hdac. > What were you doing when you triggered the interrupt problem without running X? Was there a lot of network, audio device, or disk activity at the time? Are these failures without X consistently reproducible, or unpredictable? Can you remember the revision number of the last version of -CURRENT that didn't have these problems? b. From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 08:40:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0CD1065695; Sun, 15 Aug 2010 08:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8064D8FC0C; Sun, 15 Aug 2010 08:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7F6F241C705; Sun, 15 Aug 2010 10:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Ad8g8-nkNp3a; Sun, 15 Aug 2010 10:40:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 9137C41C71D; Sun, 15 Aug 2010 10:40:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B53A64448EC; Sun, 15 Aug 2010 08:35:33 +0000 (UTC) Date: Sun, 15 Aug 2010 08:35:33 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Doug Barton In-Reply-To: <4C673F02.8000805@FreeBSD.org> Message-ID: <20100815083420.V48418@maildrop.int.zabbadoz.net> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 08:40:08 -0000 On Sat, 14 Aug 2010, Doug Barton wrote: ... > http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt > > Typical times for me, with 489 ports: > > GNU grep > Elapsed time: 3 seconds > > BSD grep > Elapsed time: 17 seconds Which version of GNU grep is this that you have in /usr/local? /bz -- Bjoern A. Zeeb This signature is about you not me. From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 08:56:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11F4B1065698 for ; Sun, 15 Aug 2010 08:56:17 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id BD9648FC0C for ; Sun, 15 Aug 2010 08:56:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id DCABB8067 for ; Sun, 15 Aug 2010 10:56:15 +0200 (CEST) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 89F868051; Sun, 15 Aug 2010 10:56:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Alban Hertroys In-Reply-To: <4C673F02.8000805@FreeBSD.org> Date: Sun, 15 Aug 2010 10:56:01 +0200 Content-Transfer-Encoding: 8bit Message-Id: <3CF90102-4DD5-4A44-925B-C215AE5AB36A@solfertje.student.utwente.nl> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1081) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Aug 15 10:56:15 2010 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 930,4c67abaf967636193329187 X-DSPAM-Factors: 27, but, 0.01000, From*Alban, 0.01000, just, 0.01000, Mime-Version*Message, 0.01000, from, 0.01000, of, 0.01000, of, 0.01000, Received*ESMTP, 0.01000, Content-Transfer-Encoding*8bit, 0.01000, doesn't, 0.01000, Alban+Hertroys, 0.01000, Mime-Version*1.0+(Apple, 0.01000, that, 0.01000, that, 0.01000, Hertroys, 0.01000, Date*2010, 0.01000, as, 0.01000, From*Hertroys, 0.01000, From*solfertje.student.utwente.nl>, 0.01000, in, 0.01000, in, 0.01000, Received*with, 0.01000, Received*id, 0.01000, Received*ESMTP+id, 0.01000, Alban, 0.01000, there, 0.01000, Received*[10.236.150.4]), 0.01000 Cc: core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 08:56:17 -0000 On 15 Aug 2010, at 3:12, Doug Barton wrote: > (And before anyone bothers to reply saying "Use pkg_info -O for that" > I'll save you the trouble. My version is from 10-20% faster. Not sure > why, don't really care.) :) Congrats for beating the performance of a(nother) utility in base, but - regardless of whether you'd use it in that case - doesn't that just indicate that pkg_info could use some performance improvements as well? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4c67abaf967636193329187! From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 09:17:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82D6E1065695 for ; Sun, 15 Aug 2010 09:17:11 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4076D8FC08 for ; Sun, 15 Aug 2010 09:17:11 +0000 (UTC) Received: from 198-12-179-94.pool.ukrtel.net ([94.179.12.198] helo=localhost) by fsm1.ukr.net with esmtps ID 1OkYso-000LPJ-K1 ; Sun, 15 Aug 2010 11:47:58 +0300 Date: Sun, 15 Aug 2010 11:47:57 +0300 From: Ivan Klymenko To: =?UTF-8?B?w4FsdmFybw==?= Castillo Message-ID: <20100815114757.039ba06f@ukr.net> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 09:17:11 -0000 =D0=92 Sun, 15 Aug 2010 02:35:02 +0100 =C3=81lvaro Castillo =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > This is my kernel >=20 > http://pastebin.com/1NpvzNp6 >=20 try the following: Delete: AGP device from the kernel config rebuild new kernel and boot into single user mode,=20 mount -u / mount -a and reinstall the NVIDIA driver port ... cd /usr/ports/x11/nvidia-driver && make reinstall clean reboot From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 10:16:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4A5E1065670 for ; Sun, 15 Aug 2010 10:16:21 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0EE8FC0C for ; Sun, 15 Aug 2010 10:16:20 +0000 (UTC) Received: by bwz20 with SMTP id 20so1255219bwz.13 for ; Sun, 15 Aug 2010 03:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=DWT3eYn+7vttuCp5eT8VjCl08nCeSHDaO9Vdt+SOVRY=; b=fwdtRTBG/tQEbLLEnpMqyOQ+UBBTYrdwElUcSUHISQW76esUcrctLv3Zlz4K7P0H1r HJjzKLPuCYbNK7fru+V2rh+bAHMvmHut16WSEaYVdFwRywbPnyEpZ4p/J6RU58Hjcp5W YSXfGjFQzZNM+ZfITZyRglh6T2Z6oVHbV0yj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=yAVitc4BMvtx6FoYs8CdjoQUwMw5n9c5xhjb5wpzcmvGkY0o53Up6q52nzMXIoho9U VIuyGboxH880nwUtG4TD7RaBWcYqojCXk5pBn4ZG+gUcidhhp825QpgX/sIb3hsv3B9K WMKY9HLcsCHvb0G0LOWWEmVXo2XPddy4L9DZ8= Received: by 10.204.27.20 with SMTP id g20mr2325472bkc.114.1281865617834; Sun, 15 Aug 2010 02:46:57 -0700 (PDT) Received: from ernst.jennejohn.org (p578E36CF.dip.t-dialin.net [87.142.54.207]) by mx.google.com with ESMTPS id y2sm3284357bkx.20.2010.08.15.02.46.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Aug 2010 02:46:57 -0700 (PDT) Date: Sun, 15 Aug 2010 11:46:55 +0200 From: Gary Jennejohn To: =?ISO-8859-1?Q?=C1lvaro?= Castillo Message-ID: <20100815114655.65073248@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 10:16:22 -0000 On Sun, 15 Aug 2010 02:35:02 +0100 __lvaro Castillo wrote: > I dont understand this -> Dump failed. Partition too small. -> My root > partition has got a 435GB only ocupated 17GB and swap 512MB > You have 4GB of memory and only 512MB of swap - too small to dump the contents of memory. Crash dumps go to the swap partition, not the root partition. swap should be about 1-1/2 times the size of memory if you want to be able to capture crash dumps, as a rule of thumb. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 10:57:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24CA51065697 for ; Sun, 15 Aug 2010 10:57:46 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id B19A68FC0A for ; Sun, 15 Aug 2010 10:57:45 +0000 (UTC) Received: by qwg5 with SMTP id 5so4812996qwg.13 for ; Sun, 15 Aug 2010 03:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=uXdH+0XPKbBJb8mVNPJeBxrnnIErmlRpmeCvhE2JM+g=; b=Ym4EFu1SFhgXthV0kYcnlGZI7X2uhP6cxlnczgGfNVoUxXH6VIKDe+0usa3+4JnprA pkABvS+avo5H3/g5QH4OsxJpuJE2DT9B8CFSEzvGqYjiLsj4LcmQdcSxy+9bhGgf/Mnb kVkMnYcVcsSkV5huoGcitEzKtR8MMMmEEQsb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=JQZ/UdwrYFCCHaSmqNoXmztSccQ73GXN8J1NRqic4i+2i82ADEZRTLKmjMWEE1ti71 wY3GRuqjC81uHjmvlx1O0xnfrPaeHvbRk/Y/drFnMKK5eA0+Wd0cJg4uA8usPaaduLNc PXrFlZ94cPy8F1XQfq97l/xi9P3dUIPVeY0xs= Received: by 10.224.96.150 with SMTP id h22mr2409238qan.173.1281869863112; Sun, 15 Aug 2010 03:57:43 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Sun, 15 Aug 2010 03:57:23 -0700 (PDT) In-Reply-To: <4C673898.2080609@FreeBSD.org> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> From: Ivan Voras Date: Sun, 15 Aug 2010 12:57:23 +0200 X-Google-Sender-Auth: ApNlzaNL4weHFZEqZxs5YnIXNOc Message-ID: To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 10:57:46 -0000 On 15 August 2010 02:45, Doug Barton wrote: > Ivan, > > I know that you mean this at least semi-humorously, however I'm going to > provide a dead-serious reply below. Thank you for your level-headed response - it's actually better than continuing less seriously or explosively :) Also, sorry for redirecting your thread but it provides me context. > Again, partial agreement. One of the reasons I resisted INDEX support > for so long was that my original idea of it was to do exactly what you > suggest here, parse it once then look up the data internally. However > even though I _can_ do this in shell it actually makes the performance > worse since now I've got his huge memory footprint to pass around every > time portmaster calls itself recursively (which for those who don't know > is portmaster's entire model of operation). This is my long-term point - it really would be beneficial to have an alternative, richer language in base which would fall between the categories of "a good system language but far too complex for simple string-parsing stuff" which is C and "a good glue language for system utilities but lacking more evolved concepts" which is shell. [skip the following section, I was going deep into wishful thinking territory] That said, I know it's useless to simply import something in the hope it will be useful in the future. My best bet is that I (or someone else) would write something useful enough to be imported in base in such a language, which would warrant importing the language itself. I also know that perl was there and was removed because of maintainance problems and clashing between user expecting it to be from ports and having an old version in base, so this potential new language will have to not clash with ports and not be used by installed ports by default. My current favorite is lua because it's very small and easily embeddable and extendable by C code, but there are others - some JavaScript engines probably fit the description. > BUT, none of that is germane to my actual argument. I was very careful > to NOT say, "BSD grep is slow, which screws up portmaster, so the > default has to change." What I said was, "BSD grep is anywhere from 6 to > 15 TIMES slower than GNU grep in all cases, so the default needs to > change." Yes, and I agree - having new grep which is about an order of magnitude slower then the old one is a bad situation. From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 17:17:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4067D1065696; Sun, 15 Aug 2010 17:17:27 +0000 (UTC) (envelope-from prvs=1843ec5375=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 338508FC1B; Sun, 15 Aug 2010 17:17:25 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 15 Aug 2010 18:07:17 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 15 Aug 2010 18:07:17 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011070231.msg; Sun, 15 Aug 2010 18:07:16 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1843ec5375=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4919ED7081CD427B93477E1BD4FE13E3@multiplay.co.uk> From: "Steven Hartland" To: "Steve Kargl" , "Doug Barton" References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org><4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> Date: Sun, 15 Aug 2010 18:07:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: delphij@freebsd.org, core@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 17:17:27 -0000 ----- Original Message ----- From: "Steve Kargl" > Whereas switching the default back to GNU grep *guarantees* > neither unsophisticated nor sophosticated user will test > BSD grep. > > It seems that you are letting a poor design decision with > respect to portmaster impair others contribution to FreeBSD. > I suspect that you could have added a USE_GREP knob to > the port infrastructure and updated your port to use > ports/textproc/gnugrep in the time that you have used to > post and reply here. It may be ideal to move to a bsd licensed grep implementation but anything more than a fractional slowdown is an unacceptable penalty. Doug is not seeing 1.1 times slower or even 1.5 times slower we are talking 6 - 15 times slower by his measurements and that is not something as a users we would want to use. The fact its a script and there may be more efficient ways of implementing it doesn't matter one jot. The fact that the new default grep is so much slower than the one its trying to replace is what matters, so until its brought up to a comparable speed then my vote would be switch back to GNU grep as the default. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 17:17:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9371110656A5; Sun, 15 Aug 2010 17:17:27 +0000 (UTC) (envelope-from prvs=1843ec5375=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5A58FC16; Sun, 15 Aug 2010 17:17:25 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 15 Aug 2010 18:10:13 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 15 Aug 2010 18:10:13 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011070241.msg; Sun, 15 Aug 2010 18:10:12 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1843ec5375=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andrew Thompson" , "Doug Barton" References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org><4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org><20100815013438.GA8958@troutmask.apl.washington.edu><4C67492C.5020206@FreeBSD.org> Date: Sun, 15 Aug 2010 18:10:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 17:17:27 -0000 ----- Original Message ----- From: "Andrew Thompson" > On 15 August 2010 13:55, Doug Barton wrote: >> Our default grep should be significantly slower than the old grep because: >> >> I think that new grep which is ____ times slower than the old grep is still >> in the acceptable range. > > > I think that new grep which is 1000 times slower than the old grep is > still in the acceptable range. > > Can we drop this now. I assume your joking right? Either that or your never use grep day to day so don't really care :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 17:53:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA56E1065740 for ; Sun, 15 Aug 2010 17:53:34 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0AE8FC13 for ; Sun, 15 Aug 2010 17:53:34 +0000 (UTC) Received: by iwn10 with SMTP id 10so995119iwn.13 for ; Sun, 15 Aug 2010 10:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jsaZzp6mNek+oUVb5G0LFGNTO8x/l5OE8epVEQGF3Bk=; b=HfVj3nHNL26mG/A3wLiVAo120Ot28IGI+wX911AoCt/FvC/1QRvzKZwI4zRpEYpLvZ vmow7G7mZaus+idsbpBNQ903us8aYug//NT5s+BMGhkLYziL6pbPcZV5N8/efY1zvbE1 HkRbHu52gg9mrsd/vE0VrRXz9G+hK+0edK67E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W4GzfhxFr75Z5Zg3fd41zBxgbagSermjp/3uU0bNBLMYw7oqjLMejEDpQM0GgjSHau Oc0zpYxXnBcfVKF0J/FBOadVDgi+ZLLE9oMfVOtKD0UEHs/WlTqBBW5tX8ejg7eutbiE rjCocNWbK2sKovCIIh2UNxvxsVX2FBHECEC30= MIME-Version: 1.0 Received: by 10.231.119.229 with SMTP id a37mr3886880ibr.169.1281893324195; Sun, 15 Aug 2010 10:28:44 -0700 (PDT) Received: by 10.231.199.15 with HTTP; Sun, 15 Aug 2010 10:28:44 -0700 (PDT) In-Reply-To: References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> Date: Sun, 15 Aug 2010 12:28:44 -0500 Message-ID: From: Astrodog To: Steven Hartland Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 17:53:34 -0000 On Sun, Aug 15, 2010 at 12:10 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Andrew Thompson" >> >> On 15 August 2010 13:55, Doug Barton wrote: >>> >>> Our default grep should be significantly slower than the old grep >>> because: >>> >>> I think that new grep which is ____ times slower than the old grep is >>> still >>> in the acceptable range. >> >> >> I think that new grep which is 1000 times slower than the old grep is >> still in the acceptable range. >> >> Can we drop this now. > > I assume your joking right? Either that or your never use grep day to day > so don't really care :( > I'd like my grep to be orange, please, not this kiwi lime tripe the rest of you are pushing. The person who committed it has already said they'll back it out, but leave it in the tree for experimenters, until some of these concerns are addressed. At that point, we can all discuss if the performance penalty (assuming there is one, at that point) is worth having a BSD licensed version. Until then, can this thread die? --- Harrison From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 18:31:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A7C106564A; Sun, 15 Aug 2010 18:31:00 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 61FED8FC17; Sun, 15 Aug 2010 18:31:00 +0000 (UTC) Received: by pvg4 with SMTP id 4so1943251pvg.13 for ; Sun, 15 Aug 2010 11:31:00 -0700 (PDT) Received: by 10.142.127.9 with SMTP id z9mr3711871wfc.124.1281895695955; Sun, 15 Aug 2010 11:08:15 -0700 (PDT) Received: from [192.168.43.181] (m4d0536d0.tmodns.net [208.54.5.77]) by mx.google.com with ESMTPS id 33sm10271435wad.6.2010.08.15.11.08.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Aug 2010 11:08:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <3CF90102-4DD5-4A44-925B-C215AE5AB36A@solfertje.student.utwente.nl> Date: Sun, 15 Aug 2010 11:08:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <894C8953-7F2F-486F-8701-A3DFF65D7627@kientzle.com> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <3CF90102-4DD5-4A44-925B-C215AE5AB36A@solfertje.student.utwente.nl> To: Alban Hertroys X-Mailer: Apple Mail (2.1081) Cc: delphij@freebsd.org, Doug Barton , core@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 18:31:00 -0000 On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote: > On 15 Aug 2010, at 3:12, Doug Barton wrote: >=20 >> (And before anyone bothers to reply saying "Use pkg_info -O for that" >> I'll save you the trouble. My version is from 10-20% faster. Not sure >> why, don't really care.) :) >=20 >=20 > Congrats for beating the performance of a(nother) utility in base, but = - regardless of whether you'd use it in that case - doesn't that just = indicate that pkg_info could use some performance improvements as well? http://libpkg.googlecode.com/ This is David Forsyth's GSoC project to build a standard library for managing the on-disk package database. His pkg_info implementation built on this library is in fact a lot faster than what's currently in the tree. He's starting to prototype pkg_delete and pkg_add on the new library but there's still a lot of work to do. Tim From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 19:08:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0B511065674; Sun, 15 Aug 2010 19:08:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E175F8FC1C; Sun, 15 Aug 2010 19:08:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 13D8B1FFC33; Sun, 15 Aug 2010 19:08:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E07F1844FF; Sun, 15 Aug 2010 21:07:59 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Justin Hibbits References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> Date: Sun, 15 Aug 2010 21:07:59 +0200 In-Reply-To: (Justin Hibbits's message of "Sat, 14 Aug 2010 22:14:42 -0400") Message-ID: <8639ufd78w.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Doug Barton , current@freebsd.org, core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 19:08:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Justin Hibbits writes: > Why not perform a run or two with portmaster and bsdgrep with > profiling, and send Gabor those results? That's just about the only sensible thing anyone has said in this thread. I built a profiling version of BSD grep and ran it with a regexp that matches only the very last line in (my copy of) INDEX-9. The results are pretty clear: % cumulative self self total=20=20=20=20=20=20=20=20= =20=20=20 time seconds seconds calls ms/call ms/call name=20=20=20=20 84.0 3.75 3.75 0 100.00% _mcount [1] 6.8 4.05 0.30 0 100.00% .mcount (118) 3.8 4.22 0.17 19969171 0.00 0.00 fgetc [7] 2.7 4.34 0.12 19989841 0.00 0.00 grep_feof [8] 1.3 4.40 0.06 19969171 0.00 0.00 grep_fgetc [6] 0.8 4.44 0.04 20670 0.00 0.02 grep_fgetln [5] 0.4 4.45 0.02 163 0.10 0.10 _read [9] 0.0 4.46 0.00 0 32.01% re_search_internal [1= 4] 0.0 4.46 0.00 20730 0.00 0.00 memset [20] 0.0 4.46 0.00 20979 0.00 0.00 arena_malloc [15] 0.0 4.46 0.00 20795 0.00 0.00 arena_dalloc [25] 0.0 4.46 0.00 20976 0.00 0.00 arena_bin_malloc_easy= [21] 0.0 4.46 0.00 20976 0.00 0.00 arena_run_rc_incr [26] 0.0 4.46 0.00 20979 0.00 0.00 choose_arena [29] 0.0 4.46 0.00 62118 0.00 0.00 free [18] 0.0 4.46 0.00 41774 0.00 0.00 malloc_spin_unlock [3= 3] 0.0 4.46 0.00 1 0.37 401.83 procfile [4] 0.0 4.46 0.00 20795 0.00 0.00 idalloc [19] 0.0 4.46 0.00 0 100.00% regexec [36] Ignore the first two lines (that's the profiling code itself). Note that the top five lines are all in stdio, and nothing else even shows up on the radar. I only included enough output to show where the regexp code ranks; the complete output is attached. I hate to suggest reinventing the wheel, but IMHO, this is clearly a case where it would pay to use hand-rolled buffered input routines instead of stdio. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Disposition: inline; filename=grep-profile.txt None call graph profile: The sum of self and descendents is the major sort for this listing. function entries: index the index of the function in the call graph listing, as an aid to locating it (see below). %time the percentage of the total time of the program accounted for by this function and its descendents. self the number of seconds spent in this function itself. descendents the number of seconds spent in the descendents of this function on behalf of this function. called the number of times this function is called (other than recursive calls). self the number of times this function calls itself recursively. name the name of the function, with an indication of its membership in a cycle, if any. index the index of the function in the call graph listing, as an aid to locating it. parent listings: self* the number of seconds of this function's self time which is due to calls from this parent. descendents* the number of seconds of this function's descendent time which is due to calls from this parent. called** the number of times this function is called by this parent. This is the numerator of the fraction which divides up the function's time to its parents. total* the number of times this function was called by all of its parents. This is the denominator of the propagation fraction. parents the name of this parent, with an indication of the parent's membership in a cycle, if any. index the index of this parent in the call graph listing, as an aid in locating it. children listings: self* the number of seconds of this child's self time which is due to being called by this function. descendent* the number of seconds of this child's descendent's time which is due to being called by this function. called** the number of times this child is called by this function. This is the numerator of the propagation fraction for this child. total* the number of times this child is called by all functions. This is the denominator of the propagation fraction. children the name of this child, and an indication of its membership in a cycle, if any. index the index of this child in the call graph listing, as an aid to locating it. * these fields are omitted for parents (or children) in the same cycle as the function. If the function (or child) is a member of a cycle, the propagated times and propagation denominator represent the self time and descendent time of the cycle as a whole. ** static-only parents and children are indicated by a call count of 0. cycle listings: the cycle as a whole is listed with the same fields as a function entry. Below it are listed the members of the cycle, and their contributions to the time and call counts of the cycle. granularity: each sample hit covers 4 byte(s) for 0.00% of 4.16 seconds called/total parents index %time self descendents called+self name index called/total children [1] 90.1 3.75 0.00 _mcount [1] ----------------------------------------------- 0.00 0.40 1/1 _start [3] [2] 9.7 0.00 0.40 1 main [2] 0.00 0.40 1/1 procfile [4] 0.00 0.00 1/1 catopen [32] 0.00 0.00 1/3 setlocale [24] 0.00 0.00 1/1 add_pattern [66] 0.00 0.00 2/2 grep_calloc [70] 0.00 0.00 1/1 fastcomp [75] 0.00 0.00 2/2 getopt_internal [105] 0.00 0.00 2/2 getopt_long [106] 0.00 0.00 1/1 currentlocale [111] 0.00 0.00 1/23 getenv [90] 0.00 0.00 1/1 catclose [110] 0.00 0.00 1/1 exit [112] ----------------------------------------------- [3] 9.7 0.00 0.40 _start [3] 0.00 0.40 1/1 main [2] ----------------------------------------------- 0.00 0.40 1/1 main [2] [4] 9.7 0.00 0.40 1 procfile [4] 0.04 0.36 20670/20670 grep_fgetln [5] 0.00 0.00 1/1 grep_open [61] 0.00 0.00 1/5 grep_malloc [67] 0.00 0.00 3/62118 free [18] 0.00 0.00 1/1 grep_close [80] 0.00 0.00 1/38 strcpy [88] 0.00 0.00 1/6 _stat [870] ----------------------------------------------- 0.04 0.36 20670/20670 procfile [4] [5] 9.6 0.04 0.36 20670 grep_fgetln [5] 0.06 0.18 19969171/19969171 grep_fgetc [6] 0.12 0.00 19989841/19989841 grep_feof [8] 0.00 0.00 14/15 grep_realloc [54] 0.00 0.00 1/5 grep_malloc [67] 0.00 0.00 1/1 memchr [114] 0.00 0.00 1/6 _stat [870] ----------------------------------------------- 0.06 0.18 19969171/19969171 grep_fgetln [5] [6] 5.8 0.06 0.18 19969171 grep_fgetc [6] 0.17 0.01 19969171/19969171 fgetc [7] ----------------------------------------------- 0.17 0.01 19969171/19969171 grep_fgetc [6] [7] 4.4 0.17 0.01 19969171 fgetc [7] 0.00 0.01 153/153 __srget [13] ----------------------------------------------- 0.12 0.00 19989841/19989841 grep_fgetln [5] [8] 2.9 0.12 0.00 19989841 grep_feof [8] ----------------------------------------------- 0.00 0.00 4/163 __part_load_locale [31] 0.02 0.00 159/163 __sread [11] [9] 0.4 0.02 0.00 163 _read [9] ----------------------------------------------- 0.00 0.00 6/159 __fread [28] 0.00 0.01 153/159 __srget [13] [10] 0.4 0.00 0.02 159 __srefill [10] 0.00 0.02 159/159 _sread [12] 0.00 0.00 2/3 __smakebuf [69] ----------------------------------------------- 0.00 0.02 159/159 _sread [12] [11] 0.4 0.00 0.02 159 __sread [11] 0.02 0.00 159/163 _read [9] ----------------------------------------------- 0.00 0.02 159/159 __srefill [10] [12] 0.4 0.00 0.02 159 _sread [12] 0.00 0.02 159/159 __sread [11] ----------------------------------------------- 0.00 0.01 153/153 fgetc [7] [13] 0.4 0.00 0.01 153 __srget [13] 0.00 0.01 153/159 __srefill [10] ----------------------------------------------- [14] 0.2 0.00 0.00 re_search_internal [14] 0.00 0.00 20715/20879 malloc [17] 0.00 0.00 20670/20730 memset [20] 0.00 0.00 20759/62118 free [18] 0.00 0.00 23/52 calloc [55] ----------------------------------------------- 0.00 0.00 18/20979 realloc [50] 0.00 0.00 52/20979 calloc [55] 0.00 0.00 20909/20979 imalloc [16] [15] 0.1 0.00 0.00 20979 arena_malloc [15] 0.00 0.00 20926/20976 arena_bin_malloc_easy [21] 0.00 0.00 20979/20979 choose_arena [29] 0.00 0.00 20979/41774 malloc_spin_unlock [33] 0.00 0.00 20979/41774 malloc_spin_lock [39] 0.00 0.00 52/20730 memset [20] 0.00 0.00 50/50 arena_bin_malloc_hard [60] 0.00 0.00 3/53 arena_run_alloc [86] ----------------------------------------------- 0.00 0.00 30/20909 realloc [50] 0.00 0.00 20879/20909 malloc [17] [16] 0.1 0.00 0.00 20909 imalloc [16] 0.00 0.00 20909/20979 arena_malloc [15] ----------------------------------------------- 0.00 0.00 1/20879 regcomp [77] 0.00 0.00 1/20879 catopen [32] 0.00 0.00 2/20879 _Read_RuneMagi [38] 0.00 0.00 3/20879 __collate_load_tables [30] 0.00 0.00 3/20879 __smakebuf [69] 0.00 0.00 4/20879 create_token_tree [68] 0.00 0.00 4/20879 re_acquire_state_context [57] 0.00 0.00 4/20879 strdup [56] 0.00 0.00 4/20879 __part_load_locale [31] 0.00 0.00 5/20879 grep_malloc [67] 0.00 0.00 6/20879 re_compile_internal [34] 0.00 0.00 23/20879 re_node_set_init_1 [59] 0.00 0.00 31/20879 re_node_set_init_copy [49] 0.00 0.00 73/20879 re_node_set_alloc [53] 0.00 0.00 20715/20879 re_search_internal [14] [17] 0.1 0.00 0.00 20879 malloc [17] 0.00 0.00 20879/20909 imalloc [16] 0.00 0.00 20879/20961 malloc_init [81] ----------------------------------------------- 0.00 0.00 1/62118 fastcomp [75] 0.00 0.00 1/62118 _Read_RuneMagi [38] 0.00 0.00 2/62118 re_compile_internal [34] 0.00 0.00 2/62118 catopen [32] 0.00 0.00 3/62118 procfile [4] 0.00 0.00 3/62118 fclose [78] 0.00 0.00 5/62118 free_workarea_compile [76] 0.00 0.00 20759/62118 re_search_internal [14] 0.00 0.00 41342/62118 re_string_destruct [22] [18] 0.0 0.00 0.00 62118 free [18] 0.00 0.00 20777/20795 idalloc [19] ----------------------------------------------- 0.00 0.00 18/20795 realloc [50] 0.00 0.00 20777/20795 free [18] [19] 0.0 0.00 0.00 20795 idalloc [19] 0.00 0.00 20795/20795 arena_dalloc [25] ----------------------------------------------- 0.00 0.00 1/20730 re_compile_fastmap [79] 0.00 0.00 1/20730 snprintf [62] 0.00 0.00 1/20730 _fseeko [72] 0.00 0.00 2/20730 re_compile_internal [34] 0.00 0.00 3/20730 __sfp [74] 0.00 0.00 52/20730 arena_malloc [15] 0.00 0.00 20670/20730 re_search_internal [14] [20] 0.0 0.00 0.00 20730 memset [20] ----------------------------------------------- 0.00 0.00 50/20976 arena_bin_malloc_hard [60] 0.00 0.00 20926/20976 arena_malloc [15] [21] 0.0 0.00 0.00 20976 arena_bin_malloc_easy [21] 0.00 0.00 20976/20976 arena_run_rc_incr [26] ----------------------------------------------- [22] 0.0 0.00 0.00 re_string_destruct [22] 0.00 0.00 41342/62118 free [18] ----------------------------------------------- 0.00 0.00 6/6 setlocale [24] [23] 0.0 0.00 0.00 6 loadlocale [23] 0.00 0.00 1/1 __collate_load_tables [30] 0.00 0.00 1/1 __wrap_setrunelocale [37] 0.00 0.00 1/1 __messages_load_locale [43] 0.00 0.00 1/1 __time_load_locale [46] 0.00 0.00 1/1 __numeric_load_locale [45] 0.00 0.00 1/1 __monetary_load_locale [44] 0.00 0.00 24/45 __error_unthreaded [863] 0.00 0.00 6/14 strchr [93] 0.00 0.00 6/6 __detect_path_locale [868] 0.00 0.00 6/12 strcmp [94] 0.00 0.00 6/38 strcpy [88] ----------------------------------------------- 0.00 0.00 1/3 main [2] 0.00 0.00 1/3 nl_langinfo [35] 0.00 0.00 1/3 catopen [32] [24] 0.0 0.00 0.00 3 setlocale [24] 0.00 0.00 6/6 loadlocale [23] 0.00 0.00 18/38 strcpy [88] 0.00 0.00 6/6 __get_locale_env [869] ----------------------------------------------- 0.00 0.00 20795/20795 idalloc [19] [25] 0.0 0.00 0.00 20795 arena_dalloc [25] 0.00 0.00 20795/41774 malloc_spin_unlock [33] 0.00 0.00 20795/41774 malloc_spin_lock [39] 0.00 0.00 36/36 arena_run_dalloc [89] 0.00 0.00 3/5 arena_purge [101] 0.00 0.00 2/2 arena_chunk_tree_dirty_insert [104] ----------------------------------------------- 0.00 0.00 20976/20976 arena_bin_malloc_easy [21] [26] 0.0 0.00 0.00 20976 arena_run_rc_incr [26] ----------------------------------------------- 0.00 0.00 1/6 _Read_RuneMagi [38] 0.00 0.00 5/6 __collate_load_tables [30] [27] 0.0 0.00 0.00 6 fread [27] 0.00 0.00 6/6 __fread [28] ----------------------------------------------- 0.00 0.00 6/6 fread [27] [28] 0.0 0.00 0.00 6 __fread [28] 0.00 0.00 6/159 __srefill [10] 0.00 0.00 12/90 memcpy [41] ----------------------------------------------- 0.00 0.00 20979/20979 arena_malloc [15] [29] 0.0 0.00 0.00 20979 choose_arena [29] ----------------------------------------------- 0.00 0.00 1/1 loadlocale [23] [30] 0.0 0.00 0.00 1 __collate_load_tables [30] 0.00 0.00 5/6 fread [27] 0.00 0.00 3/20879 malloc [17] 0.00 0.00 1/3 fopen [73] 0.00 0.00 1/3 fclose [78] 0.00 0.00 2/38 strcpy [88] 0.00 0.00 1/12 strcmp [94] 0.00 0.00 1/10 strcat [95] ----------------------------------------------- 0.00 0.00 1/4 __messages_load_locale [43] 0.00 0.00 1/4 __time_load_locale [46] 0.00 0.00 1/4 __numeric_load_locale [45] 0.00 0.00 1/4 __monetary_load_locale [44] [31] 0.0 0.00 0.00 4 __part_load_locale [31] 0.00 0.00 4/163 _read [9] 0.00 0.00 4/20879 malloc [17] 0.00 0.00 8/38 strcpy [88] 0.00 0.00 8/10 strcat [95] 0.00 0.00 4/7 open [99] 0.00 0.00 4/8 _fstat [866] 0.00 0.00 4/7 __sys_close [867] ----------------------------------------------- 0.00 0.00 1/1 main [2] [32] 0.0 0.00 0.00 1 catopen [32] 0.00 0.00 1/3 setlocale [24] 0.00 0.00 4/4 strdup [56] 0.00 0.00 1/20879 malloc [17] 0.00 0.00 2/62118 free [18] 0.00 0.00 8/10 strlcpy [96] 0.00 0.00 6/14 strchr [93] 0.00 0.00 5/5 strsep [103] 0.00 0.00 4/6 _stat [870] 0.00 0.00 2/45 __error_unthreaded [863] 0.00 0.00 1/23 getenv [90] ----------------------------------------------- 0.00 0.00 20795/41774 arena_dalloc [25] 0.00 0.00 20979/41774 arena_malloc [15] [33] 0.0 0.00 0.00 41774 malloc_spin_unlock [33] ----------------------------------------------- [34] 0.0 0.00 0.00 re_compile_internal [34] 0.00 0.00 1/1 nl_langinfo [35] 0.00 0.00 6/20879 malloc [17] 0.00 0.00 1/48 realloc [50] 0.00 0.00 1/52 calloc [55] 0.00 0.00 2/20730 memset [20] 0.00 0.00 2/62118 free [18] 0.00 0.00 1/1 strcasecmp [116] ----------------------------------------------- 0.00 0.00 1/1 re_compile_internal [34] [35] 0.0 0.00 0.00 1 nl_langinfo [35] 0.00 0.00 1/3 setlocale [24] 0.00 0.00 1/14 strchr [93] ----------------------------------------------- [36] 0.0 0.00 0.00 regexec [36] ----------------------------------------------- 0.00 0.00 1/1 loadlocale [23] [37] 0.0 0.00 0.00 1 __wrap_setrunelocale [37] 0.00 0.00 1/1 _Read_RuneMagi [38] 0.00 0.00 1/3 fopen [73] 0.00 0.00 1/3 fclose [78] 0.00 0.00 2/38 strcpy [88] 0.00 0.00 1/10 strcat [95] 0.00 0.00 1/1 _UTF8_init [880] ----------------------------------------------- 0.00 0.00 1/1 __wrap_setrunelocale [37] [38] 0.0 0.00 0.00 1 _Read_RuneMagi [38] 0.00 0.00 1/6 fread [27] 0.00 0.00 1/90 memcpy [41] 0.00 0.00 2/20879 malloc [17] 0.00 0.00 1/1 rewind [71] 0.00 0.00 1/62118 free [18] 0.00 0.00 2/45 __error_unthreaded [863] 0.00 0.00 1/8 _fstat [866] ----------------------------------------------- 0.00 0.00 20795/41774 arena_dalloc [25] 0.00 0.00 20979/41774 arena_malloc [15] [39] 0.0 0.00 0.00 41774 malloc_spin_lock [39] ----------------------------------------------- [40] 0.0 0.00 0.00 re_string_realloc_buffers [40] 0.00 0.00 1/48 realloc [50] ----------------------------------------------- 0.00 0.00 1/90 _Read_RuneMagi [38] 0.00 0.00 1/90 __sfvwrite [64] 0.00 0.00 4/90 strdup [56] 0.00 0.00 12/90 __fread [28] 0.00 0.00 18/90 realloc [50] 0.00 0.00 23/90 re_node_set_merge [51] 0.00 0.00 31/90 re_node_set_init_copy [49] [41] 0.0 0.00 0.00 90 memcpy [41] ----------------------------------------------- [42] 0.0 0.00 0.00 re_string_construct_common [42] ----------------------------------------------- 0.00 0.00 1/1 loadlocale [23] [43] 0.0 0.00 0.00 1 __messages_load_locale [43] 0.00 0.00 1/4 __part_load_locale [31] ----------------------------------------------- 0.00 0.00 1/1 loadlocale [23] [44] 0.0 0.00 0.00 1 __monetary_load_locale [44] 0.00 0.00 1/4 __part_load_locale [31] 0.00 0.00 8/8 cnv [97] 0.00 0.00 1/2 __fix_locale_grouping_str [874] ----------------------------------------------- 0.00 0.00 1/1 loadlocale [23] [45] 0.0 0.00 0.00 1 __numeric_load_locale [45] 0.00 0.00 1/4 __part_load_locale [31] 0.00 0.00 1/2 __fix_locale_grouping_str [874] ----------------------------------------------- 0.00 0.00 1/1 loadlocale [23] [46] 0.0 0.00 0.00 1 __time_load_locale [46] 0.00 0.00 1/4 __part_load_locale [31] ----------------------------------------------- [47] 0.0 0.00 0.00 arenas_extend [47] ----------------------------------------------- [48] 0.0 0.00 0.00 _malloc_postfork [48] ----------------------------------------------- [49] 0.0 0.00 0.00 re_node_set_init_copy [49] 0.00 0.00 31/90 memcpy [41] 0.00 0.00 31/20879 malloc [17] ----------------------------------------------- 0.00 0.00 1/48 re_string_realloc_buffers [40] 0.00 0.00 1/48 re_compile_internal [34] 0.00 0.00 5/48 re_dfa_add_node [58] 0.00 0.00 15/48 grep_realloc [54] 0.00 0.00 26/48 register_state [52] [50] 0.0 0.00 0.00 48 realloc [50] 0.00 0.00 18/90 memcpy [41] 0.00 0.00 30/20909 imalloc [16] 0.00 0.00 18/20979 arena_malloc [15] 0.00 0.00 18/20795 idalloc [19] 0.00 0.00 30/20961 malloc_init [81] 0.00 0.00 18/18 isalloc [92] ----------------------------------------------- [51] 0.0 0.00 0.00 re_node_set_merge [51] 0.00 0.00 23/90 memcpy [41] ----------------------------------------------- [52] 0.0 0.00 0.00 register_state [52] 0.00 0.00 26/48 realloc [50] ----------------------------------------------- [53] 0.0 0.00 0.00 re_node_set_alloc [53] 0.00 0.00 73/20879 malloc [17] ----------------------------------------------- 0.00 0.00 1/15 add_pattern [66] 0.00 0.00 14/15 grep_fgetln [5] [54] 0.0 0.00 0.00 15 grep_realloc [54] 0.00 0.00 15/48 realloc [50] ----------------------------------------------- 0.00 0.00 1/52 re_compile_internal [34] 0.00 0.00 2/52 grep_calloc [70] 0.00 0.00 23/52 re_search_internal [14] 0.00 0.00 26/52 re_acquire_state_context [57] [55] 0.0 0.00 0.00 52 calloc [55] 0.00 0.00 52/20979 arena_malloc [15] 0.00 0.00 52/20961 malloc_init [81] ----------------------------------------------- 0.00 0.00 4/4 catopen [32] [56] 0.0 0.00 0.00 4 strdup [56] 0.00 0.00 4/90 memcpy [41] 0.00 0.00 4/20879 malloc [17] ----------------------------------------------- [57] 0.0 0.00 0.00 re_acquire_state_context [57] 0.00 0.00 26/52 calloc [55] 0.00 0.00 4/20879 malloc [17] ----------------------------------------------- [58] 0.0 0.00 0.00 re_dfa_add_node [58] 0.00 0.00 5/48 realloc [50] ----------------------------------------------- [59] 0.0 0.00 0.00 re_node_set_init_1 [59] 0.00 0.00 23/20879 malloc [17] ----------------------------------------------- 0.00 0.00 50/50 arena_malloc [15] [60] 0.0 0.00 0.00 50 arena_bin_malloc_hard [60] 0.00 0.00 50/20976 arena_bin_malloc_easy [21] 0.00 0.00 50/53 arena_run_alloc [86] ----------------------------------------------- 0.00 0.00 1/1 procfile [4] [61] 0.0 0.00 0.00 1 grep_open [61] 0.00 0.00 1/1 snprintf [62] 0.00 0.00 1/5 grep_malloc [67] 0.00 0.00 1/3 fopen [73] ----------------------------------------------- 0.00 0.00 1/1 grep_open [61] [62] 0.0 0.00 0.00 1 snprintf [62] 0.00 0.00 1/1 __vfprintf [65] 0.00 0.00 1/20730 memset [20] ----------------------------------------------- 0.00 0.00 2/2 __vfprintf [65] [63] 0.0 0.00 0.00 2 __sprint [63] 0.00 0.00 1/1 __sfvwrite [64] ----------------------------------------------- 0.00 0.00 1/1 __sprint [63] [64] 0.0 0.00 0.00 1 __sfvwrite [64] 0.00 0.00 1/90 memcpy [41] ----------------------------------------------- 0.00 0.00 1/1 snprintf [62] [65] 0.0 0.00 0.00 1 __vfprintf [65] 0.00 0.00 2/2 __sprint [63] 0.00 0.00 1/1 localeconv [113] ----------------------------------------------- 0.00 0.00 1/1 main [2] [66] 0.0 0.00 0.00 1 add_pattern [66] 0.00 0.00 1/15 grep_realloc [54] 0.00 0.00 1/5 grep_malloc [67] 0.00 0.00 1/10 strlcpy [96] ----------------------------------------------- 0.00 0.00 1/5 fastcomp [75] 0.00 0.00 1/5 grep_open [61] 0.00 0.00 1/5 grep_fgetln [5] 0.00 0.00 1/5 add_pattern [66] 0.00 0.00 1/5 procfile [4] [67] 0.0 0.00 0.00 5 grep_malloc [67] 0.00 0.00 5/20879 malloc [17] ----------------------------------------------- [68] 0.0 0.00 0.00 create_token_tree [68] 0.00 0.00 4/20879 malloc [17] ----------------------------------------------- 0.00 0.00 1/3 _fseeko [72] 0.00 0.00 2/3 __srefill [10] [69] 0.0 0.00 0.00 3 __smakebuf [69] 0.00 0.00 3/20879 malloc [17] 0.00 0.00 3/3 __swhatbuf [873] ----------------------------------------------- 0.00 0.00 2/2 main [2] [70] 0.0 0.00 0.00 2 grep_calloc [70] 0.00 0.00 2/52 calloc [55] ----------------------------------------------- 0.00 0.00 1/1 _Read_RuneMagi [38] [71] 0.0 0.00 0.00 1 rewind [71] 0.00 0.00 1/1 _fseeko [72] 0.00 0.00 2/45 __error_unthreaded [863] ----------------------------------------------- 0.00 0.00 1/1 rewind [71] [72] 0.0 0.00 0.00 1 _fseeko [72] 0.00 0.00 1/3 __smakebuf [69] 0.00 0.00 1/20730 memset [20] 0.00 0.00 1/2 _sseek [879] 0.00 0.00 1/1 _ftello [888] ----------------------------------------------- 0.00 0.00 1/3 grep_open [61] 0.00 0.00 1/3 __wrap_setrunelocale [37] 0.00 0.00 1/3 __collate_load_tables [30] [73] 0.0 0.00 0.00 3 fopen [73] 0.00 0.00 3/3 __sfp [74] 0.00 0.00 3/3 __sflags [872] 0.00 0.00 3/7 open [99] ----------------------------------------------- 0.00 0.00 3/3 fopen [73] [74] 0.0 0.00 0.00 3 __sfp [74] 0.00 0.00 3/20730 memset [20] 0.00 0.00 1/1 __sinit [887] ----------------------------------------------- 0.00 0.00 1/1 main [2] [75] 0.0 0.00 0.00 1 fastcomp [75] 0.00 0.00 1/5 grep_malloc [67] 0.00 0.00 1/62118 free [18] 0.00 0.00 1/10 strlcpy [96] ----------------------------------------------- [76] 0.0 0.00 0.00 free_workarea_compile [76] 0.00 0.00 5/62118 free [18] ----------------------------------------------- [77] 0.0 0.00 0.00 regcomp [77] 0.00 0.00 1/20879 malloc [17] ----------------------------------------------- 0.00 0.00 1/3 grep_close [80] 0.00 0.00 1/3 __wrap_setrunelocale [37] 0.00 0.00 1/3 __collate_load_tables [30] [78] 0.0 0.00 0.00 3 fclose [78] 0.00 0.00 3/62118 free [18] 0.00 0.00 3/7 __sys_close [867] 0.00 0.00 3/3 __sclose [871] ----------------------------------------------- [79] 0.0 0.00 0.00 re_compile_fastmap [79] 0.00 0.00 1/20730 memset [20] ----------------------------------------------- 0.00 0.00 1/1 procfile [4] [80] 0.0 0.00 0.00 1 grep_close [80] 0.00 0.00 1/3 fclose [78] ----------------------------------------------- 0.00 0.00 30/20961 realloc [50] 0.00 0.00 52/20961 calloc [55] 0.00 0.00 20879/20961 malloc [17] [81] 0.0 0.00 0.00 20961 malloc_init [81] ----------------------------------------------- 0.00 0.00 870/870 getenv [90] [82] 0.0 0.00 0.00 870 strncmp [82] ----------------------------------------------- 0.00 0.00 101/358 arena_avail_tree_insert [84] 0.00 0.00 102/358 arena_run_alloc [86] 0.00 0.00 155/358 arena_avail_tree_remove [85] [83] 0.0 0.00 0.00 358 arena_avail_comp [83] ----------------------------------------------- 0.00 0.00 36/86 arena_run_dalloc [89] 0.00 0.00 50/86 arena_run_split [87] [84] 0.0 0.00 0.00 86 arena_avail_tree_insert [84] 0.00 0.00 101/358 arena_avail_comp [83] ----------------------------------------------- 0.00 0.00 31/84 arena_run_dalloc [89] 0.00 0.00 53/84 arena_run_split [87] [85] 0.0 0.00 0.00 84 arena_avail_tree_remove [85] 0.00 0.00 155/358 arena_avail_comp [83] ----------------------------------------------- 0.00 0.00 3/53 arena_malloc [15] 0.00 0.00 50/53 arena_bin_malloc_hard [60] [86] 0.0 0.00 0.00 53 arena_run_alloc [86] 0.00 0.00 102/358 arena_avail_comp [83] 0.00 0.00 53/53 arena_run_split [87] ----------------------------------------------- 0.00 0.00 53/53 arena_run_alloc [86] [87] 0.0 0.00 0.00 53 arena_run_split [87] 0.00 0.00 53/84 arena_avail_tree_remove [85] 0.00 0.00 50/86 arena_avail_tree_insert [84] ----------------------------------------------- 0.00 0.00 1/38 procfile [4] 0.00 0.00 1/38 currentlocale [111] 0.00 0.00 2/38 __wrap_setrunelocale [37] 0.00 0.00 2/38 __collate_load_tables [30] 0.00 0.00 6/38 loadlocale [23] 0.00 0.00 8/38 __part_load_locale [31] 0.00 0.00 18/38 setlocale [24] [88] 0.0 0.00 0.00 38 strcpy [88] ----------------------------------------------- 0.00 0.00 36/36 arena_dalloc [25] [89] 0.0 0.00 0.00 36 arena_run_dalloc [89] 0.00 0.00 36/86 arena_avail_tree_insert [84] 0.00 0.00 31/84 arena_avail_tree_remove [85] 0.00 0.00 2/5 arena_purge [101] ----------------------------------------------- 0.00 0.00 1/23 main [2] 0.00 0.00 1/23 catopen [32] 0.00 0.00 1/23 __detect_path_locale [868] 0.00 0.00 2/23 getopt_internal [105] 0.00 0.00 18/23 __get_locale_env [869] [90] 0.0 0.00 0.00 23 getenv [90] 0.00 0.00 870/870 strncmp [82] ----------------------------------------------- 0.00 0.00 23/23 build_wcs_buffer [192] [91] 0.0 0.00 0.00 23 mbrtowc [91] ----------------------------------------------- 0.00 0.00 18/18 realloc [50] [92] 0.0 0.00 0.00 18 isalloc [92] ----------------------------------------------- 0.00 0.00 1/14 getopt_internal [105] 0.00 0.00 1/14 nl_langinfo [35] 0.00 0.00 6/14 catopen [32] 0.00 0.00 6/14 loadlocale [23] [93] 0.0 0.00 0.00 14 strchr [93] ----------------------------------------------- 0.00 0.00 1/12 __collate_load_tables [30] 0.00 0.00 5/12 currentlocale [111] 0.00 0.00 6/12 loadlocale [23] [94] 0.0 0.00 0.00 12 strcmp [94] ----------------------------------------------- 0.00 0.00 1/10 __wrap_setrunelocale [37] 0.00 0.00 1/10 __collate_load_tables [30] 0.00 0.00 8/10 __part_load_locale [31] [95] 0.0 0.00 0.00 10 strcat [95] ----------------------------------------------- 0.00 0.00 1/10 fastcomp [75] 0.00 0.00 1/10 add_pattern [66] 0.00 0.00 8/10 catopen [32] [96] 0.0 0.00 0.00 10 strlcpy [96] ----------------------------------------------- 0.00 0.00 8/8 __monetary_load_locale [44] [97] 0.0 0.00 0.00 8 cnv [97] 0.00 0.00 8/8 strtol [98] ----------------------------------------------- 0.00 0.00 8/8 cnv [97] [98] 0.0 0.00 0.00 8 strtol [98] ----------------------------------------------- 0.00 0.00 3/7 fopen [73] 0.00 0.00 4/7 __part_load_locale [31] [99] 0.0 0.00 0.00 7 open [99] ----------------------------------------------- 5 arena_chunk_tree_dirty_iter_recurse [100] 0.00 0.00 5/5 arena_purge [101] [100] 0.0 0.00 0.00 5+5 arena_chunk_tree_dirty_iter_recurse [100] 0.00 0.00 5/5 chunks_dirty_iter_cb [102] 5 arena_chunk_tree_dirty_iter_recurse [100] ----------------------------------------------- 0.00 0.00 2/5 arena_run_dalloc [89] 0.00 0.00 3/5 arena_dalloc [25] [101] 0.0 0.00 0.00 5 arena_purge [101] 0.00 0.00 9/9 _madvise [865] 0.00 0.00 5/5 arena_chunk_tree_dirty_iter_recurse [100] 0.00 0.00 1/1 arena_chunk_tree_dirty_remove [109] ----------------------------------------------- 0.00 0.00 5/5 arena_chunk_tree_dirty_iter_recurse [100] [102] 0.0 0.00 0.00 5 chunks_dirty_iter_cb [102] ----------------------------------------------- 0.00 0.00 5/5 catopen [32] [103] 0.0 0.00 0.00 5 strsep [103] ----------------------------------------------- 0.00 0.00 2/2 arena_dalloc [25] [104] 0.0 0.00 0.00 2 arena_chunk_tree_dirty_insert [104] ----------------------------------------------- 0.00 0.00 2/2 main [2] [105] 0.0 0.00 0.00 2 getopt_internal [105] 0.00 0.00 2/23 getenv [90] 0.00 0.00 1/14 strchr [93] ----------------------------------------------- 0.00 0.00 2/2 main [2] [106] 0.0 0.00 0.00 2 getopt_long [106] ----------------------------------------------- 0.00 0.00 2/2 _sseek [879] [107] 0.0 0.00 0.00 2 lseek [107] 0.00 0.00 2/2 __getosreldate [875] ----------------------------------------------- 0.00 0.00 1/1 arena_chunk_tree_dirty_remove [109] [108] 0.0 0.00 0.00 1 arena_chunk_comp [108] ----------------------------------------------- 0.00 0.00 1/1 arena_purge [101] [109] 0.0 0.00 0.00 1 arena_chunk_tree_dirty_remove [109] 0.00 0.00 1/1 arena_chunk_comp [108] ----------------------------------------------- 0.00 0.00 1/1 main [2] [110] 0.0 0.00 0.00 1 catclose [110] 0.00 0.00 1/45 __error_unthreaded [863] ----------------------------------------------- 0.00 0.00 1/1 main [2] [111] 0.0 0.00 0.00 1 currentlocale [111] 0.00 0.00 5/12 strcmp [94] 0.00 0.00 1/38 strcpy [88] ----------------------------------------------- 0.00 0.00 1/1 main [2] [112] 0.0 0.00 0.00 1 exit [112] 0.00 0.00 1/1 __cxa_finalize [883] ----------------------------------------------- 0.00 0.00 1/1 __vfprintf [65] [113] 0.0 0.00 0.00 1 localeconv [113] 0.00 0.00 1/1 __get_current_numeric_locale [885] 0.00 0.00 1/1 __get_current_monetary_locale [884] ----------------------------------------------- 0.00 0.00 1/1 grep_fgetln [5] [114] 0.0 0.00 0.00 1 memchr [114] ----------------------------------------------- 0.00 0.00 1/1 _mcleanup (889) [115] 0.0 0.00 0.00 1 moncontrol [115] 0.00 0.00 1/1 _profil [890] ----------------------------------------------- 0.00 0.00 1/1 re_compile_internal [34] [116] 0.0 0.00 0.00 1 strcasecmp [116] ----------------------------------------------- 0.00 0.00 1/1 _mcleanup (889) [117] 0.0 0.00 0.00 1 sysctl [117] ----------------------------------------------- 0.00 0.00 1/45 catclose [110] 0.00 0.00 2/45 catopen [32] 0.00 0.00 2/45 _Read_RuneMagi [38] 0.00 0.00 2/45 rewind [71] 0.00 0.00 4/45 sbrk [727] 0.00 0.00 10/45 _sseek [879] 0.00 0.00 24/45 loadlocale [23] [863] 0.0 0.00 0.00 45 __error_unthreaded [863] ----------------------------------------------- 0.00 0.00 23/23 build_wcs_buffer [192] [864] 0.0 0.00 0.00 23 _UTF8_mbrtowc [864] ----------------------------------------------- 0.00 0.00 9/9 arena_purge [101] [865] 0.0 0.00 0.00 9 _madvise [865] ----------------------------------------------- 0.00 0.00 1/8 _Read_RuneMagi [38] 0.00 0.00 3/8 __swhatbuf [873] 0.00 0.00 4/8 __part_load_locale [31] [866] 0.0 0.00 0.00 8 _fstat [866] ----------------------------------------------- 0.00 0.00 3/7 fclose [78] 0.00 0.00 4/7 __part_load_locale [31] [867] 0.0 0.00 0.00 7 __sys_close [867] ----------------------------------------------- 0.00 0.00 6/6 loadlocale [23] [868] 0.0 0.00 0.00 6 __detect_path_locale [868] 0.00 0.00 1/23 getenv [90] ----------------------------------------------- 0.00 0.00 6/6 setlocale [24] [869] 0.0 0.00 0.00 6 __get_locale_env [869] 0.00 0.00 18/23 getenv [90] ----------------------------------------------- 0.00 0.00 1/6 grep_fgetln [5] 0.00 0.00 1/6 procfile [4] 0.00 0.00 4/6 catopen [32] [870] 0.0 0.00 0.00 6 _stat [870] ----------------------------------------------- 0.00 0.00 3/3 fclose [78] [871] 0.0 0.00 0.00 3 __sclose [871] ----------------------------------------------- 0.00 0.00 3/3 fopen [73] [872] 0.0 0.00 0.00 3 __sflags [872] ----------------------------------------------- 0.00 0.00 3/3 __smakebuf [69] [873] 0.0 0.00 0.00 3 __swhatbuf [873] 0.00 0.00 3/8 _fstat [866] ----------------------------------------------- 0.00 0.00 1/2 __numeric_load_locale [45] 0.00 0.00 1/2 __monetary_load_locale [44] [874] 0.0 0.00 0.00 2 __fix_locale_grouping_str [874] ----------------------------------------------- 0.00 0.00 2/2 lseek [107] [875] 0.0 0.00 0.00 2 __getosreldate [875] ----------------------------------------------- 0.00 0.00 2/2 _sseek [879] [876] 0.0 0.00 0.00 2 __sseek [876] ----------------------------------------------- 0.00 0.00 1/2 __guard_setup [886] 0.00 0.00 1/2 _mcleanup (889) [877] 0.0 0.00 0.00 2 __sys___sysctl [877] ----------------------------------------------- 0.00 0.00 2/2 _sseek [879] [878] 0.0 0.00 0.00 2 _lseek [878] ----------------------------------------------- 0.00 0.00 1/2 _fseeko [72] 0.00 0.00 1/2 _ftello [888] [879] 0.0 0.00 0.00 2 _sseek [879] 0.00 0.00 10/45 __error_unthreaded [863] 0.00 0.00 2/2 _lseek [878] 0.00 0.00 2/2 lseek [107] 0.00 0.00 2/2 __sseek [876] ----------------------------------------------- 0.00 0.00 1/1 __wrap_setrunelocale [37] [880] 0.0 0.00 0.00 1 _UTF8_init [880] ----------------------------------------------- 0.00 0.00 1/1 __do_global_dtors_aux [946] [881] 0.0 0.00 0.00 1 __clean_env [881] ----------------------------------------------- 0.00 0.00 1/1 __do_global_dtors_aux [946] [882] 0.0 0.00 0.00 1 __clean_env_destructor [882] ----------------------------------------------- 0.00 0.00 1/1 exit [112] [883] 0.0 0.00 0.00 1 __cxa_finalize [883] 0.00 0.00 1/1 _mcleanup (889) ----------------------------------------------- 0.00 0.00 1/1 localeconv [113] [884] 0.0 0.00 0.00 1 __get_current_monetary_locale [884] ----------------------------------------------- 0.00 0.00 1/1 localeconv [113] [885] 0.0 0.00 0.00 1 __get_current_numeric_locale [885] ----------------------------------------------- 0.00 0.00 1/1 __do_global_ctors_aux [945] [886] 0.0 0.00 0.00 1 __guard_setup [886] 0.00 0.00 1/2 __sys___sysctl [877] ----------------------------------------------- 0.00 0.00 1/1 __sfp [74] [887] 0.0 0.00 0.00 1 __sinit [887] ----------------------------------------------- 0.00 0.00 1/1 _fseeko [72] [888] 0.0 0.00 0.00 1 _ftello [888] 0.00 0.00 1/2 _sseek [879] ----------------------------------------------- 0.00 0.00 1/1 moncontrol [115] [890] 0.0 0.00 0.00 1 _profil [890] ----------------------------------------------- flat profile: % the percentage of the total running time of the time program used by this function. cumulative a running sum of the number of seconds accounted seconds for by this function and those listed above it. self the number of seconds accounted for by this seconds function alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. self the average number of milliseconds spent in this ms/call function per call, if this function is profiled, else blank. total the average number of milliseconds spent in this ms/call function and its descendents per call, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. The index shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would appear in the gprof listing if it were to be printed. granularity: each sample hit covers 4 byte(s) for 0.00% of 4.46 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 84.0 3.75 3.75 0 100.00% _mcount [1] 6.8 4.05 0.30 0 100.00% .mcount (118) 3.8 4.22 0.17 19969171 0.00 0.00 fgetc [7] 2.7 4.34 0.12 19989841 0.00 0.00 grep_feof [8] 1.3 4.40 0.06 19969171 0.00 0.00 grep_fgetc [6] 0.8 4.44 0.04 20670 0.00 0.02 grep_fgetln [5] 0.4 4.45 0.02 163 0.10 0.10 _read [9] 0.0 4.46 0.00 0 32.01% re_search_internal [14] 0.0 4.46 0.00 20730 0.00 0.00 memset [20] 0.0 4.46 0.00 20979 0.00 0.00 arena_malloc [15] 0.0 4.46 0.00 20795 0.00 0.00 arena_dalloc [25] 0.0 4.46 0.00 20976 0.00 0.00 arena_bin_malloc_easy [21] 0.0 4.46 0.00 20976 0.00 0.00 arena_run_rc_incr [26] 0.0 4.46 0.00 20979 0.00 0.00 choose_arena [29] 0.0 4.46 0.00 62118 0.00 0.00 free [18] 0.0 4.46 0.00 41774 0.00 0.00 malloc_spin_unlock [33] 0.0 4.46 0.00 1 0.37 401.83 procfile [4] 0.0 4.46 0.00 20795 0.00 0.00 idalloc [19] 0.0 4.46 0.00 0 100.00% regexec [36] 0.0 4.46 0.00 41774 0.00 0.00 malloc_spin_lock [39] 0.0 4.46 0.00 90 0.00 0.00 memcpy [41] 0.0 4.46 0.00 1 0.12 0.22 _Read_RuneMagi [38] 0.0 4.46 0.00 0 100.00% re_string_construct_common [42] 0.0 4.46 0.00 0 99.45% re_string_realloc_buffers [40] 0.0 4.46 0.00 0 100.00% _malloc_postfork [48] 0.0 4.46 0.00 0 100.00% arenas_extend [47] 0.0 4.46 0.00 20961 0.00 0.00 malloc_init [81] 0.0 4.46 0.00 20909 0.00 0.00 imalloc [16] 0.0 4.46 0.00 20879 0.00 0.00 malloc [17] 0.0 4.46 0.00 870 0.00 0.00 strncmp [82] 0.0 4.46 0.00 358 0.00 0.00 arena_avail_comp [83] 0.0 4.46 0.00 159 0.00 0.10 __sread [11] 0.0 4.46 0.00 159 0.00 0.10 __srefill [10] 0.0 4.46 0.00 159 0.00 0.10 _sread [12] 0.0 4.46 0.00 153 0.00 0.10 __srget [13] 0.0 4.46 0.00 86 0.00 0.00 arena_avail_tree_insert [84] 0.0 4.46 0.00 84 0.00 0.00 arena_avail_tree_remove [85] 0.0 4.46 0.00 53 0.00 0.00 arena_run_alloc [86] 0.0 4.46 0.00 53 0.00 0.00 arena_run_split [87] 0.0 4.46 0.00 52 0.00 0.00 calloc [55] 0.0 4.46 0.00 50 0.00 0.00 arena_bin_malloc_hard [60] 0.0 4.46 0.00 48 0.00 0.00 realloc [50] 0.0 4.46 0.00 45 0.00 0.00 __error_unthreaded [863] 0.0 4.46 0.00 38 0.00 0.00 strcpy [88] 0.0 4.46 0.00 36 0.00 0.00 arena_run_dalloc [89] 0.0 4.46 0.00 23 0.00 0.00 _UTF8_mbrtowc [864] 0.0 4.46 0.00 23 0.00 0.00 getenv [90] 0.0 4.46 0.00 23 0.00 0.00 mbrtowc [91] 0.0 4.46 0.00 18 0.00 0.00 isalloc [92] 0.0 4.46 0.00 15 0.00 0.00 grep_realloc [54] 0.0 4.46 0.00 14 0.00 0.00 strchr [93] 0.0 4.46 0.00 12 0.00 0.00 strcmp [94] 0.0 4.46 0.00 10 0.00 0.00 strcat [95] 0.0 4.46 0.00 10 0.00 0.00 strlcpy [96] 0.0 4.46 0.00 9 0.00 0.00 _madvise [865] 0.0 4.46 0.00 8 0.00 0.00 _fstat [866] 0.0 4.46 0.00 8 0.00 0.00 cnv [97] 0.0 4.46 0.00 8 0.00 0.00 strtol [98] 0.0 4.46 0.00 7 0.00 0.00 __sys_close [867] 0.0 4.46 0.00 7 0.00 0.00 open [99] 0.0 4.46 0.00 6 0.00 0.00 __detect_path_locale [868] 0.0 4.46 0.00 6 0.00 0.10 __fread [28] 0.0 4.46 0.00 6 0.00 0.00 __get_locale_env [869] 0.0 4.46 0.00 6 0.00 0.00 _stat [870] 0.0 4.46 0.00 6 0.00 0.10 fread [27] 0.0 4.46 0.00 6 0.00 0.18 loadlocale [23] 0.0 4.46 0.00 5 0.00 0.00 arena_chunk_tree_dirty_iter_recurse [100] 0.0 4.46 0.00 5 0.00 0.00 arena_purge [101] 0.0 4.46 0.00 5 0.00 0.00 chunks_dirty_iter_cb [102] 0.0 4.46 0.00 5 0.00 0.00 grep_malloc [67] 0.0 4.46 0.00 5 0.00 0.00 strsep [103] 0.0 4.46 0.00 4 0.00 0.10 __part_load_locale [31] 0.0 4.46 0.00 4 0.00 0.00 strdup [56] 0.0 4.46 0.00 3 0.00 0.00 __sclose [871] 0.0 4.46 0.00 3 0.00 0.00 __sflags [872] 0.0 4.46 0.00 3 0.00 0.00 __sfp [74] 0.0 4.46 0.00 3 0.00 0.00 __smakebuf [69] 0.0 4.46 0.00 3 0.00 0.00 __swhatbuf [873] 0.0 4.46 0.00 3 0.00 0.00 fclose [78] 0.0 4.46 0.00 3 0.00 0.00 fopen [73] 0.0 4.46 0.00 3 0.00 0.37 setlocale [24] 0.0 4.46 0.00 2 0.00 0.00 __fix_locale_grouping_str [874] 0.0 4.46 0.00 2 0.00 0.00 __getosreldate [875] 0.0 4.46 0.00 2 0.00 0.00 __sprint [63] 0.0 4.46 0.00 2 0.00 0.00 __sseek [876] 0.0 4.46 0.00 2 0.00 0.00 __sys___sysctl [877] 0.0 4.46 0.00 2 0.00 0.00 _lseek [878] 0.0 4.46 0.00 2 0.00 0.00 _sseek [879] 0.0 4.46 0.00 2 0.00 0.00 arena_chunk_tree_dirty_insert [104] 0.0 4.46 0.00 2 0.00 0.00 getopt_internal [105] 0.0 4.46 0.00 2 0.00 0.00 getopt_long [106] 0.0 4.46 0.00 2 0.00 0.00 grep_calloc [70] 0.0 4.46 0.00 2 0.00 0.00 lseek [107] 0.0 4.46 0.00 1 0.00 0.00 _UTF8_init [880] 0.0 4.46 0.00 1 0.00 0.00 __clean_env [881] 0.0 4.46 0.00 1 0.00 0.00 __clean_env_destructor [882] 0.0 4.46 0.00 1 0.00 0.49 __collate_load_tables [30] 0.0 4.46 0.00 1 0.00 0.00 __cxa_finalize [883] 0.0 4.46 0.00 1 0.00 0.00 __get_current_monetary_locale [884] 0.0 4.46 0.00 1 0.00 0.00 __get_current_numeric_locale [885] 0.0 4.46 0.00 1 0.00 0.00 __guard_setup [886] 0.0 4.46 0.00 1 0.00 0.10 __messages_load_locale [43] 0.0 4.46 0.00 1 0.00 0.10 __monetary_load_locale [44] 0.0 4.46 0.00 1 0.00 0.10 __numeric_load_locale [45] 0.0 4.46 0.00 1 0.00 0.00 __sfvwrite [64] 0.0 4.46 0.00 1 0.00 0.00 __sinit [887] 0.0 4.46 0.00 1 0.00 0.10 __time_load_locale [46] 0.0 4.46 0.00 1 0.00 0.00 __vfprintf [65] 0.0 4.46 0.00 1 0.00 0.22 __wrap_setrunelocale [37] 0.0 4.46 0.00 1 0.00 0.00 _fseeko [72] 0.0 4.46 0.00 1 0.00 0.00 _ftello [888] 0.0 4.46 0.00 1 0.00 0.00 _mcleanup (889) 0.0 4.46 0.00 1 0.00 0.00 _profil [890] 0.0 4.46 0.00 1 0.00 0.00 add_pattern [66] 0.0 4.46 0.00 1 0.00 0.00 arena_chunk_comp [108] 0.0 4.46 0.00 1 0.00 0.00 arena_chunk_tree_dirty_remove [109] 0.0 4.46 0.00 1 0.00 0.00 catclose [110] 0.0 4.46 0.00 1 0.00 0.37 catopen [32] 0.0 4.46 0.00 1 0.00 0.00 currentlocale [111] 0.0 4.46 0.00 1 0.00 0.00 exit [112] 0.0 4.46 0.00 1 0.00 0.00 fastcomp [75] 0.0 4.46 0.00 1 0.00 0.00 grep_close [80] 0.0 4.46 0.00 1 0.00 0.00 grep_open [61] 0.0 4.46 0.00 1 0.00 0.00 localeconv [113] 0.0 4.46 0.00 1 0.00 402.58 main [2] 0.0 4.46 0.00 1 0.00 0.00 memchr [114] 0.0 4.46 0.00 1 0.00 0.00 moncontrol [115] 0.0 4.46 0.00 1 0.00 0.37 nl_langinfo [35] 0.0 4.46 0.00 1 0.00 0.00 rewind [71] 0.0 4.46 0.00 1 0.00 0.00 snprintf [62] 0.0 4.46 0.00 1 0.00 0.00 strcasecmp [116] 0.0 4.46 0.00 1 0.00 0.00 sysctl [117] 0.0 4.46 0.00 0 0.00% _start [3] 0.0 4.46 0.00 0 0.00% create_token_tree [68] 0.0 4.46 0.00 0 0.00% free_workarea_compile [76] 0.0 4.46 0.00 0 0.00% re_acquire_state_context [57] 0.0 4.46 0.00 0 0.00% re_compile_fastmap [79] 0.0 4.46 0.00 0 0.00% re_compile_internal [34] 0.0 4.46 0.00 0 0.00% re_dfa_add_node [58] 0.0 4.46 0.00 0 0.00% re_node_set_alloc [53] 0.0 4.46 0.00 0 0.00% re_node_set_init_1 [59] 0.0 4.46 0.00 0 0.00% re_node_set_init_copy [49] 0.0 4.46 0.00 0 0.00% re_node_set_merge [51] 0.0 4.46 0.00 0 0.00% re_string_destruct [22] 0.0 4.46 0.00 0 0.00% regcomp [77] 0.0 4.46 0.00 0 0.00% register_state [52] Index by function name (118) .mcount (889) _mcleanup [8] grep_feof [38] _Read_RuneMagi [1] _mcount [6] grep_fgetc [880] _UTF8_init [890] _profil [5] grep_fgetln [864] _UTF8_mbrtowc [9] _read [67] grep_malloc [881] __clean_env [12] _sread [61] grep_open [882] __clean_env_destruc [879] _sseek [54] grep_realloc [30] __collate_load_tabl [870] _stat [19] idalloc [883] __cxa_finalize [66] add_pattern [16] imalloc [868] __detect_path_local [83] arena_avail_comp [92] isalloc [863] __error_unthreaded [84] arena_avail_tree_in [23] loadlocale [874] __fix_locale_groupi [85] arena_avail_tree_re [113] localeconv [28] __fread [21] arena_bin_malloc_ea [107] lseek [884] __get_current_monet [60] arena_bin_malloc_ha [2] main [885] __get_current_numer [108] arena_chunk_comp [17] malloc [869] __get_locale_env [104] arena_chunk_tree_di [81] malloc_init [875] __getosreldate [100] arena_chunk_tree_di [39] malloc_spin_lock [886] __guard_setup [109] arena_chunk_tree_di [33] malloc_spin_unlock [43] __messages_load_loc [25] arena_dalloc [91] mbrtowc [44] __monetary_load_loc [15] arena_malloc [114] memchr [45] __numeric_load_loca [101] arena_purge [41] memcpy [31] __part_load_locale [86] arena_run_alloc [20] memset [871] __sclose [89] arena_run_dalloc [115] moncontrol [872] __sflags [26] arena_run_rc_incr [35] nl_langinfo [74] __sfp [87] arena_run_split [99] open [64] __sfvwrite [47] arenas_extend [4] procfile [887] __sinit [55] calloc [14] re_search_internal [69] __smakebuf [110] catclose [42] re_string_construct [63] __sprint [32] catopen [40] re_string_realloc_b [11] __sread [29] choose_arena [50] realloc [10] __srefill [102] chunks_dirty_iter_c [36] regexec [13] __srget [97] cnv [71] rewind [876] __sseek [111] currentlocale [24] setlocale [873] __swhatbuf [112] exit [62] snprintf [877] __sys___sysctl [75] fastcomp [116] strcasecmp [867] __sys_close [78] fclose [95] strcat [46] __time_load_locale [7] fgetc [93] strchr [65] __vfprintf [73] fopen [94] strcmp [37] __wrap_setrunelocal [27] fread [88] strcpy [72] _fseeko [18] free [56] strdup [866] _fstat [90] getenv [96] strlcpy [888] _ftello [105] getopt_internal [82] strncmp [878] _lseek [106] getopt_long [103] strsep [865] _madvise [70] grep_calloc [98] strtol [48] _malloc_postfork [80] grep_close [117] sysctl --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 19:14:12 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82708106564A; Sun, 15 Aug 2010 19:14:12 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0858FC17; Sun, 15 Aug 2010 19:14:12 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 42C411FFC34; Sun, 15 Aug 2010 19:14:11 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 175DF8452D; Sun, 15 Aug 2010 21:14:11 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> Date: Sun, 15 Aug 2010 21:14:10 +0200 In-Reply-To: (Sean C. Farley's message of "Fri, 13 Aug 2010 10:41:35 -0500 (CDT)") Message-ID: <86y6c7bse5.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Gabor Kovesdan , current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 19:14:12 -0000 "Sean C. Farley" writes: > This should trim some time off BSD grep. Did you actually test your patch? It makes absolutely no measurable difference. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 19:49:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACE3610656A3; Sun, 15 Aug 2010 19:49:40 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D197B8FC0A; Sun, 15 Aug 2010 19:49:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:6403:24ec:96ef:bc90] (unknown [IPv6:2001:7b8:3a7:0:6403:24ec:96ef:bc90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A72EE5C43; Sun, 15 Aug 2010 21:49:38 +0200 (CEST) Message-ID: <4C6844D8.5070602@andric.com> Date: Sun, 15 Aug 2010 21:49:44 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> In-Reply-To: <8639ufd78w.fsf@ds4.des.no> Content-Type: multipart/mixed; boundary="------------010000040108020607000907" Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 19:49:40 -0000 This is a multi-part message in MIME format. --------------010000040108020607000907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2010-08-15 21:07, Dag-Erling Sm=C3=B8rgrav wrote: > I built a profiling version of BSD grep and ran it with a regexp that > matches only the very last line in (my copy of) INDEX-9. The results > are pretty clear: [I also did precisely that, and I just read your mail when I was composing the following... :) ] I had a look at Doug Barton's time trial script for GNU and BSD grep, and decided to profile both greps a bit. This gave some interesting results. I started with GNU grep, doing approximately the same search as in Doug's trial, e.g. grep -m1 "|/usr/ports/x11-wm/xfce4-wm|", but I made the testfile 373491 lines instead of the original 21971, with the only matching line as the last one. The GNU grep top called functions are (please ignore the .mcount entry, which is a gprof side effect): % cumulative self self total =20 time seconds seconds calls ms/call ms/call name =20 99.1 0.59 0.59 11497 0.05 0.05 read [5] 0.6 0.59 0.00 11497 0.00 0.00 kwsexec [8] 0.1 0.59 0.00 0 100.00% .mcount (130) 0.1 0.59 0.00 1 0.62 594.77 grepfile [3] 0.1 0.60 0.00 11496 0.00 0.00 memmove [9] 0.0 0.60 0.00 4 0.03 0.03 memchr [10] 0.0 0.60 0.00 12541 0.00 0.00 memset [16] 0.0 0.60 0.00 11497 0.00 0.00 EGexecute [7] 0.0 0.60 0.00 11497 0.00 0.05 fillbuf [4] 0.0 0.60 0.00 11497 0.00 0.00 grepbuf [6] The same exercise with BSD grep indeed runs *much* slower, and its top called functions are: % cumulative self self total =20 time seconds seconds calls ms/call ms/call name =20 67.3 8.60 8.60 0 100.00% .mcount (105) 22.2 11.44 2.84 22778 0.12 0.12 __sys_read [9] 3.6 11.91 0.46 373553797 0.00 0.00 grep_feof [11] 3.5 12.35 0.45 373180306 0.00 0.00 fgetc [6] 2.1 12.63 0.27 373180306 0.00 0.00 grep_fgetc [5] 1.2 12.78 0.15 373491 0.00 0.01 grep_fgetln [4] 0.0 12.78 0.01 464 0.01 0.01 memset [12] 0.0 12.79 0.00 1 2.83 4184.69 procfile [3] 0.0 12.79 0.00 5 0.42 0.69 free [14] 0.0 12.79 0.00 22778 0.00 0.00 __sread [607] The testfile has 373180306 bytes, so you can see there is a tremendous overhead in calling grep_fgetc, grep_feof and fgetc, which is done separately for EACH byte in the file! So my first quick fix attempt was to replace the home-grown grep_fgetln with fgetln(3), which is in libc. This does not support gzip and bzip2 files, but just to prove the point, it is enough. It gave the following profiling result: % cumulative self self total =20 time seconds seconds calls ms/call ms/call name =20 80.0 0.68 0.68 5695 0.12 0.12 read [5] 15.5 0.81 0.13 379178 0.00 0.00 memchr [8] 3.2 0.83 0.03 0 100.00% .mcount (102) 0.6 0.84 0.00 451 0.01 0.01 memset [9] 0.4 0.84 0.00 5 0.59 0.85 free [10] 0.1 0.84 0.00 1 1.23 814.47 procfile [3] 0.1 0.84 0.00 373491 0.00 0.00 fgetln [4] 0.0 0.84 0.00 373491 0.00 0.00 grep_fgetln [29] 0.0 0.84 0.00 11379 0.00 0.00 memcpy [30] 0.0 0.84 0.00 50 0.00 0.00 arena_run_alloc [36= ] You can see there is much less overhead, and it is the regular read() function that gets the most calls, though not yet as much as with GNU grep. However, this already gave MUCH better runtimes with Doug's trial script: GNU grep Elapsed time: 57 seconds BSD grep (original) Elapsed time: 820 seconds (~14.4x slower than GNU grep) BSD grep (quickfixed) Elapsed time: 115 seconds (~2.0x slower than GNU grep) It proves that getting rid of the fgetc's is certainly worthwhile, and I have attached a more complete patch that: - Replaces the horrendously inefficient grep_fgetln() with mostly the same implementation as the libc fgetln() function. - Uses plain file descriptors instead of struct FILE, since the buffering is done manually anyway, and it makes it easier to support gzip and bzip2. - Let the bzip2 reader just read the file as plain data, when the initial magic number doesn't match, mimicking the behaviour of GNU grep. There is probably more room for optimization, but let's see if this survives a bunch of tests first. :) --------------010000040108020607000907 Content-Type: text/plain; name="bsdgrep-speed-1.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bsdgrep-speed-1.diff" ZGlmZiAtLWdpdCBhL3Vzci5iaW4vZ3JlcC9mYXN0Z3JlcC5jIGIvdXNyLmJpbi9ncmVwL2Zh c3RncmVwLmMKaW5kZXggNTIzOWEwZS4uMjQwNWVkOCAxMDA2NDQKLS0tIGEvdXNyLmJpbi9n cmVwL2Zhc3RncmVwLmMKKysrIGIvdXNyLmJpbi9ncmVwL2Zhc3RncmVwLmMKQEAgLTE5OCw3 ICsxOTgsNyBAQCBmYXN0Y29tcChmYXN0Z3JlcF90ICpmZywgY29uc3QgY2hhciAqcGF0KQog fQogCiBpbnQKLWdyZXBfc2VhcmNoKGZhc3RncmVwX3QgKmZnLCB1bnNpZ25lZCBjaGFyICpk YXRhLCBzaXplX3QgbGVuLCByZWdtYXRjaF90ICpwbWF0Y2gpCitncmVwX3NlYXJjaChmYXN0 Z3JlcF90ICpmZywgY29uc3QgdW5zaWduZWQgY2hhciAqZGF0YSwgc2l6ZV90IGxlbiwgcmVn bWF0Y2hfdCAqcG1hdGNoKQogewogCXVuc2lnbmVkIGludCBqOwogCWludCByZXQgPSBSRUdf Tk9NQVRDSDsKZGlmZiAtLWdpdCBhL3Vzci5iaW4vZ3JlcC9maWxlLmMgYi91c3IuYmluL2dy ZXAvZmlsZS5jCmluZGV4IGM0ZGU3ZGIuLmE3ZTNiZjAgMTAwNjQ0Ci0tLSBhL3Vzci5iaW4v Z3JlcC9maWxlLmMKKysrIGIvdXNyLmJpbi9ncmVwL2ZpbGUuYwpAQCAtMzcsNyArMzcsNyBA QCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8YnpsaWIuaD4KICNpbmNsdWRl IDxlcnIuaD4KICNpbmNsdWRlIDxlcnJuby5oPgotI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5j bHVkZSA8ZmNudGwuaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxzdHJpbmcu aD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KQEAgLTQ3LDEzMyArNDcsMTU5IEBAIF9fRkJTRElE KCIkRnJlZUJTRCQiKTsKIAogI2luY2x1ZGUgImdyZXAuaCIKIAotc3RhdGljIGNoYXIJIGZu YW1lW01BWFBBVEhMRU5dOwkvKiBmaWxlIG5hbWUgKi8KKyNkZWZpbmUJTUFYQlVGU0laCSgz MiAqIDEwMjQpCisjZGVmaW5lCUxOQlVGQlVNUAk4MAogCi0jZGVmaW5lCQkgTUFYQlVGU0la CSgxNiAqIDEwMjQpCi0jZGVmaW5lCQkgUFJFUkVBRF9NCTAuMgorc3RhdGljIGd6RmlsZSBn emJ1ZmRlc2M7CitzdGF0aWMgQlpGSUxFKiBiemJ1ZmRlc2M7CiAKLS8qIFNvbWUgZ2xvYmFs IHZhcmlhYmxlcyBmb3IgdGhlIGJ1ZmZlcmluZyBhbmQgcmVhZGluZy4gKi8KLXN0YXRpYyBj aGFyCSpsbmJ1ZjsKLXN0YXRpYyBzaXplX3QJIGxuYnVmbGVuOwotc3RhdGljIHVuc2lnbmVk IGNoYXIgKmJpbmJ1ZjsKLXN0YXRpYyBpbnQJIGJpbmJ1ZnNpejsKLXVuc2lnbmVkIGNoYXIJ KmJpbmJ1ZnB0cjsKLXN0YXRpYyBpbnQJIGJ6ZXJyOworc3RhdGljIHVuc2lnbmVkIGNoYXIg YnVmZmVyW01BWEJVRlNJWl07CitzdGF0aWMgdW5zaWduZWQgY2hhciAqYnVmcG9zOworc3Rh dGljIHNpemVfdCBidWZyZW07CiAKLSNkZWZpbmUgaXN3YmluYXJ5KGNoKQkoIWlzd3NwYWNl KChjaCkpICYmIGlzd2NudHJsKChjaCkpICYmIFwKLQkJCSAgICAoY2ggIT0gTCdcYicpICYm IChjaCAhPSBMJ1wwJykpCitzdGF0aWMgdW5zaWduZWQgY2hhciAqbG5idWY7CitzdGF0aWMg c2l6ZV90IGxuYnVmbGVuOwogCi0vKgotICogUmV0dXJucyBhIHNpbmdsZSBjaGFyYWN0ZXIg YWNjb3JkaW5nIHRvIHRoZSBmaWxlIHR5cGUuCi0gKiBSZXR1cm5zIC0xIG9uIGZhaWx1cmUu Ci0gKi8KLWludAotZ3JlcF9mZ2V0YyhzdHJ1Y3QgZmlsZSAqZikKK3N0YXRpYyBpbnQKK2dy ZXBfcmVmaWxsKHN0cnVjdCBmaWxlICpmKQogewotCXVuc2lnbmVkIGNoYXIgYzsKLQotCXN3 aXRjaCAoZmlsZWJlaGF2ZSkgewotCWNhc2UgRklMRV9TVERJTzoKLQkJcmV0dXJuIChmZ2V0 YyhmLT5mKSk7Ci0JY2FzZSBGSUxFX0daSVA6Ci0JCXJldHVybiAoZ3pnZXRjKGYtPmd6Zikp OwotCWNhc2UgRklMRV9CWklQOgotCQlCWjJfYnpSZWFkKCZiemVyciwgZi0+YnpmLCAmYywg MSk7Ci0JCWlmIChiemVyciA9PSBCWl9TVFJFQU1fRU5EKQotCQkJcmV0dXJuICgtMSk7Ci0J CWVsc2UgaWYgKGJ6ZXJyICE9IEJaX1NFUVVFTkNFX0VSUk9SICYmIGJ6ZXJyICE9IEJaX09L KQotCQkJZXJyeCgyLCAiJXMiLCBnZXRzdHIoMikpOwotCQlyZXR1cm4gKGMpOworCXNzaXpl X3QgbnI7CisJaW50IGJ6ZXJyOworCisJYnVmcG9zID0gYnVmZmVyOworCWJ1ZnJlbSA9IDA7 CisKKwlpZiAoZmlsZWJlaGF2ZSA9PSBGSUxFX0daSVApIHsKKwkJbnIgPSBnenJlYWQoZ3pi dWZkZXNjLCBidWZmZXIsIE1BWEJVRlNJWik7CisJfSBlbHNlIGlmIChmaWxlYmVoYXZlID09 IEZJTEVfQlpJUCAmJiBiemJ1ZmRlc2MgIT0gTlVMTCkgeworCQluciA9IEJaMl9ielJlYWQo JmJ6ZXJyLCBiemJ1ZmRlc2MsIGJ1ZmZlciwgTUFYQlVGU0laKTsKKwkJc3dpdGNoIChiemVy cikgeworCQljYXNlIEJaX09LOgorCQljYXNlIEJaX1NUUkVBTV9FTkQ6CisJCQkvKiBObyBw cm9ibGVtLCBuciB3aWxsIGJlIG9rYXkgKi8KKwkJCWJyZWFrOworCQljYXNlIEJaX0RBVEFf RVJST1JfTUFHSUM6CisJCQkvKgorCQkJICogQXMgb3Bwb3NlZCB0byBnenJlYWQoKSwgd2hp Y2ggc2ltcGx5IHJldHVybnMgdGhlCisJCQkgKiBwbGFpbiBmaWxlIGRhdGEsIGlmIGl0IGlz IG5vdCBpbiB0aGUgY29ycmVjdAorCQkJICogY29tcHJlc3NlZCBmb3JtYXQsIEJaMl9ielJl YWQoKSBpbnN0ZWFkIGFib3J0cy4KKwkJCSAqCisJCQkgKiBTbywganVzdCByZXN0YXJ0IGF0 IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGZpbGUgYWdhaW4sCisJCQkgKiBhbmQgdXNlIHBsYWlu IHJlYWRzIGZyb20gbm93IG9uLgorCQkJICovCisJCQlCWjJfYnpSZWFkQ2xvc2UoJmJ6ZXJy LCBiemJ1ZmRlc2MpOworCQkJYnpidWZkZXNjID0gTlVMTDsKKwkJCWlmIChsc2VlayhmLT5m ZCwgMCwgU0VFS19TRVQpID09IC0xKQorCQkJCXJldHVybiAoRU9GKTsKKwkJCW5yID0gcmVh ZChmLT5mZCwgYnVmZmVyLCBNQVhCVUZTSVopOworCQkJYnJlYWs7CisJCWRlZmF1bHQ6CisJ CQkvKiBNYWtlIHN1cmUgd2UgZXhpdCB3aXRoIGFuIGVycm9yICovCisJCQluciA9IC0xOwor CQl9CisJfSBlbHNlIHsKKwkJbnIgPSByZWFkKGYtPmZkLCBidWZmZXIsIE1BWEJVRlNJWik7 CiAJfQotCXJldHVybiAoLTEpOworCisJaWYgKG5yIDw9IDApCisJCXJldHVybiAoRU9GKTsK KworCWJ1ZnJlbSA9IG5yOworCXJldHVybiAoMCk7CiB9CiAKLS8qCi0gKiBSZXR1cm5zIHRy dWUgaWYgdGhlIGZpbGUgcG9zaXRpb24gaXMgYSBFT0YsIHJldHVybnMgZmFsc2UKLSAqIG90 aGVyd2lzZS4KLSAqLwotaW50Ci1ncmVwX2Zlb2Yoc3RydWN0IGZpbGUgKmYpCitzdGF0aWMg aW50CitncmVwX2xuYnVmZ3JvdyhzaXplX3QgbmV3bGVuKQogewotCi0Jc3dpdGNoIChmaWxl YmVoYXZlKSB7Ci0JY2FzZSBGSUxFX1NURElPOgotCQlyZXR1cm4gKGZlb2YoZi0+ZikpOwot CWNhc2UgRklMRV9HWklQOgotCQlyZXR1cm4gKGd6ZW9mKGYtPmd6ZikpOwotCWNhc2UgRklM RV9CWklQOgotCQlyZXR1cm4gKGJ6ZXJyID09IEJaX1NUUkVBTV9FTkQpOwotCX0KLQlyZXR1 cm4gKDEpOworCXVuc2lnbmVkIGNoYXIgKnA7CisKKwlpZiAobG5idWZsZW4gPj0gbmV3bGVu KQorCQlyZXR1cm4gKDApOworCWlmICgocCA9IHJlYWxsb2MobG5idWYsIG5ld2xlbikpID09 IE5VTEwpCisJCXJldHVybiAoRU9GKTsKKwlsbmJ1ZiA9IHA7CisJbG5idWZsZW4gPSBuZXds ZW47CisJcmV0dXJuICgwKTsKIH0KIAotLyoKLSAqIEF0IHRoZSBmaXJzdCBjYWxsLCBmaWxs cyBpbiBhbiBpbnRlcm5hbCBidWZmZXIgYW5kIGNoZWNrcyBpZiB0aGUgZ2l2ZW4KLSAqIGZp bGUgaXMgYSBiaW5hcnkgZmlsZSBhbmQgc2V0cyB0aGUgYmluYXJ5IGZsYWcgYWNjb3JkaW5n bHkuICBUaGVuIHJldHVybnMKLSAqIGEgc2luZ2xlIGxpbmUgYW5kIHNldHMgbGVuIHRvIHRo ZSBsZW5ndGggb2YgdGhlIHJldHVybmVkIGxpbmUuCi0gKiBBdCBhbnkgb3RoZXIgY2FsbCBy ZXR1cm5zIGEgc2luZ2xlIGxpbmUgZWl0aGVyIGZyb20gdGhlIGludGVybmFsIGJ1ZmZlcgot ICogb3IgZnJvbSB0aGUgZmlsZSBpZiB0aGUgYnVmZmVyIGlzIGV4aGF1c3RlZCBhbmQgc2V0 cyBsZW4gdG8gdGhlIGxlbmd0aAotICogb2YgdGhlIGxpbmUuCi0gKi8KIGNoYXIgKgotZ3Jl cF9mZ2V0bG4oc3RydWN0IGZpbGUgKmYsIHNpemVfdCAqbGVuKQorZ3JlcF9mZ2V0bG4oc3Ry dWN0IGZpbGUgKmYsIHNpemVfdCAqbGVucCkKIHsKLQlzdHJ1Y3Qgc3RhdCBzdDsKLQlzaXpl X3QgYnVmc2l6LCBpID0gMDsKLQlpbnQgY2ggPSAwOwotCi0JLyogRmlsbCBpbiB0aGUgYnVm ZmVyIGlmIGl0IGlzIGVtcHR5LiAqLwotCWlmIChiaW5idWZwdHIgPT0gTlVMTCkgewotCi0J CS8qIE9ubHkgcHJlLXJlYWQgdG8gdGhlIGJ1ZmZlciBpZiB3ZSBuZWVkIHRoZSBiaW5hcnkg Y2hlY2suICovCi0JCWlmIChiaW5iZWhhdmUgIT0gQklORklMRV9URVhUKSB7Ci0JCQlpZiAo Zi0+c3RkaW4pCi0JCQkJc3Quc3Rfc2l6ZSA9IE1BWEJVRlNJWjsKLQkJCWVsc2UgaWYgKHN0 YXQoZm5hbWUsICZzdCkgIT0gMCkKLQkJCQllcnIoMiwgTlVMTCk7Ci0KLQkJCWJ1ZnNpeiA9 IChNQVhCVUZTSVogPiAoc3Quc3Rfc2l6ZSAqIFBSRVJFQURfTSkpID8KLQkJCSAgICAoc3Qu c3Rfc2l6ZSAvIDIpIDogTUFYQlVGU0laOwotCi0JCQliaW5idWYgPSBncmVwX21hbGxvYyhz aXplb2YoY2hhcikgKiBidWZzaXopOwotCi0JCQl3aGlsZSAoaSA8IGJ1ZnNpeikgewotCQkJ CWNoID0gZ3JlcF9mZ2V0YyhmKTsKLQkJCQlpZiAoY2ggPT0gRU9GKQotCQkJCQlicmVhazsK LQkJCQliaW5idWZbaSsrXSA9IGNoOwotCQkJfQotCi0JCQlmLT5iaW5hcnkgPSBtZW1jaHIo YmluYnVmLCAoZmlsZWJlaGF2ZSAhPSBGSUxFX0daSVApID8KLQkJCSAgICAnXDAnIDogJ1wy MDAnLCBpIC0gMSkgIT0gTlVMTDsKLQkJfQotCQliaW5idWZzaXogPSBpOwotCQliaW5idWZw dHIgPSBiaW5idWY7CisJdW5zaWduZWQgY2hhciAqcDsKKwljaGFyICpyZXQ7CisJc2l6ZV90 IGxlbjsKKwlzaXplX3QgZGlmZjsKKwlzaXplX3Qgb2ZmOworCisJLyogRmlsbCB0aGUgYnVm ZmVyLCBpZiBuZWNlc3NhcnkgKi8KKwlpZiAoYnVmcmVtID09IDAgJiYgZ3JlcF9yZWZpbGwo ZikpIHsKK2Vycm9yOgorCQkqbGVucCA9IDA7CisJCXJldHVybiAoTlVMTCk7CiAJfQogCi0J LyogUmVhZCBhIGxpbmUgd2hldGhlciBmcm9tIHRoZSBidWZmZXIgb3IgZnJvbSB0aGUgZmls ZSBpdHNlbGYuICovCi0JZm9yIChpID0gMDsgIShncmVwX2Zlb2YoZikgJiYKLQkgICAgKGJp bmJ1ZnB0ciA9PSAmYmluYnVmW2JpbmJ1ZnNpel0pKTsgaSsrKSB7Ci0JCWlmIChiaW5idWZw dHIgPT0gJmJpbmJ1ZltiaW5idWZzaXpdKSB7Ci0JCQljaCA9IGdyZXBfZmdldGMoZik7Ci0J CX0gZWxzZSB7Ci0JCQljaCA9IGJpbmJ1ZnB0clswXTsKLQkJCWJpbmJ1ZnB0cisrOwotCQl9 Ci0JCWlmIChpID49IGxuYnVmbGVuKSB7Ci0JCQlsbmJ1ZmxlbiAqPSAyOwotCQkJbG5idWYg PSBncmVwX3JlYWxsb2MobG5idWYsICsrbG5idWZsZW4pOwotCQl9Ci0JCWlmICgoY2ggPT0g J1xuJykgfHwgKGNoID09IEVPRikpIHsKLQkJCWxuYnVmW2ldID0gJ1wwJzsKLQkJCWJyZWFr OwotCQl9IGVsc2UKLQkJCWxuYnVmW2ldID0gY2g7CisJLyogTG9vayBmb3IgYSBuZXdsaW5l IGluIHRoZSByZW1haW5pbmcgcGFydCBvZiB0aGUgYnVmZmVyICovCisJaWYgKChwID0gbWVt Y2hyKGJ1ZnBvcywgJ1xuJywgYnVmcmVtKSkgIT0gTlVMTCkgeworCQkrK3A7IC8qIGFkdmFu Y2Ugb3ZlciBuZXdsaW5lICovCisJCXJldCA9IGJ1ZnBvczsKKwkJbGVuID0gcCAtIGJ1ZnBv czsKKwkJYnVmcmVtIC09IGxlbjsKKwkJYnVmcG9zID0gcDsKKwkJKmxlbnAgPSBsZW47CisJ CXJldHVybiAocmV0KTsKIAl9Ci0JaWYgKGdyZXBfZmVvZihmKSAmJiAoaSA9PSAwKSAmJiAo Y2ggIT0gJ1xuJykpCisKKwkvKiBXZSBoYXZlIHRvIGNvcHkgdGhlIGN1cnJlbnQgYnVmZmVy ZWQgZGF0YSB0byB0aGUgbGluZSBidWZmZXIgKi8KKwlmb3IgKGxlbiA9IGJ1ZnJlbSwgb2Zm ID0gMDsgOyBsZW4gKz0gYnVmcmVtKSB7CisJCS8qIE1ha2Ugc3VyZSB0aGVyZSBpcyByb29t IGZvciBtb3JlIGRhdGEgKi8KKwkJaWYgKGdyZXBfbG5idWZncm93KGxlbiArIExOQlVGQlVN UCkpCisJCQlnb3RvIGVycm9yOworCQltZW1jcHkobG5idWYgKyBvZmYsIGJ1ZnBvcywgbGVu IC0gb2ZmKTsKKwkJb2ZmID0gbGVuOworCQlpZiAoZ3JlcF9yZWZpbGwoZikpCisJCQlicmVh azsgLyogRU9GIG9yIGVycm9yOiByZXR1cm4gcGFydGlhbCBsaW5lICovCisJCWlmICgocCA9 IG1lbWNocihidWZwb3MsICdcbicsIGJ1ZnJlbSkpID09IE5VTEwpCisJCQljb250aW51ZTsK KwkJLyogZ290IGl0OiBmaW5pc2ggdXAgdGhlIGxpbmUgKGxpa2UgY29kZSBhYm92ZSkgKi8K KwkJKytwOworCQlkaWZmID0gcCAtIGJ1ZnBvczsKKwkJbGVuID0rIGRpZmY7CisJCWlmIChn cmVwX2xuYnVmZ3JvdyhsZW4pKQorCQkgICAgZ290byBlcnJvcjsKKwkJbWVtY3B5KGxuYnVm ICsgb2ZmLCBidWZwb3MsIGRpZmYpOworCQlidWZyZW0gLT0gZGlmZjsKKwkJYnVmcG9zID0g cDsKKwkJYnJlYWs7CisJfQorCSpsZW5wID0gbGVuOworCXJldHVybiBsbmJ1ZjsKK30KKwor c3RhdGljIHN0cnVjdCBmaWxlICoKK2dyZXBfZmlsZV9pbml0KHN0cnVjdCBmaWxlICpmKQor eworCWlmIChmaWxlYmVoYXZlID09IEZJTEVfR1pJUCAmJgorCSAgICAoZ3pidWZkZXNjID0g Z3pkb3BlbihmLT5mZCwgInIiKSkgPT0gTlVMTCkgeworZXJyb3I6CisJCWlmICghZi0+c3Rk aW4pCisJCQljbG9zZShmLT5mZCk7CisJCWZyZWUoZik7CiAJCXJldHVybiAoTlVMTCk7Ci0J KmxlbiA9IGk7Ci0JcmV0dXJuIChsbmJ1Zik7CisJfQorCisJaWYgKGZpbGViZWhhdmUgPT0g RklMRV9CWklQICYmCisJICAgIChiemJ1ZmRlc2MgPSBCWjJfYnpkb3BlbihmLT5mZCwgInIi KSkgPT0gTlVMTCkKKwkJZ290byBlcnJvcjsKKworCS8qIEZpbGwgcmVhZCBidWZmZXIsIGFs c28gY2F0Y2hlcyBlcnJvcnMgZWFybHkgKi8KKwlpZiAoZ3JlcF9yZWZpbGwoZikpCisJCWdv dG8gZXJyb3I7CisKKwkvKiBDaGVjayBmb3IgYmluYXJ5IHN0dWZmLCBpZiBuZWNlc3Nhcnkg Ki8KKwlpZiAoYmluYmVoYXZlICE9IEJJTkZJTEVfVEVYVCAmJiBtZW1jaHIoYnVmcG9zLCAn XDAnLCBidWZyZW0pICE9IE5VTEwpCisJCWYtPmJpbmFyeSA9IHRydWU7CisKKwlyZXR1cm4g KGYpOwogfQogCiAvKgpAQCAtMTg0LDcyICsyMTAsNDUgQEAgZ3JlcF9zdGRpbl9vcGVuKHZv aWQpCiB7CiAJc3RydWN0IGZpbGUgKmY7CiAKLQlzbnByaW50ZihmbmFtZSwgc2l6ZW9mIGZu YW1lLCAiJXMiLCBnZXRzdHIoMSkpOwotCiAJZiA9IGdyZXBfbWFsbG9jKHNpemVvZiAqZik7 CisJbWVtc2V0KGYsIDAsIHNpemVvZiAqZik7CisJZi0+ZmQgPSBmaWxlbm8oc3RkaW4pOwor CWYtPnN0ZGluID0gdHJ1ZTsKIAotCWlmICgoZi0+ZiA9IGZkb3BlbihTVERJTl9GSUxFTk8s ICJyIikpICE9IE5VTEwpIHsKLQkJZi0+c3RkaW4gPSB0cnVlOwotCQlyZXR1cm4gKGYpOwot CX0KLQotCWZyZWUoZik7Ci0JcmV0dXJuIChOVUxMKTsKKwlyZXR1cm4gZ3JlcF9maWxlX2lu aXQoZik7CiB9CiAKIC8qCi0gKiBPcGVucyBhIG5vcm1hbCwgYSBnemlwcGVkIG9yIGEgYnpp cDIgY29tcHJlc3NlZCBmaWxlIGZvciBwcm9jZXNzaW5nLgorICogT3BlbnMgYSBmaWxlIGZv ciBwcm9jZXNzaW5nLgogICovCiBzdHJ1Y3QgZmlsZSAqCiBncmVwX29wZW4oY29uc3QgY2hh ciAqcGF0aCkKIHsKIAlzdHJ1Y3QgZmlsZSAqZjsKIAotCXNucHJpbnRmKGZuYW1lLCBzaXpl b2YgZm5hbWUsICIlcyIsIHBhdGgpOwotCiAJZiA9IGdyZXBfbWFsbG9jKHNpemVvZiAqZik7 Ci0KLQlmLT5zdGRpbiA9IGZhbHNlOwotCXN3aXRjaCAoZmlsZWJlaGF2ZSkgewotCWNhc2Ug RklMRV9TVERJTzoKLQkJaWYgKChmLT5mID0gZm9wZW4ocGF0aCwgInIiKSkgIT0gTlVMTCkK LQkJCXJldHVybiAoZik7Ci0JCWJyZWFrOwotCWNhc2UgRklMRV9HWklQOgotCQlpZiAoKGYt Pmd6ZiA9IGd6b3BlbihmbmFtZSwgInIiKSkgIT0gTlVMTCkKLQkJCXJldHVybiAoZik7Ci0J CWJyZWFrOwotCWNhc2UgRklMRV9CWklQOgotCQlpZiAoKGYtPmJ6ZiA9IEJaMl9iem9wZW4o Zm5hbWUsICJyIikpICE9IE5VTEwpCi0JCQlyZXR1cm4gKGYpOwotCQlicmVhazsKKwltZW1z ZXQoZiwgMCwgc2l6ZW9mICpmKTsKKwlpZiAoKGYtPmZkID0gb3BlbihwYXRoLCBPX1JET05M WSkpID09IC0xKSB7CisJCWZyZWUoZik7CisJCXJldHVybiAoTlVMTCk7CiAJfQogCi0JZnJl ZShmKTsKLQlyZXR1cm4gKE5VTEwpOworCXJldHVybiBncmVwX2ZpbGVfaW5pdChmKTsKIH0K IAogLyoKLSAqIENsb3NlcyBhIG5vcm1hbCwgYSBnemlwcGVkIG9yIGEgYnppcDIgY29tcHJl c3NlZCBmaWxlLgorICogQ2xvc2VzIGEgZmlsZS4KICAqLwogdm9pZAogZ3JlcF9jbG9zZShz dHJ1Y3QgZmlsZSAqZikKIHsKKwljbG9zZShmLT5mZCk7CiAKLQlzd2l0Y2ggKGZpbGViZWhh dmUpIHsKLQljYXNlIEZJTEVfU1RESU86Ci0JCWZjbG9zZShmLT5mKTsKLQkJYnJlYWs7Ci0J Y2FzZSBGSUxFX0daSVA6Ci0JCWd6Y2xvc2UoZi0+Z3pmKTsKLQkJYnJlYWs7Ci0JY2FzZSBG SUxFX0JaSVA6Ci0JCUJaMl9iemNsb3NlKGYtPmJ6Zik7Ci0JCWJyZWFrOwotCX0KLQotCS8q IFJlc2V0IHJlYWQgYnVmZmVyIGZvciB0aGUgZmlsZSB3ZSBhcmUgY2xvc2luZyAqLwotCWJp bmJ1ZnB0ciA9IE5VTEw7Ci0JZnJlZShiaW5idWYpOworCS8qIFJlc2V0IHJlYWQgYnVmZmVy IGFuZCBsaW5lIGJ1ZmZlciAqLworCWJ1ZnBvcyA9IGJ1ZmZlcjsKKwlidWZyZW0gPSAwOwog CisJZnJlZShsbmJ1Zik7CisJbG5idWYgPSBOVUxMOworCWxuYnVmbGVuID0gMDsKIH0KZGlm ZiAtLWdpdCBhL3Vzci5iaW4vZ3JlcC9ncmVwLmggYi91c3IuYmluL2dyZXAvZ3JlcC5oCmlu ZGV4IGJiNWU1ZjkuLjM5ODgyNDAgMTAwNjQ0Ci0tLSBhL3Vzci5iaW4vZ3JlcC9ncmVwLmgK KysrIGIvdXNyLmJpbi9ncmVwL2dyZXAuaApAQCAtNzcsMTAgKzc3LDcgQEAgZXh0ZXJuIGNv bnN0IGNoYXIJCSplcnJzdHJbXTsKICNkZWZpbmUgTUFYX0xJTkVfTUFUQ0hFUwkzMgogCiBz dHJ1Y3QgZmlsZSB7Ci0Jc3RydWN0IG1tZmlsZQkqbW1mOwotCUJaRklMRQkJKmJ6ZjsKLQlG SUxFCQkqZjsKLQlnekZpbGUJCSpnemY7CisJaW50CQkgZmQ7CiAJYm9vbAkJIGJpbmFyeTsK IAlib29sCQkgc3RkaW47CiB9OwpAQCAtMTUzLDExICsxNTAsOSBAQCB2b2lkCSBjbGVhcnF1 ZXVlKHZvaWQpOwogdm9pZAkJIGdyZXBfY2xvc2Uoc3RydWN0IGZpbGUgKmYpOwogc3RydWN0 IGZpbGUJKmdyZXBfc3RkaW5fb3Blbih2b2lkKTsKIHN0cnVjdCBmaWxlCSpncmVwX29wZW4o Y29uc3QgY2hhciAqcGF0aCk7Ci1pbnQJCSBncmVwX2Zlb2Yoc3RydWN0IGZpbGUgKmYpOwot aW50CQkgZ3JlcF9mZ2V0YyhzdHJ1Y3QgZmlsZSAqZik7CiBjaGFyCQkqZ3JlcF9mZ2V0bG4o c3RydWN0IGZpbGUgKmYsIHNpemVfdCAqbGVuKTsKIAogLyogZmFzdGdyZXAuYyAqLwogaW50 CQkgZmFzdGNvbXAoZmFzdGdyZXBfdCAqLCBjb25zdCBjaGFyICopOwogdm9pZAkJIGZncmVw Y29tcChmYXN0Z3JlcF90ICosIGNvbnN0IGNoYXIgKik7Ci1pbnQJCSBncmVwX3NlYXJjaChm YXN0Z3JlcF90ICosIHVuc2lnbmVkIGNoYXIgKiwgc2l6ZV90LCByZWdtYXRjaF90ICopOwor aW50CQkgZ3JlcF9zZWFyY2goZmFzdGdyZXBfdCAqLCBjb25zdCB1bnNpZ25lZCBjaGFyICos IHNpemVfdCwgcmVnbWF0Y2hfdCAqKTsK --------------010000040108020607000907-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 20:54:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382DF1065695 for ; Sun, 15 Aug 2010 20:54:44 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id A025C8FC1A for ; Sun, 15 Aug 2010 20:54:43 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7FKse5n009731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 06:54:41 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o7FKsYIG001682; Mon, 16 Aug 2010 06:54:34 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o7FKsY1X001681; Mon, 16 Aug 2010 06:54:34 +1000 (EST) (envelope-from peter) Date: Mon, 16 Aug 2010 06:54:34 +1000 From: Peter Jeremy To: Doug Barton Message-ID: <20100815205433.GA1612@server.vk2pj.dyndns.org> References: <4C675F64.9080205@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <4C675F64.9080205@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 20:54:44 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Aug-14 20:30:44 -0700, Doug Barton wrote: >It DOESN'T happen with loads that produce a lot more heat than my >typical desktop workloads (like say, make -j2 buildworld). Whilst I also doubt it's hardware, it's worth noting that flash (or other multimedia workload) is likely to stress different areas of the CPU than makeworld, Have you checked to see if there's a BIOS upgrade available? Other possibilities: - Have you tried running a uniprocessor kernel? - If your CPU supports LM, have you tried an amd64 kernel? --=20 Peter Jeremy --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxoVAkACgkQ/opHv/APuIfNQgCfUfBrWjyG2SHGR8okwhbmfqC2 LLsAn3V1S6qq/MqUnr67n8LmX0MADD4f =WPGt -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 20:56:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAC4A10656C0; Sun, 15 Aug 2010 20:56:34 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4548FC13; Sun, 15 Aug 2010 20:56:34 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id CD7A214DC675; Sun, 15 Aug 2010 22:56:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k4eKv4RVVpam; Sun, 15 Aug 2010 22:56:31 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 71C7214DC548; Sun, 15 Aug 2010 22:56:31 +0200 (CEST) Message-ID: <4C68547E.2080907@FreeBSD.org> Date: Sun, 15 Aug 2010 22:56:30 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> In-Reply-To: <8639ufd78w.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 20:56:34 -0000 Em 2010.08.15. 21:07, Dag-Erling Smørgrav escreveu: > Ignore the first two lines (that's the profiling code itself). Note > that the top five lines are all in stdio, and nothing else even shows up > on the radar. I only included enough output to show where the regexp > code ranks; the complete output is attached. > > I hate to suggest reinventing the wheel, but IMHO, this is clearly a > case where it would pay to use hand-rolled buffered input routines > instead of stdio. > Thank you very much for the valuable tests, I've already started to refactor this part but it will take some time and still it doesn't garantize that the performance will be the same as GNU's with this change. It may need more investigation, so I'm also already testing my patch to change the default and we'll see how the performance improvement progresses. Gabor From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 21:50:52 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C578106566C; Sun, 15 Aug 2010 21:50:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 293898FC17; Sun, 15 Aug 2010 21:50:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7FLfceh041792; Sun, 15 Aug 2010 15:41:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 15 Aug 2010 15:42:11 -0600 (MDT) Message-Id: <20100815.154211.338122493920752843.imp@bsdimp.com> To: tim@kientzle.com From: "M. Warner Losh" In-Reply-To: <894C8953-7F2F-486F-8701-A3DFF65D7627@kientzle.com> References: <4C673F02.8000805@FreeBSD.org> <3CF90102-4DD5-4A44-925B-C215AE5AB36A@solfertje.student.utwente.nl> <894C8953-7F2F-486F-8701-A3DFF65D7627@kientzle.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dougb@FreeBSD.org, current@FreeBSD.org, core@FreeBSD.org, delphij@FreeBSD.org, gabor@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 21:50:52 -0000 In message: <894C8953-7F2F-486F-8701-A3DFF65D7627@kientzle.com> Tim Kientzle writes: : : On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote: : : > On 15 Aug 2010, at 3:12, Doug Barton wrote: : > : >> (And before anyone bothers to reply saying "Use pkg_info -O for that" : >> I'll save you the trouble. My version is from 10-20% faster. Not sure : >> why, don't really care.) :) : > : > : > Congrats for beating the performance of a(nother) utility in base, but - regardless of whether you'd use it in that case - doesn't that just indicate that pkg_info could use some performance improvements as well? : : http://libpkg.googlecode.com/ : : This is David Forsyth's GSoC project to build a standard library : for managing the on-disk package database. : : His pkg_info implementation built on this library is in fact : a lot faster than what's currently in the tree. He's starting : to prototype pkg_delete and pkg_add on the new library : but there's still a lot of work to do. heh, maybe he needs to do work on an upgrader too. :) Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 22:08:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3612B10656A5; Sun, 15 Aug 2010 22:08:01 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC8018FC19; Sun, 15 Aug 2010 22:08:00 +0000 (UTC) Received: by pvg4 with SMTP id 4so2013386pvg.13 for ; Sun, 15 Aug 2010 15:08:00 -0700 (PDT) Received: by 10.114.121.18 with SMTP id t18mr5195441wac.136.1281910080253; Sun, 15 Aug 2010 15:08:00 -0700 (PDT) Received: from [192.168.43.181] (m3d0536d0.tmodns.net [208.54.5.61]) by mx.google.com with ESMTPS id d39sm10737313wam.16.2010.08.15.15.07.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Aug 2010 15:07:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <4C6844D8.5070602@andric.com> Date: Sun, 15 Aug 2010 15:07:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9C0F9422-439B-4DB8-A1C4-9F1749407FC5@kientzle.com> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> To: Dimitry Andric X-Mailer: Apple Mail (2.1081) Cc: Doug Barton , Justin Hibbits , delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 22:08:01 -0000 On Aug 15, 2010, at 12:49 PM, Dimitry Andric wrote: > So my first quick fix attempt was to replace the home-grown grep_fgetln > with fgetln(3), which is in libc. This does not support gzip and bzip2 > files, but just to prove the point, it is enough. It gave the following > profiling result: FYI: libarchive has some pretty heavily-optimized bulk I/O routines and handles automatic decompression (including gzip, bzip2, lzma, xz, lzip, compress, and soon uuencode). There's a trick supported in libarchive now that will let you just use it's automatic decompression features on non-archive files (via "format_raw"). Unfortunately, it provides binary blocks of data; there's no nice line-reader interface. There's an effort afoot to refactor libarchive so that the stream I/O and compression/decompression support is actually a separate library that should be very useful for this sort of usage. As part of that, we plan to add some line-oriented I/O features that should be noticeably more efficient than stdio. Cheers, Tim From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 05:09:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73C341065679 for ; Mon, 16 Aug 2010 05:09:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 03F6C8FC08 for ; Mon, 16 Aug 2010 05:09:18 +0000 (UTC) Received: (qmail 16119 invoked by uid 399); 16 Aug 2010 05:09:17 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Aug 2010 05:09:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 15 Aug 2010 22:09:14 -0700 (PDT) From: Doug Barton To: bf1783@gmail.com In-Reply-To: Message-ID: References: <4C675F64.9080205@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 05:09:20 -0000 On Sun, 15 Aug 2010, b. f. wrote: > What were you doing when you triggered the interrupt problem without > running X? I'm afraid to say, lest I am once again labeled a bad programmer. :) > Was there a lot of network, audio device, or disk activity > at the time? Disk, lots and lots of disk. No network or audio (I purposely constrained those 2). > Are these failures without X consistently reproducible, > or unpredictable? If I watch enough flash videos, it's 100% sure that it will happen, the only question is when. Last night (on r211309) I got through 2 shows, and started on a 3rd before it happened. Rebooted, and I was back in business. Sometimes it happens on the first one I watch after a cold boot. > Can you remember the revision number of the last > version of -CURRENT that didn't have these problems? It was at least a year ago, so no; I can't remember specifically. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 05:23:07 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98A111065679 for ; Mon, 16 Aug 2010 05:23:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 27A3B8FC17 for ; Mon, 16 Aug 2010 05:23:07 +0000 (UTC) Received: (qmail 3053 invoked by uid 399); 16 Aug 2010 05:23:06 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Aug 2010 05:23:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 15 Aug 2010 22:23:03 -0700 (PDT) From: Doug Barton To: Peter Jeremy In-Reply-To: <20100815205433.GA1612@server.vk2pj.dyndns.org> Message-ID: References: <4C675F64.9080205@FreeBSD.org> <20100815205433.GA1612@server.vk2pj.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 05:23:07 -0000 On Mon, 16 Aug 2010, Peter Jeremy wrote: > On 2010-Aug-14 20:30:44 -0700, Doug Barton wrote: >> It DOESN'T happen with loads that produce a lot more heat than my >> typical desktop workloads (like say, make -j2 buildworld). > > Whilst I also doubt it's hardware, it's worth noting that flash > (or other multimedia workload) is likely to stress different areas > of the CPU than makeworld, I was responding to the heat question, not cpu load. Other than that, you're right of course. :) > Have you checked to see if there's a BIOS upgrade available? Yes I have, and no there isn't. > Other possibilities: > - Have you tried running a uniprocessor kernel? That one I haven't tried, thanks for the suggestion! > - If your CPU supports LM, have you tried an amd64 kernel? I haven't, mostly because in the past some things I wanted were not available in amd64. I'm running a C2D in i386/SMP. Trying amd64 is a bit more of a jump, but when I get my HD repartitioned I can try 7.3 i386 and -current amd64 ... back to the drawing board ... Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 06:15:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E0A1065670 for ; Mon, 16 Aug 2010 06:15:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2AD8FC20 for ; Mon, 16 Aug 2010 06:15:59 +0000 (UTC) Received: (qmail 4531 invoked by uid 399); 16 Aug 2010 06:15:58 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Aug 2010 06:15:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 15 Aug 2010 23:15:55 -0700 (PDT) From: Doug Barton To: Ivan Voras In-Reply-To: Message-ID: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 06:15:59 -0000 On Sun, 15 Aug 2010, Ivan Voras wrote: > This is my long-term point - it really would be beneficial to have an > alternative, richer language in base which would fall between the > categories of "a good system language but far too complex for simple > string-parsing stuff" which is C and "a good glue language for system > utilities but lacking more evolved concepts" which is shell. I sort of agree with you here, but I don't. :) ONE of the reasons that perl was axed from the base was that it was very very hard to keep the bmake glue up to date. However, a bigger reason was that it was impossible to marry our concept of a "stable" branch with the ever-evolving world that was perl. We often had a situation where a long-lived stable branch would have a VERY stale version of perl in it, to the point that the only rational course of action was to disable the perl build and install a usable version from ports. We do not want to go back down that road. (And I'm not speculating here, I lived through it.) Personally, I think the whole "base" and "ports" thing is an artificial divide that is rapidly losing utility. I think we're past due for stripping the FreeBSD "base" down to a much more bare minimum, and having a lot more of the bells and whistles live in the ports tree. Aside from the usual suspects (BIND, sendmail, etc.) I also would dearly like to see the ports tools themselves move into the ports tree. This would make it TONS easier to introduce new features and bug fixes to the ports infrastructure. There are many other such examples. > That said, I know it's useless to simply import something in the hope > it will be useful in the future. Not only useless, but certain to be vigorously opposed by many, including me. > My best bet is that I (or someone else) would write something useful > enough to be imported in base in such a language, which would warrant > importing the language itself. 13 years ago I very nearly wrote mergemaster in bash for this exact reason (and believe me, many is the time that I wish I had possessed the courage to be that devious back in the day, but I was new to the community and still idealistic). 6 years ago when I started working on portmaster I had the same internal debate, but my better angels won out. Short version of my tortuous internal struggle, you can't win this argument, even if I though you should be able to. **IF** this were a good idea, the only rational choice would be one of the more sophisticated yet still POSIX-compliant shells because they offer you significantly more features, without the dramatic churn problem that the "cooler" languages do. So let me give you the reader's digest version of the debate, then ask yourself again if you want to keep proposing this: lua too "flavor of the day," not enough track record of stability, not enough installed base/proven utility ruby too much churn, weird/zealotrous user community, more utility but still feels to new for some of our graybeards python possible, but you still have the churn problem, not to mention actually pulling this trigger massively inflames the communities for all the other "interpreted" languages ksh arguably most POSIX-compliant, has a lot of good features, but but (also arguably) sort of a klunky shell which reduces the value in the '2 birds for 1 stone' department zsh less POSIX-compliant, oddly deviant from "standard" bourne-derived shells which makes graybeards break out in hives also, see ruby under user community bash probably the best candidate in the 3 most important categories, POSIX compliance, good feature set (although not as feature full as even zsh is), and is a less klunky shell. HOWEVER, it's too "establishment" to make the kids happy, and isn't as clean in the license category as we'd like. (And yeah, I purposely omitted that question from all the other candidates as well.) got any other suggestions? > some JavaScript engines probably fit the description. Yikes! Sorry I asked. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 06:57:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72118106566B; Mon, 16 Aug 2010 06:57:31 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from visi.gothic.net.au (visi.gothic.net.au [115.64.131.102]) by mx1.freebsd.org (Postfix) with ESMTP id 227BF8FC16; Mon, 16 Aug 2010 06:57:30 +0000 (UTC) Received: from visi.gothic.net.au (localhost [127.0.0.1]) by visi.gothic.net.au (Postfix) with ESMTP id 5696741EDB; Mon, 16 Aug 2010 16:41:18 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from localhost ([127.0.0.1]) by visi.gothic.net.au (visi.gothic.net.au [127.0.0.1]) (amavisd-new, port 10026) with SMTP id FvY6bnfauueZ; Mon, 16 Aug 2010 16:41:12 +1000 (EST) Received: from dhcp195.gothic.net.au (dhcp195.gothic.net.au [10.168.1.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean) by visi.gothic.net.au (Postfix) with ESMTPSA id C5F3F41ED3; Mon, 16 Aug 2010 16:41:11 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Sean In-Reply-To: Date: Mon, 16 Aug 2010 16:41:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 06:57:31 -0000 On 16/08/2010, at 4:15 PM, Doug Barton wrote: > On Sun, 15 Aug 2010, Ivan Voras wrote: >=20 >> This is my long-term point - it really would be beneficial to have an >> alternative, richer language in base which would fall between the >> categories of "a good system language but far too complex for simple >> string-parsing stuff" which is C and "a good glue language for system >> utilities but lacking more evolved concepts" which is shell. >=20 > I sort of agree with you here, but I don't. :) ONE of the reasons = that perl was axed from the base was that it was very very hard to keep = the bmake glue up to date. However, a bigger reason was that it was = impossible to marry our concept of a "stable" branch with the = ever-evolving world that was perl. We often had a situation where a = long-lived stable branch would have a VERY stale version of perl in it, = to the point that the only rational course of action was to disable the = perl build and install a usable version from ports. We do not want to go = back down that road. (And I'm not speculating here, I lived through it.) >=20 And lest anyone think "that's just perl", look at the history of TCL in = the base system as well.=20= From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 07:12:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE0F61065695; Mon, 16 Aug 2010 07:12:05 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id C11D28FC1A; Mon, 16 Aug 2010 07:12:05 +0000 (UTC) Received: from draco.over-yonder.net (c-75-64-226-141.hsd1.ms.comcast.net [75.64.226.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 741AB37B470; Mon, 16 Aug 2010 01:52:34 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id DF9C661C57; Mon, 16 Aug 2010 01:52:33 -0500 (CDT) Date: Mon, 16 Aug 2010 01:52:33 -0500 From: "Matthew D. Fuller" To: Doug Barton Message-ID: <20100816065233.GA35264@over-yonder.net> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 07:12:06 -0000 On Sun, Aug 15, 2010 at 11:15:55PM -0700 I heard the voice of Doug Barton, and lo! it spake thus: > > However, a bigger reason was that it was impossible to marry our > concept of a "stable" branch with the ever-evolving world that was > perl. This one at least is conceptually pretty easy to solve. We don't have any worries about how old or new the version of expat in base is; since it's not called libexpat, nothing but the stuff in base written specifically against it has to worry about it getting old, and upgrading it requires only checking against those things in base. So we could go right ahead and import perl, just renamed to 'bsdscript' 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 07:24:52 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CAAD1065696 for ; Mon, 16 Aug 2010 07:24:52 +0000 (UTC) (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 0BFF78FC22 for ; Mon, 16 Aug 2010 07:24:51 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2DFFB3F5BC; Mon, 16 Aug 2010 07:24:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o7G7Onkn002296; Mon, 16 Aug 2010 07:24:50 GMT (envelope-from phk@critter.freebsd.dk) To: Doug Barton From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 15 Aug 2010 23:15:55 MST." Date: Mon, 16 Aug 2010 07:24:49 +0000 Message-ID: <2295.1281943489@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@FreeBSD.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 07:24:52 -0000 In message , Doug Barton writes: >On Sun, 15 Aug 2010, Ivan Voras wrote: >> This is my long-term point - [...] Some of use were 12 years ahead of you :-) >I sort of agree with you here, but I don't. :) ONE of the reasons that >perl was axed [...] Actually, let me put that stuff on the record, as one of the prime & convicted suspects of that entire ordeal. Tcl, a very small language, specifically designed to be embeddable in other programs, was imported into FreeBSD because we had a dream. The intent of the Tcl import was that it would be embedded into other programs, and thus open them up to customization at a net reduction in C-code lines. Inetd(8) is an example: Rather than "exec this file" you would get to examine IP#'s and other context before you made up your mind about what to do, all in a friendly script language. Other obvious candidates: ampd(8), ppp(8), config(8) and so on. In other words, the Intent behind Tcl was architectural: To improve the base system, eliminated duplication of structural code giving an overall stream-lining of the system. We probably did not manage to sell that vision back then, and I will forego conclusions on the advisability of our vision in hindsight. Tcl was soon axed again, because people did not see the value of having a high-level language, if it were not THEIR high-level language, which was missing the point by the width of the horizon. Next we tried Perl. The thing we probably did not realize and certainly not appreciate the importance of, is that pretty much all other languages than Tcl, are languages you add things to, not languages you add to things. This has two implications: The first is that the only thing you gain by including such a language, is the ability to run scripts in it. That might improve (or not!) the readability of the rc.d scripts. The second is that such languages really do not want to be treated as house-guests in a software distribution. Maintaining them is a major hazzle and they all have fuzzy boundaries, in the sense that calls along the lines of "We should really import the P-FOO package/module/library also because it is so much more convenient..." will never cease. With Perl we found conclusively that the benefits did not even get close to balance the hazzle. And thus perl was also removed again. Based on what we learned, My advice would be: The window of opportunity for an embeddable language is long since closed. Nobody uses the base-system any more to an extent where it makes sense to bother about, for that concept to have been long term viable, it would have had to cross-fertilize into desktops (KDE, Gnome etc) and Apache. Adding any of the "big" languages (perl, python, ruby, ...) will not _ever_ pay off the costs, even if we exclude from the bill the friendly fire involved in determining which we pick. If it is the /bin/sh syntax that bothers you, set your eyes on gettung us a zsh or ksh upgrade, that may be feasible and would be sensible, considering what a new language can do for the base system. But otherwise: Forget it. Poul-Henning PS: The sickening irony is that today we have two embedded languages, one in the kernel even, and it is the most crappy ones you can imagine: Forth and ACPI. -- 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-current@FreeBSD.ORG Mon Aug 16 08:14:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E2051065695 for ; Mon, 16 Aug 2010 08:14:24 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id A2ED18FC14 for ; Mon, 16 Aug 2010 08:14:22 +0000 (UTC) Received: (qmail 25078 invoked from network); 16 Aug 2010 07:47:40 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Aug 2010 07:47:40 -0000 Date: Mon, 16 Aug 2010 09:47:40 +0200 (CEST) Message-Id: <20100816.094740.74728369.sthaug@nethelp.no> To: dougb@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: References: <4C673898.2080609@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 08:14:24 -0000 > Personally, I think the whole "base" and "ports" thing is an artificial > divide that is rapidly losing utility. I think we're past due for > stripping the FreeBSD "base" down to a much more bare minimum, and > having a lot more of the bells and whistles live in the ports tree. Strongly disagree. One of the reasons I've been using FreeBSD for many years is precisely the fact that the base system is very good, and contains most of what I need without installing a lot of extra ports/ packages. (Yes, I always end up installing perl, but that is one of a select few.) If I only wanted a kernel and everything else as installable packages, I might as well use one of the Linux distributions. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 08:23:41 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1CE01065693; Mon, 16 Aug 2010 08:23:41 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id A79918FC0C; Mon, 16 Aug 2010 08:23:40 +0000 (UTC) Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id E1FDC1C157CE; Mon, 16 Aug 2010 10:04:20 +0200 (CEST) Received: from mail.reifenberger.com (ppp-93-104-48-250.dynamic.mnet-online.de [93.104.48.250]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS id CE08E1C001CF; Mon, 16 Aug 2010 10:04:20 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 705BF32577; Mon, 16 Aug 2010 10:04:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 68EC132574; Mon, 16 Aug 2010 10:04:20 +0200 (CEST) Date: Mon, 16 Aug 2010 10:04:20 +0200 (CEST) From: Michael Reifenberger To: Poul-Henning Kamp In-Reply-To: <2295.1281943489@critter.freebsd.dk> Message-ID: References: <2295.1281943489@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, Doug Barton , Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 08:23:42 -0000 On Mon, 16 Aug 2010, Poul-Henning Kamp wrote: ... > PS: The sickening irony is that today we have two embedded languages, > one in the kernel even, and it is the most crappy ones you can > imagine: Forth and ACPI. > Besides the syntax FORTH ist the only embeddable high level language which has both intepreter and compiler built in. It has a small form factor too. One alternative could be something like WABA (http://waba.sourceforge.net/). Besides the wrong license it would mean to have pre-compiled byte code on the FS and no chance to recompile on the fly... Or ECMAScript as a pure interpreted language. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 08:43:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 590DD1065670; Mon, 16 Aug 2010 08:43:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id DCA948FC08; Mon, 16 Aug 2010 08:43:56 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o7G8hsva058792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Aug 2010 10:43:54 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id o7G8hmDB026188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 10:43:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o7G8hm4W018190; Mon, 16 Aug 2010 10:43:48 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o7G8hm7u018189; Mon, 16 Aug 2010 10:43:48 +0200 (CEST) (envelope-from ticso) Date: Mon, 16 Aug 2010 10:43:48 +0200 From: Bernd Walter To: sthaug@nethelp.no Message-ID: <20100816084348.GY99358@cicely7.cicely.de> References: <4C673898.2080609@FreeBSD.org> <20100816.094740.74728369.sthaug@nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100816.094740.74728369.sthaug@nethelp.no> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: dougb@freebsd.org, freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 08:43:57 -0000 On Mon, Aug 16, 2010 at 09:47:40AM +0200, sthaug@nethelp.no wrote: > > Personally, I think the whole "base" and "ports" thing is an artificial > > divide that is rapidly losing utility. I think we're past due for > > stripping the FreeBSD "base" down to a much more bare minimum, and > > having a lot more of the bells and whistles live in the ports tree. > > Strongly disagree. One of the reasons I've been using FreeBSD for many > years is precisely the fact that the base system is very good, and > contains most of what I need without installing a lot of extra ports/ > packages. I can agree to this argument. While it is easy to install required tools on your system it is a hassle if you are doing support for systems installed by someone else. With FreeBSD you can expect a great set of tools already available. I remember the old days when I was doing embedded systems on tiny CF media and thought I only stripped the tools I really don't need, but in the end I often missed something. But I also never missed something with a complete base. Perl is a fancy tool, but when you really need it you don't have a problem in installing it. It is not that long time ago that a friend with his Linux couldn't even check the negotiated ethernet link without installing an additional tool - easy if you have network, but isn't this a tool to debug network problems? The last thing I've missed was something to script in single-user-mode. In loader we have FICL and in single-user-mode we have /bin/sh, while the shell is reasonable to write scripts it also requires external helpers which sits in non-mounted /usr - e.g.: grep, sed, lock, ... With todays disk and partition sizes however I don't split /usr - I split /usr/local (often don't even this), so this isn't a problem anymore. Having an embeddable lanmguage is another story - no matter if it is TCL, FICL, Lua or whatever. There is a possible benefit for extending our tools, but after reading PHKs history description I'm not that sure about it anymore. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 08:50:24 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D5B10656A7 for ; Mon, 16 Aug 2010 08:50:24 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id E41B58FC21 for ; Mon, 16 Aug 2010 08:50:23 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OkvOh-0001gE-D7 for current@freebsd.org; Mon, 16 Aug 2010 08:50:23 +0000 Date: Mon, 16 Aug 2010 17:50:22 +0900 Message-ID: From: Randy Bush To: FreeBSD current mailing list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: better way than hacking termcap to be ca_mode free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 08:50:24 -0000 is there a better way to achieve this? randy *** termcap.FCS Tue Jun 17 15:10:46 2003 --- termcap Tue Jun 17 15:14:15 2003 *************** *** 299,305 **** adm3|3|lsi adm3:\ :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: xterm|xterm-color|X11 terminal emulator:\ ! :ti@:te@:tc=xterm-xfree86: # # DESCRIPTION: # This file describes capabilities of various terminals, as needed by --- 299,305 ---- adm3|3|lsi adm3:\ :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: xterm|xterm-color|X11 terminal emulator:\ ! :tc=xterm-xfree86: # # DESCRIPTION: # This file describes capabilities of various terminals, as needed by From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 08:55:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 180281065693; Mon, 16 Aug 2010 08:55:23 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C53D88FC14; Mon, 16 Aug 2010 08:55:20 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 6420F1FFC38; Mon, 16 Aug 2010 08:55:19 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3697D8455C; Mon, 16 Aug 2010 10:55:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dimitry Andric References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> Date: Mon, 16 Aug 2010 10:55:18 +0200 In-Reply-To: <4C6844D8.5070602@andric.com> (Dimitry Andric's message of "Sun, 15 Aug 2010 21:49:44 +0200") Message-ID: <86sk2faqdl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 08:55:23 -0000 Dimitry Andric writes: > - Uses plain file descriptors instead of struct FILE, since the > buffering is done manually anyway, and it makes it easier to support > gzip and bzip2. It might be worth a shot adding mmap(2) support as well, i.e. when processing an uncompressed regular file, try to mmap(2) it first, and if that fails, fall back to the plain buffered read(2) method. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 09:02:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1913D1065672 for ; Mon, 16 Aug 2010 09:02:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 705188FC15 for ; Mon, 16 Aug 2010 09:02:56 +0000 (UTC) Received: by eyh6 with SMTP id 6so2604968eyh.13 for ; Mon, 16 Aug 2010 02:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=TPqlFYHEH/K6mxUUrkVX3r6/FHG4+OvPoeHI1mKVE9A=; b=q9PTbNnZvyRPl/DU0GD8RrG+6dtor/OPKrNlbyNarjYN5FImLMfyQXuQiCuDYeVfv7 lihRiAo621uFiNDaS+XEDbDwB4L4LSsVUGRMVuvG9b6kXhPjmFoxEdXQXtw4XDLBdrxR nsVqRZtcDSeer+dil8c/c1yf98p+uXSyAOQsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=YliSs9hPAjdnxC3iObcy4tlF8LUF2EmsZNjrdJbfcpwbiGbNFEQD54VlDVbFL1/Q1M YX9cvgNkkN8J6VoKB6keGWUjRqVQrL9IlrXgPef9e6LQ9TrsE8P0IJQCcLMErcUQRWht B/ygnUsUeg6ZLLgbXyFsbglYhTc6IPPqr4xck= MIME-Version: 1.0 Received: by 10.213.59.76 with SMTP id k12mr2480922ebh.13.1281949375386; Mon, 16 Aug 2010 02:02:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.213.108.205 with HTTP; Mon, 16 Aug 2010 02:02:55 -0700 (PDT) In-Reply-To: References: <4C675F64.9080205@FreeBSD.org> Date: Mon, 16 Aug 2010 17:02:55 +0800 X-Google-Sender-Auth: qeyoBSKyKRkh7oCYsMpe3bTwsEA Message-ID: From: Adrian Chadd To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: bf1783@gmail.com, freebsd-current@freebsd.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:02:57 -0000 On 16 August 2010 13:09, Doug Barton wrote: >> Can you remember the revision number of the last >> version of -CURRENT that didn't have these problems? > > It was at least a year ago, so no; I can't remember specifically. Have you tried running software build(s) from ~ 1.5 years ago to see whether it makes a difference? So it's still possibly hardware (which the software is somehow handling badly?) Adrian From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 09:03:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF671065697; Mon, 16 Aug 2010 09:03:43 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE8D8FC08; Mon, 16 Aug 2010 09:03:43 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 698A11FFC34; Mon, 16 Aug 2010 09:03:42 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 3F12884559; Mon, 16 Aug 2010 11:03:42 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> Date: Mon, 16 Aug 2010 11:03:42 +0200 In-Reply-To: (Doug Barton's message of "Sun, 15 Aug 2010 23:15:55 -0700 (PDT)") Message-ID: <86ocd3apzl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:03:43 -0000 Doug Barton writes: > lua too "flavor of the day," not enough track record of stability, > not enough installed base/proven utility You're wrong. Lua has been around for ages and is especially widely used as a game scripting engine. It is not intended as a standalone language, but as an embeddable scripting engine. We could easily create our own scripting language based on lua with FreeBSD-specific functions, and there would be no fear of interfering with third-party software, because it wouldn't be called lua. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 09:27:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57952106564A for ; Mon, 16 Aug 2010 09:27:16 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id D8FF58FC16 for ; Mon, 16 Aug 2010 09:27:14 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7G9RC0N023157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 19:27:13 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o7G9RALP006099; Mon, 16 Aug 2010 19:27:10 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o7G9RAct006098; Mon, 16 Aug 2010 19:27:10 +1000 (EST) (envelope-from peter) Date: Mon, 16 Aug 2010 19:27:10 +1000 From: Peter Jeremy To: Ivan Voras Message-ID: <20100816092710.GA5963@server.vk2pj.dyndns.org> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Scripting language in base [was Re: Official request: Please make GNU grep the default] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:27:16 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Since this is now well off the original topic. On 2010-Aug-15 12:57:23 +0200, Ivan Voras wrote: >This is my long-term point - it really would be beneficial to have an >alternative, richer language in base which would fall between the >categories of "a good system language but far too complex for simple >string-parsing stuff" which is C and "a good glue language for system >utilities but lacking more evolved concepts" which is shell. I'd say the bigger problem with C is that its native string processing capabilities are basically non-existent. Compared to awk, perl, ruby, (insert your favourite scripting language here) or even sh, the equivalent code in C is going to be much longer and less clear. Note that the system does have a language intermediate between sh and C - awk. The main downside of awk is its lack of pipe support. >default. My current favorite is lua because it's very small and easily >embeddable and extendable by C code, but there are others - some >JavaScript engines probably fit the description. You have previously suggested importing lua. I'd suggest that all you need is the killer app written in lua to justify importing it. Another option might be ficl - the code is already in the base system, it would just need to be compiled. Of course, the downside is that FORTH is a very niche language. --=20 Peter Jeremy --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEUEARECAAYFAkxpBG4ACgkQ/opHv/APuIe/QQCY2icgcwdkbWGMqZP0IPIOdIze cwCfeNCxY2YUAptDYASBfe/JzWLr1BE= =Bw+8 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 10:42:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A04A91065675; Mon, 16 Aug 2010 10:42:47 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3405E8FC13; Mon, 16 Aug 2010 10:42:46 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8c6d:ecb1:2b0e:5d24] (unknown [IPv6:2001:7b8:3a7:0:8c6d:ecb1:2b0e:5d24]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C03935C43; Mon, 16 Aug 2010 12:42:42 +0200 (CEST) Message-ID: <4C691629.4010006@andric.com> Date: Mon, 16 Aug 2010 12:42:49 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> In-Reply-To: <4C6844D8.5070602@andric.com> Content-Type: multipart/mixed; boundary="------------030707040809090904070205" Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 10:42:47 -0000 This is a multi-part message in MIME format. --------------030707040809090904070205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2010-08-15 21:49, Dimitry Andric wrote: > ...I > have attached a more complete patch that: > > - Replaces the horrendously inefficient grep_fgetln() with mostly the > same implementation as the libc fgetln() function. > - Uses plain file descriptors instead of struct FILE, since the > buffering is done manually anyway, and it makes it easier to support > gzip and bzip2. > - Let the bzip2 reader just read the file as plain data, when the > initial magic number doesn't match, mimicking the behaviour of GNU > grep. Here is a new patch, updated against Gabor's changes in r211364. --------------030707040809090904070205 Content-Type: text/plain; name="bsdgrep-speed-2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bsdgrep-speed-2.diff" ZGlmZiAtLWdpdCBhL3Vzci5iaW4vZ3JlcC9mYXN0Z3JlcC5jIGIvdXNyLmJpbi9ncmVwL2Zh c3RncmVwLmMKaW5kZXggYzY2ZjBhNy4uMzBhMmRjNSAxMDA2NDQKLS0tIGEvdXNyLmJpbi9n cmVwL2Zhc3RncmVwLmMKKysrIGIvdXNyLmJpbi9ncmVwL2Zhc3RncmVwLmMKQEAgLTE5OCw3 ICsxOTgsNyBAQCBmYXN0Y29tcChmYXN0Z3JlcF90ICpmZywgY29uc3QgY2hhciAqcGF0KQog fQogCiBpbnQKLWdyZXBfc2VhcmNoKGZhc3RncmVwX3QgKmZnLCB1bnNpZ25lZCBjaGFyICpk YXRhLCBzaXplX3QgbGVuLCByZWdtYXRjaF90ICpwbWF0Y2gpCitncmVwX3NlYXJjaChmYXN0 Z3JlcF90ICpmZywgY29uc3QgdW5zaWduZWQgY2hhciAqZGF0YSwgc2l6ZV90IGxlbiwgcmVn bWF0Y2hfdCAqcG1hdGNoKQogewogCXVuc2lnbmVkIGludCBqOwogCWludCByZXQgPSBSRUdf Tk9NQVRDSDsKZGlmZiAtLWdpdCBhL3Vzci5iaW4vZ3JlcC9maWxlLmMgYi91c3IuYmluL2dy ZXAvZmlsZS5jCmluZGV4IDE4NzJkMGUuLjE4NWFiMWQgMTAwNjQ0Ci0tLSBhL3Vzci5iaW4v Z3JlcC9maWxlLmMKKysrIGIvdXNyLmJpbi9ncmVwL2ZpbGUuYwpAQCAtMzcsNyArMzcsNyBA QCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8YnpsaWIuaD4KICNpbmNsdWRl IDxlcnIuaD4KICNpbmNsdWRlIDxlcnJuby5oPgotI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5j bHVkZSA8ZmNudGwuaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxzdHJpbmcu aD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KQEAgLTQ3LDEzOCArNDcsMTYwIEBAIF9fRkJTRElE KCIkRnJlZUJTRCQiKTsKIAogI2luY2x1ZGUgImdyZXAuaCIKIAotc3RhdGljIGNoYXIJIGZu YW1lW01BWFBBVEhMRU5dOwkvKiBmaWxlIG5hbWUgKi8KKyNkZWZpbmUJTUFYQlVGU0laCSgz MiAqIDEwMjQpCisjZGVmaW5lCUxOQlVGQlVNUAk4MAogCi0jZGVmaW5lCQkgTUFYQlVGU0la CSgxNiAqIDEwMjQpCi0jZGVmaW5lCQkgUFJFUkVBRF9NCTAuMgorc3RhdGljIGd6RmlsZSBn emJ1ZmRlc2M7CitzdGF0aWMgQlpGSUxFKiBiemJ1ZmRlc2M7CiAKLS8qIFNvbWUgZ2xvYmFs IHZhcmlhYmxlcyBmb3IgdGhlIGJ1ZmZlcmluZyBhbmQgcmVhZGluZy4gKi8KLXN0YXRpYyBj aGFyCSpsbmJ1ZjsKLXN0YXRpYyBzaXplX3QJIGxuYnVmbGVuOwotc3RhdGljIHVuc2lnbmVk IGNoYXIgKmJpbmJ1ZjsKLXN0YXRpYyBpbnQJIGJpbmJ1ZnNpejsKLXVuc2lnbmVkIGNoYXIJ KmJpbmJ1ZnB0cjsKLXN0YXRpYyBpbnQJIGJ6ZXJyOworc3RhdGljIHVuc2lnbmVkIGNoYXIg YnVmZmVyW01BWEJVRlNJWl07CitzdGF0aWMgdW5zaWduZWQgY2hhciAqYnVmcG9zOworc3Rh dGljIHNpemVfdCBidWZyZW07CiAKLSNkZWZpbmUgaXN3YmluYXJ5KGNoKQkoIWlzd3NwYWNl KChjaCkpICYmIGlzd2NudHJsKChjaCkpICYmIFwKLQkJCSAgICAoY2ggIT0gTCdcYicpICYm IChjaCAhPSBMJ1wwJykpCitzdGF0aWMgdW5zaWduZWQgY2hhciAqbG5idWY7CitzdGF0aWMg c2l6ZV90IGxuYnVmbGVuOwogCi0vKgotICogUmV0dXJucyBhIHNpbmdsZSBjaGFyYWN0ZXIg YWNjb3JkaW5nIHRvIHRoZSBmaWxlIHR5cGUuCi0gKiBSZXR1cm5zIC0xIG9uIGZhaWx1cmUu Ci0gKi8KLXN0YXRpYyBpbmxpbmUgaW50Ci1ncmVwX2ZnZXRjKHN0cnVjdCBmaWxlICpmKQor c3RhdGljIGludAorZ3JlcF9yZWZpbGwoc3RydWN0IGZpbGUgKmYpCiB7Ci0JdW5zaWduZWQg Y2hhciBjOworCXNzaXplX3QgbnI7CisJaW50IGJ6ZXJyOwogCi0Jc3dpdGNoIChmaWxlYmVo YXZlKSB7Ci0JY2FzZSBGSUxFX1NURElPOgotCQlyZXR1cm4gKGdldGNfdW5sb2NrZWQoZi0+ ZikpOwotCWNhc2UgRklMRV9HWklQOgotCQlyZXR1cm4gKGd6Z2V0YyhmLT5nemYpKTsKLQlj YXNlIEZJTEVfQlpJUDoKLQkJQloyX2J6UmVhZCgmYnplcnIsIGYtPmJ6ZiwgJmMsIDEpOwot CQlpZiAoYnplcnIgPT0gQlpfU1RSRUFNX0VORCkKLQkJCXJldHVybiAoLTEpOwotCQllbHNl IGlmIChiemVyciAhPSBCWl9TRVFVRU5DRV9FUlJPUiAmJiBiemVyciAhPSBCWl9PSykKLQkJ CWVycngoMiwgIiVzIiwgZ2V0c3RyKDIpKTsKLQkJcmV0dXJuIChjKTsKKwlidWZwb3MgPSBi dWZmZXI7CisJYnVmcmVtID0gMDsKKworCWlmIChmaWxlYmVoYXZlID09IEZJTEVfR1pJUCkg eworCQluciA9IGd6cmVhZChnemJ1ZmRlc2MsIGJ1ZmZlciwgTUFYQlVGU0laKTsKKwl9IGVs c2UgaWYgKGZpbGViZWhhdmUgPT0gRklMRV9CWklQICYmIGJ6YnVmZGVzYyAhPSBOVUxMKSB7 CisJCW5yID0gQloyX2J6UmVhZCgmYnplcnIsIGJ6YnVmZGVzYywgYnVmZmVyLCBNQVhCVUZT SVopOworCQlzd2l0Y2ggKGJ6ZXJyKSB7CisJCWNhc2UgQlpfT0s6CisJCWNhc2UgQlpfU1RS RUFNX0VORDoKKwkJCS8qIE5vIHByb2JsZW0sIG5yIHdpbGwgYmUgb2theSAqLworCQkJYnJl YWs7CisJCWNhc2UgQlpfREFUQV9FUlJPUl9NQUdJQzoKKwkJCS8qCisJCQkgKiBBcyBvcHBv c2VkIHRvIGd6cmVhZCgpLCB3aGljaCBzaW1wbHkgcmV0dXJucyB0aGUKKwkJCSAqIHBsYWlu IGZpbGUgZGF0YSwgaWYgaXQgaXMgbm90IGluIHRoZSBjb3JyZWN0CisJCQkgKiBjb21wcmVz c2VkIGZvcm1hdCwgQloyX2J6UmVhZCgpIGluc3RlYWQgYWJvcnRzLgorCQkJICoKKwkJCSAq IFNvLCBqdXN0IHJlc3RhcnQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgZmlsZSBhZ2FpbiwK KwkJCSAqIGFuZCB1c2UgcGxhaW4gcmVhZHMgZnJvbSBub3cgb24uCisJCQkgKi8KKwkJCUJa Ml9ielJlYWRDbG9zZSgmYnplcnIsIGJ6YnVmZGVzYyk7CisJCQliemJ1ZmRlc2MgPSBOVUxM OworCQkJaWYgKGxzZWVrKGYtPmZkLCAwLCBTRUVLX1NFVCkgPT0gLTEpCisJCQkJcmV0dXJu IChFT0YpOworCQkJbnIgPSByZWFkKGYtPmZkLCBidWZmZXIsIE1BWEJVRlNJWik7CisJCQli cmVhazsKKwkJZGVmYXVsdDoKKwkJCS8qIE1ha2Ugc3VyZSB3ZSBleGl0IHdpdGggYW4gZXJy b3IgKi8KKwkJCW5yID0gLTE7CisJCX0KKwl9IGVsc2UgeworCQluciA9IHJlYWQoZi0+ZmQs IGJ1ZmZlciwgTUFYQlVGU0laKTsKIAl9Ci0JcmV0dXJuICgtMSk7CisKKwlpZiAobnIgPD0g MCkKKwkJcmV0dXJuIChFT0YpOworCisJYnVmcmVtID0gbnI7CisJcmV0dXJuICgwKTsKIH0K IAotLyoKLSAqIFJldHVybnMgdHJ1ZSBpZiB0aGUgZmlsZSBwb3NpdGlvbiBpcyBhIEVPRiwg cmV0dXJucyBmYWxzZQotICogb3RoZXJ3aXNlLgotICovCi1zdGF0aWMgaW5saW5lIGludAot Z3JlcF9mZW9mKHN0cnVjdCBmaWxlICpmKQorc3RhdGljIGludAorZ3JlcF9sbmJ1Zmdyb3co c2l6ZV90IG5ld2xlbikKIHsKKwl1bnNpZ25lZCBjaGFyICpwOwogCi0Jc3dpdGNoIChmaWxl YmVoYXZlKSB7Ci0JY2FzZSBGSUxFX1NURElPOgotCQlyZXR1cm4gKGZlb2ZfdW5sb2NrZWQo Zi0+ZikpOwotCWNhc2UgRklMRV9HWklQOgotCQlyZXR1cm4gKGd6ZW9mKGYtPmd6ZikpOwot CWNhc2UgRklMRV9CWklQOgotCQlyZXR1cm4gKGJ6ZXJyID09IEJaX1NUUkVBTV9FTkQpOwot CX0KLQlyZXR1cm4gKDEpOworCWlmIChsbmJ1ZmxlbiA+PSBuZXdsZW4pCisJCXJldHVybiAo MCk7CisJaWYgKChwID0gcmVhbGxvYyhsbmJ1ZiwgbmV3bGVuKSkgPT0gTlVMTCkKKwkJcmV0 dXJuIChFT0YpOworCWxuYnVmID0gcDsKKwlsbmJ1ZmxlbiA9IG5ld2xlbjsKKwlyZXR1cm4g KDApOwogfQogCi0vKgotICogQXQgdGhlIGZpcnN0IGNhbGwsIGZpbGxzIGluIGFuIGludGVy bmFsIGJ1ZmZlciBhbmQgY2hlY2tzIGlmIHRoZSBnaXZlbgotICogZmlsZSBpcyBhIGJpbmFy eSBmaWxlIGFuZCBzZXRzIHRoZSBiaW5hcnkgZmxhZyBhY2NvcmRpbmdseS4gIFRoZW4gcmV0 dXJucwotICogYSBzaW5nbGUgbGluZSBhbmQgc2V0cyBsZW4gdG8gdGhlIGxlbmd0aCBvZiB0 aGUgcmV0dXJuZWQgbGluZS4KLSAqIEF0IGFueSBvdGhlciBjYWxsIHJldHVybnMgYSBzaW5n bGUgbGluZSBlaXRoZXIgZnJvbSB0aGUgaW50ZXJuYWwgYnVmZmVyCi0gKiBvciBmcm9tIHRo ZSBmaWxlIGlmIHRoZSBidWZmZXIgaXMgZXhoYXVzdGVkIGFuZCBzZXRzIGxlbiB0byB0aGUg bGVuZ3RoCi0gKiBvZiB0aGUgbGluZS4KLSAqLwogY2hhciAqCi1ncmVwX2ZnZXRsbihzdHJ1 Y3QgZmlsZSAqZiwgc2l6ZV90ICpsZW4pCitncmVwX2ZnZXRsbihzdHJ1Y3QgZmlsZSAqZiwg c2l6ZV90ICpsZW5wKQogewotCXN0cnVjdCBzdGF0IHN0OwotCXNpemVfdCBidWZzaXosIGkg PSAwOwotCWludCBjaCA9IDA7Ci0KLQkvKiBGaWxsIGluIHRoZSBidWZmZXIgaWYgaXQgaXMg ZW1wdHkuICovCi0JaWYgKGJpbmJ1ZnB0ciA9PSBOVUxMKSB7Ci0KLQkJLyogT25seSBwcmUt cmVhZCB0byB0aGUgYnVmZmVyIGlmIHdlIG5lZWQgdGhlIGJpbmFyeSBjaGVjay4gKi8KLQkJ aWYgKGJpbmJlaGF2ZSAhPSBCSU5GSUxFX1RFWFQpIHsKLQkJCWlmIChmLT5zdGRpbikKLQkJ CQlzdC5zdF9zaXplID0gTUFYQlVGU0laOwotCQkJZWxzZSBpZiAoc3RhdChmbmFtZSwgJnN0 KSAhPSAwKQotCQkJCWVycigyLCBOVUxMKTsKLQkJCS8qIG5vIG5lZWQgdG8gYWxsb2NhdGUg YnVmZmVyLiAqLwotCQkJaWYgKHN0LnN0X3NpemUgPT0gMCkKLQkJCQlyZXR1cm4gKE5VTEwp OwotCi0JCQlidWZzaXogPSAoTUFYQlVGU0laID4gKHN0LnN0X3NpemUgKiBQUkVSRUFEX00p KSA/Ci0JCQkgICAgKHN0LnN0X3NpemUgLyAyKSA6IE1BWEJVRlNJWjsKLQotCQkJYmluYnVm ID0gZ3JlcF9tYWxsb2Moc2l6ZW9mKGNoYXIpICogYnVmc2l6KTsKLQotCQkJd2hpbGUgKGkg PCBidWZzaXopIHsKLQkJCQljaCA9IGdyZXBfZmdldGMoZik7Ci0JCQkJaWYgKGNoID09IEVP RikKLQkJCQkJYnJlYWs7Ci0JCQkJYmluYnVmW2krK10gPSBjaDsKLQkJCQlpZiAoKGNoID09 ICdcbicpICYmIGxiZmxhZykKLQkJCQkJYnJlYWs7Ci0JCQl9Ci0KLQkJCWYtPmJpbmFyeSA9 IG1lbWNocihiaW5idWYsIChmaWxlYmVoYXZlICE9IEZJTEVfR1pJUCkgPwotCQkJICAgICdc MCcgOiAnXDIwMCcsIGkgLSAxKSAhPSBOVUxMOwotCQl9Ci0JCWJpbmJ1ZnNpeiA9IGk7Ci0J CWJpbmJ1ZnB0ciA9IGJpbmJ1ZjsKKwl1bnNpZ25lZCBjaGFyICpwOworCWNoYXIgKnJldDsK KwlzaXplX3QgbGVuOworCXNpemVfdCBkaWZmOworCXNpemVfdCBvZmY7CisKKwkvKiBGaWxs IHRoZSBidWZmZXIsIGlmIG5lY2Vzc2FyeSAqLworCWlmIChidWZyZW0gPT0gMCAmJiBncmVw X3JlZmlsbChmKSkgeworZXJyb3I6CisJCSpsZW5wID0gMDsKKwkJcmV0dXJuIChOVUxMKTsK Kwl9CisKKwkvKiBMb29rIGZvciBhIG5ld2xpbmUgaW4gdGhlIHJlbWFpbmluZyBwYXJ0IG9m IHRoZSBidWZmZXIgKi8KKwlpZiAoKHAgPSBtZW1jaHIoYnVmcG9zLCAnXG4nLCBidWZyZW0p KSAhPSBOVUxMKSB7CisJCSsrcDsgLyogYWR2YW5jZSBvdmVyIG5ld2xpbmUgKi8KKwkJcmV0 ID0gYnVmcG9zOworCQlsZW4gPSBwIC0gYnVmcG9zOworCQlidWZyZW0gLT0gbGVuOworCQli dWZwb3MgPSBwOworCQkqbGVucCA9IGxlbjsKKwkJcmV0dXJuIChyZXQpOwogCX0KIAotCS8q IFJlYWQgYSBsaW5lIHdoZXRoZXIgZnJvbSB0aGUgYnVmZmVyIG9yIGZyb20gdGhlIGZpbGUg aXRzZWxmLiAqLwotCWZvciAoaSA9IDA7ICEoZ3JlcF9mZW9mKGYpICYmCi0JICAgIChiaW5i dWZwdHIgPT0gJmJpbmJ1ZltiaW5idWZzaXpdKSk7IGkrKykgewotCQlpZiAoYmluYnVmcHRy ID09ICZiaW5idWZbYmluYnVmc2l6XSkgewotCQkJY2ggPSBncmVwX2ZnZXRjKGYpOwotCQl9 IGVsc2UgewotCQkJY2ggPSBiaW5idWZwdHJbMF07Ci0JCQliaW5idWZwdHIrKzsKLQkJfQot CQlpZiAoaSA+PSBsbmJ1ZmxlbikgewotCQkJbG5idWZsZW4gKj0gMjsKLQkJCWxuYnVmID0g Z3JlcF9yZWFsbG9jKGxuYnVmLCArK2xuYnVmbGVuKTsKLQkJfQotCQlpZiAoKGNoID09ICdc bicpIHx8IChjaCA9PSBFT0YpKSB7Ci0JCQlsbmJ1ZltpXSA9ICdcMCc7Ci0JCQlicmVhazsK LQkJfSBlbHNlCi0JCQlsbmJ1ZltpXSA9IGNoOworCS8qIFdlIGhhdmUgdG8gY29weSB0aGUg Y3VycmVudCBidWZmZXJlZCBkYXRhIHRvIHRoZSBsaW5lIGJ1ZmZlciAqLworCWZvciAobGVu ID0gYnVmcmVtLCBvZmYgPSAwOyA7IGxlbiArPSBidWZyZW0pIHsKKwkJLyogTWFrZSBzdXJl IHRoZXJlIGlzIHJvb20gZm9yIG1vcmUgZGF0YSAqLworCQlpZiAoZ3JlcF9sbmJ1Zmdyb3co bGVuICsgTE5CVUZCVU1QKSkKKwkJCWdvdG8gZXJyb3I7CisJCW1lbWNweShsbmJ1ZiArIG9m ZiwgYnVmcG9zLCBsZW4gLSBvZmYpOworCQlvZmYgPSBsZW47CisJCWlmIChncmVwX3JlZmls bChmKSkKKwkJCWJyZWFrOyAvKiBFT0Ygb3IgZXJyb3I6IHJldHVybiBwYXJ0aWFsIGxpbmUg Ki8KKwkJaWYgKChwID0gbWVtY2hyKGJ1ZnBvcywgJ1xuJywgYnVmcmVtKSkgPT0gTlVMTCkK KwkJCWNvbnRpbnVlOworCQkvKiBnb3QgaXQ6IGZpbmlzaCB1cCB0aGUgbGluZSAobGlrZSBj b2RlIGFib3ZlKSAqLworCQkrK3A7CisJCWRpZmYgPSBwIC0gYnVmcG9zOworCQlsZW4gPSsg ZGlmZjsKKwkJaWYgKGdyZXBfbG5idWZncm93KGxlbikpCisJCSAgICBnb3RvIGVycm9yOwor CQltZW1jcHkobG5idWYgKyBvZmYsIGJ1ZnBvcywgZGlmZik7CisJCWJ1ZnJlbSAtPSBkaWZm OworCQlidWZwb3MgPSBwOworCQlicmVhazsKIAl9Ci0JaWYgKGdyZXBfZmVvZihmKSAmJiAo aSA9PSAwKSAmJiAoY2ggIT0gJ1xuJykpCisJKmxlbnAgPSBsZW47CisJcmV0dXJuIGxuYnVm OworfQorCitzdGF0aWMgc3RydWN0IGZpbGUgKgorZ3JlcF9maWxlX2luaXQoc3RydWN0IGZp bGUgKmYpCit7CisKKwlpZiAoZmlsZWJlaGF2ZSA9PSBGSUxFX0daSVAgJiYKKwkgICAgKGd6 YnVmZGVzYyA9IGd6ZG9wZW4oZi0+ZmQsICJyIikpID09IE5VTEwpIHsKK2Vycm9yOgorCQlp ZiAoIWYtPnN0ZGluKQorCQkJY2xvc2UoZi0+ZmQpOworCQlmcmVlKGYpOwogCQlyZXR1cm4g KE5VTEwpOwotCSpsZW4gPSBpOwotCXJldHVybiAobG5idWYpOworCX0KKworCWlmIChmaWxl YmVoYXZlID09IEZJTEVfQlpJUCAmJgorCSAgICAoYnpidWZkZXNjID0gQloyX2J6ZG9wZW4o Zi0+ZmQsICJyIikpID09IE5VTEwpCisJCWdvdG8gZXJyb3I7CisKKwkvKiBGaWxsIHJlYWQg YnVmZmVyLCBhbHNvIGNhdGNoZXMgZXJyb3JzIGVhcmx5ICovCisJaWYgKGdyZXBfcmVmaWxs KGYpKQorCQlnb3RvIGVycm9yOworCisJLyogQ2hlY2sgZm9yIGJpbmFyeSBzdHVmZiwgaWYg bmVjZXNzYXJ5ICovCisJaWYgKGJpbmJlaGF2ZSAhPSBCSU5GSUxFX1RFWFQgJiYgbWVtY2hy KGJ1ZnBvcywgJ1wwJywgYnVmcmVtKSAhPSBOVUxMKQorCQlmLT5iaW5hcnkgPSB0cnVlOwor CisJcmV0dXJuIChmKTsKIH0KIAogLyoKQEAgLTE5Miw3NyArMjE0LDQ2IEBAIGdyZXBfc3Rk aW5fb3Blbih2b2lkKQogCS8qIFByb2Nlc3Npbmcgc3RkaW4gaW1wbGllcyAtLWxpbmUtYnVm ZmVyZWQgZm9yIHRhaWwgLWYgdG8gd29yay4gKi8KIAlsYmZsYWcgPSB0cnVlOwogCi0Jc25w cmludGYoZm5hbWUsIHNpemVvZiBmbmFtZSwgIiVzIiwgZ2V0c3RyKDEpKTsKLQogCWYgPSBn cmVwX21hbGxvYyhzaXplb2YgKmYpOworCW1lbXNldChmLCAwLCBzaXplb2YgKmYpOworCWYt PmZkID0gU1RESU5fRklMRU5POworCWYtPnN0ZGluID0gdHJ1ZTsKIAotCWJpbmJ1ZiA9IE5V TEw7Ci0JaWYgKChmLT5mID0gZmRvcGVuKFNURElOX0ZJTEVOTywgInIiKSkgIT0gTlVMTCkg ewotCQlmbG9ja2ZpbGUoZi0+Zik7Ci0JCWYtPnN0ZGluID0gdHJ1ZTsKLQkJcmV0dXJuIChm KTsKLQl9Ci0KLQlmcmVlKGYpOwotCXJldHVybiAoTlVMTCk7CisJcmV0dXJuIGdyZXBfZmls ZV9pbml0KGYpOwogfQogCiAvKgotICogT3BlbnMgYSBub3JtYWwsIGEgZ3ppcHBlZCBvciBh IGJ6aXAyIGNvbXByZXNzZWQgZmlsZSBmb3IgcHJvY2Vzc2luZy4KKyAqIE9wZW5zIGEgZmls ZSBmb3IgcHJvY2Vzc2luZy4KICAqLwogc3RydWN0IGZpbGUgKgogZ3JlcF9vcGVuKGNvbnN0 IGNoYXIgKnBhdGgpCiB7CiAJc3RydWN0IGZpbGUgKmY7CiAKLQlzbnByaW50ZihmbmFtZSwg c2l6ZW9mIGZuYW1lLCAiJXMiLCBwYXRoKTsKLQogCWYgPSBncmVwX21hbGxvYyhzaXplb2Yg KmYpOwotCi0JYmluYnVmID0gTlVMTDsKLQlmLT5zdGRpbiA9IGZhbHNlOwotCXN3aXRjaCAo ZmlsZWJlaGF2ZSkgewotCWNhc2UgRklMRV9TVERJTzoKLQkJaWYgKChmLT5mID0gZm9wZW4o cGF0aCwgInIiKSkgIT0gTlVMTCkgewotCQkJZmxvY2tmaWxlKGYtPmYpOwotCQkJcmV0dXJu IChmKTsKLQkJfQotCQlicmVhazsKLQljYXNlIEZJTEVfR1pJUDoKLQkJaWYgKChmLT5nemYg PSBnem9wZW4oZm5hbWUsICJyIikpICE9IE5VTEwpCi0JCQlyZXR1cm4gKGYpOwotCQlicmVh azsKLQljYXNlIEZJTEVfQlpJUDoKLQkJaWYgKChmLT5iemYgPSBCWjJfYnpvcGVuKGZuYW1l LCAiciIpKSAhPSBOVUxMKQotCQkJcmV0dXJuIChmKTsKLQkJYnJlYWs7CisJbWVtc2V0KGYs IDAsIHNpemVvZiAqZik7CisJaWYgKChmLT5mZCA9IG9wZW4ocGF0aCwgT19SRE9OTFkpKSA9 PSAtMSkgeworCQlmcmVlKGYpOworCQlyZXR1cm4gKE5VTEwpOwogCX0KIAotCWZyZWUoZik7 Ci0JcmV0dXJuIChOVUxMKTsKKwlyZXR1cm4gZ3JlcF9maWxlX2luaXQoZik7CiB9CiAKIC8q Ci0gKiBDbG9zZXMgYSBub3JtYWwsIGEgZ3ppcHBlZCBvciBhIGJ6aXAyIGNvbXByZXNzZWQg ZmlsZS4KKyAqIENsb3NlcyBhIGZpbGUuCiAgKi8KIHZvaWQKIGdyZXBfY2xvc2Uoc3RydWN0 IGZpbGUgKmYpCiB7CiAKLQlzd2l0Y2ggKGZpbGViZWhhdmUpIHsKLQljYXNlIEZJTEVfU1RE SU86Ci0JCWZ1bmxvY2tmaWxlKGYtPmYpOwotCQlmY2xvc2UoZi0+Zik7Ci0JCWJyZWFrOwot CWNhc2UgRklMRV9HWklQOgotCQlnemNsb3NlKGYtPmd6Zik7Ci0JCWJyZWFrOwotCWNhc2Ug RklMRV9CWklQOgotCQlCWjJfYnpjbG9zZShmLT5iemYpOwotCQlicmVhazsKLQl9CisJY2xv c2UoZi0+ZmQpOwogCi0JLyogUmVzZXQgcmVhZCBidWZmZXIgZm9yIHRoZSBmaWxlIHdlIGFy ZSBjbG9zaW5nICovCi0JYmluYnVmcHRyID0gTlVMTDsKLQlmcmVlKGJpbmJ1Zik7CisJLyog UmVzZXQgcmVhZCBidWZmZXIgYW5kIGxpbmUgYnVmZmVyICovCisJYnVmcG9zID0gYnVmZmVy OworCWJ1ZnJlbSA9IDA7CisKKwlmcmVlKGxuYnVmKTsKKwlsbmJ1ZiA9IE5VTEw7CisJbG5i dWZsZW4gPSAwOwogfQpkaWZmIC0tZ2l0IGEvdXNyLmJpbi9ncmVwL2dyZXAuaCBiL3Vzci5i aW4vZ3JlcC9ncmVwLmgKaW5kZXggMmY3NDNlNC4uOTY3ZDQ2NCAxMDA2NDQKLS0tIGEvdXNy LmJpbi9ncmVwL2dyZXAuaAorKysgYi91c3IuYmluL2dyZXAvZ3JlcC5oCkBAIC03NywxMCAr NzcsNyBAQCBleHRlcm4gY29uc3QgY2hhcgkJKmVycnN0cltdOwogI2RlZmluZSBNQVhfTElO RV9NQVRDSEVTCTMyCiAKIHN0cnVjdCBmaWxlIHsKLQlzdHJ1Y3QgbW1maWxlCSptbWY7Ci0J QlpGSUxFCQkqYnpmOwotCUZJTEUJCSpmOwotCWd6RmlsZQkJKmd6ZjsKKwlpbnQJCSBmZDsK IAlib29sCQkgYmluYXJ5OwogCWJvb2wJCSBzdGRpbjsKIH07CkBAIC0xNTcsNCArMTU0LDQg QEAgY2hhcgkJKmdyZXBfZmdldGxuKHN0cnVjdCBmaWxlICpmLCBzaXplX3QgKmxlbik7CiAv KiBmYXN0Z3JlcC5jICovCiBpbnQJCSBmYXN0Y29tcChmYXN0Z3JlcF90ICosIGNvbnN0IGNo YXIgKik7CiB2b2lkCQkgZmdyZXBjb21wKGZhc3RncmVwX3QgKiwgY29uc3QgY2hhciAqKTsK LWludAkJIGdyZXBfc2VhcmNoKGZhc3RncmVwX3QgKiwgdW5zaWduZWQgY2hhciAqLCBzaXpl X3QsIHJlZ21hdGNoX3QgKik7CitpbnQJCSBncmVwX3NlYXJjaChmYXN0Z3JlcF90ICosIGNv bnN0IHVuc2lnbmVkIGNoYXIgKiwgc2l6ZV90LCByZWdtYXRjaF90ICopOwo= --------------030707040809090904070205-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 11:10:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1A6410656A8; Mon, 16 Aug 2010 11:10:21 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 875838FC1A; Mon, 16 Aug 2010 11:10:21 +0000 (UTC) Received: by iwn10 with SMTP id 10so1814466iwn.13 for ; Mon, 16 Aug 2010 04:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=IqUpVuGQKnkgymqPV6GqyldPRF1+PnWmE+udadVEm6s=; b=ZwlKD3pwNA9XbL3gJ4PyyTZ3Sa0l3byfn6HB7Hdx92/G0NuT8RdK8G+ll0cyl6AgIE jNFqqYVDx18jqFnALXxOGKlz1z/iAnhftfy1dJkrl5ajoCLIa2GPifW6tw/Gv6/IhS2H KgUhoUWeLQOc++Fc77jGrPL5eJDOHp19U5qrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ru0gckSHUlJSOLJEsGXP6BI6JJwK1Cpiq9j57hDXeIWfMnGfDc1B6jV8lyWgo/yVfM L8K2XjuT+otlZ9YbEN/DIDGGh7NvugSIq1PqrscNQN0heqXhyWeZlEEZ+qq0RHuXU0kl D7Jawt40Rr647M9DbL1C1ESIOq468Y2QNjbh4= MIME-Version: 1.0 Received: by 10.231.12.74 with SMTP id w10mr5615667ibw.189.1281955715871; Mon, 16 Aug 2010 03:48:35 -0700 (PDT) Sender: baptiste.daroussin@gmail.com Received: by 10.231.208.15 with HTTP; Mon, 16 Aug 2010 03:48:35 -0700 (PDT) In-Reply-To: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> Date: Mon, 16 Aug 2010 10:48:35 +0000 X-Google-Sender-Auth: Kv-grkH25YX2suFfuufHCJGDSPk Message-ID: From: Baptiste Daroussin To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 11:10:22 -0000 > zsh =A0 =A0 less POSIX-compliant, oddly deviant from "standard" > =A0 =A0 =A0 =A0bourne-derived shells which makes graybeards break out in = hives > =A0 =A0 =A0 =A0also, see ruby under user community ZSH has a POSIX-compliant interface through emulate -L sh or by naming (linking) zsh binary sh. even if the man page says that the posix compliance isn't complete from my own tests it is at least as compliant as bash. For example I'm able to run portmaster using zsh instead of sh. (by the way it is a lot faster using zsh :) but that is another storry) -- Bapt From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 11:25:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F345F1065673 for ; Mon, 16 Aug 2010 11:25:03 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED158FC19 for ; Mon, 16 Aug 2010 11:25:03 +0000 (UTC) Received: by qwg5 with SMTP id 5so5570383qwg.13 for ; Mon, 16 Aug 2010 04:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=+SDADoCeGQtv8uTnthLVDG03bPAtO9NaJLnuR+nexhM=; b=lgWLoZIU/7zZk7W6XBHSfck0Zrf1aw2IF+sFF8Gh7ogkdMBLXkB8oeY43z+u4cweO2 9BP8dSWmMFcZAFDHUP9wTv6LQaZPNS8ol9KtIQmkNDF8M64dhrvk5DTWPHVcTV+0DJIq ss8JSdabwKp5O6ldTCA02uZ8Nj7Hdw7Res0V8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rQC01dCpoqGDi1d+Y1Nf8H9OtPAEiRF8d/wo8MmXLQgBNPQSG7lBNiLtLKoYEfn8ds UBhxN9jFINtU2GUdkxpLe1RL2wlQ/NWO59epPVN4JxXmnJw34rcqtDU56GxZQmbWM3MF 7d1w/VvG/Nel9u4w2YQ1/wIgzYT8kxir+DKPc= Received: by 10.229.213.80 with SMTP id gv16mr3530860qcb.134.1281957781168; Mon, 16 Aug 2010 04:23:01 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Mon, 16 Aug 2010 04:22:41 -0700 (PDT) In-Reply-To: <86ocd3apzl.fsf@ds4.des.no> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <86ocd3apzl.fsf@ds4.des.no> From: Ivan Voras Date: Mon, 16 Aug 2010 13:22:41 +0200 X-Google-Sender-Auth: nhh5QmE6QF90oRQ3AeskPTYDweI Message-ID: To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 11:25:04 -0000 2010/8/16 Dag-Erling Sm=C3=B8rgrav : > Doug Barton writes: >> lua =C2=A0 too "flavor of the day," not enough track record of stability= , >> =C2=A0 =C2=A0 =C2=A0 not enough installed base/proven utility > > You're wrong. =C2=A0Lua has been around for ages and is especially widely > used as a game scripting engine. =C2=A0It is not intended as a standalone > language, but as an embeddable scripting engine. =C2=A0We could easily cr= eate > our own scripting language based on lua with FreeBSD-specific functions, > and there would be no fear of interfering with third-party software, > because it wouldn't be called lua. Replying randomly to this post but also to phk's, dougb's and others' points specifically about lua: 1. "churn" / version stability / "language of the day" History of lua's recent releases is: - 5.2 : TBD, new yet unfinished release, "will be done when it is done" - 5.1 : 2006. - 5.0 : 2003. - 4.0 : 2000. ... - 1.0 : 1993. [source: http://www.lua.org/versions.html] If anything, it's much slower than the "hip" languages. 2. Future compatibility / ports dependancies, etc. If anything gets imported, lua or something else, I will loudly support renaming it to something like "bsdscript", binaries and libraries and all. 3. Size of language Lua *is* 32 C files (and as many C headers) in a single directory, totalling (with headers) a bit over 17,000 lines. The interpreter can be compiled with "gcc -o bsdscript *.c". Libraries can be built similarly. There are no other libraries or modules which "make" lua, Among the mentioned above are equivalents of stdio, libm, libz, etc. 4. Embeddability Here's the documentation: http://www.lua.org/pil/24.1.html Personally, I'm more interested in the opposite direction: writing FreeBSD-specific lua libraries (which would wrap, as an obvious example coming from me, libgeom) making it possible to script complex system scripts in lua. 5. License Released under MIT license: http://www.lua.org/license.html From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 11:35:01 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B90D6106566C for ; Mon, 16 Aug 2010 11:35:01 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 420618FC08 for ; Mon, 16 Aug 2010 11:35:00 +0000 (UTC) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7GA41o1014862 for ; Mon, 16 Aug 2010 20:04:03 +1000 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7GA3svK007294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 20:03:57 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o7GA3qBI006336; Mon, 16 Aug 2010 20:03:52 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o7GA3qIi006335; Mon, 16 Aug 2010 20:03:52 +1000 (EST) (envelope-from peter) Date: Mon, 16 Aug 2010 20:03:52 +1000 From: Peter Jeremy To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20100816100352.GA6255@server.vk2pj.dyndns.org> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <86sk2faqdl.fsf@ds4.des.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 11:35:01 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Aug-16 10:55:18 +0200, Dag-Erling Sm=F8rgrav wrote: >It might be worth a shot adding mmap(2) support as well, i.e. when >processing an uncompressed regular file, try to mmap(2) it first, and if >that fails, fall back to the plain buffered read(2) method. Note that ZFS and mmap() don't get on especially well together so this isn't a definite win. You also need to allow for files that are too large to be mapped in one go. --=20 Peter Jeremy --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxpDQgACgkQ/opHv/APuId/oQCfWVrBX6Qn1Lq5ZeImbqpzxWCo WAwAoIWR36t/AYpTfuqK3BwuSbuDl26H =7JaF -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 13:52:20 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B010F1065670; Mon, 16 Aug 2010 13:52:20 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id 691738FC15; Mon, 16 Aug 2010 13:52:20 +0000 (UTC) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.4/8.14.4) with ESMTP id o7GDqFep050015; Mon, 16 Aug 2010 08:52:16 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Mon, 16 Aug 2010 08:52:15 -0500 (CDT) From: "Sean C. Farley" To: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86y6c7bse5.fsf@ds4.des.no> Message-ID: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <86y6c7bse5.fsf@ds4.des.no> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="56599777-1799541866-1281964549=:21804" Content-ID: X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_00,SPF_SOFTFAIL, T_FRT_PROFILE2 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.farley.org Cc: Gabor Kovesdan , current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 13:52:20 -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. --56599777-1799541866-1281964549=:21804 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Sun, 15 Aug 2010, Dag-Erling Smørgrav wrote: > "Sean C. Farley" writes: >> This should trim some time off BSD grep. > > Did you actually test your patch? It makes absolutely no measurable > difference. Yes, I saw a reduction, using the first test script Doug provided, from 36 to 27 seconds. I only sent the patch after profiling confirmed a reduction. The script ran non-profiled grep 100 times. "Trim" did not imply it would reduce the time from 36 to 2 seconds. Here are profiles of one execution of bsdgrep using the parameters from the script. Non-patched grep (cumulative time 4.17 seconds): % cumulative self self total time seconds seconds calls ms/call ms/call name 79.5 3.32 3.32 0 100.00% _mcount [1] 7.9 3.65 0.33 0 100.00% .mcount (106) 4.5 3.83 0.19 21971711 0.00 0.00 fgetc [7] 3.5 3.98 0.15 21993762 0.00 0.00 grep_feof [8] 2.5 4.09 0.10 21971711 0.00 0.00 grep_fgetc [6] 1.5 4.15 0.06 22051 0.00 0.02 grep_fgetln [5] 0.5 4.17 0.02 1352 0.02 0.02 read [9] 0.0 4.17 0.00 67 0.02 0.02 memset [14] 0.0 4.17 0.00 61 0.01 0.01 arena_run_split [17] 0.0 4.17 0.00 1 0.50 522.57 procfile [4] ... Patched grep (cumulative time 2.82 seconds): % cumulative self self total time seconds seconds calls ms/call ms/call name 77.4 2.19 2.19 0 100.00% _mcount [1] 8.4 2.42 0.24 0 100.00% .mcount (109) 6.1 2.60 0.17 21971711 0.00 0.00 grep_fgetc [6] 4.9 2.74 0.14 21993762 0.00 0.00 grep_feof [7] 2.7 2.81 0.08 22051 0.00 0.02 grep_fgetln [5] 0.3 2.82 0.01 1352 0.01 0.01 _read [10] 0.1 2.82 0.00 67 0.03 0.03 memset [13] 0.1 2.82 0.00 10 0.15 0.15 free [16] 0.0 2.82 0.00 1 1.00 398.11 procfile [4] ... getc_unlocked() is merely a macro around __sgetr() as opposed to calling into getc(). My patch was to show it could be reduced by removing some of stdio's overhead (one function call and unneeded locking). I did not have time to do a complete removal of stdio as I was unsure of any dependencies this version of bsdgrep had on stdio. For some reason, I thought there was mention of making bsdgrep into an application and library. If threading became involved, losing fgetc() would help more. Without threading, the test for locking would still be performed in getc(). Sean -- scf@FreeBSD.org --56599777-1799541866-1281964549=:21804-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 14:11:36 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D731065673; Mon, 16 Aug 2010 14:11:36 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 074F38FC0A; Mon, 16 Aug 2010 14:11:35 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D9E7B1FFC33; Mon, 16 Aug 2010 14:11:34 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2F6AB84567; Mon, 16 Aug 2010 16:11:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sean C. Farley" References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <86y6c7bse5.fsf@ds4.des.no> Date: Mon, 16 Aug 2010 16:11:33 +0200 In-Reply-To: (Sean C. Farley's message of "Mon, 16 Aug 2010 08:52:15 -0500 (CDT)") Message-ID: <8639ue4pgq.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Gabor Kovesdan , current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 14:11:36 -0000 "Sean C. Farley" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Did you actually test your patch? It makes absolutely no measurable > > difference. > Yes, I saw a reduction, I didn't... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 16:47:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C301065672 for ; Mon, 16 Aug 2010 16:47:43 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 868258FC19 for ; Mon, 16 Aug 2010 16:47:42 +0000 (UTC) Received: by wwb24 with SMTP id 24so3584003wwb.31 for ; Mon, 16 Aug 2010 09:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=DotwafOn+wmfUO7w/j6yQUv7TBC72dDq6/uXYCZGLzc=; b=P37pGlNzKFLRghogqDYoLLFcmqMg8C+QdhiikubPVZuM7+lxwHaYn5WThEXVZTMdzP w5n+hI5yl/3pizj5guBsnOFvmaAwHYu96mpbhCXu603Nt5fqOy9wrN/IACacDecNPg3t jsvEpD8zgrvPVF7GIZLByvRP+I72Jb5w079H4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=lQjgpwvC6AwzMazwbA1JICJZuUzmBmNNSTPn9DmPLC+022POmfez+MUECntdWp4/WJ YrFy2Am48KmmI5Hg7utwhbc80/b1AtIOPCopj7CAR0gbHsgtPEMn4RcIJzvHr/GHLXMy U9r3pUrEzyz+LXo6vTdvUcPwBMWjvLu9cn7iQ= Received: by 10.227.145.5 with SMTP id b5mr4607460wbv.189.1281977261373; Mon, 16 Aug 2010 09:47:41 -0700 (PDT) Received: from localhost (server51262.uk2net.com [83.170.92.9]) by mx.google.com with ESMTPS id w32sm4763516wbd.19.2010.08.16.09.47.37 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 09:47:39 -0700 (PDT) From: Anonymous To: Randy Bush References: Date: Mon, 16 Aug 2010 20:47:25 +0400 In-Reply-To: (Randy Bush's message of "Mon, 16 Aug 2010 17:50:22 +0900") Message-ID: <86aaomec82.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: FreeBSD current mailing list Subject: Re: better way than hacking termcap to be ca_mode free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:47:43 -0000 Randy Bush writes: > is there a better way to achieve this? Not sure about ~/.termcap but you can just override ti/te via TERMCAP in environment. $ export TERM=${TERM:-xterm} $ export TERMCAP=${TERM}:ti@:te@:tc=${TERM}: > > *** termcap.FCS Tue Jun 17 15:10:46 2003 > --- termcap Tue Jun 17 15:14:15 2003 > *************** > *** 299,305 **** > adm3|3|lsi adm3:\ > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > xterm|xterm-color|X11 terminal emulator:\ > ! :ti@:te@:tc=xterm-xfree86: > # > # DESCRIPTION: > # This file describes capabilities of various terminals, as needed by > --- 299,305 ---- > adm3|3|lsi adm3:\ > :do=^J:am:le=^H:bs:cl=^Z:li#24:ma=^K^P:co#80: > xterm|xterm-color|X11 terminal emulator:\ > ! :tc=xterm-xfree86: > # > # DESCRIPTION: > # This file describes capabilities of various terminals, as needed by I guess the diff is not for termcap file from /head. From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 17:05:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E688310656AA for ; Mon, 16 Aug 2010 17:05:15 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9F68FC0A for ; Mon, 16 Aug 2010 17:05:15 +0000 (UTC) Received: by qyk11 with SMTP id 11so3593083qyk.13 for ; Mon, 16 Aug 2010 10:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=mEwvsOYFud09LaX54DCc3vd9wjSpYXzMezZV7CeZUtM=; b=doUOXdVD6g36Gpav/wn3VAVaNZo2dLSquG9pv9yju+h99p/zMe+PkDUvpLzQ1qzzhU 5LOU+PVQDLNhvzXZEKY8v6EKYwEOJ96rRvLOpcik9Zekj0TNrHagG32tnBk04eC4Sk3v UpEumR+k+SsZFLjpa/6ckxxUuHd7ZGB3FWtG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UUiig0TqzVBKaS9W0k/VyT+B61DdO+E7Hy7bnXPrpz3pn+IwqpwOSEzVPcHxH8ezKF o3JsUuXsYwjBC+HfhDAnn2s2LVPGwehefTxhLCJ3XK2Lc9lE984n2K//0HW/8P1/nf28 +WA1qSU02bOZeb/vXzXOzwiCuymeFTczudEdQ= MIME-Version: 1.0 Received: by 10.229.65.159 with SMTP id j31mr376883qci.212.1281978314598; Mon, 16 Aug 2010 10:05:14 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Mon, 16 Aug 2010 10:05:14 -0700 (PDT) Date: Mon, 16 Aug 2010 21:05:14 +0400 Message-ID: From: pluknet To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 17:05:16 -0000 Hi. Seeing on mostly idle, recently updated current, while closing a file. Presumably never reported on ML. lock order reversal: 1st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0xffffff000234a048 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1580 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 fdinit() at fdinit+0x5b fdcopy() at fdcopy+0x2a fork1() at fork1+0x836 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = 0x7fffffffea88, rbp = 0 --- -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 17:07:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BFC710656A9 for ; Mon, 16 Aug 2010 17:07:26 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E22C8FC1F for ; Mon, 16 Aug 2010 17:07:25 +0000 (UTC) Received: by qwg5 with SMTP id 5so5948503qwg.13 for ; Mon, 16 Aug 2010 10:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jzSgsKoSE0qf8NUNpV16afTzDW8sR6Z2S+mSsAOyAnk=; b=Yyql6uQvUtO9slOXXRntWUvw4BpUFzXdkxJ3tKI66NPy4QV31m5++RjpN9sF6+ZDHv O6QDibc1q1/i6XnjWrjLAD7TEtMde8N8smYLg5UoR5o/jXxg/v0Kpt34veokmBO+vBSt TTsC45bCoVQzIS/MG0tATYEqu17t023zUVEfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Gyd5vyqH3u86wi8xBPwXFQCaxV20TFu7hSP+7JR2p9Dsmaz6KJD3tieJmvOMlQUUjs qSB3Cjbxyn5Kq7TZvfZZ0bZAYtl6qK15wx6FpaaOp6XHWEFgOCsjktYuMKqejttdolfb Q0UhanJkCt43bvuad8CXk4+AuXo9FvA1A/Rlw= MIME-Version: 1.0 Received: by 10.224.123.146 with SMTP id p18mr3521505qar.4.1281978444982; Mon, 16 Aug 2010 10:07:24 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Mon, 16 Aug 2010 10:07:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Aug 2010 21:07:24 +0400 Message-ID: From: pluknet To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 17:07:26 -0000 On 16 August 2010 21:05, pluknet wrote: > Hi. > > Seeing on mostly idle, recently updated current, while closing a file. > Presumably never reported on ML. > > lock order reversal: > =A01st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > =A02nd 0xffffff000234a048 filedesc structure (filedesc structure) @ > /usr/src/sys/kern/kern_descrip.c:1580 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _sx_xlock() at _sx_xlock+0x55 > fdinit() at fdinit+0x5b > fdcopy() at fdcopy+0x2a > fork1() at fork1+0x836 > kproc_create() at kproc_create+0x63 > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > nfs_asyncio() at nfs_asyncio+0xa6 > nfs_strategy() at nfs_strategy+0x83 > bufstrategy() at bufstrategy+0x43 > nfs_writebp() at nfs_writebp+0xcf > nfs_flush() at nfs_flush+0x1dc > nfs_close() at nfs_close+0x213 > vn_close() at vn_close+0x10e > vn_closefile() at vn_closefile+0x5a > _fdrop() at _fdrop+0x23 > closef() at closef+0x5b > kern_close() at kern_close+0x110 > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > --- syscall (6, FreeBSD ELF64, close), rip =3D 0x80089830c, rsp =3D > 0x7fffffffea88, rbp =3D 0 --- > > Mostly the same (different 2nd lock path). lock order reversal: 1st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0xffffffff80ca47e0 proctree (proctree) @ /usr/src/sys/kern/kern_fork.c= :335 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_slock() at _sx_slock+0x55 fork1() at fork1+0x190 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip =3D 0x80089830c, rsp =3D 0x7fffffffea88, rbp =3D 0 --- --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 18:55:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76AEC106566C for ; Mon, 16 Aug 2010 18:55:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5A58FC20 for ; Mon, 16 Aug 2010 18:55:00 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7GIsu0g009772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 21:54:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7GIsugv020619; Mon, 16 Aug 2010 21:54:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7GIsuKn020618; Mon, 16 Aug 2010 21:54:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Aug 2010 21:54:56 +0300 From: Kostik Belousov To: pluknet Message-ID: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1pyOwMoA9G3DWfK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:55:01 -0000 --X1pyOwMoA9G3DWfK Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: > On 16 August 2010 21:05, pluknet wrote: > > Hi. > > > > Seeing on mostly idle, recently updated current, while closing a file. > > Presumably never reported on ML. > > > > lock order reversal: > > =9A1st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > > =9A2nd 0xffffff000234a048 filedesc structure (filedesc structure) @ > > /usr/src/sys/kern/kern_descrip.c:1580 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x807 > > _sx_xlock() at _sx_xlock+0x55 > > fdinit() at fdinit+0x5b > > fdcopy() at fdcopy+0x2a > > fork1() at fork1+0x836 > > kproc_create() at kproc_create+0x63 > > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > > nfs_asyncio() at nfs_asyncio+0xa6 > > nfs_strategy() at nfs_strategy+0x83 > > bufstrategy() at bufstrategy+0x43 > > nfs_writebp() at nfs_writebp+0xcf > > nfs_flush() at nfs_flush+0x1dc > > nfs_close() at nfs_close+0x213 > > vn_close() at vn_close+0x10e > > vn_closefile() at vn_closefile+0x5a > > _fdrop() at _fdrop+0x23 > > closef() at closef+0x5b > > kern_close() at kern_close+0x110 > > syscallenter() at syscallenter+0x1aa > > syscall() at syscall+0x4c > > Xfast_syscall() at Xfast_syscall+0xe2 > > --- syscall (6, FreeBSD ELF64, close), rip =3D 0x80089830c, rsp =3D > > 0x7fffffffea88, rbp =3D 0 --- > > > > >=20 > Mostly the same (different 2nd lock path). >=20 > lock order reversal: > 1st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > 2nd 0xffffffff80ca47e0 proctree (proctree) @ /usr/src/sys/kern/kern_fork= .c:335 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x807 > _sx_slock() at _sx_slock+0x55 > fork1() at fork1+0x190 > kproc_create() at kproc_create+0x63 > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > nfs_asyncio() at nfs_asyncio+0xa6 > nfs_strategy() at nfs_strategy+0x83 > bufstrategy() at bufstrategy+0x43 > nfs_writebp() at nfs_writebp+0xcf > nfs_flush() at nfs_flush+0x1dc > nfs_close() at nfs_close+0x213 > vn_close() at vn_close+0x10e > vn_closefile() at vn_closefile+0x5a > _fdrop() at _fdrop+0x23 > closef() at closef+0x5b > kern_close() at kern_close+0x110 > syscallenter() at syscallenter+0x1aa > syscall() at syscall+0x4c > Xfast_syscall() at Xfast_syscall+0xe2 > --- syscall (6, FreeBSD ELF64, close), rip =3D 0x80089830c, rsp =3D > 0x7fffffffea88, rbp =3D 0 --- >=20 Both LORs are valid. The fork performed deep inside the VFS call stack is obviously problematic. As a workaround, you may fix the number of nfsiods. Proper fix might consist of creating a shepherd thread which only task is to act on the requests on creating new nfsiods. Would you try to implement this ? I will provide the assistance, if needed. --X1pyOwMoA9G3DWfK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxpiX8ACgkQC3+MBN1Mb4hvegCgrnKToTzUoPP1aF9vdPsc7NZ8 u9QAoLhcPEITehKNH1Q21vDsI79dxwMA =LVpk -----END PGP SIGNATURE----- --X1pyOwMoA9G3DWfK-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 19:18:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66E141065670; Mon, 16 Aug 2010 19:18:43 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id DE5288FC08; Mon, 16 Aug 2010 19:18:42 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id F36B714DC69D; Mon, 16 Aug 2010 21:18:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kVdx2aq1Pz7P; Mon, 16 Aug 2010 21:18:39 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id B080A14DC64C; Mon, 16 Aug 2010 21:18:39 +0200 (CEST) Message-ID: <4C698F0E.5080408@FreeBSD.org> Date: Mon, 16 Aug 2010 21:18:38 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Dimitry Andric References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> In-Reply-To: <4C6844D8.5070602@andric.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Steve Kargl , =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:18:43 -0000 Em 2010.08.15. 21:49, Dimitry Andric escreveu: > GNU grep > Elapsed time: 57 seconds > > BSD grep (original) > Elapsed time: 820 seconds (~14.4x slower than GNU grep) > > BSD grep (quickfixed) > Elapsed time: 115 seconds (~2.0x slower than GNU grep) > > It proves that getting rid of the fgetc's is certainly worthwhile, and I > have attached a more complete patch that: > > - Replaces the horrendously inefficient grep_fgetln() with mostly the > same implementation as the libc fgetln() function. > - Uses plain file descriptors instead of struct FILE, since the > buffering is done manually anyway, and it makes it easier to support > gzip and bzip2. > - Let the bzip2 reader just read the file as plain data, when the > initial magic number doesn't match, mimicking the behaviour of GNU > grep. > > There is probably more room for optimization, but let's see if this > survives a bunch of tests first. :) > Thanks Dmitry, I've also started to work on a similar solution but you were extremely fast. :) I'm checking your patch just now and will tell my experiences if I see any regression. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 19:19:28 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B4BD1065694 for ; Mon, 16 Aug 2010 19:19:28 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 4D60E8FC29 for ; Mon, 16 Aug 2010 19:19:28 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id A54A714DC6A5; Mon, 16 Aug 2010 21:19:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FJ2qmOnyRUmh; Mon, 16 Aug 2010 21:19:25 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 693AE14DC69D; Mon, 16 Aug 2010 21:19:25 +0200 (CEST) Message-ID: <4C698F3C.4070104@FreeBSD.org> Date: Mon, 16 Aug 2010 21:19:24 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <86y6c7bse5.fsf@ds4.des.no> <8639ue4pgq.fsf@ds4.des.no> In-Reply-To: <8639ue4pgq.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: current@FreeBSD.org, "Sean C. Farley" Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:19:28 -0000 Em 2010.08.16. 16:11, Dag-Erling Smørgrav escreveu: > "Sean C. Farley" writes: > >> Dag-Erling Smørgrav writes: >> >>> Did you actually test your patch? It makes absolutely no measurable >>> difference. >>> >> Yes, I saw a reduction, >> > I didn't... > I also saw a reduction by 8-30% depending on the particular case. Gabor From owner-freebsd-current@FreeBSD.ORG Mon Aug 16 21:32:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E94A1065670; Mon, 16 Aug 2010 21:32:31 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite.broker.freenet6.net [IPv6:2001:5c0:1000:b::599b]) by mx1.freebsd.org (Postfix) with ESMTP id 659E78FC12; Mon, 16 Aug 2010 21:32:30 +0000 (UTC) Received: from [10.0.0.10] (phenom.otrada.od.ua [10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.3/8.14.3) with ESMTP id o7GLWOvJ020879; Tue, 17 Aug 2010 00:32:25 +0300 (EEST) (envelope-from universite@ukr.net) X-Authentication-Warning: otrada.od.ua: Host phenom.otrada.od.ua [10.0.0.10] claimed to be [10.0.0.10] Message-ID: <4C69AE22.2030201@ukr.net> Date: Tue, 17 Aug 2010 00:31:14 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mary-teresa.otrada.od.ua X-Virus-Scanned: clamav-milter 0.95.3 at mary-teresa.otrada.od.ua X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Performance AMD Phenom II X6 1090T X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:32:31 -0000 Is there anyone using AMD Phenom II X6 1090T? What can you say about it's performance? Have you any tasks that use all 6-cores? Does it balance workload between all 6 cores properly? I am interested how it will work specifically under 8.1-RELEASE and 9.0-CURRENT. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 01:53:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C17F10656A4 for ; Tue, 17 Aug 2010 01:53:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 244638FC16 for ; Tue, 17 Aug 2010 01:53:15 +0000 (UTC) Received: (qmail 9072 invoked by uid 399); 17 Aug 2010 01:53:15 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Aug 2010 01:53:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C69EB89.2090605@FreeBSD.org> Date: Mon, 16 Aug 2010 18:53:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C673898.2080609@FreeBSD.org> <20100816.094740.74728369.sthaug@nethelp.no> In-Reply-To: <20100816.094740.74728369.sthaug@nethelp.no> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 01:53:16 -0000 On 08/16/2010 00:47, sthaug@nethelp.no wrote: > If I only wanted a kernel and everything else as installable packages, > I might as well use one of the Linux distributions. That wasn't at all what I said, or what I was suggesting. There is a middle ground between "everything is a package" and the status quo. The fact that people keep asking for more things to be in the base that clearly don't/can't belong there is evidence of this. Meanwhile, to respond more or less generally to some of the specific responses I received: 1. My descriptions of the various possible things to import were meant to be tongue-in-cheek, not exhaustive technical reviews of the alternatives. The fact that some people "bit" on those, particularly the ones that described rabid user communities, is, well, funny. :) 2. phk's description of the the situation with tcl is both more eloquent and more complete than I could have come up with, which is why I didn't mention it in my previous post. Although the situation with perl is more vivid for me since I was directly affected by it my recollections of the tcl thing match his description, and more importantly I agree with him that it should be viewed as a cautionary tale. 3. In case I wasn't clear in my last post the correct answer at this time is neither "import more stuff into the base" nor "turn more things into packages." It's "write good apps using the tool(s) of your own choosing and we'll find a way to make it work." Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 00:51:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85EB21065674 for ; Tue, 17 Aug 2010 00:51:15 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8308FC1B for ; Tue, 17 Aug 2010 00:51:14 +0000 (UTC) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 16 Aug 2010 20:22:38 -0400 Received: from mx04.lnh.mail.rcn.net (mx04.lnh.mail.rcn.net [207.172.157.54]) by mr08.lnh.mail.rcn.net (MOS 3.10.8-GA) with ESMTP id LVS72309; Mon, 16 Aug 2010 20:22:37 -0400 (EDT) X-Auth-ID: stuartb.4gh@starpower.net Received: from 66-44-125-101.c3-0.slvr-ubr1.lnh-slvr.md.cable.rcn.com (HELO freeman.4gh.net) ([66.44.125.101]) by smtp04.lnh.mail.rcn.net with ESMTP; 16 Aug 2010 20:22:37 -0400 Received: by freeman.4gh.net (Postfix, from userid 1001) id 3A8C85C21D; Mon, 16 Aug 2010 20:22:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by freeman.4gh.net (Postfix) with ESMTP id 2C9AA5C21C; Mon, 16 Aug 2010 20:22:33 -0400 (EDT) Date: Mon, 16 Aug 2010 20:22:33 -0400 (EDT) From: Stuart Barkley To: Randy Bush In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Junkmail-Status: score=10/50, host=mr08.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020208.4C69D64D.01D7,ss=1,fgs=0, ip=66.44.125.101, so=2009-09-21 22:56:10, dmn=5.4.3/2007-10-18, mode=single engine X-Junkmail-IWF: false X-Mailman-Approved-At: Tue, 17 Aug 2010 02:42:25 +0000 Cc: FreeBSD current mailing list Subject: Re: better way than hacking termcap to be ca_mode free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 00:51:15 -0000 On Mon, 16 Aug 2010 at 04:50 -0000, Randy Bush wrote: > is there a better way to achieve this? I'm not sure what ca_mode is, but I have the following in my .Xresources file: XTerm*tiXtraScroll: true XTerm*titeInhibit: true These get rid of the silly alternate screen in vi, etc. There are also similar options directly to xterm. Stuart Barkley -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 04:47:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD3721065695 for ; Tue, 17 Aug 2010 04:47:18 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65F9F8FC15 for ; Tue, 17 Aug 2010 04:47:18 +0000 (UTC) Received: by qwg5 with SMTP id 5so6559806qwg.13 for ; Mon, 16 Aug 2010 21:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=hqNhZ4i9L6YbBr3SZcHxrkntbEnKWfPf9I40pneG3D4=; b=i+nbV3fR+Y0hkxjp4+n4eygnQ4rXXisyMRez096EANJAoZBNFp8orRiUCnNquAi7F7 K8O8FpYYMiGFaR03XeFXnxK2Db7pt07kT5tqALmEQiurW1m2OaRj6wKZwTXb9ezRLIkn 0Yjw3dP4zKqGkAzs9KdaWuZK4r7V75bnR1i+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FBJms+11B/T8m4nNiMVgikS1aV8fvsaKODvSRcbfA81r+jADWaim6vLYhkXfcEbgaU i2ZUaV8Dvn/GhPv2ycU7D+5QMHMxCaqm4JSI+pOVYrLjFvqjDbUpJj1HQjYGgqrMQf/c vmHO0kbHUhKnNevI8A80vM21Fg10PgEWyZrN8= MIME-Version: 1.0 Received: by 10.229.87.74 with SMTP id v10mr4406606qcl.38.1282018867403; Mon, 16 Aug 2010 21:21:07 -0700 (PDT) Received: by 10.229.232.77 with HTTP; Mon, 16 Aug 2010 21:21:07 -0700 (PDT) Date: Tue, 17 Aug 2010 12:21:07 +0800 Message-ID: From: lhmwzy To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 04:47:18 -0000 opensolaris is gone,ZFS also gone. Will FreeBSD import btrfs or other similar file system? From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 05:15:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FCC10656A4 for ; Tue, 17 Aug 2010 05:15:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 959908FC14 for ; Tue, 17 Aug 2010 05:15:36 +0000 (UTC) Received: (qmail 9883 invoked by uid 399); 17 Aug 2010 05:15:35 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Aug 2010 05:15:35 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6A1AF4.6010909@FreeBSD.org> Date: Mon, 16 Aug 2010 22:15:32 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Dimitry Andric References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <4C691629.4010006@andric.com> In-Reply-To: <4C691629.4010006@andric.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 05:15:37 -0000 On 08/16/2010 03:42, Dimitry Andric wrote: > On 2010-08-15 21:49, Dimitry Andric wrote: >> ...I >> have attached a more complete patch that: >> >> - Replaces the horrendously inefficient grep_fgetln() with mostly the >> same implementation as the libc fgetln() function. >> - Uses plain file descriptors instead of struct FILE, since the >> buffering is done manually anyway, and it makes it easier to support >> gzip and bzip2. >> - Let the bzip2 reader just read the file as plain data, when the >> initial magic number doesn't match, mimicking the behaviour of GNU >> grep. > > Here is a new patch, updated against Gabor's changes in r211364. Huge improvement! r211364: With your patch: ./grep-time-trial GNU grep Elapsed time: 2 seconds BSD grep BSD grep Elapsed time: 33 seconds Elapsed time: 16 seconds ./grep-time-trial-2 GNU grep Elapsed time: 3 seconds BSD grep BSD grep Elapsed time: 18 seconds Elapsed time: 11 seconds -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 05:21:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E560E106567A for ; Tue, 17 Aug 2010 05:21:14 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id CB24E8FC13 for ; Tue, 17 Aug 2010 05:21:14 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 011BD8C0A3; Tue, 17 Aug 2010 00:01:28 -0500 (CDT) Date: Tue, 17 Aug 2010 00:01:28 -0500 From: Mark Linimon To: lhmwzy Message-ID: <20100817050128.GC13790@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 05:21:15 -0000 On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote: > opensolaris is gone It appears there will be a fork, but that's not particularly crucial to FreeBSD. > ZFS also gone. We're not going to drop ZFS because Oracle's plans are unclear. It remains to be seen how much other community support there is behind ZFS. > Will FreeBSD import btrfs or other similar file system? >From my observation, it takes about 2 years from the initial work on a new filesystem until it's relatively stable, so I don't know why we would suddenly decide to go that direction. mcl From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 06:23:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492D41065673 for ; Tue, 17 Aug 2010 06:23:12 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EFA748FC0A for ; Tue, 17 Aug 2010 06:23:11 +0000 (UTC) Received: by qwg5 with SMTP id 5so6615772qwg.13 for ; Mon, 16 Aug 2010 23:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+fQlRYrrYFwkQt6onN63ue+wBGQQ6bR0j6bPVu2wXQQ=; b=M9WhM/maBdkL+uPrSfdt/xJ5VZA7ObLFKU14FjFjGBKQrrk2otgFFwL1Q82FDpz/v4 rLT18X8/n79WXtB0Qh0UdWwKWJ9LKmLuXV310KX1YCUCnARs66tC5LMRv8LiuGY/Chbu 4CkV7bY8TII3WF2eocKdo6g6/vIFnYU1LO190= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mk8vmzdPfzuA3u+iexAw6mu8vWFoIXynlCaa4jRgBEnMhRprGwijAfQs9sikkdNeJW J2r5Skgfdf0aBQ4hxMqWWDtIchZqn8SuRM5jqHpc6iRVU5egNX7SdgN+A1c+vkvFt46j fvAT/SSUycq3Wi7uPne7R6ZYl7bwTOIfGVMm8= MIME-Version: 1.0 Received: by 10.224.84.75 with SMTP id i11mr4013137qal.121.1282026191261; Mon, 16 Aug 2010 23:23:11 -0700 (PDT) Received: by 10.229.232.77 with HTTP; Mon, 16 Aug 2010 23:23:11 -0700 (PDT) In-Reply-To: <20100817050128.GC13790@lonesome.com> References: <20100817050128.GC13790@lonesome.com> Date: Tue, 17 Aug 2010 14:23:11 +0800 Message-ID: From: lhmwzy To: Mark Linimon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:23:12 -0000 Thanks for your reply. 2010/8/17 Mark Linimon : > On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote: >> opensolaris is gone > > It appears there will be a fork, but that's not particularly crucial > to FreeBSD. > >> ZFS also gone. > > We're not going to drop ZFS because Oracle's plans are unclear. =A0It > remains to be seen how much other community support there is behind ZFS. > >> Will FreeBSD import btrfs or other similar file system? > > From my observation, it takes about 2 years from the initial work on a > new filesystem until it's relatively stable, so I don't know why we would > suddenly decide to go that direction. > > mcl > From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 06:39:00 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 701CB106566B for ; Tue, 17 Aug 2010 06:39:00 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0900C8FC16 for ; Tue, 17 Aug 2010 06:38:59 +0000 (UTC) Received: by wwb24 with SMTP id 24so4470775wwb.31 for ; Mon, 16 Aug 2010 23:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=npdCmDt+1XComDKcH9fPj8xiV4o0Nn6jw9cLoeS6gkY=; b=ouqdqhuEfb+OmujvsfWLOLIVPaAYymPt8LfJyn+eBjmA7q928VWmaKr/F4cCjPHYao EMnhDAioHE7Ut9ni00b7nrGyR/FAzu/NaLWHyvQkPJXU594McGop5LZy/aaTCLfojyaa gilZmB3jJTMIG5GPb4vClNgVFQkk5xvEJB0Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FM0d1+s/IAWLi7UxK2EEZrA+bvMUUiQ/zJXkUiWkoqAMi+/2rnZyBu9Yp5qzfpom3B jghD54me7wJ6eu2jN1kOBtNG47HOWjPwCUYD+ivpml3PSnfM7DiCwrk35+knAz333L51 JQH/ktzFShs2Z1q5vLNnJJzK2kg0PtAfvB2kw= MIME-Version: 1.0 Received: by 10.216.236.146 with SMTP id w18mr5265685weq.19.1282027138803; Mon, 16 Aug 2010 23:38:58 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Mon, 16 Aug 2010 23:38:58 -0700 (PDT) Date: Tue, 17 Aug 2010 06:38:58 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:39:00 -0000 2010/8/16 Dag-Erling Sm=F8rgrav : > Doug Barton writes: >> lua =A0 too "flavor of the day," not enough track record of stability, >> =A0 =A0 =A0 not enough installed base/proven utility > > You're wrong. =A0Lua has been around for ages and is especially widely > used as a game scripting engine. =A0It is not intended as a standalone > language, but as an embeddable scripting engine. =A0We could easily creat= e > our own scripting language based on lua with FreeBSD-specific functions, > and there would be no fear of interfering with third-party software, > because it wouldn't be called lua. It looks like this is rearing its head again elsewhere: http://mail-index.netbsd.org/tech-userlevel/2009/10/24/msg002827.html http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/netbsd= /t127230760748 "Student Name: Lourival Vieira Organization: The NetBSD Foundation Organization Home Page: http://www.netbsd.org/ Mentor Name: Marc Balmer Title: Provide support for dynamic NetBSD kernel extensions using the Lua language - Lunatik/NetBSD Abstract: This project has the goal to develop a framework to provide support for dynamically extending the NetBSD kernel using the Lua programming language. I intend to allow adaptation of the kernel and its subsystems for different purposes at runtime, through download of Lua scripts and exposure of kernel internals to Lua. Moreover, this framework will provide support for rapid prototyping and experimentation with new algorithms and mechanisms inside the kernel." b. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 07:27:49 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DD9A1065693 for ; Tue, 17 Aug 2010 07:27:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id F29E68FC0C for ; Tue, 17 Aug 2010 07:27:48 +0000 (UTC) Received: (qmail 1905 invoked by uid 399); 17 Aug 2010 07:27:47 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Aug 2010 07:27:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Tue, 17 Aug 2010 00:27:45 -0700 (PDT) From: Doug Barton To: Peter Jeremy In-Reply-To: <20100815205433.GA1612@server.vk2pj.dyndns.org> Message-ID: References: <4C675F64.9080205@FreeBSD.org> <20100815205433.GA1612@server.vk2pj.dyndns.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 07:27:49 -0000 On Mon, 16 Aug 2010, Peter Jeremy wrote: > - Have you tried running a uniprocessor kernel? Ok I tried this, and got the same result early into the 3rd video. After I ran the dtrace intr got up to a truly impressive 27% cpu before I shut it down. last pid: 4423; load averages: 2.07, 1.32, 0.91 up 0+02:37:40 23:50:59 98 processes: 2 running, 79 sleeping, 17 waiting CPU: 3.2% user, 0.0% nice, 16.0% system, 17.3% interrupt, 63.5% idle Mem: 48M Active, 210M Inact, 117M Wired, 544K Cache, 112M Buf, 1625M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 10 root 171 ki31 0K 8K RUN 69:12 48.19% idle 4423 dougb 104 0 9912K 2036K RUN 0:02 10.70% top 11 root -32 - 0K 136K WAIT 0:15 6.79% {swi4: clock} 14 root 0 - 0K 8K tzpoll 0:05 0.68% acpi_thermal 11 root -68 - 0K 136K WAIT 0:55 0.54% {irq5: wpi0} 17 root 96 - 0K 8K syncer 0:02 0.44% syncer 781 root 98 0 9684K 1268K select 0:08 0.34% moused 3 root -8 - 0K 8K - 0:02 0.24% g_up 1340 root 96 0 9580K 1192K select 0:07 0.15% powerd 4 root -8 - 0K 8K - 0:01 0.10% g_down 19 root -16 - 0K 8K sdflus 0:00 0.10% softdepflush CPU ID FUNCTION:NAME 0 2 :END kernel`realitexpire value ------------- Distribution ------------- count 32768 | 0 65536 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 131072 | 0 0xc0b0bf30 value ------------- Distribution ------------- count 131072 | 0 262144 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 524288 | 0 kernel`ieee80211_node_timeout value ------------- Distribution ------------- count 262144 | 0 524288 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 1048576 | 0 kernel`loadav value ------------- Distribution ------------- count 512 | 0 1024 |@@@@@@@ 1 2048 | 0 4096 | 0 8192 | 0 16384 | 0 32768 | 0 65536 |@@@@@@@ 1 131072 |@@@@@@@@@@@@@@@@@@@@ 3 262144 |@@@@@@@ 1 524288 | 0 kernel`uma_timeout value ------------- Distribution ------------- count 1048576 | 0 2097152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 4194304 | 0 kernel`ipport_tick value ------------- Distribution ------------- count 256 | 0 512 |@@@ 2 1024 | 0 2048 | 0 4096 | 0 8192 | 0 16384 |@@@@@ 3 32768 |@@ 1 65536 |@@@@@@@@@ 6 131072 |@@@@@@@@@@@@@@@@@@@@@@ 14 262144 | 0 kernel`kbdmux_kbd_intr_timo value ------------- Distribution ------------- count 128 | 0 256 |@@ 1 512 |@@@ 2 1024 | 0 2048 | 0 4096 | 0 8192 | 0 16384 |@@ 1 32768 |@@@@@ 3 65536 |@@@@@@@@ 5 131072 |@@@@@@@@@@@@@@@@@@@@ 13 262144 | 0 524288 |@@ 1 1048576 | 0 0xc0b0a9d0 value ------------- Distribution ------------- count 512 | 0 1024 |@@@@@ 3 2048 | 0 4096 | 0 8192 | 0 16384 |@@ 1 32768 | 0 65536 |@@@@@@ 4 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@@ 17 262144 |@@ 1 524288 | 0 0xc5c9a5d0 value ------------- Distribution ------------- count 8192 | 0 16384 |@@@ 2 32768 |@@ 1 65536 |@@@@@ 3 131072 |@@ 1 262144 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 18 524288 | 0 kernel`nd6_timer value ------------- Distribution ------------- count 8192 | 0 16384 |@@@ 2 32768 |@@ 1 65536 |@@@@@@ 4 131072 |@@@@@@@@@@@@@@@@@@ 12 262144 |@@@@@@@@ 5 524288 |@@ 1 1048576 | 0 2097152 |@@ 1 4194304 | 0 kernel`lim_cb value ------------- Distribution ------------- count 128 | 0 256 |@ 1 512 |@ 1 1024 |@@ 3 2048 | 0 4096 | 0 8192 | 0 16384 |@@@ 6 32768 | 0 65536 |@@@ 6 131072 |@@@@@@@@@@@@@@@@@@@ 37 262144 |@@@@@@@@@@@@ 23 524288 |@ 1 1048576 | 0 kernel`uhci_root_intr value ------------- Distribution ------------- count 8192 | 0 16384 |@@ 5 32768 |@@ 6 65536 |@@@@ 11 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 79 262144 |@ 3 524288 | 0 kernel`logtimeout value ------------- Distribution ------------- count 128 | 0 256 |@ 3 512 |@@@ 10 1024 | 0 2048 | 0 4096 | 0 8192 | 0 16384 |@@ 6 32768 |@@ 6 65536 |@@@@@ 15 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@@ 84 262144 |@ 3 524288 |@ 2 1048576 | 0 kernel`realtimer_expire value ------------- Distribution ------------- count 32768 | 0 65536 |@@@ 2 131072 |@ 1 262144 |@@@@@ 4 524288 |@@@@@@@@@@@@@@@@@@@@@ 16 1048576 |@@@@@@@@ 6 2097152 |@ 1 4194304 | 0 kernel`pfslowtimo value ------------- Distribution ------------- count 16384 | 0 32768 |@@@ 4 65536 |@@ 3 131072 |@@@@@ 7 262144 |@@@@@@@@@@@@ 16 524288 |@@@@@@@@@@@@@@@@ 21 1048576 | 0 2097152 |@ 1 4194304 | 0 kernel`pffasttimo value ------------- Distribution ------------- count 256 | 0 512 |@ 2 1024 |@ 3 2048 | 0 4096 | 0 8192 | 0 16384 |@@@ 10 32768 |@ 2 65536 |@@@@@@ 18 131072 |@@@@@@@@@@@@@ 42 262144 |@@@@@@@@@@@@@@@@ 50 524288 |@ 2 1048576 | 0 kernel`atkbd_timeout value ------------- Distribution ------------- count 1024 | 0 2048 | 1 4096 | 0 8192 | 0 16384 |@@ 11 32768 |@@ 14 65536 |@@@@@@ 39 131072 |@@@@@@@@@@@@@ 84 262144 |@@@@@@@@@@@@@@@@ 106 524288 |@ 4 1048576 | 0 kernel`scrn_timer value ------------- Distribution ------------- count 256 | 0 512 |@ 17 1024 |@ 14 2048 | 0 4096 | 0 8192 | 0 16384 |@@@ 46 32768 | 7 65536 |@@@@@@ 93 131072 |@@@@@@@@@@ 165 262144 |@@@@@@@@@@@@@@@@@@ 284 524288 |@ 14 1048576 | 0 2097152 | 2 4194304 | 0 kernel`usb_power_wdog value ------------- Distribution ------------- count 65536 | 0 131072 |@@ 2 262144 |@@ 2 524288 |@@@@@ 4 1048576 |@ 1 2097152 |@@@@@@@@@@@@@@@@@@@@@@@ 20 4194304 |@ 1 8388608 | 0 16777216 |@@@@@@ 5 33554432 | 0 kernel`sleepq_timeout value ------------- Distribution ------------- count 256 | 0 512 |@ 16 1024 |@ 25 2048 | 0 4096 | 0 8192 | 0 16384 |@@ 51 32768 |@ 15 65536 |@@@@@ 111 131072 |@@@@@@@@ 169 262144 |@@@@@@@@@@@@@@@@@@@@ 408 524288 |@ 24 1048576 | 0 2097152 | 0 4194304 | 0 8388608 | 1 16777216 | 0 kernel`tcp_isn_tick value ------------- Distribution ------------- count 128 | 0 256 |@ 59 512 |@@ 106 1024 | 29 2048 | 0 4096 | 0 8192 | 0 16384 |@@@ 165 32768 |@@ 138 65536 |@@@@@ 312 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@@ 1662 262144 |@ 49 524288 | 5 1048576 | 1 2097152 | 4 4194304 | 0 0xc5ca5f40 value ------------- Distribution ------------- count 128 | 0 256 | 1 512 |@@ 103 1024 |@ 80 2048 | 0 4096 | 0 8192 | 0 16384 |@@@ 165 32768 |@ 35 65536 |@@@@@ 331 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@ 1590 262144 |@@@ 185 524288 |@ 35 1048576 | 0 2097152 | 4 4194304 | 0 kernel`realitexpire 1 kernel`ieee80211_node_timeout 1 kernel`uma_timeout 1 0xc0b0bf30 1 kernel`loadav 6 0xc5c9a5d0 25 kernel`kbdmux_kbd_intr_timo 26 kernel`ipport_tick 26 kernel`nd6_timer 26 0xc0b0a9d0 26 kernel`realtimer_expire 30 kernel`usb_power_wdog 35 kernel`pfslowtimo 52 kernel`lim_cb 78 kernel`uhci_root_intr 104 kernel`logtimeout 129 kernel`pffasttimo 129 kernel`atkbd_timeout 259 kernel`scrn_timer 642 kernel`sleepq_timeout 820 0xc5ca5f40 2529 kernel`tcp_isn_tick 2530 -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 08:15:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9EA1065673 for ; Tue, 17 Aug 2010 08:15:56 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB018FC1D for ; Tue, 17 Aug 2010 08:15:54 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OlHKq-0007hr-2e for current@freebsd.org; Tue, 17 Aug 2010 10:15:52 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlHKo-0000Va-BP for current@freebsd.org; Tue, 17 Aug 2010 10:15:50 +0200 Message-Id: To: current@freebsd.org From: "Ian FREISLICH" X-Attribution: BOFH Date: Tue, 17 Aug 2010 10:15:50 +0200 Cc: Subject: bwn(0) BCM4315/BCM22062000 up for grabs (driver devs only) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:15:56 -0000 Hi This device is up for grabs for a willing driver developer. It's a mini PCI-express half length card. siba_bwn0@pci0:1:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network It does the following: Aug 12 20:48:24 mini kernel: bwn0: need multicast update callback Aug 12 20:48:25 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:48:27 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:48:28 mini kernel: bwn0: need multicast update callback Aug 12 20:48:28 mini kernel: bwn0: need multicast update callback Aug 12 20:48:28 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:48:30 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:51:39 mini kernel: bwn0: need multicast update callback After about 20 minutes I start seeing packet loss at about 5%. Within a few minutes packet loss increases to 100%. Contact me off list if you're interested. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 08:17:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B491B10656BB for ; Tue, 17 Aug 2010 08:17:37 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 443D78FC1D for ; Tue, 17 Aug 2010 08:17:37 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OlHMV-0007rX-Uh for current@freebsd.org; Tue, 17 Aug 2010 10:17:36 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlHMU-0000Vo-Lf for current@freebsd.org; Tue, 17 Aug 2010 10:17:34 +0200 Message-Id: To: current@freebsd.org From: "Ian FREISLICH" X-Attribution: BOFH Date: Tue, 17 Aug 2010 10:17:34 +0200 Cc: Subject: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:17:37 -0000 Hi I recently managed to hack my HP/Compaq BIOS to bypass the RF Whitelist and replace the (crappy) bwn interface with a (decent) ath card. There are a few things - 1. The card has AR5B93 printed on the label, but its detected as: ath0@pci0:1:0:0: class=0x028000 card=0x663211ad chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR5B91 Wireless Network Adapter (0001)' class = network ath0: mem 0xfeaf0000-0xfeafffff irq 16 at device 0.0 on pci1 ath0: [MPSAFE] ath0: [ITHREAD] ath0: AR9280 mac 128.2 RF5133 phy 13.0 Everything I've read suggests it's actually an Atheros 9281. It's possible that the label is wrong. I'm reluctant to desolder the RF shield on the spare card I ordered to see what's actually printed on the chip. 2. I'm getting these messages fairly often. Transmission stops briefly around these times: Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80) Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80) Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting Aug 17 09:05:47 mini kernel: ath0: 0x00000000 0x00002000 0x00000000, 0x00000000 0x00000000 0x00000000 Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 08:24:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852BD1065674 for ; Tue, 17 Aug 2010 08:24:12 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 449C78FC12 for ; Tue, 17 Aug 2010 08:24:12 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlHSt-00014j-4V; Tue, 17 Aug 2010 10:24:11 +0200 Date: Tue, 17 Aug 2010 10:24:11 +0200 From: Kurt Jaeger To: Ian FREISLICH Message-ID: <20100817082411.GB67795@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:24:12 -0000 Hi! > I recently managed to hack my HP/Compaq BIOS to bypass the RF > Whitelist and replace the (crappy) bwn interface with a (decent) > ath card. Cool 8-) > 2. I'm getting these messages fairly often. Transmission stops > briefly around these times: There's an PR which looks pretty similar: http://www.freebsd.org/cgi/query-pr.cgi?pr=148112 I disabled the call to ath_reset() in ath_bmiss_proc and was able to use my AR9285 that way (not very stable, but usable). -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 10:59:37 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA3F110656A6 for ; Tue, 17 Aug 2010 10:59:37 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 844DD8FC13 for ; Tue, 17 Aug 2010 10:59:37 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 7CD3E11B854; Tue, 17 Aug 2010 05:59:36 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id XQGQKZC402WF; Tue, 17 Aug 2010 05:59:36 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Tue, 17 Aug 2010 11:59:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> References: To: Ian FREISLICH X-Mailer: Apple Mail (2.1081) Cc: current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 10:59:37 -0000 On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: > Hi >=20 > I recently managed to hack my HP/Compaq BIOS to bypass the RF > Whitelist and replace the (crappy) bwn interface with a (decent) > ath card. >=20 > There are a few things - >=20 > 1. The card has AR5B93 printed on the label, but its detected as: >=20 > ath0@pci0:1:0:0: class=3D0x028000 card=3D0x663211ad = chip=3D0x002a168c rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'Atheros AR5B91 Wireless Network Adapter (0001)' > class =3D network >=20 > ath0: mem 0xfeaf0000-0xfeafffff irq 16 at device 0.0 on = pci1 > ath0: [MPSAFE] > ath0: [ITHREAD] > ath0: AR9280 mac 128.2 RF5133 phy 13.0 >=20 > Everything I've read suggests it's actually an Atheros 9281. 9281 is the 9280 MAC, so this is ok. > It's > possible that the label is wrong. I'm reluctant to desolder the > RF shield on the spare card I ordered to see what's actually printed > on the chip. >=20 >=20 >=20 >=20 > 2. I'm getting these messages fairly often. Transmission stops > briefly around these times: >=20 > Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80) > Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80) > Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting > Aug 17 09:05:47 mini kernel: ath0: 0x00000000 0x00002000 0x00000000, = 0x00000000 0x00000000 0x00000000 > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting >=20 BB hangs are a problem with the 9280 but I don't know how to fix. Hardware errors shouldn't happen, but this might mean you have very = aggressive power reduction settings (ACPI C3, etc.) that are interfering = with the atheros card. This has happened to me in the past. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 11:17:54 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476CE106566C for ; Tue, 17 Aug 2010 11:17:54 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id D8FDC8FC0C for ; Tue, 17 Aug 2010 11:17:53 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OlKAy-0007Ci-B5; Tue, 17 Aug 2010 13:17:52 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlKAw-0001DC-QX; Tue, 17 Aug 2010 13:17:50 +0200 Message-Id: To: Rui Paulo From: Ian FREISLICH In-Reply-To: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> X-Attribution: BOFH Date: Tue, 17 Aug 2010 13:17:45 +0200 Cc: current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:17:54 -0000 Rui Paulo wrote: > > On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: > > 2. I'm getting these messages fairly often. Transmission stops > > briefly around these times: > >=20 > > Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80) > > Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80) > > Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting > > Aug 17 09:05:47 mini kernel: ath0: 0x00000000 0x00002000 0x00000000, = > 0x00000000 0x00000000 0x00000000 > > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting > >=20 > > BB hangs are a problem with the 9280 but I don't know how to fix. Do you have a card to play with? (Since I'm offering hardware at the moment) > Hardware errors shouldn't happen, but this might mean you have very = > aggressive power reduction settings (ACPI C3, etc.) that are interfering = > with the atheros card. This has happened to me in the past. I don't think it's that: hw.acpi.cpu.cx_lowest: C1 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 11:32:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5644C106566B for ; Tue, 17 Aug 2010 11:32:33 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A57A08FC16 for ; Tue, 17 Aug 2010 11:32:32 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CB7B95C59 for ; Tue, 17 Aug 2010 13:32:30 +0200 (CEST) Message-ID: <4C6A7357.8000606@andric.com> Date: Tue, 17 Aug 2010 13:32:39 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------090709090403060100020802" Cc: Subject: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:32:33 -0000 This is a multi-part message in MIME format. --------------090709090403060100020802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Since clang has gone into the tree, there has been an effort to get head in a state where world can optionally be built with it. A number of changes required for this have already been committed, mainly thanks to Ed Schouten, Roman Divacky and Rui Paulo. Most of these changes were adapted from the clangbsd project branch. There are several other changes in the queue, pending review and/or further enhancement, but I would like to solicit your comments about one particular set: the changes required to let buildworld use clang as the compiler. Probably the most logical way to specify that you want world built with clang, is to put CC=clang and CXX=clang++ in /etc/src.conf. Any necessary modifications to Makefile.inc1 or bsd.*.mk can then be put between conditionals like: .if ${CC:T:Mclang} == "clang" [...stuff specific to clang...] .endif so nothing will change for non-clang builds. Now, for building clang as the bootstrap compiler, there are basically two methods to make it use the correct headers, C startup objects, and libraries from the object tree (${WORLDTMP}): 1) The "isysroot" method: build a regular version of clang, and make sure WMAKEENV contains something like: CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \ -L${WORLDTMP}/usr/lib/" 2) The "tools-prefix" method: build a special version of clang, that has its default search paths for headers, startup objects and libraries modified, to look for everything under ${WORLDTMP}. Method 1) is used in the clangbsd project branch. Method 2) is similar to what is used for building the in-tree gcc as the bootstrap compiler. During the cross-tools stage, TOOLS_PREFIX is defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in search paths get prefixed with it. An advantage of method 1) is that it does not require any modifications to the compiler, and basically just a few extra command line arguments. The same method could probably even be made to work for gcc. However, a disadvantage is that the built-in search paths of the bootstrap compiler are not entirely disabled by using the -isysroot, -B and -L flags, so there is still a chance that headers, objects or libraries outside of ${WORLDTMP} will be picked up during the world stage. An advantage of method 2) is that you can be 100% sure all built-in search paths of the bootstrap compiler point to directories under ${WORLDTMP}. Of course, a disadvantage is that you have to make some modifications to the compiler source itself. I would like to hear your opinions about which method is preferred, or if there may be another good way to solve the bootstrap compiler issue. I have also attached two patches to this mail, which can be applied to head, to show the exact set of changes required for each method. --------------090709090403060100020802 Content-Type: text/plain; name="clang-bootstrap-isysroot.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clang-bootstrap-isysroot.diff" The "isysroot" method for building world with clang. First of all, Makefile.inc1 is modified to build the clang libraries and binaries during the cross-tools stage, iff CC=clang. We basically adjust WMAKEENV, which applies to the world stage, and LIB32FLAGS, which optionally applies to 32-bit world stage, to add -isysroot, -B and -L options, so the compiler looks under ${WORLDTMP} for its headers, startup objects and libraries. We also need to create symlinks from ${WORLDTMP}/usr/bin/as and ld to ${WORLDTMP}/usr/lib, since the -B option in clang is not additive, and is used both for finding CRT startup objects and for finding the assembler and linker. diff --git a/Makefile.inc1 b/Makefile.inc1 index d2581c5..c31eba9 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -257,6 +257,10 @@ WMAKEENV= ${CROSSENV} \ VERSION="${VERSION}" \ INSTALL="sh ${.CURDIR}/tools/install.sh" \ PATH=${TMPPATH} +.if ${CC:T:Mclang} == "clang" +WMAKEENV+= CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ -L${WORLDTMP}/usr/lib/" \ + CXX="${CXX} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ -L${WORLDTMP}/usr/lib/" +.endif .if ${MK_CDDL} == "no" WMAKEENV+= NO_CTF=1 .endif @@ -289,8 +293,11 @@ LIB32WMAKEENV= MACHINE=powerpc MACHINE_ARCH=powerpc \ .endif -LIB32FLAGS= -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ - -isystem ${LIB32TMP}/usr/include/ \ +LIB32FLAGS= -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT +.if ${CC:T:Mclang} == "clang" +LIB32FLAGS+= -isysroot ${LIB32TMP}/ +.endif +LIB32FLAGS+= -isystem ${LIB32TMP}/usr/include/ \ -L${LIB32TMP}/usr/lib32 \ -B${LIB32TMP}/usr/lib32 @@ -440,6 +447,11 @@ everything: @echo "--------------------------------------------------------------" @echo ">>> stage 4.4: building everything" @echo "--------------------------------------------------------------" +.if ${CC:T:Mclang} == "clang" + # mergemaster goes through this but those files do not exist + [ ! -e ${WORLDTMP}/usr/bin/as ] || ln -sf ${WORLDTMP}/usr/bin/as ${WORLDTMP}/usr/lib/as + [ ! -e ${WORLDTMP}/usr/bin/ld ] || ln -sf ${WORLDTMP}/usr/bin/ld ${WORLDTMP}/usr/lib/ld +.endif ${_+_}cd ${.CURDIR}; ${WMAKE} par-all .if defined(LIB32TMP) build32: @@ -453,6 +465,12 @@ build32: mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \ -p ${LIB32TMP}/usr/include >/dev/null mkdir -p ${WORLDTMP} +.if ${CC:T:Mclang} == "clang" + # relink /usr/bin/{as,ld} to the lib32 tmp so the -B can pick up + # the /usr/bin/ld and /usr/bin/as + ln -sf ${WORLDTMP}/usr/bin/as ${LIB32TMP}/usr/lib32/as + ln -sf ${WORLDTMP}/usr/bin/ld ${LIB32TMP}/usr/lib32/ld +.endif ln -sf ${.CURDIR}/sys ${WORLDTMP} .if ${MK_KERBEROS} != "no" .for _t in obj depend all @@ -1078,8 +1096,15 @@ _kgzip= usr.sbin/kgzip .endif .endif +.if ${CC:T:Mclang} == "clang" +_clang= usr.bin/clang +_clang_libs= lib/clang +.endif + cross-tools: .for _tool in \ + ${_clang_libs} \ + ${_clang} \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ usr.bin/xlint/lint1 usr.bin/xlint/lint2 usr.bin/xlint/xlint \ --------------090709090403060100020802 Content-Type: text/plain; name="clang-bootstrap-tools-prefix.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clang-bootstrap-tools-prefix.diff" The "tools-prefix" method for building world with clang. First of all, Makefile.inc1 is modified to build the clang libraries and binaries during the cross-tools stage, iff CC=clang. The lib/clang/clang.build.mk file, which contains common build settings for all llvm and clang sources, is modified to add a CLANG_PREFIX macro to CFLAGS, iff TOOLS_PREFIX is defined. In the clang sources, the files that define the built-in search paths for headers, startup objects and libraries, are modified to use the (optional) CLANG_PREFIX macro as prefix for all those paths. diff --git a/Makefile.inc1 b/Makefile.inc1 index d2581c5..6e58396 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -1078,8 +1078,15 @@ _kgzip= usr.sbin/kgzip .endif .endif +.if ${CC:T:Mclang} == "clang" +_clang= usr.bin/clang +_clang_libs= lib/clang +.endif + cross-tools: .for _tool in \ + ${_clang_libs} \ + ${_clang} \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ usr.bin/xlint/lint1 usr.bin/xlint/lint2 usr.bin/xlint/xlint \ diff --git a/contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp b/contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp index a78d153..3506590 100644 --- a/contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp +++ b/contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp @@ -26,6 +26,10 @@ #include // ::getenv +#ifndef CLANG_PREFIX +#define CLANG_PREFIX +#endif + using namespace clang::driver; using namespace clang::driver::toolchains; @@ -869,11 +873,9 @@ FreeBSD::FreeBSD(const HostInfo &Host, const llvm::Triple& Triple, bool Lib32) getProgramPaths().push_back(getDriver().Dir + "/../libexec"); getProgramPaths().push_back("/usr/libexec"); if (Lib32) { - getFilePaths().push_back(getDriver().Dir + "/../lib32"); - getFilePaths().push_back("/usr/lib32"); + getFilePaths().push_back(CLANG_PREFIX "/usr/lib32"); } else { - getFilePaths().push_back(getDriver().Dir + "/../lib"); - getFilePaths().push_back("/usr/lib"); + getFilePaths().push_back(CLANG_PREFIX "/usr/lib"); } } diff --git a/contrib/llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp b/contrib/llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp index fcfee71..9187148 100644 --- a/contrib/llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp +++ b/contrib/llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp @@ -30,6 +30,9 @@ #define WIN32_LEAN_AND_MEAN 1 #include #endif +#ifndef CLANG_PREFIX +#define CLANG_PREFIX +#endif using namespace clang; using namespace clang::frontend; @@ -408,9 +411,10 @@ static bool getWindowsSDKDir(std::string &path) { void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &triple, const HeaderSearchOptions &HSOpts) { -#if 0 /* Remove unneeded include paths. */ // FIXME: temporary hack: hard-coded paths. - AddPath("/usr/local/include", System, true, false, false); +#ifndef __FreeBSD__ + AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false); +#endif // Builtin includes use #include_next directives and should be positioned // just prior C include dirs. @@ -421,7 +425,6 @@ void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &triple, P.appendComponent("include"); AddPath(P.str(), System, false, false, false, /*IgnoreSysRoot=*/ true); } -#endif // Add dirs specified via 'configure --with-c-include-dirs'. llvm::StringRef CIncludeDirs(C_INCLUDE_DIRS); @@ -518,13 +521,15 @@ void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &triple, case llvm::Triple::MinGW32: AddPath("c:/mingw/include", System, true, false, false); break; + case llvm::Triple::FreeBSD: + AddPath(CLANG_PREFIX "/usr/include/clang/" CLANG_VERSION_STRING, + System, false, false, false); + break; default: break; } - AddPath("/usr/include/clang/" CLANG_VERSION_STRING, - System, false, false, false); - AddPath("/usr/include", System, false, false, false); + AddPath(CLANG_PREFIX "/usr/include", System, false, false, false); } void InitHeaderSearch:: @@ -726,8 +731,10 @@ AddDefaultCPlusPlusIncludePaths(const llvm::Triple &triple) { case llvm::Triple::FreeBSD: // FreeBSD 8.0 // FreeBSD 7.3 - AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2", "", "", "", triple); - AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2/backward", "", "", "", triple); + AddGnuCPlusPlusIncludePaths(CLANG_PREFIX "/usr/include/c++/4.2", + "", "", "", triple); + AddGnuCPlusPlusIncludePaths(CLANG_PREFIX "/usr/include/c++/4.2/backward", + "", "", "", triple); break; case llvm::Triple::Minix: AddGnuCPlusPlusIncludePaths("/usr/gnu/include/c++/4.4.3", diff --git a/lib/clang/clang.build.mk b/lib/clang/clang.build.mk index 6351eda..86384db 100644 --- a/lib/clang/clang.build.mk +++ b/lib/clang/clang.build.mk @@ -28,6 +28,10 @@ LLVM_REQUIRES_RTTI= CFLAGS+=-fno-rtti .endif +.ifdef TOOLS_PREFIX +CFLAGS+=-DCLANG_PREFIX=\"${TOOLS_PREFIX}\" +.endif + .PATH: ${LLVM_SRCS}/${SRCDIR} TBLGEN=tblgen ${CFLAGS:M-I*} --------------090709090403060100020802-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 11:40:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956C010656A4 for ; Tue, 17 Aug 2010 11:40:35 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 335948FC0A for ; Tue, 17 Aug 2010 11:40:35 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id D56712A28CD4; Tue, 17 Aug 2010 13:40:33 +0200 (CEST) Date: Tue, 17 Aug 2010 13:40:33 +0200 From: Ed Schouten To: Dimitry Andric Message-ID: <20100817114033.GX2978@hoeg.nl> References: <4C6A7357.8000606@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WVf18ZLo9bznw8Mz" Content-Disposition: inline In-Reply-To: <4C6A7357.8000606@andric.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:40:35 -0000 --WVf18ZLo9bznw8Mz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Dimitry! * Dimitry Andric wrote: > @@ -408,9 +411,10 @@ static bool getWindowsSDKDir(std::string &path) { > =20 > void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &tripl= e, > const HeaderSearchOptions &H= SOpts) { > -#if 0 /* Remove unneeded include paths. */ > // FIXME: temporary hack: hard-coded paths. > - AddPath("/usr/local/include", System, true, false, false); > +#ifndef __FreeBSD__ > + AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false); > +#endif > =20 > // Builtin includes use #include_next directives and should be positio= ned > // just prior C include dirs. Hmmm... Do we really want this? /usr/local/include is omitted from our compiler include paths on purpose, to prevent accidental linkage against pieces of software built from ports. --=20 Ed Schouten WWW: http://80386.nl/ --WVf18ZLo9bznw8Mz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxqdTEACgkQ52SDGA2eCwVq7wCeJnfKESMUH+oGAd2EQVg1N7l5 6n0AnRE7nDHUrt2MKMqr+/tTR4VPSNxi =ruLg -----END PGP SIGNATURE----- --WVf18ZLo9bznw8Mz-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 11:55:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8669F10656A4 for ; Tue, 17 Aug 2010 11:55:41 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8208FC24 for ; Tue, 17 Aug 2010 11:55:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 968745C59; Tue, 17 Aug 2010 13:55:40 +0200 (CEST) Message-ID: <4C6A78C5.1050405@andric.com> Date: Tue, 17 Aug 2010 13:55:49 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Ed Schouten References: <4C6A7357.8000606@andric.com> <20100817114033.GX2978@hoeg.nl> In-Reply-To: <20100817114033.GX2978@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:55:41 -0000 On 2010-08-17 13:40, Ed Schouten wrote: >> +#ifndef __FreeBSD__ >> + AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false); >> +#endif >> >> // Builtin includes use #include_next directives and should be positioned >> // just prior C include dirs. > > Hmmm... Do we really want this? /usr/local/include is omitted from our > compiler include paths on purpose, to prevent accidental linkage against > pieces of software built from ports. That is why it says "#ifndef __FreeBSD__" :) I just changed the "#if 0" from the clangbsd tree to this, so it is more palatable for upstream. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 11:59:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAE7B106564A for ; Tue, 17 Aug 2010 11:59:59 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 9FDF28FC12 for ; Tue, 17 Aug 2010 11:59:59 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 12E982A28CD4; Tue, 17 Aug 2010 13:59:59 +0200 (CEST) Date: Tue, 17 Aug 2010 13:59:59 +0200 From: Ed Schouten To: Dimitry Andric Message-ID: <20100817115959.GY2978@hoeg.nl> References: <4C6A7357.8000606@andric.com> <20100817114033.GX2978@hoeg.nl> <4C6A78C5.1050405@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iRaAnoDFBoP0sW/E" Content-Disposition: inline In-Reply-To: <4C6A78C5.1050405@andric.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 11:59:59 -0000 --iRaAnoDFBoP0sW/E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Dimitry Andric wrote: > On 2010-08-17 13:40, Ed Schouten wrote: > >> +#ifndef __FreeBSD__ > >> + AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, fal= se); > >> +#endif > >> =20 > >> // Builtin includes use #include_next directives and should be posi= tioned > >> // just prior C include dirs. > >=20 > > Hmmm... Do we really want this? /usr/local/include is omitted from our > > compiler include paths on purpose, to prevent accidental linkage against > > pieces of software built from ports. >=20 > That is why it says "#ifndef __FreeBSD__" :) I just changed the "#if > 0" from the clangbsd tree to this, so it is more palatable for upstream. Sorry about that. I only read the `#if 0' part. --=20 Ed Schouten WWW: http://80386.nl/ --iRaAnoDFBoP0sW/E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxqeb8ACgkQ52SDGA2eCwVaYACffL3NLvy2GQ13u5CKzQcpDVbz T/QAn3ifBlsbVv+whLUJg2UUAniCffnO =gom6 -----END PGP SIGNATURE----- --iRaAnoDFBoP0sW/E-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 12:05:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95CD1106567A for ; Tue, 17 Aug 2010 12:05:34 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2F48FC19 for ; Tue, 17 Aug 2010 12:05:33 +0000 (UTC) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id o7HBoB0q074797; Tue, 17 Aug 2010 12:50:11 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [192.168.1.2] (host86-178-206-201.range86-178.btcentralplus.com [86.178.206.201]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id o7HBo5hZ029584; Tue, 17 Aug 2010 12:50:05 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <4C6A7357.8000606@andric.com> Date: Tue, 17 Aug 2010 12:49:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> References: <4C6A7357.8000606@andric.com> To: Dimitry Andric X-Mailer: Apple Mail (2.1081) Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:05:34 -0000 Hi, On 17 Aug 2010, at 12:32, Dimitry Andric wrote: > Hi, >=20 > Since clang has gone into the tree, there has been an effort to get = head > in a state where world can optionally be built with it. > [...] > Now, for building clang as the bootstrap compiler, there are basically > two methods to make it use the correct headers, C startup objects, and > libraries from the object tree (${WORLDTMP}): >=20 > 1) The "isysroot" method: build a regular version of clang, and make > sure WMAKEENV contains something like: >=20 > CC=3D"${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \ > -L${WORLDTMP}/usr/lib/" >=20 > 2) The "tools-prefix" method: build a special version of clang, that > has its default search paths for headers, startup objects and > libraries modified, to look for everything under ${WORLDTMP}. >=20 > Method 1) is used in the clangbsd project branch. >=20 > Method 2) is similar to what is used for building the in-tree gcc as > the bootstrap compiler. During the cross-tools stage, TOOLS_PREFIX is > defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in > search paths get prefixed with it. >=20 > An advantage of method 1) is that it does not require any = modifications > to the compiler, and basically just a few extra command line = arguments. > The same method could probably even be made to work for gcc. >=20 > However, a disadvantage is that the built-in search paths of the > bootstrap compiler are not entirely disabled by using the -isysroot, = -B > and -L flags, This could be viewed as a bug ... > so there is still a chance that headers, objects or > libraries outside of ${WORLDTMP} will be picked up during the world > stage. ... and the last thing you want in buildworld is this kind of POLA = violation ... > An advantage of method 2) is that you can be 100% sure all built-in > search paths of the bootstrap compiler point to directories under > ${WORLDTMP}. Of course, a disadvantage is that you have to make some > modifications to the compiler source itself. ... so, which fix to the compiler do you want to make? > [etc] -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 12:19:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7440A1065693 for ; Tue, 17 Aug 2010 12:19:08 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4DA588FC18 for ; Tue, 17 Aug 2010 12:19:08 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id BE3A211B946; Tue, 17 Aug 2010 07:19:07 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id TRR74KMPN8D2; Tue, 17 Aug 2010 07:19:07 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Tue, 17 Aug 2010 13:19:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <849F3B4F-3451-4165-BA5A-E8451E9CEBD3@FreeBSD.org> References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> To: Ian FREISLICH X-Mailer: Apple Mail (2.1081) Cc: current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:19:08 -0000 On 17 Aug 2010, at 12:17, Ian FREISLICH wrote: > Rui Paulo wrote: >>=20 >> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: >>> 2. I'm getting these messages fairly often. Transmission stops >>> briefly around these times: >>> =3D20 >>> Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80) >>> Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80) >>> Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting >>> Aug 17 09:05:47 mini kernel: ath0: 0x00000000 0x00002000 0x00000000, = =3D >> 0x00000000 0x00000000 0x00000000 >>> Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), = resetting >>> Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), = resetting >>> Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), = resetting >>> Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), = resetting >>> =3D20 >>=20 >> BB hangs are a problem with the 9280 but I don't know how to fix. >=20 > Do you have a card to play with? (Since I'm offering hardware at the = moment) >=20 Yes. What I don't have is time and access to the proper documentation. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 12:23:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA421065673; Tue, 17 Aug 2010 12:23:27 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 885F48FC19; Tue, 17 Aug 2010 12:23:27 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OlLCQ-0003uj-0Y; Tue, 17 Aug 2010 14:23:26 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlLCO-0001Py-6D; Tue, 17 Aug 2010 14:23:24 +0200 Message-Id: From: Ian FREISLICH In-Reply-To: References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> X-Attribution: BOFH Date: Tue, 17 Aug 2010 14:23:24 +0200 Cc: Rui Paulo , current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:23:28 -0000 Ian FREISLICH wrote: > Rui Paulo wrote: > > > > BB hangs are a problem with the 9280 but I don't know how to fix. > > Do you have a card to play with? (Since I'm offering hardware at the moment) > > > Hardware errors shouldn't happen, but this might mean you have very = Replying to myself - Just got this error: ath0: ath_chan_set: unable to reset channel 3 (2422 MHz, flags 0x480), hal status 14 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 13:21:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F09010656A4 for ; Tue, 17 Aug 2010 13:21:45 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF888FC1D for ; Tue, 17 Aug 2010 13:21:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7235D5C59; Tue, 17 Aug 2010 15:21:44 +0200 (CEST) Message-ID: <4C6A8CF0.8000002@andric.com> Date: Tue, 17 Aug 2010 15:21:52 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Bob Bishop References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> In-Reply-To: <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:21:45 -0000 On 2010-08-17 13:49, Bob Bishop wrote: >> However, a disadvantage is that the built-in search paths of the >> bootstrap compiler are not entirely disabled by using the -isysroot, -B >> and -L flags, > > This could be viewed as a bug ... It is probably a bit more complicated than that. Let me expand a bit on those compiler flags (and note that clang tries to mimic gcc's interpretation of them, but is not always perfect). The -isysroot option ==================== The -isysroot option is supposed to 'reset' the root for include files to the specified path, according to the gcc documentation. If I compile an empty .c file with "gcc -v -S", the default include paths are printed: /usr/include/gcc/4.2 /usr/include If you now add "-isysroot ${WORLDTMP}" (the default value of WORLDTMP is /usr/obj/usr/src/tmp), the resulting include paths become: /usr/include/gcc/4.2 ${WORLDTMP}/usr/include So unfortunately, gcc seems to only prepend the isysroot path to one of the directories. Clang's default include paths are: /usr/include/clang/2.8 /usr/include With the same -isysroot option added, they become: ${WORLDTMP}/usr/include/clang/2.8 ${WORLDTMP}/usr/include E.g. clang does the right thing here. The -B option ============= The -B option is supposed to "...[specify] where to find the executables, libraries, include files, and data files of the compiler itself". This option is a bit strange, since it is used for finding both executables (cc1, as, ld), objects (crt*.o) and libraries. If you run "gcc -print-search-dirs", it gives its defaults: programs: =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ libraries: =/usr/lib/:/usr/lib/ When you add -B${WORLDTMP}/usr/libexec/ (where the cross-tools built cc1 and cc1plus are), it gives: programs: =${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ libraries: =${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:/usr/lib/:/usr/lib/ Thus, the -B path is prepended (why it does it twice, I do not know; probably a bug), but the defaults are *not* removed, so there is still a risk of picking up an incorrect executable. Note the path is also prepended to the libraries path, which is rather useless; there are never any .o or .a files in a libexec directory. To fix that path up, you would need to add yet *another* -B option, and you probably also need yet another -B option to make it find the correct as and ld. The final command line would then become: gcc -B${WORLDTMP}/usr/bin/ -B${WORLDTMP}/usr/libexec/ -B${WORLDTMP}/usr/lib/ giving the following search dirs: programs: =${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/lib/:${WORLDTMP}/usr/lib/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/ libraries: =${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/lib/:${WORLDTMP}/usr/lib/:/usr/lib/:/usr/lib/ Clang also implements the -B option, but it is not additive yet, so there is no way to specify both the ${WORLDTMP}/usr/bin directory (for finding its second stage, as and ld), and ${WORLDTMP}/usr/lib (for finding startup objects and libraries). This is also the reason clang-bootstrap-isysroot.diff needs to create symlinks from ${WORLDTMP}/usr/bin/as and ld to ${WORLDTMP}/usr/lib, as only the latter directory is specified with -B, and it otherwise would not be able to find the correct as and ld. The -L option ============= The -L option just adds the specified directory to the library search path. It puts them before the built-in paths, but it does not disable those either. Moreover, the -L paths are *not* used to find the CRT startup objects: $ gcc -L${WORLDTMP}/usr/lib -v test.c [...] /usr/bin/as -o /tmp/ccZcUXwc.o /tmp/ccYTRRrk.s /usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o test /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib /tmp/ccZcUXwc.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o The behaviour of clang is the same for this option, so it does not improve the situation: it is still possible for libraries outside of ${WORLDTMP} to be found. >> An advantage of method 2) is that you can be 100% sure all built-in >> search paths of the bootstrap compiler point to directories under >> ${WORLDTMP}. Of course, a disadvantage is that you have to make some >> modifications to the compiler source itself. > > ... so, which fix to the compiler do you want to make? My personal preference is method 2), e.g. modify the compiler's built-in paths, but it is more reasonable to present both methods, and ask for opinions. Someone may even know another good method. :) From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 13:33:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EDC41065670 for ; Tue, 17 Aug 2010 13:33:51 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 03E6F8FC12 for ; Tue, 17 Aug 2010 13:33:50 +0000 (UTC) Received: by vws7 with SMTP id 7so5466663vws.13 for ; Tue, 17 Aug 2010 06:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/S6sbE0yo4u5k37uqa0Xt5H5QRRRs3C0RBCf+sL1rhE=; b=pJ1Mwc0UGxKKI+/mYvQ6OwyXU1Ij2OWA5FGWhwt7Nr2ZRHC4AeExi5/Kbb5ahVEzxJ 81zHXZKy6ReDzOx/RDatf0pw0ZWx1gQ7Thej3z6E6p/xo3FrY0/Autiv7krD9VV6Nec8 pxFuphPZ4DSprJFfL7peCfq+yWWhfYdY3dr4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IKPpQWkmG0nDjp8t87yfGmtokepIsT8INH8KcLtUc+azjllSgY/z8GHJ0FbPJYyKr6 UKXccnKV4SFF7MMJC/B9M0yZawxgjZSIBu98dYR3IowJTf0WCdfaofCWZYlLcrKyTRLy 8ZExRIxMGUgeXINVCkKwbl3uBdhOO4w2VH1+g= MIME-Version: 1.0 Received: by 10.220.62.136 with SMTP id x8mr4053764vch.10.1282050216197; Tue, 17 Aug 2010 06:03:36 -0700 (PDT) Received: by 10.220.193.132 with HTTP; Tue, 17 Aug 2010 06:03:35 -0700 (PDT) In-Reply-To: <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> Date: Tue, 17 Aug 2010 15:03:35 +0200 Message-ID: From: Daniel Nebdal To: Bob Bishop Content-Type: text/plain; charset=ISO-8859-1 Cc: Dimitry Andric , current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:33:51 -0000 On Tue, Aug 17, 2010 at 1:49 PM, Bob Bishop wrote: > On 17 Aug 2010, at 12:32, Dimitry Andric wrote: > >> However, a disadvantage is that the built-in search paths of the >> bootstrap compiler are not entirely disabled by using the -isysroot, -B >> and -L flags, > > This could be viewed as a bug ... For clarification, did you (Dimitry, that is) mean a) The paths are still there so they could resurface if some Makefile doesn't specify those flags , or b) they sometimes come into play even when using the appropriate flags? -- Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 13:37:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88CCC1065693 for ; Tue, 17 Aug 2010 13:37:36 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2212C8FC1D for ; Tue, 17 Aug 2010 13:37:35 +0000 (UTC) Received: by qwg5 with SMTP id 5so6986771qwg.13 for ; Tue, 17 Aug 2010 06:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=FxyNJXRWeWzGxp37+DSa5osLwi0gwCfup26MV0DMhlw=; b=X3zuyrsWzOIX+g5/QpvS4F9iclraQn2z/6aL5wMvZIYY2tpsE5CmUz1zcCHJ6AMTzd qbLnasIt/QiXDG3MhHAfUcZF4S/tFfdekFlAUJlpRWs7u/CfL/xHwUqoyGmMHxNHLz/s 8dl/KIbz6TLZ50kMP7iiVsvrwcU6PbWxuVqXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=VJi2FxFZIMUcux/2Niazw5jwnvLR/Slqmn4GwjcT3GaXclZoqFqM0l7EWLbvkZUHB2 NP5NwW7kdMVxJCSkSC8YCeYFrSUAbae32BB8iwxM6rYU/4xaz75MFIChth2UARcDLiCt 0+thrrTQQSYkkXrH1RO9ab04fUc8CuNx7/+Oc= Received: by 10.224.69.169 with SMTP id z41mr4336260qai.160.1282050922835; Tue, 17 Aug 2010 06:15:22 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id e6sm8759714qcr.17.2010.08.17.06.15.20 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 06:15:21 -0700 (PDT) Date: Tue, 17 Aug 2010 09:15:15 -0400 From: Alexander Kabaev To: Dimitry Andric Message-ID: <20100817091515.4510ebfd@kan.dnsalias.net> In-Reply-To: <4C6A7357.8000606@andric.com> References: <4C6A7357.8000606@andric.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Qa04UvAjLX6S1lYdVwlBcTy"; protocol="application/pgp-signature" Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:37:36 -0000 --Sig_/Qa04UvAjLX6S1lYdVwlBcTy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 17 Aug 2010 13:32:39 +0200 Dimitry Andric wrote: > Hi, >=20 > Since clang has gone into the tree, there has been an effort to get > head in a state where world can optionally be built with it. A > number of changes required for this have already been committed, > mainly thanks to Ed Schouten, Roman Divacky and Rui Paulo. Most of > these changes were adapted from the clangbsd project branch. >=20 > There are several other changes in the queue, pending review and/or > further enhancement, but I would like to solicit your comments about > one particular set: the changes required to let buildworld use clang > as the compiler. >=20 > Probably the most logical way to specify that you want world built > with clang, is to put CC=3Dclang and CXX=3Dclang++ in /etc/src.conf. Any > necessary modifications to Makefile.inc1 or bsd.*.mk can then be put > between conditionals like: >=20 > .if ${CC:T:Mclang} =3D=3D "clang" > [...stuff specific to clang...] > .endif >=20 > so nothing will change for non-clang builds. >=20 > Now, for building clang as the bootstrap compiler, there are basically > two methods to make it use the correct headers, C startup objects, and > libraries from the object tree (${WORLDTMP}): >=20 > 1) The "isysroot" method: build a regular version of clang, and make > sure WMAKEENV contains something like: >=20 > CC=3D"${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \ > -L${WORLDTMP}/usr/lib/" >=20 > 2) The "tools-prefix" method: build a special version of clang, that > has its default search paths for headers, startup objects and > libraries modified, to look for everything under ${WORLDTMP}. >=20 > Method 1) is used in the clangbsd project branch. >=20 > Method 2) is similar to what is used for building the in-tree gcc as > the bootstrap compiler. During the cross-tools stage, TOOLS_PREFIX is > defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in > search paths get prefixed with it. >=20 > An advantage of method 1) is that it does not require any > modifications to the compiler, and basically just a few extra command > line arguments. The same method could probably even be made to work > for gcc. >=20 > However, a disadvantage is that the built-in search paths of the > bootstrap compiler are not entirely disabled by using the -isysroot, > -B and -L flags, so there is still a chance that headers, objects or > libraries outside of ${WORLDTMP} will be picked up during the world > stage. >=20 > An advantage of method 2) is that you can be 100% sure all built-in > search paths of the bootstrap compiler point to directories under > ${WORLDTMP}. Of course, a disadvantage is that you have to make some > modifications to the compiler source itself. >=20 > I would like to hear your opinions about which method is preferred, or > if there may be another good way to solve the bootstrap compiler > issue. >=20 > I have also attached two patches to this mail, which can be applied to > head, to show the exact set of changes required for each method. >=20 Does method 1) work fine with 'make buildenv'? I doubt that. I would strongly suggest we should not lose this feature. I do not like the idea of having to depend on -isystem in CFLAGS in such an environment.=20 --=20 Alexander Kabaev --Sig_/Qa04UvAjLX6S1lYdVwlBcTy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iD8DBQFMaotnQ6z1jMm+XZYRAorwAKDGCp/1zDFBgl31vpyS2Pl+19cXRgCgzV8O r8Niu/tZM/0ie1jZzEuB1/0= =y/ij -----END PGP SIGNATURE----- --Sig_/Qa04UvAjLX6S1lYdVwlBcTy-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 13:47:04 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC361065695 for ; Tue, 17 Aug 2010 13:47:04 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0D58FC14 for ; Tue, 17 Aug 2010 13:47:04 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 616B75C59; Tue, 17 Aug 2010 15:47:03 +0200 (CEST) Message-ID: <4C6A92E0.4050104@andric.com> Date: Tue, 17 Aug 2010 15:47:12 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Daniel Nebdal References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:47:04 -0000 On 2010-08-17 15:03, Daniel Nebdal wrote: >>> However, a disadvantage is that the built-in search paths of the >>> bootstrap compiler are not entirely disabled by using the -isysroot, -B >>> and -L flags, ... > For clarification, did you (Dimitry, that is) mean > a) The paths are still there so they could resurface if some Makefile > doesn't specify those flags , or > b) they sometimes come into play even when using the appropriate flags? Any sub-makefiles would not have to specify those flags explicitly, since they were added to ${CC} and ${CXX}. But what I meant is that even if you specify those flags, the compiler still searches for headers and libraries in the base system. So if some header is removed from /usr/src, for example, but is still available in /usr/include, it can be erroneously picked up during buildworld. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 13:56:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DA4B1065670 for ; Tue, 17 Aug 2010 13:56:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8278FC1F for ; Tue, 17 Aug 2010 13:56:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B46E446B91; Tue, 17 Aug 2010 09:56:39 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8EE648A03C; Tue, 17 Aug 2010 09:56:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 17 Aug 2010 09:52:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201008170952.50766.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 17 Aug 2010 09:56:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: =?utf-8?q?=C3=81lvaro_Castillo?= Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:56:40 -0000 On Saturday, August 14, 2010 9:35:02 pm =C3=81lvaro Castillo wrote: > $ dmesg (cut) >=20 > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 > cpuid =3D 0 > Uptime: 3m35s Use the latest nvidia driver from the website (256.44) and not from the por= t. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 13:56:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8BE106566C for ; Tue, 17 Aug 2010 13:56:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BD18A8FC15 for ; Tue, 17 Aug 2010 13:56:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3F76346BA0; Tue, 17 Aug 2010 09:56:41 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A6DE8A04E; Tue, 17 Aug 2010 09:56:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 17 Aug 2010 09:54:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> In-Reply-To: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008170954.09041.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 17 Aug 2010 09:56:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , pluknet Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:56:42 -0000 On Monday, August 16, 2010 2:54:56 pm Kostik Belousov wrote: > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: > > On 16 August 2010 21:05, pluknet wrote: > > > Hi. > > > > > > Seeing on mostly idle, recently updated current, while closing a file. > > > Presumably never reported on ML. > > > > > > lock order reversal: > > > 1st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > > > 2nd 0xffffff000234a048 filedesc structure (filedesc structure) @ > > > /usr/src/sys/kern/kern_descrip.c:1580 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > _witness_debugger() at _witness_debugger+0x2e > > > witness_checkorder() at witness_checkorder+0x807 > > > _sx_xlock() at _sx_xlock+0x55 > > > fdinit() at fdinit+0x5b > > > fdcopy() at fdcopy+0x2a > > > fork1() at fork1+0x836 > > > kproc_create() at kproc_create+0x63 > > > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > > > nfs_asyncio() at nfs_asyncio+0xa6 > > > nfs_strategy() at nfs_strategy+0x83 > > > bufstrategy() at bufstrategy+0x43 > > > nfs_writebp() at nfs_writebp+0xcf > > > nfs_flush() at nfs_flush+0x1dc > > > nfs_close() at nfs_close+0x213 > > > vn_close() at vn_close+0x10e > > > vn_closefile() at vn_closefile+0x5a > > > _fdrop() at _fdrop+0x23 > > > closef() at closef+0x5b > > > kern_close() at kern_close+0x110 > > > syscallenter() at syscallenter+0x1aa > > > syscall() at syscall+0x4c > > > Xfast_syscall() at Xfast_syscall+0xe2 > > > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = > > > 0x7fffffffea88, rbp = 0 --- > > > > > > > > > > Mostly the same (different 2nd lock path). > > > > lock order reversal: > > 1st 0xffffff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 > > 2nd 0xffffffff80ca47e0 proctree (proctree) @ /usr/src/sys/kern/kern_fork.c:335 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x807 > > _sx_slock() at _sx_slock+0x55 > > fork1() at fork1+0x190 > > kproc_create() at kproc_create+0x63 > > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 > > nfs_asyncio() at nfs_asyncio+0xa6 > > nfs_strategy() at nfs_strategy+0x83 > > bufstrategy() at bufstrategy+0x43 > > nfs_writebp() at nfs_writebp+0xcf > > nfs_flush() at nfs_flush+0x1dc > > nfs_close() at nfs_close+0x213 > > vn_close() at vn_close+0x10e > > vn_closefile() at vn_closefile+0x5a > > _fdrop() at _fdrop+0x23 > > closef() at closef+0x5b > > kern_close() at kern_close+0x110 > > syscallenter() at syscallenter+0x1aa > > syscall() at syscall+0x4c > > Xfast_syscall() at Xfast_syscall+0xe2 > > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = > > 0x7fffffffea88, rbp = 0 --- > > > Both LORs are valid. The fork performed deep inside the VFS call stack > is obviously problematic. As a workaround, you may fix the number of > nfsiods. > > Proper fix might consist of creating a shepherd thread which only task > is to act on the requests on creating new nfsiods. > > Would you try to implement this ? I will provide the assistance, if needed. Or queue a task to create new nfsiod threads instead of invoking kproc_create() directly. That can be cheaper than creating a dedicated shepherd thread. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 14:11:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E99021065674 for ; Tue, 17 Aug 2010 14:11:43 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 82C4B8FC18 for ; Tue, 17 Aug 2010 14:11:43 +0000 (UTC) Received: from 226-137-132-95.pool.ukrtel.net ([95.132.137.226] helo=localhost) by fsm1.ukr.net with esmtps ID 1OlMtC-0001Mv-03 ; Tue, 17 Aug 2010 17:11:42 +0300 Date: Tue, 17 Aug 2010 17:11:40 +0300 From: Ivan Klymenko To: John Baldwin Message-ID: <20100817171140.21191ffd@ukr.net> In-Reply-To: <201008170952.50766.jhb@freebsd.org> References: <201008170952.50766.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/Pa0j+_toX6Rc1PWiX29PGev" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, =?UTF-8?B?w4FsdmFybw==?= Castillo Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 14:11:44 -0000 --MP_/Pa0j+_toX6Rc1PWiX29PGev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =D0=92 Tue, 17 Aug 2010 09:52:50 -0400 John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Saturday, August 14, 2010 9:35:02 pm =C3=81lvaro Castillo wrote: > > $ dmesg (cut) > >=20 > > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 > > cpuid =3D 0 > > Uptime: 3m35s >=20 > Use the latest nvidia driver from the website (256.44) and not from > the port. >=20 Here the test port... --MP_/Pa0j+_toX6Rc1PWiX29PGev-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 14:21:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D44981065670 for ; Tue, 17 Aug 2010 14:21:18 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 980948FC17 for ; Tue, 17 Aug 2010 14:21:18 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E8C595C59; Tue, 17 Aug 2010 16:21:17 +0200 (CEST) Message-ID: <4C6A9AE7.3060704@andric.com> Date: Tue, 17 Aug 2010 16:21:27 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Alexander Kabaev References: <4C6A7357.8000606@andric.com> <20100817091515.4510ebfd@kan.dnsalias.net> In-Reply-To: <20100817091515.4510ebfd@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 14:21:18 -0000 On 2010-08-17 15:15, Alexander Kabaev wrote: > Dimitry Andric wrote: ... >> 1) The "isysroot" method: build a regular version of clang, and make >> sure WMAKEENV contains something like: >> >> CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \ >> -L${WORLDTMP}/usr/lib/" >> >> 2) The "tools-prefix" method: build a special version of clang, that >> has its default search paths for headers, startup objects and >> libraries modified, to look for everything under ${WORLDTMP}. ... > Does method 1) work fine with 'make buildenv'? I doubt that. I would > strongly suggest we should not lose this feature. I do not like the > idea of having to depend on -isystem in CFLAGS in such an environment. I have not tested make buildenv with this method, but since ${CC} is modified, not ${CFLAGS}, there is a reasonable chance that it might work. :) Note a similar method is already being using for the build32 stage on amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B) appended. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 14:29:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFFB61065673 for ; Tue, 17 Aug 2010 14:29:01 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82D328FC2D for ; Tue, 17 Aug 2010 14:29:01 +0000 (UTC) Received: by vws7 with SMTP id 7so5527626vws.13 for ; Tue, 17 Aug 2010 07:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Qbva9HeXdktDBaLDmljRmILCQFG6bQim2quOg1bOyoQ=; b=vRC18Llrr/Y6uBQ5m8LKWCcwxdSl7Ox7uhPf12Htge02V5feyPamBBaPlUE3M66gpT LiIS9WhxisRQxZ4WqcMToHdb/7C5A0RxxBhU+riXTwl/nnuuvKpMrF8ApJkFMCX7+jtK zN+n9e1FwSoKuubqzEKek+a2LhHzWS6dOLK7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KoxeYwi0mldJhAbdWzVsKNf3vDC/bZ7SfH/jAP2AoZqo++2iI4qG1CWfCX2AsOj9UZ OwHQ/fXwdsQ45qgCNl6S7RWRQs+Cc+CkVi8p+ZdHA8pwjiVowOVrI1eTmmnuJ6Er096W JlEXv2J0VlksV6ObqZ6OX8EBohVU+t8Kzlk44= MIME-Version: 1.0 Received: by 10.220.99.21 with SMTP id s21mr4044472vcn.222.1282055340308; Tue, 17 Aug 2010 07:29:00 -0700 (PDT) Received: by 10.220.193.132 with HTTP; Tue, 17 Aug 2010 07:28:59 -0700 (PDT) In-Reply-To: <4C6A92E0.4050104@andric.com> References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> <4C6A92E0.4050104@andric.com> Date: Tue, 17 Aug 2010 16:28:59 +0200 Message-ID: From: Daniel Nebdal To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 14:29:02 -0000 On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric wrote: > On 2010-08-17 15:03, Daniel Nebdal wrote: >>>> However, a disadvantage is that the built-in search paths of the >>>> bootstrap compiler are not entirely disabled by using the -isysroot, -= B >>>> and -L flags, > ... >> For clarification, did you (Dimitry, that is) mean >> a) The paths are still there so they could resurface if some Makefile >> doesn't specify those flags , or >> b) they sometimes come into play even when using the appropriate flags? > > Any sub-makefiles would not have to specify those flags explicitly, > since they were added to ${CC} and ${CXX}. > > But what I meant is that even if you specify those flags, the compiler > still searches for headers and libraries in the base system. =A0So if som= e > header is removed from /usr/src, for example, but is still available in > /usr/include, it can be erroneously picked up during buildworld. > Mmh, I just read through the in-detail description you gave in another mail. It's a bit surprising that there isn't a simple and reliable way to disable/replace all hardcoded paths, but I guess it doesn't come up that often. As a third possibility, hacking a real -drop-all-builtin-paths flag into the local copies of both compilers could work (essentially being a cleanup of your alternative 1), though there's still the issues with -B. All in all, I agree that your alternative 2 sounds better. --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 15:09:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 608261065670 for ; Tue, 17 Aug 2010 15:09:59 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 215AB8FC19 for ; Tue, 17 Aug 2010 15:09:59 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 381575C59; Tue, 17 Aug 2010 17:09:58 +0200 (CEST) Message-ID: <4C6AA64F.3050100@andric.com> Date: Tue, 17 Aug 2010 17:10:07 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Daniel Nebdal References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> <4C6A92E0.4050104@andric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:09:59 -0000 On 2010-08-17 16:28, Daniel Nebdal wrote: > Mmh, I just read through the in-detail description you gave in another > mail. It's a bit surprising that there isn't a simple and reliable way > to disable/replace all hardcoded paths, but I guess it doesn't come up > that often. Well, except when you want to bootstrap something. :) I guess this whole issue is just not as applicable to Linux, where gcc's main development takes place. > As a third possibility, hacking a real -drop-all-builtin-paths flag > into the local copies of both compilers could work The idea of method 1) is that you do not modify the compiler at all, making it potentially easier to hook in any new compilers, provided they are option-compatible with gcc. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 15:26:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60B3410656A8 for ; Tue, 17 Aug 2010 15:26:19 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 406358FC1A for ; Tue, 17 Aug 2010 15:26:18 +0000 (UTC) Received: by pzk7 with SMTP id 7so2952788pzk.13 for ; Tue, 17 Aug 2010 08:26:18 -0700 (PDT) Received: by 10.114.66.10 with SMTP id o10mr7981053waa.113.1282057466577; Tue, 17 Aug 2010 08:04:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.150.135 with HTTP; Tue, 17 Aug 2010 08:04:06 -0700 (PDT) In-Reply-To: References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> <4C6A92E0.4050104@andric.com> From: Eitan Adler Date: Tue, 17 Aug 2010 11:04:06 -0400 Message-ID: To: Daniel Nebdal Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:26:19 -0000 On Tue, Aug 17, 2010 at 10:28 AM, Daniel Nebdal wrote: > On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric wrot= e: >> On 2010-08-17 15:03, Daniel Nebdal wrote: >>>>> However, a disadvantage is that the built-in search paths of the >>>>> bootstrap compiler are not entirely disabled by using the -isysroot, = -B >>>>> and -L flags, >> ... >>> For clarification, did you (Dimitry, that is) mean >>> a) The paths are still there so they could resurface if some Makefile >>> doesn't specify those flags , or >>> b) they sometimes come into play even when using the appropriate flags? >> >> Any sub-makefiles would not have to specify those flags explicitly, >> since they were added to ${CC} and ${CXX}. >> >> But what I meant is that even if you specify those flags, the compiler >> still searches for headers and libraries in the base system. =C2=A0So if= some >> header is removed from /usr/src, for example, but is still available in >> /usr/include, it can be erroneously picked up during buildworld. >> > > Mmh, I just read through the in-detail description you gave in another > mail. It's a bit surprising that there isn't a simple and reliable way > to disable/replace all hardcoded paths, but I guess it doesn't come up > that often. what about -nostdinc ? Do not search the standard system directories for header files. Or will this also disable the command line equivalents ? --=20 Eitan Adler From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 15:28:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 822D61065672; Tue, 17 Aug 2010 15:28:00 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4658FC18; Tue, 17 Aug 2010 15:28:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6B4A35C59; Tue, 17 Aug 2010 17:27:59 +0200 (CEST) Message-ID: <4C6AAA88.5080606@andric.com> Date: Tue, 17 Aug 2010 17:28:08 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> In-Reply-To: <86sk2faqdl.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:28:00 -0000 On 2010-08-16 10:55, Dag-Erling Sm=C3=B8rgrav wrote: > Dimitry Andric writes: >> - Uses plain file descriptors instead of struct FILE, since the >> buffering is done manually anyway, and it makes it easier to support= >> gzip and bzip2. > It might be worth a shot adding mmap(2) support as well, i.e. when > processing an uncompressed regular file, try to mmap(2) it first, and i= f > that fails, fall back to the plain buffered read(2) method. I added a simple mmap to grep, and time-trialed it, but the mmap version was somewhat slower than the regular version. I understood from Kostik Belousov that readahead does not work properly with mmap, and it should not be used for "one-time" reads. I also experimented with different buffer sizes on the same big test file, and this gives the following results (times in s): buffer size test1 test2 test3 average =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D= =3D=3D=3D 512 467 484 465 472 1,024 391 415 392 399 2,048 361 356 365 361 4,096 353 353 356 354 8,192 348 345 357 350 16,384 341 373 350 354 32,768 339 348 346 344 65,536 336 359 371 355 262,144 334 352 350 345 1,048,576 334 350 351 345 2,097,152 339 342 369 350 373,293,056 544 547 559 550 E.g. the 32k buffer size that I borrowed from GNU grep seems to be reasonable enough. There is no profit in wasting huge amounts of memory to speed things up. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 15:42:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C18D1065696 for ; Tue, 17 Aug 2010 15:42:43 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D02C78FC19 for ; Tue, 17 Aug 2010 15:42:42 +0000 (UTC) Received: by qwg5 with SMTP id 5so7139014qwg.13 for ; Tue, 17 Aug 2010 08:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=23Qfs5dOZKGusrw4Cnv4d2mg+ity8VTxVY+ojtgC68o=; b=EI3cLOER9OlnimVDnCirv6TiyFzlewJMAwypUFHXzLgkKw3RaB9uqxBh1geW61P8Af ZXCizwNJaFWUGF3nbyRLims2G00ghrFZ8ofSVCsjMfcHlBFVtF39XQ+1DIXeh/PWmu2w eIxRwVpojc3b6XrBw/ha4pa7fGolwf9M2fX5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lPmNNL/T3UR0121FoMbrDMSo8mhYRW9QHdt9g4UmwaB+FNsvkmGjtligJ4AtIhjUpv DijE/KzXfZPwvBjMAX2LKyXmhLBskRCGgXfTw0yK5Gsr7C6wgTO5KXIFdVY/unf+ef5h sHacXtGetPI1D0LVTet1ruUWgUWrakDibr+xE= MIME-Version: 1.0 Received: by 10.229.88.10 with SMTP id y10mr4892697qcl.144.1282059761915; Tue, 17 Aug 2010 08:42:41 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Tue, 17 Aug 2010 08:42:41 -0700 (PDT) In-Reply-To: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> Date: Tue, 17 Aug 2010 19:42:41 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: multipart/mixed; boundary=0016367fa1bab09977048e06ccc5 Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:42:43 -0000 --0016367fa1bab09977048e06ccc5 Content-Type: text/plain; charset=ISO-8859-1 2010/8/16 Kostik Belousov : > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: >> On 16 August 2010 21:05, pluknet wrote: >> > Hi. >> > >> > Seeing on mostly idle, recently updated current, while closing a file. >> > Presumably never reported on ML. [...] >> > Both LORs are valid. The fork performed deep inside the VFS call stack > is obviously problematic. As a workaround, you may fix the number of > nfsiods. > > Proper fix might consist of creating a shepherd thread which only task > is to act on the requests on creating new nfsiods. > > Would you try to implement this ? I will provide the assistance, if needed. Hmm.. I tried to move kproc_create() under shepherd thread and now stuck with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b. Did I screw up something? See weird draft patch attached (weird, as I have no idea how to nicely exchange data between nfs_nfsiodnew() and shep_thread() thread). load: 1.34 cmd: cp 1348 [bo_wwait] 4.74r 0.00u 0.00s 0% 1204k tst-web# procstat -k 1348 PID TID COMM TDNAME KSTACK 1348 100095 cp - mi_switch sleepq_switch sleepq_wait _sleep bufobj_wwait nfs_flush nfs_close vn_close vn_closefile _fdrop closef kern_close syscallenter syscall Xfast_syscall Process 1347 (cp) thread 0xffffff0002ed7000 (100094) exclusive lockmgr nfs (nfs) r = 0 (0xffffff006a05a638) locked @ /usr/src/sys/kern/vfs_vnops.c:301 (kgdb) bt #0 sched_switch (td=0xffffff0002ed7000, newtd=0xffffffff80ca17e0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 #1 0xffffffff805bf49b in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:449 #2 0xffffffff805f50e3 in sleepq_switch (wchan=0xffffff006a05a720, pri=77) at /usr/src/sys/kern/subr_sleepqueue.c:530 #3 0xffffffff805f5ccd in sleepq_wait (wchan=0xffffff006a05a720, pri=77) at /usr/src/sys/kern/subr_sleepqueue.c:609 #4 0xffffffff805bfac9 in _sleep (ident=0xffffff006a05a720, lock=0xffffff006a05a6c0, priority=Variable "priority" is not available. ) at /usr/src/sys/kern/kern_synch.c:234 #5 0xffffffff80633083 in bufobj_wwait (bo=0xffffff006a05a6c0, slpflag=Variable "slpflag" is not available. ) at /usr/src/sys/kern/vfs_bio.c:4016 #6 0xffffffff8077f5af in nfs_flush (vp=0xffffff006a05a5a0, waitfor=1, commit=Variable "commit" is not available. ) at /usr/src/sys/nfsclient/nfs_vnops.c:3216 #7 0xffffffff807802e3 in nfs_close (ap=0xffffff8029bd8900) at /usr/src/sys/nfsclient/nfs_vnops.c:644 #8 0xffffffff8065b3fe in vn_close (vp=0xffffff006a05a5a0, flags=2, file_cred=0xffffff006a01b600, td=0xffffff0002ed7000) at vnode_if.h:225 #9 0xffffffff8065b4fa in vn_closefile (fp=0xffffff00027c7500, td=0xffffff0002ed7000) at /usr/src/sys/kern/vfs_vnops.c:942 #10 0xffffffff8057e3e3 in _fdrop (fp=0xffffff00027c7500, td=Variable "td" is not available. ) at file.h:277 #11 0xffffffff8057ff4b in closef (fp=0xffffff00027c7500, td=0xffffff0002ed7000) at /usr/src/sys/kern/kern_descrip.c:2117 ---Type to continue, or q to quit--- #12 0xffffffff80580530 in kern_close (td=0xffffff0002ed7000, fd=4) at /usr/src/sys/kern/kern_descrip.c:1162 -- wbr, pluknet --0016367fa1bab09977048e06ccc5 Content-Type: application/octet-stream; name="nfs_shep.diff" Content-Disposition: attachment; filename="nfs_shep.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcyx7bby0 SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX3Zub3BzLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25mc2Ns aWVudC9uZnNfdm5vcHMuYwkocmV2aXNpb24gMjExMjc5KQorKysgc3lzL25mc2NsaWVudC9uZnNf dm5vcHMuYwkod29ya2luZyBjb3B5KQpAQCAtMjEyLDYgKzIxMiw3IEBACiAgKiBHbG9iYWwgdmFy aWFibGVzCiAgKi8KIHN0cnVjdCBtdHggCW5mc19pb2RfbXR4Oworc3RydWN0IG10eAlzaGVwX210 eDsKIGVudW0gbmZzaW9kX3N0YXRlIG5mc19pb2R3YW50W05GU19NQVhBU1lOQ0RBRU1PTl07CiBz dHJ1Y3QgbmZzbW91bnQgKm5mc19pb2Rtb3VudFtORlNfTUFYQVNZTkNEQUVNT05dOwogaW50CQkg bmZzX251bWFzeW5jID0gMDsKSW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX3N1YnMuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvbmZzY2xpZW50L25mc19zdWJzLmMJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5 cy9uZnNjbGllbnQvbmZzX3N1YnMuYwkod29ya2luZyBjb3B5KQpAQCAtMzU0LDYgKzM1NCw3IEBA CiAJICovCiAJbXR4X2luaXQoJm5mc19pb2RfbXR4LCAiTkZTIGlvZCBsb2NrIiwgTlVMTCwgTVRY X0RFRik7CiAJbXR4X2luaXQoJm5mc194aWRfbXR4LCAiTkZTIHhpZCBsb2NrIiwgTlVMTCwgTVRY X0RFRik7CisJbXR4X2luaXQoJnNoZXBfbXR4LCAiTkZTIHNoZXBfdGhyZWFkIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKIAogCW5mc19wYnVmX2ZyZWVjbnQgPSBuc3didWYgLyAyICsgMTsKIApJbmRl eDogc3lzL25mc2NsaWVudC9uZnNfbmZzaW9kLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25mc2NsaWVu dC9uZnNfbmZzaW9kLmMJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5cy9uZnNjbGllbnQvbmZzX25m c2lvZC5jCSh3b3JraW5nIGNvcHkpCkBAIC03NSw2ICs3NSwxMyBAQAogCiBzdGF0aWMgdm9pZAlu ZnNzdmNfaW9kKHZvaWQgKik7CiAKK3N0cnVjdCBzaGVwaGVyZF9zdHIgeworCWludCAqc2hlcF9p bnN0OworCWludCBzaGVwX25pb2Q7CisJaW50IHNoZXBfZXJyb3I7CisJaW50IHNoZXBfZG9uZTsK K30gc2hlcF9jaGFuOworCiBzdGF0aWMgaW50IG5mc19hc3luY2RhZW1vbltORlNfTUFYQVNZTkNE QUVNT05dOwogCiBTWVNDVExfREVDTChfdmZzX25mcyk7CkBAIC0xNTksMTAgKzE2NiwzMiBAQAog ICAgIHNpemVvZiAobmZzX2lvZG1heCksIHN5c2N0bF9pb2RtYXgsICJJVSIsCiAgICAgIk1heCBu dW1iZXIgb2YgbmZzaW9kIGt0aHJlYWRzIik7CiAKK3N0YXRpYyB2b2lkCitzaGVwX3RocmVhZCh2 b2lkICpkdW1teSkKK3sKKwlpbnQgZXJyID0gMDsKKworLy8JbXR4X2xvY2soJnNoZXBfbXR4KTsK Kwlmb3IgKDs7KSB7CisvLwkJZXJyID0gbXNsZWVwKCZzaGVwX2NoYW4sICZzaGVwX210eCwgUFdB SVQgfCBQQ0FUQ0gsICJzaHB3dCIsIDApOworCQllcnIgPSB0c2xlZXAoJnNoZXBfY2hhbiwgUFdB SVQgfCBQQ0FUQ0gsICJzaHB3dCIsIDApOworCQlpZiAoZXJyKQorCQkJY29udGludWU7CisvLwkJ bXR4X3VubG9jaygmc2hlcF9tdHgpOworCQlzaGVwX2NoYW4uc2hlcF9lcnJvciA9IGtwcm9jX2Ny ZWF0ZShuZnNzdmNfaW9kLAorCQkgICAgJnNoZXBfY2hhbi5zaGVwX2luc3QsIE5VTEwsIFJGSElH SFBJRCwgMCwgIm5mc2lvZCAlZCIsCisJCSAgICBzaGVwX2NoYW4uc2hlcF9uaW9kKTsKKwkJc2hl cF9jaGFuLnNoZXBfZG9uZSA9IDE7CisvLwkJbXR4X2xvY2soJnNoZXBfbXR4KTsKKwl9CisvLwlt dHhfdW5sb2NrKCZzaGVwX210eCk7Cit9CitTWVNJTklUKHNoZXBoZXJkLCBTSV9TVUJfS1RIUkVB RF9JRExFLCBTSV9PUkRFUl9BTlksIHNoZXBfdGhyZWFkLCBOVUxMKTsKKwogaW50CiBuZnNfbmZz aW9kbmV3KGludCBzZXRfaW9kd2FudCkKIHsKLQlpbnQgZXJyb3IsIGk7CisJaW50IGk7CiAJaW50 IG5ld2lvZDsKIAogCWlmIChuZnNfbnVtYXN5bmMgPj0gbmZzX2lvZG1heCkKQEAgLTE3OCwxMSAr MjA3LDE2IEBACiAJCXJldHVybiAoLTEpOwogCWlmIChzZXRfaW9kd2FudCA+IDApCiAJCW5mc19p b2R3YW50W2ldID0gTkZTSU9EX0NSRUFURURfRk9SX05GU19BU1lOQ0lPOworCWJ6ZXJvKCZzaGVw X2NoYW4sIHNpemVvZihzaGVwX2NoYW4pKTsKKwlzaGVwX2NoYW4uc2hlcF9pbnN0ID0gbmZzX2Fz eW5jZGFlbW9uICsgaTsKKwlzaGVwX2NoYW4uc2hlcF9uaW9kID0gbmV3aW9kOwogCW10eF91bmxv Y2soJm5mc19pb2RfbXR4KTsKLQllcnJvciA9IGtwcm9jX2NyZWF0ZShuZnNzdmNfaW9kLCBuZnNf YXN5bmNkYWVtb24gKyBpLCBOVUxMLCBSRkhJR0hQSUQsCi0JICAgIDAsICJuZnNpb2QgJWQiLCBu ZXdpb2QpOworCXdha2V1cCgmc2hlcF9jaGFuKTsKIAltdHhfbG9jaygmbmZzX2lvZF9tdHgpOwot CWlmIChlcnJvcikgeworCXdoaWxlIChzaGVwX2NoYW4uc2hlcF9kb25lKQorCQljb250aW51ZTsK KwlzaGVwX2NoYW4uc2hlcF9kb25lID0gMDsKKwlpZiAoc2hlcF9jaGFuLnNoZXBfZXJyb3IpIHsK IAkJaWYgKHNldF9pb2R3YW50ID4gMCkKIAkJCW5mc19pb2R3YW50W2ldID0gTkZTSU9EX05PVF9B VkFJTEFCTEU7CiAJCXJldHVybiAoLTEpOwpJbmRleDogc3lzL25mc2NsaWVudC9uZnMuaAo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzeXMvbmZzY2xpZW50L25mcy5oCShyZXZpc2lvbiAyMTEyNzkpCisrKyBzeXMv bmZzY2xpZW50L25mcy5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMjUsNiArMTI1LDcgQEAKIAogZXh0 ZXJuIHN0cnVjdCBuZnNzdGF0cyBuZnNzdGF0czsKIGV4dGVybiBzdHJ1Y3QgbXR4IG5mc19pb2Rf bXR4OworZXh0ZXJuIHN0cnVjdCBtdHggc2hlcF9tdHg7CiAKIGV4dGVybiBpbnQgbmZzX251bWFz eW5jOwogZXh0ZXJuIHVuc2lnbmVkIGludCBuZnNfaW9kbWF4Owo= --0016367fa1bab09977048e06ccc5-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 15:47:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B45110656A8 for ; Tue, 17 Aug 2010 15:47:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA118FC23 for ; Tue, 17 Aug 2010 15:47:13 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7HFjbj5033915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 18:45:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7HFjb5i006131; Tue, 17 Aug 2010 18:45:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7HFjbd9006130; Tue, 17 Aug 2010 18:45:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Aug 2010 18:45:37 +0300 From: Kostik Belousov To: Dimitry Andric Message-ID: <20100817154537.GM2396@deviant.kiev.zoral.com.ua> References: <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XrEgl6YxVIw5fRRT" Content-Disposition: inline In-Reply-To: <4C6AAA88.5080606@andric.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:47:14 -0000 --XrEgl6YxVIw5fRRT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Cc: list sanitized] On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote: > On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote: > > Dimitry Andric writes: > >> - Uses plain file descriptors instead of struct FILE, since the > >> buffering is done manually anyway, and it makes it easier to support > >> gzip and bzip2. > > It might be worth a shot adding mmap(2) support as well, i.e. when > > processing an uncompressed regular file, try to mmap(2) it first, and if > > that fails, fall back to the plain buffered read(2) method. >=20 > I added a simple mmap to grep, and time-trialed it, but the mmap version > was somewhat slower than the regular version. I understood from Kostik > Belousov that readahead does not work properly with mmap, and it should > not be used for "one-time" reads. This is not exactly what I said. I argue that read-ahead implemented by vm_faul() is much less efficient that buffer clustering. Also, the cost of setting user mapping for the one time read is also non-trivial. The conclusion is right, it is better to use read(2) for one-time read. --XrEgl6YxVIw5fRRT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxqrqEACgkQC3+MBN1Mb4ieBQCgr3hLFBU2p68taZr5szZ9Rwv2 dc8An0j/aPqtFF2W0OGHmlYCF2YeRp9g =8N0A -----END PGP SIGNATURE----- --XrEgl6YxVIw5fRRT-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:04:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B480106567A for ; Tue, 17 Aug 2010 16:04:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A9F3C8FC14 for ; Tue, 17 Aug 2010 16:04:52 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7HG4kh5035598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 19:04:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7HG4kl1006329; Tue, 17 Aug 2010 19:04:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7HG4jxA006328; Tue, 17 Aug 2010 19:04:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Aug 2010 19:04:45 +0300 From: Kostik Belousov To: pluknet Message-ID: <20100817160445.GO2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+aJhGqIeocQJJWbN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:04:53 -0000 --+aJhGqIeocQJJWbN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote: > 2010/8/16 Kostik Belousov : > > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: > >> On 16 August 2010 21:05, pluknet wrote: > >> > Hi. > >> > > >> > Seeing on mostly idle, recently updated current, while closing a fil= e. > >> > Presumably never reported on ML. > [...] > >> > > Both LORs are valid. The fork performed deep inside the VFS call stack > > is obviously problematic. As a workaround, you may fix the number of > > nfsiods. > > > > Proper fix might consist of creating a shepherd thread which only task > > is to act on the requests on creating new nfsiods. > > > > Would you try to implement this ? I will provide the assistance, if nee= ded. >=20 > Hmm.. I tried to move kproc_create() under shepherd thread and now stuck > with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b. > Did I screw up something? > See weird draft patch attached (weird, as I have no idea how to nicely > exchange data between nfs_nfsiodnew() and shep_thread() thread). Most likely, you loose the requests to create nfsiods since the existing request in the global variable shep_chan can be overwritten by new request. You should either sleep till existing request is serviced, or form a queue. Also please take a note of the John' suggestion to use the taskqueue. --+aJhGqIeocQJJWbN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxqsx0ACgkQC3+MBN1Mb4jIygCeJaFieJ7FfnurFjWPQZnUs7rQ rXsAoIv8Wn5f4F0MSC7sd085LRZzIhwD =JJsd -----END PGP SIGNATURE----- --+aJhGqIeocQJJWbN-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:14:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1901010656AB for ; Tue, 17 Aug 2010 16:14:41 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D57368FC1D for ; Tue, 17 Aug 2010 16:14:40 +0000 (UTC) Received: by gwj23 with SMTP id 23so3213041gwj.13 for ; Tue, 17 Aug 2010 09:14:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.79.11 with SMTP id g11mr3186162ybl.219.1282059878236; Tue, 17 Aug 2010 08:44:38 -0700 (PDT) Received: by 10.231.176.140 with HTTP; Tue, 17 Aug 2010 08:44:37 -0700 (PDT) In-Reply-To: <20100817050128.GC13790@lonesome.com> References: <20100817050128.GC13790@lonesome.com> Date: Tue, 17 Aug 2010 17:44:37 +0200 Message-ID: From: Olivier Smedts To: Mark Linimon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lhmwzy , current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:14:41 -0000 2010/8/17 Mark Linimon : > On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote: >> opensolaris is gone > > It appears there will be a fork, but that's not particularly crucial > to FreeBSD. > >> ZFS also gone. OpenSolaris is gone, Oracle won't make any OpenSolaris release but they're still working on Solaris (and maybe ZFS). But did they close the sources too ? I mean, they have a VCS, can we still access it and download the ZFS source files ? Did they also relicense them ? As for btrfs, don't forget it's GPL, and still not production-ready. ZFS has a proven reliability, if Oracle drops it because they have btrfs, I'll be very angry... > We're not going to drop ZFS because Oracle's plans are unclear. =A0It > remains to be seen how much other community support there is behind ZFS. > >> Will FreeBSD import btrfs or other similar file system? > > >From my observation, it takes about 2 years from the initial work on a > new filesystem until it's relatively stable, so I don't know why we would > suddenly decide to go that direction. > > mcl > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:16:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F4991065674 for ; Tue, 17 Aug 2010 16:16:36 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 20F878FC1F for ; Tue, 17 Aug 2010 16:16:35 +0000 (UTC) Received: by pvg4 with SMTP id 4so2968644pvg.13 for ; Tue, 17 Aug 2010 09:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9OfaXfjcPQYQRQc+Qjlzh+/4+b7jCLk13xSI6L+AZtQ=; b=jgWlDeztHmjdW/8/UEVpekT6qvr6lL+3VyscPPJRSnbdB4fs/zhbj9vDNlTs/idyCg RH57MWmho47Sf45NyfAUK6Twa4zDfpgZOcgzL3NtjqD5J17Adz+H0I+EhISZrcxoIS83 P4sQOIrvK/ROqtuZZpuJxlzDaBGvC3+uxmxyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BEAEqY9ObzvMm3yjHHMwFTEmirXkwI/e89ba3MYPkdv/tx5D+7I4IBL3O9v/WQ0bsc Ijv1pcO+juXhIExHvq3xYCOsZ/9a1wOOEFDOKASvzXHsxY2l6dmHtrp1QLzPvIqtWu8q bqUch6RFvTinRRbNXq3msFD1FRxx3InfWxyxs= MIME-Version: 1.0 Received: by 10.115.47.13 with SMTP id z13mr8127063waj.30.1282061795351; Tue, 17 Aug 2010 09:16:35 -0700 (PDT) Received: by 10.220.72.4 with HTTP; Tue, 17 Aug 2010 09:16:34 -0700 (PDT) In-Reply-To: <20100817160445.GO2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> Date: Tue, 17 Aug 2010 16:16:34 +0000 Message-ID: From: Matthew Fleming To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: pluknet , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:16:36 -0000 On Tue, Aug 17, 2010 at 4:04 PM, Kostik Belousov wrote: > On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote: >> 2010/8/16 Kostik Belousov : >> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: >> >> On 16 August 2010 21:05, pluknet wrote: >> >> > Hi. >> >> > >> >> > Seeing on mostly idle, recently updated current, while closing a file. >> >> > Presumably never reported on ML. >> [...] >> >> >> > Both LORs are valid. The fork performed deep inside the VFS call stack >> > is obviously problematic. As a workaround, you may fix the number of >> > nfsiods. >> > >> > Proper fix might consist of creating a shepherd thread which only task >> > is to act on the requests on creating new nfsiods. >> > >> > Would you try to implement this ? I will provide the assistance, if needed. >> >> Hmm.. I tried to move kproc_create() under shepherd thread and now stuck >> with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b. >> Did I screw up something? >> See weird draft patch attached (weird, as I have no idea how to nicely >> exchange data between nfs_nfsiodnew() and shep_thread() thread). > Most likely, you loose the requests to create nfsiods since the > existing request in the global variable shep_chan can be overwritten > by new request. You should either sleep till existing request is serviced, > or form a queue. If you sleep for the request to be serviced, this presumably has the same LOR/deadlock possibility (unless locks are released before sleep), except now WITNESS can't see the LOR. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:34:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31811065696 for ; Tue, 17 Aug 2010 16:34:59 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id AFFBC8FC0C for ; Tue, 17 Aug 2010 16:34:59 +0000 (UTC) Received: by gwj23 with SMTP id 23so3229348gwj.13 for ; Tue, 17 Aug 2010 09:34:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.182.204 with SMTP id cd12mr7930564ibb.101.1282062898525; Tue, 17 Aug 2010 09:34:58 -0700 (PDT) Received: by 10.231.176.140 with HTTP; Tue, 17 Aug 2010 09:34:58 -0700 (PDT) In-Reply-To: References: <20100817050128.GC13790@lonesome.com> Date: Tue, 17 Aug 2010 18:34:58 +0200 Message-ID: From: Olivier Smedts To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mark Linimon , lhmwzy , current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:35:00 -0000 2010/8/17 Artem Belevich : >> But did they close the sources too ? >> I mean, they have a VCS, can we still access it and download the ZFS sou= rce files ? > > If I understand Oracle's announcement correctly, sources would still > be available. The change is that they will stop publishing them > near-real-time and would release them after corresponding features > appear in official Solaris release. > >> Did they also relicense them ? > Quote: > =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 > We will not remove the CDDL from any files in Solaris to which it > already applies, and new source code files that are created will > follow the current policy regarding applying the CDDL (simply, that > usr/src files will have the CDDL, and the very small minority of files > in usr/closed might not have it) > =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 > > The way I read it ZFS will still be available under CDDL. Great. That would mean : no change for ZFS in FreeBSD. If Oracle implements the long-awaited block pointer rewrite feature, we'll be able to import it :) I hope they will continue working on it, even if they have btrfs... > > --Artem > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:35:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 674AF1065693 for ; Tue, 17 Aug 2010 16:35:53 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2219A8FC21 for ; Tue, 17 Aug 2010 16:35:52 +0000 (UTC) Received: by ywk9 with SMTP id 9so3202967ywk.13 for ; Tue, 17 Aug 2010 09:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:cc:content-type :content-transfer-encoding; bh=6jSIUmXES/SKxKHnRlejEjXiJc3ALG7v1kZJF6BZ+2k=; b=pBso+FR/A1wxmpVMT4lxQJVBDD5pH6kU0zFSrSTS1nvJgl56T+vp9fvgQT/tT5opCJ Z69s/K/gYovx+MQKonaMAALfyN+3nKWBAjH9YYKBYysNXm3bbfSl+Sn6ZXjR+k45ZKST dPj7mAVOhFb2OB/im/YEEz8Dw6L5ozwGIfYSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding; b=w6dpgV93YEC769ElRIrT+DUNpM0I+sifdvT2ynnBLAs6rW3KFq7+mxIGvD9yv4CSDK l9zSUjGsE1owMYkpeEBdnIK+1TCs5EU/LJqZhU+ioqImlnJSJpvYyeK6XySQdDy3FOdI x9lJKqpCK5f7u2GUN9JuZ9mk3NioLyIy96hY0= MIME-Version: 1.0 Received: by 10.100.33.18 with SMTP id g18mr7851469ang.68.1282062952305; Tue, 17 Aug 2010 09:35:52 -0700 (PDT) Received: by 10.231.199.15 with HTTP; Tue, 17 Aug 2010 09:35:52 -0700 (PDT) In-Reply-To: References: <20100817050128.GC13790@lonesome.com> Date: Tue, 17 Aug 2010 11:35:52 -0500 Message-ID: From: Astrodog Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:35:53 -0000 On Tue, Aug 17, 2010 at 10:44 AM, Olivier Smedts wrote: > 2010/8/17 Mark Linimon : >> On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote: >>> opensolaris is gone >> >> It appears there will be a fork, but that's not particularly crucial >> to FreeBSD. >> >>> ZFS also gone. > > OpenSolaris is gone, Oracle won't make any OpenSolaris release but > they're still working on Solaris (and maybe ZFS). > > But did they close the sources too ? I mean, they have a VCS, can we > still access it and download the ZFS source files ? Did they also > relicense them ? > As for btrfs, don't forget it's GPL, and still not production-ready. > ZFS has a proven reliability, if Oracle drops it because they have > btrfs, I'll be very angry... > >> We're not going to drop ZFS because Oracle's plans are unclear. =A0It >> remains to be seen how much other community support there is behind ZFS. >> >>> Will FreeBSD import btrfs or other similar file system? >> >> >From my observation, it takes about 2 years from the initial work on a >> new filesystem until it's relatively stable, so I don't know why we woul= d >> suddenly decide to go that direction. >> >> mcl Assuming, for the moment, that there is no other support behind ZFS, I don't see why one would want to remove it from FreeBSD. It fills a useful gap, as far as filesystems on FreeBSD go, and if it came down to it, atleast for the foreseeable future, it would be worth supporting alone. It's not like anyone thinks FreeBSD should toss out UFS2, just because not many other OSes use it. The same holds true for DTrace. It's useful to have, Solaris or no Solaris. OpenSolaris dying shouldn't have a big impact on where FreeBSD goes with these tools, as long as they continue to be useful for the community and the developers, and aren't hampering development elsewhere. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:47:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97AB61065675 for ; Tue, 17 Aug 2010 16:47:33 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9938FC0A for ; Tue, 17 Aug 2010 16:47:33 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id B39FCA5A3A0; Wed, 18 Aug 2010 00:47:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 6iJymwtKiirk; Wed, 18 Aug 2010 00:47:26 +0800 (CST) Received: from delta.delphij.net (c-24-4-100-103.hsd1.ca.comcast.net [24.4.100.103]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 68009A5A44A; Wed, 18 Aug 2010 00:47:25 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=WN/zDS9V41Q425ElOxtq7VSEGFF5YylNVnBzJa05R/D5rVJT0GltIJJubfaAdFzLo GElMMzzwnL/RlyEOcJ3cg== Message-ID: <4C6ABD04.3030506@delphij.net> Date: Tue, 17 Aug 2010 09:47:00 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100721 Thunderbird/3.0.6 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: lhmwzy References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:47:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/08/16 21:21, lhmwzy wrote: > opensolaris is gone,ZFS also gone. It's not "gone" since Oracle can not withdraw code that is already licensed under CDDL. They _may_ choose not to release anything new but we already have a newer zfs version that have basic functionality usable in p4. > Will FreeBSD import btrfs or other similar file system? Not until someone(TM) sit down and work on it. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMar0EAAoJEATO+BI/yjfB56sH/0kp+vWpiomiC7GKp6q8RFis wH+VTdh0HJbxeguXX89otUbHwQ5bm4XdxKl1PCUH7HFAkbUgKxkhRLGQAefMiGQE yqH+IVY3hT4qWpPaFkXadzx7TKyP/zEbrKOSdf+9zjMu64RCipmfH3PvqoZn7fVu KLQPUdeWhAY63MsFI7fAoLRqCckWS6YpcQrGcQhKqJ5TGPkXh50Ww3ZUGN9dGUvZ Ik2+SEXscBjB/lKjxurkBruqwJkrowUTORUcD5RQrb2hYJEQdkFEpYBk0RXVYNuX 61uNGgUGM9/PUnqSA+ddU5sckFLk/9lyj/+TVk5eEqaskSOHi+DKL+xSE1U1cqs= =Zq75 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:47:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3518106566C; Tue, 17 Aug 2010 16:47:35 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4D7A08FC12; Tue, 17 Aug 2010 16:47:35 +0000 (UTC) Received: from 226-137-132-95.pool.ukrtel.net ([95.132.137.226] helo=localhost) by fsm1.ukr.net with esmtps ID 1OlPK1-000POI-O0 ; Tue, 17 Aug 2010 19:47:34 +0300 Date: Tue, 17 Aug 2010 19:47:32 +0300 From: Ivan Klymenko To: Rainer Hurling Message-ID: <20100817194732.450cbacf@ukr.net> In-Reply-To: <4C6AB739.3090708@gwdg.de> References: <201008170952.50766.jhb@freebsd.org> <20100817171140.21191ffd@ukr.net> <4C6AB739.3090708@gwdg.de> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/VfPXRcQbJkkr8FboxyWVX+." X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, =?UTF-8?B?w4FsdmFybw==?= Castillo Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:47:35 -0000 --MP_/VfPXRcQbJkkr8FboxyWVX+. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline > >>> $ dmesg (cut) > >>> > >>> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 > >>> cpuid = 0 > >>> Uptime: 3m35s > >> > >> Use the latest nvidia driver from the website (256.44) and not from > >> the port. > >> > > Here the test port... > > Sorry, I am afraid there is no attachment another attempt... --MP_/VfPXRcQbJkkr8FboxyWVX+.-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:56:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02129106566B; Tue, 17 Aug 2010 16:56:29 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EABA8FC13; Tue, 17 Aug 2010 16:56:27 +0000 (UTC) Received: by qyk4 with SMTP id 4so1238685qyk.13 for ; Tue, 17 Aug 2010 09:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=1NHmXTkBivldHwlHDsPakYo/SXetgFBOjJam3SoknQY=; b=DiSRtjeRTl9Qh/YtVcEk+8+XlDG1jT+4ZgS4Uac784h0zeKwc71ThFyD8mzPw0+WmW kWHBanh8VRUc4e0t+98MYyCf+dlZUzXqIVRpsZ4LvzKw2RgoxdOp9kWLlZ5og9L4h9lM DiFhlSFNw2g+Rq7ebiZ+/E2+P5PBGqtDxtMyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=lr03hfdbRi9P6R5cbmTGllqmQysGXAIQlu3EuKoX+8TmivCixLFdo0/EccarM7P8p8 D8KuDbHoiaTTu3RNP+iMgfUu6rB+RKZN+ketHqsTpEQRxIw9z9BldvbUU0bGI4H3iscf D19hhX08Ietpf3DSCM5wAtNq9of+R+jBcYRf8= MIME-Version: 1.0 Received: by 10.229.52.31 with SMTP id f31mr560477qcg.256.1282062590873; Tue, 17 Aug 2010 09:29:50 -0700 (PDT) Received: by 10.229.22.11 with HTTP; Tue, 17 Aug 2010 09:29:50 -0700 (PDT) In-Reply-To: <4C6AAA88.5080606@andric.com> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> Date: Tue, 17 Aug 2010 11:29:50 -0500 Message-ID: From: Alan Cox To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , Justin Hibbits , core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Steve Kargl , =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:56:29 -0000 2010/8/17 Dimitry Andric > On 2010-08-16 10:55, Dag-Erling Sm=F8rgrav wrote: > > Dimitry Andric writes: > >> - Uses plain file descriptors instead of struct FILE, since the > >> buffering is done manually anyway, and it makes it easier to support > >> gzip and bzip2. > > It might be worth a shot adding mmap(2) support as well, i.e. when > > processing an uncompressed regular file, try to mmap(2) it first, and i= f > > that fails, fall back to the plain buffered read(2) method. > > I added a simple mmap to grep, and time-trialed it, but the mmap version > was somewhat slower than the regular version. I understood from Kostik > Belousov that readahead does not work properly with mmap, and it should > not be used for "one-time" reads. > > Try it again on a memory resident file with the MAP_PREFAULT_READ option that is provided by this patch: http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch Regards, Alan From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 16:58:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6C610656A8 for ; Tue, 17 Aug 2010 16:58:40 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9858FC0A for ; Tue, 17 Aug 2010 16:58:39 +0000 (UTC) Received: by vws7 with SMTP id 7so5673948vws.13 for ; Tue, 17 Aug 2010 09:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Coelob1DPpVNw66Xm4jC7l28IvnIfYI3InL2dDob33o=; b=agT2XUpSnbKK7woiL/FwZj7pbb1Dc/FetH13m6iJNWE/tmsppiKSV5NQOb7zEG9AOJ Emp9fg1BGwlmxJqryNrcUvkTqKQ46nNEzu026LJ635ruUT/UJMD/4AmA4IEN8H3v6YWG NEcoZf327/EQK3oRzn3Hah5NdJ9FhVfeuhpTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HYZzqMBEKkZyzTS9c+WwuE2zRKykEmj6k2MdwBkS+eFDcuw2Dt+WJVSq5Wc1Bwygtv oRGPuSnx4Uk/vP4qjkI1qiGlBN8Mfp5vR9OzdiU87dWp5NncZcJ0QlGXi2ZH1u/rf/G/ eBKbV65MMZTLziRIsq8V9f0gx7XkQqDd3gRio= MIME-Version: 1.0 Received: by 10.220.124.74 with SMTP id t10mr4240979vcr.39.1282062692591; Tue, 17 Aug 2010 09:31:32 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.49.70 with HTTP; Tue, 17 Aug 2010 09:31:32 -0700 (PDT) In-Reply-To: References: <20100817050128.GC13790@lonesome.com> Date: Tue, 17 Aug 2010 09:31:32 -0700 X-Google-Sender-Auth: ggkvDYxkreLonaunwSfU02H5hrs Message-ID: From: Artem Belevich To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Linimon , lhmwzy , current@freebsd.org Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:58:40 -0000 > But did they close the sources too ? > I mean, they have a VCS, can we still access it and download the ZFS source files ? If I understand Oracle's announcement correctly, sources would still be available. The change is that they will stop publishing them near-real-time and would release them after corresponding features appear in official Solaris release. > Did they also relicense them ? Quote: ==================================== We will not remove the CDDL from any files in Solaris to which it already applies, and new source code files that are created will follow the current policy regarding applying the CDDL (simply, that usr/src files will have the CDDL, and the very small minority of files in usr/closed might not have it) ==================================== The way I read it ZFS will still be available under CDDL. --Artem From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 17:17:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF20B106564A for ; Tue, 17 Aug 2010 17:17:47 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAF18FC15 for ; Tue, 17 Aug 2010 17:17:47 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OlOvd-0003En-1Q; Tue, 17 Aug 2010 18:22:21 +0200 Message-ID: <4C6AB739.3090708@gwdg.de> Date: Tue, 17 Aug 2010 18:22:17 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.8) Gecko/20100806 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ivan Klymenko References: <201008170952.50766.jhb@freebsd.org> <20100817171140.21191ffd@ukr.net> In-Reply-To: <20100817171140.21191ffd@ukr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:17:48 -0000 On 17.08.2010 16:11 (UTC+1), Ivan Klymenko wrote: > Ð’ Tue, 17 Aug 2010 09:52:50 -0400 > John Baldwin пишет: > >> On Saturday, August 14, 2010 9:35:02 pm Ãlvaro Castillo wrote: >>> $ dmesg (cut) >>> >>> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 >>> cpuid = 0 >>> Uptime: 3m35s >> >> Use the latest nvidia driver from the website (256.44) and not from >> the port. >> > Here the test port... Sorry, I am afraid there is no attachment From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 17:32:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C54F01065672 for ; Tue, 17 Aug 2010 17:32:55 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 702FE8FC23 for ; Tue, 17 Aug 2010 17:32:55 +0000 (UTC) Received: by qwg5 with SMTP id 5so7270095qwg.13 for ; Tue, 17 Aug 2010 10:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=cXqxRi5Ftwm38qqFrPCHP5RCst/pYGgU7PW1B1Ur4F8=; b=gk60J6ZU9uQ8oqb5RK2omOu5jWnm2f7o3fBPywhn/PTVg7UsFvdKI2R/yqASoZnRRI Gf8+x5G47HNkZbCPH4faDFmprOYxlo7TUeb6iVdT5jUV1qPxlVL9M/K2oM+3WsMelZY4 jCeL1lOC7npjVs2zVQqB/JUy5AMFA03602bro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=x8PIGys4ne/BiBxOrIlxQfPoeHAMhGg8rzfj5NflUY1j86XxEIn2RakItHjh5JZCn2 6XIsEf+2jaSHM1QyzNyf09+UqTzc9tTZsz+dexewFLRk6L2y8Ypn6NJpD37zxOsAlwiN 0zUZI9oL3YqBkI3W4/p9HzzS5hcnnclPR/Y84= MIME-Version: 1.0 Received: by 10.224.71.148 with SMTP id h20mr4549759qaj.361.1282066372902; Tue, 17 Aug 2010 10:32:52 -0700 (PDT) Received: by 10.229.22.11 with HTTP; Tue, 17 Aug 2010 10:32:52 -0700 (PDT) In-Reply-To: <20100817154537.GM2396@deviant.kiev.zoral.com.ua> References: <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <20100817154537.GM2396@deviant.kiev.zoral.com.ua> Date: Tue, 17 Aug 2010 12:32:52 -0500 Message-ID: From: Alan Cox To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dimitry Andric , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:32:55 -0000 On Tue, Aug 17, 2010 at 10:45 AM, Kostik Belousov wrote: > [Cc: list sanitized] > > On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote: > > On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote: > > > Dimitry Andric writes: > > >> - Uses plain file descriptors instead of struct FILE, since the > > >> buffering is done manually anyway, and it makes it easier to support > > >> gzip and bzip2. > > > It might be worth a shot adding mmap(2) support as well, i.e. when > > > processing an uncompressed regular file, try to mmap(2) it first, and > if > > > that fails, fall back to the plain buffered read(2) method. > > > > I added a simple mmap to grep, and time-trialed it, but the mmap version > > was somewhat slower than the regular version. I understood from Kostik > > Belousov that readahead does not work properly with mmap, and it should > > not be used for "one-time" reads. > This is not exactly what I said. I argue that read-ahead implemented > by vm_faul() is much less efficient that buffer clustering. Also, > the cost of setting user mapping for the one time read is also non-trivial. > The conclusion is right, it is better to use read(2) for one-time read. > The mapping (and unmapping) costs should be relatively small if the contents of the file can be prefaulted using 2/4MB pages. In such cases, we still touch every struct vm_page in the 2/4MB region, but we only create and destroy one PTE and PV entry, and perform a single INVLPG. Alan From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 17:47:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A914D1065693 for ; Tue, 17 Aug 2010 17:47:27 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1008FC23 for ; Tue, 17 Aug 2010 17:47:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6520D5C59; Tue, 17 Aug 2010 19:47:26 +0200 (CEST) Message-ID: <4C6ACB37.8010602@andric.com> Date: Tue, 17 Aug 2010 19:47:35 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Eitan Adler References: <4C6A7357.8000606@andric.com> <19F5467B-6432-4531-BF04-62D8EB4F3093@gid.co.uk> <4C6A92E0.4050104@andric.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Daniel Nebdal , current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:47:27 -0000 On 2010-08-17 17:04, Eitan Adler wrote: > what about -nostdinc ? > Do not search the standard system directories for header files. > > Or will this also disable the command line equivalents ? It seems that -isysroot doesn't work with that: $ gcc -nostdinc -isysroot ${WORLDTMP} -S -v test.c [...] #include "..." search starts here: #include <...> search starts here: End of search list. So you have to cumbersomely specify all needed include directories by hand instead: $ gcc -nostdinc -isystem ${WORLDTMP}/usr/include/gcc/4.2 -isystem ${WORLDTMP}/usr/include -S -v testc [...] #include "..." search starts here: #include <...> search starts here: ${WORLDTMP}/usr/include/gcc/4.2 ${WORLDTMP}/usr/include End of search list. An alternative that almost works properly, is when you use multiple -B options: - The first pointing to ${WORLDTMP}/usr/bin, where as and ld live - The second pointing to ${WORLDTMP}/usr/libexec, where cc1, cc1obj and cc1plus live - The third pointing to ${WORLDTMP}/usr/lib, where the startup objects and the libraries live This results in: $ gcc -B${WORLDTMP}/usr/bin -B${WORLDTMP}/usr/libexec -B${WORLDTMP}/usr/lib -v test.c -o test Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] ${WORLDTMP}/usr/libexec/cc1 -quiet -v -D_LONGLONG test.c -quiet -dumpbase test.c -auxbase test -version -o /tmp/cceCBnL1.s #include "..." search starts here: #include <...> search starts here: ${WORLDTMP}/usr/include/gcc/4.2 ${WORLDTMP}/usr/include End of search list. GNU C version 4.2.1 20070719 [FreeBSD] (i386-undermydesk-freebsd) compiled by GNU C version 4.2.1 20070719 [FreeBSD]. GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128948 Compiler executable checksum: c9b7cdb24796993b910f114335b27daf ${WORLDTMP}/usr/bin/as -o /tmp/ccTZPpZn.o /tmp/cceCBnL1.s ${WORLDTMP}/usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o test ${WORLDTMP}/usr/lib/crt1.o ${WORLDTMP}/usr/lib/crti.o ${WORLDTMP}/usr/lib/crtbegin.o -L${WORLDTMP}/usr/bin -L${WORLDTMP}/usr/bin -L${WORLDTMP}/usr/libexec -L${WORLDTMP}/usr/libexec -L${WORLDTMP}/usr/lib -L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib /tmp/ccTZPpZn.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ${WORLDTMP}/usr/lib/crtend.o ${WORLDTMP}/usr/lib/crtn.o GNU ld version 2.15 [FreeBSD] 2004-05-23 Supported emulations: elf_i386_fbsd The include directories have been completely reset, but unfortunately you can still see the default library directory /usr/lib in there. Yet another alternative is to use the COMPILER_PATH and LIBRARY_PATH environment variables, which can contain colon-separated directories: $ COMPILER_PATH=${WORLDTMP}/usr/bin:${WORLDTMP}/usr/libexec LIBRARY_PATH=${WORLDTMP}/usr/lib gcc -v hello.c -o hello Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] ${WORLDTMP}/usr/libexec/cc1 -quiet -v -D_LONGLONG test.c -quiet -dumpbase test.c -auxbase test -version -o /tmp/cciXQvhb.s #include "..." search starts here: #include <...> search starts here: ${WORLDTMP}/usr/include/gcc/4.2 ${WORLDTMP}/usr/include End of search list. GNU C version 4.2.1 20070719 [FreeBSD] (i386-undermydesk-freebsd) compiled by GNU C version 4.2.1 20070719 [FreeBSD]. GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128948 Compiler executable checksum: c9b7cdb24796993b910f114335b27daf ${WORLDTMP}/usr/bin/as -o /tmp/ccKJZI5V.o /tmp/cciXQvhb.s ${WORLDTMP}/usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o test ${WORLDTMP}/usr/lib/crt1.o ${WORLDTMP}/usr/lib/crti.o ${WORLDTMP}/usr/lib/crtbegin.o -L${WORLDTMP}/usr/lib -L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib /tmp/ccKJZI5V.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ${WORLDTMP}/usr/lib/crtend.o ${WORLDTMP}/usr/lib/crtn.o GNU ld version 2.15 [FreeBSD] 2004-05-23 Supported emulations: elf_i386_fbsd Conclusion: it looks like there is no working option to disable the built-in library directory /usr/lib. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 18:01:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E13106567A; Tue, 17 Aug 2010 18:01:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D8E398FC1C; Tue, 17 Aug 2010 18:01:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7HI16AL023796; Tue, 17 Aug 2010 14:01:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7HI16kG023771; Tue, 17 Aug 2010 18:01:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 17 Aug 2010 18:01:06 GMT Message-Id: <201008171801.o7HI16kG023771@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:01:08 -0000 TB --- 2010-08-17 17:55:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-17 17:55:45 - starting HEAD tinderbox run for powerpc/powerpc64 TB --- 2010-08-17 17:55:45 - mkdir /tinderbox/HEAD/powerpc/powerpc64 TB --- 2010-08-17 17:55:45 - cleaning the object tree TB --- 2010-08-17 17:55:45 - cvsupping the source tree TB --- 2010-08-17 17:55:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc64/supfile TB --- 2010-08-17 18:01:06 - building world TB --- 2010-08-17 18:01:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-17 18:01:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-17 18:01:06 - TARGET=powerpc64 TB --- 2010-08-17 18:01:06 - TARGET_ARCH=powerpc TB --- 2010-08-17 18:01:06 - TZ=UTC TB --- 2010-08-17 18:01:06 - __MAKE_CONF=/dev/null TB --- 2010-08-17 18:01:06 - cd /src TB --- 2010-08-17 18:01:06 - /usr/bin/make -B buildworld "/src/Makefile.inc1", line 139: Unknown target powerpc:powerpc64. *** Error code 1 Stop in /src. TB --- 2010-08-17 18:01:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-17 18:01:06 - ERROR: failed to build world TB --- 2010-08-17 18:01:06 - 12.50 user 39.09 system 321.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc64.full From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 18:32:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D6CC1065679 for ; Tue, 17 Aug 2010 18:32:44 +0000 (UTC) (envelope-from echotty3@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2CF8FC13 for ; Tue, 17 Aug 2010 18:32:43 +0000 (UTC) Received: by vws7 with SMTP id 7so5779214vws.13 for ; Tue, 17 Aug 2010 11:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=vlC+TSvINa49A5zR+gD1MKfpu0s4A+4FgN1H6kdKPWY=; b=GKPPseSYYedY7hUy6JjoOX7njjrcz8sNL9i1c3iJEKk3/VNMGoxYIs743waE8BIgVs vq/xnH02V8IIcjQavK3P5jN+ulqQZGnHjxy1Rh5fcYvha+lQk2UDYshzxxTKa4L/GlDd qdGiHY33eK8BKIovhpY8n3EHsrT/wMVsfREuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kdI95VyVY+qdpwB34Kq509ljzFjKjHwOybB97QWTWiyLXQmIn2taO1TyN4CnIuMzZX Jdnp/GqOPvg82lkfGUcjEpQCJqlsdjpForAaJZnb4cHgsXJxskmZkOTRcTlnrBcD0nAo 4PDXKE0fhP/vqNcARebJqOwRCmBWWTdBEp6Nk= MIME-Version: 1.0 Received: by 10.220.59.202 with SMTP id m10mr4301843vch.48.1282069961889; Tue, 17 Aug 2010 11:32:41 -0700 (PDT) Received: by 10.220.190.5 with HTTP; Tue, 17 Aug 2010 11:32:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Aug 2010 19:32:41 +0100 Message-ID: From: =?UTF-8?Q?=C3=81lvaro_Castillo?= To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:32:44 -0000 [Solved] The problem, is a driver of the port "nvidia-driver", i used the test port (said me Ivan) =D0=92 Tue, 17 Aug 2010 09:52:50 -0400 John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: - Show quoted text - Here the test port... nvidia-driver.256.44.port.tar.bz2 5K Download I upload the file in this URL http://rapidshare.com/files/413522883/nvidia-driver.256.44.port.tar.bz2 MD5: F4167FAFAFD76C8FE9AA067877F8DE1A Have got nvidia geforce 8200 Thanks all On 15 August 2010 02:35, =C3=81lvaro Castillo wrote: > Hello all > > I installed the FreeBSD/amd64 8.0 and updated to 9-CURRENT with csup > > Following... > # cp /usr/share/examples/cvsup/standard-supfile /root && cd /root && sed > -ie 's/CHANGE_THIS/cvsup.de/g' standard-supfile && sed -ie > 's/CHANGE_THIS/./g' standard-supfile && csup -g -L 2 /root/standard-supfi= le > > Downloaded files... > > # cd /usr/src && make buildworld > > All good, now, i compiled the kernel with my conf > > # cd /usr/src/sys/amd64/conf && mdkir /root/kernels && cp GENERIC > /root/kernels/SPACE && ee /root/kernels/SPACE && ln -s /root/kernels/SPAC= E > && cd /usr/src && make buildkernel KERNCONF=3DSPACE && make installkernel > KERNCONF=3DSPACE > > This is my kernel > > http://pastebin.com/1NpvzNp6 > > $ dmesg (cut) > > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 > cpuid =3D 0 > Uptime: 3m35s > > Dump failed. Partition too small. > Automatic reboot in 15 seconds - press a key on the console to abort > panic: bufwrite: buffer is not busy??? > cpuid =3D 0 > Uptime: 3m35s > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #0: Sat Aug 14 19:58:17 WEST 2010 > tty3@x0term.lan:/usr/obj/usr/src/sys/SPACE amd64 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3015.07-MHz K8-class > CPU) > Origin =3D "AuthenticAMD" Id =3D 0x40f33 Family =3D f Model =3D 43 Steppi= ng =3D 3 > > Features=3D0x178bfbff > Features2=3D0x2001 > AMD Features=3D0xea500800 > AMD Features2=3D0x1f > real memory =3D 4294967296 (4096 MB) > > > vgapci0: port 0xec00-0xec7f mem > 0xfd000000-0xfdffffff,0xf0000000-0xf7ffffff,0xfa000000-0xfbffffff irq 21 = at > device 0.0 on pci2 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_busmaster > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > nvidia0: [ITHREAD] > > > I compiled to nvidia-driver next to install kernel, and i charge to this, > here good, work, but i try $ startx with Driver "nvidia" on xorg.conf and > the pc is not responding, screen is black. > With nv and vesa work. > I dont understand this -> Dump failed. Partition too small. -> My root > partition has got a 435GB only ocupated 17GB and swap 512MB > > Can help me? This is a primary failed to nvidia-driver > From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 19:15:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E1771065697 for ; Tue, 17 Aug 2010 19:15:46 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0F08FC27 for ; Tue, 17 Aug 2010 19:15:46 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OlRdQ-00047J-45; Tue, 17 Aug 2010 21:15:44 +0200 Message-ID: <4C6ADFDC.60306@gwdg.de> Date: Tue, 17 Aug 2010 21:15:40 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.8) Gecko/20100806 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ivan Klymenko References: <201008170952.50766.jhb@freebsd.org> <20100817171140.21191ffd@ukr.net> <4C6AB739.3090708@gwdg.de> <20100817194732.450cbacf@ukr.net> In-Reply-To: <20100817194732.450cbacf@ukr.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: nvidia-driver not work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:15:46 -0000 On 17.08.2010 18:47 (UTC+1), Ivan Klymenko wrote: >>>>> $ dmesg (cut) >>>>> >>>>> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759 >>>>> cpuid = 0 >>>>> Uptime: 3m35s >>>> >>>> Use the latest nvidia driver from the website (256.44) and not from >>>> the port. >>>> >>> Here the test port... >> >> Sorry, I am afraid there is no attachment > > another attempt... Thanks for the test port. It works like a charm for me :-) This is on recent FreeBSD 9.0-CURRENT (amd64) with 4GB RAM and NVidia GeForce 9800GT. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 20:29:49 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D697F106564A for ; Tue, 17 Aug 2010 20:29:49 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 944578FC1B for ; Tue, 17 Aug 2010 20:29:49 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343] (unknown [IPv6:2001:7b8:3a7:0:2911:19d3:9b0d:9343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AE85C5C59; Tue, 17 Aug 2010 22:29:47 +0200 (CEST) Message-ID: <4C6AF13A.1080606@andric.com> Date: Tue, 17 Aug 2010 22:29:46 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Alan Cox References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:29:49 -0000 On 2010-08-17 18:29, Alan Cox wrote: > Try it again on a memory resident file with the MAP_PREFAULT_READ option > that is provided by this patch: > > http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch A time trial gives: grep with normal mmap() 1396s grep with prefault mmap() 1354s grep with regular read() 1354s So normal mmap is ~3% slower, and prefault mmap does not seem to make any measurable difference. I guess the added complexity is not really worth it, for now. From owner-freebsd-current@FreeBSD.ORG Tue Aug 17 21:24:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E53106566C for ; Tue, 17 Aug 2010 21:24:35 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9A98FC1A for ; Tue, 17 Aug 2010 21:24:34 +0000 (UTC) Received: by qyk4 with SMTP id 4so1555153qyk.13 for ; Tue, 17 Aug 2010 14:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=GCbG49OL08nbEcOAq31/zXJFhaHFJ5/rKhLbj1CF9R8=; b=Szgi0koB3m3m09DIgd0492HarMh880Y8yhQU0CDXapNSRfAnwBJ4/6e/KvLn7hw3IS w2WH++dJoxJUZyPr8QeXpoOnq5t4yNLZMawbVbUIRHOXm1FeQpAh6iHyqso7p1sZNKXS QMjUe3CM1tB+Q6n+pYB3eR+w0lfuHqjHQ5sZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=JGFIIC/AiOieBaoIrPWAOXE4iQmaLgWgEG0FmaoR8f4nlqZlDpN5eG9fS+VoaaKrgw XvloIg/+O4A2/be2/cVXBM+b+ovyfcm2iz32d27jwARxSkdnjyL/SGT4kjOWbPcUkBGE SYn9uWFvjQ71Do65GI02iXXM8Pxbrgb/CAmOg= MIME-Version: 1.0 Received: by 10.224.65.91 with SMTP id h27mr4773019qai.13.1282080274246; Tue, 17 Aug 2010 14:24:34 -0700 (PDT) Received: by 10.229.22.11 with HTTP; Tue, 17 Aug 2010 14:24:34 -0700 (PDT) In-Reply-To: <4C6AF13A.1080606@andric.com> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> Date: Tue, 17 Aug 2010 16:24:34 -0500 Message-ID: From: Alan Cox To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 21:24:35 -0000 On Tue, Aug 17, 2010 at 3:29 PM, Dimitry Andric wrote: > On 2010-08-17 18:29, Alan Cox wrote: > > Try it again on a memory resident file with the MAP_PREFAULT_READ option > > that is provided by this patch: > > > > http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch > > A time trial gives: > > grep with normal mmap() 1396s > grep with prefault mmap() 1354s > grep with regular read() 1354s > > So normal mmap is ~3% slower, and prefault mmap does not seem to make > any measurable difference. I guess the added complexity is not really > worth it, for now. > Do you know what fraction of this time is being spent in the kernel? Does the value of "sysctl vm.pmap.pde.mappings" increase as a result of your test? If not, there is still room for improvement in the results with mmap(). Alan From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 08:07:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D8F0106566B for ; Wed, 18 Aug 2010 08:07:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF8078FC12 for ; Wed, 18 Aug 2010 08:07:10 +0000 (UTC) Received: by qyk4 with SMTP id 4so331047qyk.13 for ; Wed, 18 Aug 2010 01:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=o3ZP7z1iizrjG1+Mo7B9C/LPZwkZHorSq7ZnOSr031I=; b=q/uwn0d6Ptpqn2lYY08rvdn44c5Dtw0tnkSwTHAEEWw7PuVNbZYC01VRTNUniBCAYn 2BYG/qcLqsU885MylGbDTGrtzVouT2IklOTBpLv1v0fRXS9n6v5ClmEa2aFxOmQpHVH/ NrHMqXk1jC7MchAYlJmt2gEg6gwxuyytUFoAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rTqWL59jB4ujV5mXnvP1uWayL75FyfdCBW5n+B3vhaT4+8dF6xIkGbc/x2Rs2paPKK KNtG0W4Ndx5XwWZpJE1KwZ0PBrZp5WXlswq6oG2SeD9J/YyHyHYjTEMePBGW0f4O5HUG iiARWjJl2J2FEhA7TKQDw47R8GHRTuJS8Fhlo= MIME-Version: 1.0 Received: by 10.224.62.217 with SMTP id y25mr5115898qah.193.1282118829177; Wed, 18 Aug 2010 01:07:09 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Wed, 18 Aug 2010 01:07:09 -0700 (PDT) In-Reply-To: <20100817160445.GO2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> Date: Wed, 18 Aug 2010 12:07:09 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:07:11 -0000 On 17 August 2010 20:04, Kostik Belousov wrote: > On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote: >> 2010/8/16 Kostik Belousov : >> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: >> >> On 16 August 2010 21:05, pluknet wrote: >> >> > Hi. >> >> > >> >> > Seeing on mostly idle, recently updated current, while closing a file. >> >> > Presumably never reported on ML. >> [...] >> >> >> > Both LORs are valid. The fork performed deep inside the VFS call stack >> > is obviously problematic. As a workaround, you may fix the number of >> > nfsiods. >> > >> > Proper fix might consist of creating a shepherd thread which only task >> > is to act on the requests on creating new nfsiods. >> > >> > Would you try to implement this ? I will provide the assistance, if needed. >> >> Hmm.. I tried to move kproc_create() under shepherd thread and now stuck >> with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b. >> Did I screw up something? >> See weird draft patch attached (weird, as I have no idea how to nicely >> exchange data between nfs_nfsiodnew() and shep_thread() thread). > Most likely, you loose the requests to create nfsiods since the > existing request in the global variable shep_chan can be overwritten > by new request. You should either sleep till existing request is serviced, > or form a queue. It turns out I passed pointer to pointer instead of pointer (sorry for my poor English). > > Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 08:26:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA5051065675; Wed, 18 Aug 2010 08:26:47 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 258CC8FC1A; Wed, 18 Aug 2010 08:26:46 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Oldyu-0003PL-2n; Wed, 18 Aug 2010 10:26:44 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oldys-0000Wx-RN; Wed, 18 Aug 2010 10:26:42 +0200 Message-Id: To: Rui Paulo From: Ian FREISLICH In-Reply-To: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> X-Attribution: BOFH Date: Wed, 18 Aug 2010 10:26:42 +0200 Cc: current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:26:48 -0000 Rui Paulo wrote: > On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: > > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting > > BB hangs are a problem with the 9280 but I don't know how to fix. > Hardware errors shouldn't happen, but this might mean you have > very aggressive power reduction settings (ACPI C3, etc.) that are > interfering with the atheros card. This has happened to me in the > past. Now, I've made 2 changes so I'm not sure which affected it: 1. I replaced the card with an AR9285 ath0@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)' class = network 2. I changed the channel on our AP. (there were 2 other nearby APs on the same channel). I noticed that I got a lot more bb hangs at the office compared to home - there are a lot more APs nearby: [mini] /usr/home/ianf $ ifconfig wlan0 scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS Ignition 00:26:bb:78:b4:91 6 54M -89:-96 100 EPS RSN HTCAP WPA WME Eco Impact 00:22:3f:55:80:bc 11 54M -92:-96 100 EP HTCAP WPS WPA WME Viic 00:14:6c:49:3f:1c 11 54M -92:-96 100 EPS WPA ATH WME cluelan 00:30:4f:58:bf:96 7 54M -72:-96 100 EPS WPA ATH WME PRIVATE LABEL 00:19:70:05:28:c4 3 54M -79:-96 100 EP WPA WME blinkbroom1 00:18:4d:1c:8e:3a 5 54M -89:-96 100 EPS WPA Sasman 00:26:f2:46:2c:de 1 54M -93:-96 100 EP WME cocoa 00:26:f2:3d:aa:13 3 54M -94:-96 200 EPS WME HTCAP ATH CareCross 30:46:9a:1e:b0:ca 8 54M -35:-96 100 EPS RSN WPA We're "cluelan" and we were on channel 3. Previously, I was seeing a hang every 10 minutes or so, since changing the channel to a "free" one, I haven't had a hang in the last 40 minutes. The only bb hang I've had was when I deactivated the RF switch on netbook and that was a semi-expected result. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 08:39:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E742C10656E8 for ; Wed, 18 Aug 2010 08:39:59 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id AC3498FC1D for ; Wed, 18 Aug 2010 08:39:59 +0000 (UTC) Received: from thor.mobile.rz (unknown [194.50.70.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id 4235FB03B9 for ; Wed, 18 Aug 2010 10:23:25 +0200 (CEST) Message-ID: <4C6B987F.5050703@kernel32.de> Date: Wed, 18 Aug 2010 10:23:27 +0200 From: Marian Hettwer User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: 8.1-release + zfs v15 df(1) hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:40:00 -0000 Hi All, i installed freebsd 8.1-release on my workstation (based on the 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. A df(1) doesn't return and is not killable and while taking a look around in my process table, I could find several find's hanging around too. mhettwer 5976 0.0 0.0 6896 1088 13 D+ 5:55PM 0:00.00 df -h mhettwer 5351 0.0 0.0 6896 1088 19 D+ 1:49PM 0:00.00 df -h root 215 0.0 0.0 5804 1232 ?? D Mon05AM 0:04.29 find -sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} + root 4139 0.0 0.0 5804 1324 ?? D Tue05AM 0:02.38 find -sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} + root 7305 0.0 0.0 5804 1324 ?? D 5:01AM 0:00.43 find -sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} + root 73775 0.0 0.0 5804 1232 ?? D Fri05AM 0:10.18 find -sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} + root 94589 0.0 0.0 5804 1232 ?? D Sat05AM 0:07.68 find -sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} + nobody 94746 0.0 0.0 5804 1072 ?? DN Sat06AM 0:07.38 find -s / ! ( -fstype zfs ) -prune -or -path /tmp -prune -or -path /usr/tmp -prune -or -path /var/tmp -prune -or -path /var/db/portsnap -prune -or -print root 97430 0.0 0.0 5804 1232 ?? D Sun05AM 0:06.02 find -sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or -perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} + I couldn't figure out where they're coming from, but since it seems there's a new one every night I suspect its coming from a periodic script. Any ideas how to get rid of those processes? And yes, I know that zfs V15 isn't in -STABLE for a reason... # uname -a # FreeBSD siteop38-1.mobile.rz 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Aug 3 12:03:02 UTC 2010 root@siteop38-1.mobile.rz:/usr/obj/usr/src/sys/GENERIC amd64 (I csup'ed to RELENG_8_1 and applied the v15 patch from http://mfsbsd.vx.sk/ and did a make world) best regards, Marian PS.: For the author of mfsbsd iso's: I like them. Cool! Thanks! :) From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 08:56:30 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4834106566B; Wed, 18 Aug 2010 08:56:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7503B8FC28; Wed, 18 Aug 2010 08:56:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7I8uTmL051002; Wed, 18 Aug 2010 04:56:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7I8uTSG051001; Wed, 18 Aug 2010 08:56:29 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Aug 2010 08:56:29 GMT Message-Id: <201008180856.o7I8uTSG051001@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 08:56:30 -0000 TB --- 2010-08-18 06:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 06:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-08-18 06:10:00 - cleaning the object tree TB --- 2010-08-18 06:10:38 - cvsupping the source tree TB --- 2010-08-18 06:10:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-08-18 06:16:37 - building world TB --- 2010-08-18 06:16:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 06:16:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 06:16:37 - TARGET=i386 TB --- 2010-08-18 06:16:37 - TARGET_ARCH=i386 TB --- 2010-08-18 06:16:37 - TZ=UTC TB --- 2010-08-18 06:16:37 - __MAKE_CONF=/dev/null TB --- 2010-08-18 06:16:37 - cd /src TB --- 2010-08-18 06:16:37 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 18 06:16:37 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 18 08:03:38 UTC 2010 TB --- 2010-08-18 08:03:38 - generating LINT kernel config TB --- 2010-08-18 08:03:38 - cd /src/sys/i386/conf TB --- 2010-08-18 08:03:38 - /usr/bin/make -B LINT TB --- 2010-08-18 08:03:38 - building LINT kernel TB --- 2010-08-18 08:03:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 08:03:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 08:03:38 - TARGET=i386 TB --- 2010-08-18 08:03:38 - TARGET_ARCH=i386 TB --- 2010-08-18 08:03:38 - TZ=UTC TB --- 2010-08-18 08:03:38 - __MAKE_CONF=/dev/null TB --- 2010-08-18 08:03:38 - cd /src TB --- 2010-08-18 08:03:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 18 08:03:38 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT completed on Wed Aug 18 08:30:39 UTC 2010 TB --- 2010-08-18 08:30:39 - building GENERIC kernel TB --- 2010-08-18 08:30:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 08:30:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 08:30:39 - TARGET=i386 TB --- 2010-08-18 08:30:39 - TARGET_ARCH=i386 TB --- 2010-08-18 08:30:39 - TZ=UTC TB --- 2010-08-18 08:30:39 - __MAKE_CONF=/dev/null TB --- 2010-08-18 08:30:39 - cd /src TB --- 2010-08-18 08:30:39 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Aug 18 08:30:39 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for GENERIC completed on Wed Aug 18 08:51:08 UTC 2010 TB --- 2010-08-18 08:51:08 - building PAE kernel TB --- 2010-08-18 08:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 08:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 08:51:08 - TARGET=i386 TB --- 2010-08-18 08:51:08 - TARGET_ARCH=i386 TB --- 2010-08-18 08:51:08 - TZ=UTC TB --- 2010-08-18 08:51:08 - __MAKE_CONF=/dev/null TB --- 2010-08-18 08:51:08 - cd /src TB --- 2010-08-18 08:51:08 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Wed Aug 18 08:51:08 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules -------------------------------------------------------------- cd /obj/i386.i386/src/sys/PAE; MAKEOBJDIRPREFIX=/obj/i386.i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/obj/i386.i386/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/i386.i386/src/tmp VERSION="FreeBSD 8.0-STABLE amd64 800504" INSTALL="sh /src/tools/install.sh" PATH=/obj/i386.i386/src/tmp/legacy/usr/sbin:/obj/i386.i386/src/tmp/legacy/usr/bin:/obj/i386.i386/src/tmp/legacy/usr/games:/obj/i386.i386/src/tmp/usr/sbin:/obj/i386.i386/src/tmp/usr/bin:/obj/i386.i386/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel modules-all -DNO_MODULES_OBJ make: don't know how to make modules-all. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-18 08:56:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-18 08:56:29 - ERROR: failed to build PAE kernel TB --- 2010-08-18 08:56:29 - 7339.23 user 1486.55 system 9989.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 09:10:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 853BE1065695; Wed, 18 Aug 2010 09:10:54 +0000 (UTC) (envelope-from daichi@freebsd.org) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 55C188FC23; Wed, 18 Aug 2010 09:10:54 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 12B6E12543B; Wed, 18 Aug 2010 17:52:34 +0900 (JST) Message-ID: <4C6B9F51.1060009@freebsd.org> Date: Wed, 18 Aug 2010 17:52:33 +0900 From: Daichi GOTO User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100724 Thunderbird/3.0.6 MIME-Version: 1.0 To: ed@80386.nl, freebsd-current@freebsd.org, freebsd-fs@freebsd.org, ozawa@ongs.co.jp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: unionfs a little improvement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 09:10:54 -0000 Hi Ed and unionfs fan gyus. Ed pointed out a contradict behavior between current unionfs implementation and its manual, and sent me a patch. Thanks Ed ;) ---- Index: sys/fs/unionfs/union_vfsops.c =================================================================== --- sys/fs/unionfs/union_vfsops.c (revision 211093) +++ sys/fs/unionfs/union_vfsops.c (working copy) @@ -89,7 +89,6 @@ u_short ufile; unionfs_copymode copymode; unionfs_whitemode whitemode; - struct componentname fakecn; struct nameidata nd, *ndp; struct vattr va; @@ -280,26 +279,6 @@ mp->mnt_flag |= ump->um_uppervp->v_mount->mnt_flag & MNT_RDONLY; /* - * Check whiteout - */ - if ((mp->mnt_flag & MNT_RDONLY) == 0) { - memset(&fakecn, 0, sizeof(fakecn)); - fakecn.cn_nameiop = LOOKUP; - fakecn.cn_thread = td; - error = VOP_WHITEOUT(ump->um_uppervp, &fakecn, LOOKUP); - if (error) { - if (below) { - VOP_UNLOCK(ump->um_uppervp, 0); - vrele(upperrootvp); - } else - vput(ump->um_uppervp); - free(ump, M_UNIONFSMNT); - mp->mnt_data = NULL; - return (error); - } - } - - /* * Unlock the node */ VOP_UNLOCK(ump->um_uppervp, 0); ---- Ed's message here: ---- Just for fun I was hacking on a writable bootcd, using unionfs and tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents unionfs from mounting tmpfs on top. I do want to be able to use tmpfs, even if it means we can't get any whiteouts. The manpage says the following: Without whiteout support from the file system backing the upper layer, there is no way that delete and rename operations on lower layer objects can be done. EROFS is returned for this kind of operations along with any others which would make modifications to the lower layer, such as chmod(1). This seems to contradict the current behaviour, which is to deny the mount altogether. The attached patch makes it work, but instead of EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT(). ---- It looks like reasonable and patch is simple and effective I guess. If you unionfs guys or fs guys have some ideas around this patch, please teach me. After some tests and a couple of weeks after, I'll commit ed's patch if there is no objections. -- Daichi GOTO 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 09:14:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0369810656A6 for ; Wed, 18 Aug 2010 09:14:13 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id BF1718FC0C for ; Wed, 18 Aug 2010 09:14:12 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 0410711B85D; Wed, 18 Aug 2010 04:14:12 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id 60AXBBGQHITG; Wed, 18 Aug 2010 04:14:12 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Wed, 18 Aug 2010 10:14:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> To: Ian FREISLICH X-Mailer: Apple Mail (2.1081) Cc: current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 09:14:13 -0000 On 18 Aug 2010, at 09:26, Ian FREISLICH wrote: > Rui Paulo wrote: >> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: >>> Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), = resetting >>> Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), = resetting >>> Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), = resetting >>> Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), = resetting >>=20 >> BB hangs are a problem with the 9280 but I don't know how to fix. >> Hardware errors shouldn't happen, but this might mean you have >> very aggressive power reduction settings (ACPI C3, etc.) that are >> interfering with the atheros card. This has happened to me in the >> past. >=20 > Now, I've made 2 changes so I'm not sure which affected it: >=20 > 1. I replaced the card with an AR9285 >=20 > ath0@pci0:1:0:0: class=3D0x028000 card=3D0x7167144f chip=3D0x002b168c = rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller = (AR928x)' > class =3D network >=20 > 2. I changed the channel on our AP. (there were 2 other nearby APs > on the same channel). >=20 > I noticed that I got a lot more bb hangs at the office compared to > home - there are a lot more APs nearby: >=20 > [mini] /usr/home/ianf $ ifconfig wlan0 scan > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > Ignition 00:26:bb:78:b4:91 6 54M -89:-96 100 EPS RSN = HTCAP WPA WME > Eco Impact 00:22:3f:55:80:bc 11 54M -92:-96 100 EP HTCAP = WPS WPA WME > Viic 00:14:6c:49:3f:1c 11 54M -92:-96 100 EPS WPA ATH = WME > cluelan 00:30:4f:58:bf:96 7 54M -72:-96 100 EPS WPA ATH = WME > PRIVATE LABEL 00:19:70:05:28:c4 3 54M -79:-96 100 EP WPA WME > blinkbroom1 00:18:4d:1c:8e:3a 5 54M -89:-96 100 EPS WPA > Sasman 00:26:f2:46:2c:de 1 54M -93:-96 100 EP WME > cocoa 00:26:f2:3d:aa:13 3 54M -94:-96 200 EPS WME = HTCAP ATH > CareCross 30:46:9a:1e:b0:ca 8 54M -35:-96 100 EPS RSN WPA >=20 > We're "cluelan" and we were on channel 3. Previously, I was seeing > a hang every 10 minutes or so, since changing the channel to a > "free" one, I haven't had a hang in the last 40 minutes. The only > bb hang I've had was when I deactivated the RF switch on netbook > and that was a semi-expected result. Yes, the hangs are dependent on the signal and noise conditions. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 09:15:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DCB1065698 for ; Wed, 18 Aug 2010 09:15:55 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CDDEF8FC13 for ; Wed, 18 Aug 2010 09:15:54 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D5A481FFC34; Wed, 18 Aug 2010 09:15:52 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B1FD38454E; Wed, 18 Aug 2010 11:15:51 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dimitry Andric References: <4C6A7357.8000606@andric.com> <20100817091515.4510ebfd@kan.dnsalias.net> <4C6A9AE7.3060704@andric.com> Date: Wed, 18 Aug 2010 11:15:51 +0200 In-Reply-To: <4C6A9AE7.3060704@andric.com> (Dimitry Andric's message of "Tue, 17 Aug 2010 16:21:27 +0200") Message-ID: <86aaokb7so.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 09:15:55 -0000 Dimitry Andric writes: > Alexander Kabaev writes: > > Does method 1) work fine with 'make buildenv'? I doubt that. I would > > strongly suggest we should not lose this feature. I do not like the > > idea of having to depend on -isystem in CFLAGS in such an environment.= =20 > I have not tested make buildenv with this method, but since ${CC} is > modified, not ${CFLAGS}, there is a reasonable chance that it might > work. :) I'm not a big fan of "reasonable chances" when it comes to the toolchain. > Note a similar method is already being using for the build32 stage on > amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B) > appended. No, what is used is a variant of method 1 *on top of* method 2 for a very specific case. You need "a special version of clang" (method 2) anyway to support cross-building. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 10:20:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0B01065679; Wed, 18 Aug 2010 10:20:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB5BC8FC15; Wed, 18 Aug 2010 10:20:11 +0000 (UTC) Received: by eyh6 with SMTP id 6so190292eyh.13 for ; Wed, 18 Aug 2010 03:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aLZRCIfKAemlZbf7Z0y+yeBozXI3FfLLEBw36yzljIg=; b=idGFV6UCl74Mh5uJAiXOgS96vPbXT4Gsx0bbXW9kz8uin6egzMgl2pJp6RdMn+fgyu m2W6QNV/XrvhLBv0GQP/UaZwzCOI+zmMXFMEFnYY658jd10RbN2StHQiZJUtcpvWozbw jNuNXEAlaUyLiIdjQLzOyQTyZW9OtdWLhNgaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DRaWDonSxvxRI5h5WFOJkbdXmEDVfYP0lb1bgKB72uGTYXfU2tNz04u7UkmM+1pEyJ vJlmnTRBxupXqEesWNbv1lUIq4S9kW0QffqMLp4k/56m6s55w4xB/9V7M7jrYW6uS/gT DN5deRLxq2RB/IjkK03rc6mbq4iIQXNDf6vEI= MIME-Version: 1.0 Received: by 10.213.21.201 with SMTP id k9mr1927550ebb.64.1282126809919; Wed, 18 Aug 2010 03:20:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.213.108.205 with HTTP; Wed, 18 Aug 2010 03:20:09 -0700 (PDT) In-Reply-To: References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> Date: Wed, 18 Aug 2010 18:20:09 +0800 X-Google-Sender-Auth: eRuJcf1yjFuQ-ZJWNDaNBNYXO9c Message-ID: From: Adrian Chadd To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rui Paulo , current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 10:20:12 -0000 Can you please change one at a time and see which affected it? Thanks, Adrian On 18 August 2010 16:26, Ian FREISLICH wrote: > Rui Paulo wrote: >> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: >> > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting >> > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting >> > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting >> > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting >> >> BB hangs are a problem with the 9280 but I don't know how to fix. >> Hardware errors shouldn't happen, but this might mean you have >> very aggressive power reduction settings (ACPI C3, etc.) that are >> interfering with the atheros card. This has happened to me in the >> past. > > Now, I've made 2 changes so I'm not sure which affected it: > > 1. I replaced the card with an AR9285 > > ath0@pci0:1:0:0: class=3D0x028000 card=3D0x7167144f chip=3D0x002b168c rev= =3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0=3D 'Atheros Communications Inc.' > =A0 =A0device =A0=3D 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controll= er (AR928x)' > =A0 =A0class =A0 =3D network > > 2. I changed the channel on our AP. (there were 2 other nearby APs > =A0 on the same channel). > > I noticed that I got a lot more bb hangs at the office compared to > home - there are a lot more APs nearby: > > [mini] /usr/home/ianf $ ifconfig wlan0 scan > SSID/MESH ID =A0 =A0BSSID =A0 =A0 =A0 =A0 =A0 =A0 =A0CHAN RATE =A0 S:N = =A0 =A0 INT CAPS > Ignition =A0 =A0 =A0 =A000:26:bb:78:b4:91 =A0 =A06 =A0 54M -89:-96 =A0100= EPS =A0RSN HTCAP WPA WME > Eco Impact =A0 =A0 =A000:22:3f:55:80:bc =A0 11 =A0 54M -92:-96 =A0100 EP = =A0 HTCAP WPS WPA WME > Viic =A0 =A0 =A0 =A0 =A0 =A000:14:6c:49:3f:1c =A0 11 =A0 54M -92:-96 =A01= 00 EPS =A0WPA ATH WME > cluelan =A0 =A0 =A0 =A0 00:30:4f:58:bf:96 =A0 =A07 =A0 54M -72:-96 =A0100= EPS =A0WPA ATH WME > PRIVATE LABEL =A0 00:19:70:05:28:c4 =A0 =A03 =A0 54M -79:-96 =A0100 EP = =A0 WPA WME > blinkbroom1 =A0 =A0 00:18:4d:1c:8e:3a =A0 =A05 =A0 54M -89:-96 =A0100 EPS= =A0WPA > Sasman =A0 =A0 =A0 =A0 =A000:26:f2:46:2c:de =A0 =A01 =A0 54M -93:-96 =A01= 00 EP =A0 WME > cocoa =A0 =A0 =A0 =A0 =A0 00:26:f2:3d:aa:13 =A0 =A03 =A0 54M -94:-96 =A02= 00 EPS =A0WME HTCAP ATH > CareCross =A0 =A0 =A0 30:46:9a:1e:b0:ca =A0 =A08 =A0 54M -35:-96 =A0100 E= PS =A0RSN WPA > > We're "cluelan" and we were on channel 3. =A0Previously, I was seeing > a hang every 10 minutes or so, since changing the channel to a > "free" one, I haven't had a hang in the last 40 minutes. =A0The only > bb hang I've had was when I deactivated the RF switch on netbook > and that was a semi-expected result. > > Ian > > -- > Ian Freislich > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 10:38:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21AAF1065672; Wed, 18 Aug 2010 10:38:13 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id B100F8FC13; Wed, 18 Aug 2010 10:38:12 +0000 (UTC) Received: from [196.7.162.28] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Olg26-0005Cy-Dj; Wed, 18 Aug 2010 12:38:10 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Olg24-0000pY-QN; Wed, 18 Aug 2010 12:38:08 +0200 Message-Id: To: Adrian Chadd From: Ian FREISLICH In-reply-to: References: <0D4EA23D-605F-4F15-B07E-6019055EA6F5@FreeBSD.org> X-Attribution: BOFH Date: Wed, 18 Aug 2010 12:38:08 +0200 Cc: Rui Paulo , current@freebsd.org Subject: Re: AR9280 "bb hang" and other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 10:38:13 -0000 Adrian Chadd wrote: > Can you please change one at a time and see which affected it? Looking at my logs: startup: Aug 18 09:41:40 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09 Aug 18 09:41:41 mini kernel: wlan0: link state changed to UP ?: Aug 18 09:45:25 mini kernel: ath0: bb hang detected (0x80), resetting RF switch off: Aug 18 09:49:50 mini kernel: ath0: bb hang detected (0x80), resetting Aug 18 09:50:13 mini kernel: wlan0: link state changed to DOWN RF switch on: Aug 18 09:50:13 mini kernel: wlan0: link state changed to UP AP changed channels Aug 18 09:54:40 mini kernel: ath0: bb hang detected (0x80), resetting wlan0 destroy: Aug 18 09:56:31 mini kernel: wlan0: link state changed to DOWN Aug 18 09:56:31 mini dhclient[1300]: Interface wlan0 no longer appears valid. wlan0 create: Aug 18 09:56:33 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09 Aug 18 09:56:36 mini kernel: wlan0: link state changed to UP It really looks likes like it's signal related, not card related because this card still got a signal related bb hang before the channel change, but not after. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 10:43:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CA1D1065674; Wed, 18 Aug 2010 10:43:20 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id BE6288FC1B; Wed, 18 Aug 2010 10:43:19 +0000 (UTC) Received: by qyk11 with SMTP id 11so1873380qyk.13 for ; Wed, 18 Aug 2010 03:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=v5bJvJytD07WX2ZukXwKaUOzSfm3rVPIle2wC9vhVAM=; b=uSViCiIb5VMNihVNJm3W6qG5iPcYPpfXfjxAuogJx/aNVz77xZsQbju7RtUE/wZm4c FYob5PDTssd6Lf9CXxx0HT2TbRyzwE08LMPAm/SWiGWaXzdJAW5O3p4GCek+Q34zChHO +32ay7WqpBgsq1EYjmmyG6rF0iRR/WleAJfm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rBwS0YdOecYkIEjf9oLHZZFpVCkarGsmLnQzaEr8Jaxs6KdCLf4p27m1qkxgMFUlPA QNnhCN+0AdpKfB1fxwXIKP7ltPG2A7gjppsvcWu0RrXHe/o+MwahSwB0p8uu4TPlKj75 edX1odSDNrTxVYjBTXeBrO9tCF/jy70x3ftls= MIME-Version: 1.0 Received: by 10.224.28.129 with SMTP id m1mr5312863qac.113.1282128199075; Wed, 18 Aug 2010 03:43:19 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Wed, 18 Aug 2010 03:43:19 -0700 (PDT) In-Reply-To: References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> Date: Wed, 18 Aug 2010 14:43:19 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: multipart/mixed; boundary=0015175cb21edccb15048e16bb7b Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 10:43:20 -0000 --0015175cb21edccb15048e16bb7b Content-Type: text/plain; charset=ISO-8859-1 On 18 August 2010 12:07, pluknet wrote: > On 17 August 2010 20:04, Kostik Belousov wrote: > >> >> Also please take a note of the John' suggestion to use the taskqueue. > > I decided to go this road. Thank you both. > Now I do nfs buildkernel survive and prepare some benchmark results. > So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. -- wbr, pluknet --0015175cb21edccb15048e16bb7b Content-Type: application/octet-stream; name="nfsiod_tq.diff" Content-Disposition: attachment; filename="nfsiod_tq.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gd01toqi0 SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX3Zub3BzLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25mc2Ns aWVudC9uZnNfdm5vcHMuYwkocmV2aXNpb24gMjExMjc5KQorKysgc3lzL25mc2NsaWVudC9uZnNf dm5vcHMuYwkod29ya2luZyBjb3B5KQpAQCAtNjIsNiArNjIsNyBAQAogI2luY2x1ZGUgPHN5cy9z dGF0Lmg+CiAjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgogI2luY2x1ZGUgPHN5cy9zaWduYWx2YXIu aD4KKyNpbmNsdWRlIDxzeXMvdGFza3F1ZXVlLmg+CiAKICNpbmNsdWRlIDx2bS92bS5oPgogI2lu Y2x1ZGUgPHZtL3ZtX29iamVjdC5oPgpAQCAtMjEyLDYgKzIxMyw3IEBACiAgKiBHbG9iYWwgdmFy aWFibGVzCiAgKi8KIHN0cnVjdCBtdHggCW5mc19pb2RfbXR4Oworc3RydWN0IHRhc2sJbmZzX25m c2lvZG5ld190YXNrOwogZW51bSBuZnNpb2Rfc3RhdGUgbmZzX2lvZHdhbnRbTkZTX01BWEFTWU5D REFFTU9OXTsKIHN0cnVjdCBuZnNtb3VudCAqbmZzX2lvZG1vdW50W05GU19NQVhBU1lOQ0RBRU1P Tl07CiBpbnQJCSBuZnNfbnVtYXN5bmMgPSAwOwpJbmRleDogc3lzL25mc2NsaWVudC9uZnNfc3Vi cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHN5cy9uZnNjbGllbnQvbmZzX3N1YnMuYwkocmV2aXNpb24gMjEx Mjc5KQorKysgc3lzL25mc2NsaWVudC9uZnNfc3Vicy5jCSh3b3JraW5nIGNvcHkpCkBAIC01OSw2 ICs1OSw3IEBACiAjaW5jbHVkZSA8c3lzL3N5c2VudC5oPgogI2luY2x1ZGUgPHN5cy9zeXNjYWxs Lmg+CiAjaW5jbHVkZSA8c3lzL3N5c3Byb3RvLmg+CisjaW5jbHVkZSA8c3lzL3Rhc2txdWV1ZS5o PgogCiAjaW5jbHVkZSA8dm0vdm0uaD4KICNpbmNsdWRlIDx2bS92bV9vYmplY3QuaD4KQEAgLTM1 NCw2ICszNTUsNyBAQAogCSAqLwogCW10eF9pbml0KCZuZnNfaW9kX210eCwgIk5GUyBpb2QgbG9j ayIsIE5VTEwsIE1UWF9ERUYpOwogCW10eF9pbml0KCZuZnNfeGlkX210eCwgIk5GUyB4aWQgbG9j ayIsIE5VTEwsIE1UWF9ERUYpOworCVRBU0tfSU5JVCgmbmZzX25mc2lvZG5ld190YXNrLCAwLCBu ZnNfbmZzaW9kbmV3X3RxLCBOVUxMKTsKIAogCW5mc19wYnVmX2ZyZWVjbnQgPSBuc3didWYgLyAy ICsgMTsKIApJbmRleDogc3lzL25mc2NsaWVudC9uZnNfbmZzaW9kLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c3lzL25mc2NsaWVudC9uZnNfbmZzaW9kLmMJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5cy9uZnNj bGllbnQvbmZzX25mc2lvZC5jCSh3b3JraW5nIGNvcHkpCkBAIC01OSw2ICs1OSw3IEBACiAjaW5j bHVkZSA8c3lzL2ZjbnRsLmg+CiAjaW5jbHVkZSA8c3lzL2xvY2tmLmg+CiAjaW5jbHVkZSA8c3lz L211dGV4Lmg+CisjaW5jbHVkZSA8c3lzL3Rhc2txdWV1ZS5oPgogCiAjaW5jbHVkZSA8bmV0aW5l dC9pbi5oPgogI2luY2x1ZGUgPG5ldGluZXQvdGNwLmg+CkBAIC03NSw2ICs3NiwxMiBAQAogCiBz dGF0aWMgdm9pZAluZnNzdmNfaW9kKHZvaWQgKik7CiAKK3N0cnVjdCBzaGVwaGVyZF9zdHIgewor CWludCAqc2hlcF9pbnN0OworCWludCBzaGVwX25pb2Q7CisJaW50IHNoZXBfZXJyb3I7Cit9IHNo ZXBfY2hhbjsKKwogc3RhdGljIGludCBuZnNfYXN5bmNkYWVtb25bTkZTX01BWEFTWU5DREFFTU9O XTsKIAogU1lTQ1RMX0RFQ0woX3Zmc19uZnMpOwpAQCAtMTU5LDEwICsxNjYsMTkgQEAKICAgICBz aXplb2YgKG5mc19pb2RtYXgpLCBzeXNjdGxfaW9kbWF4LCAiSVUiLAogICAgICJNYXggbnVtYmVy IG9mIG5mc2lvZCBrdGhyZWFkcyIpOwogCit2b2lkCituZnNfbmZzaW9kbmV3X3RxKF9fdW51c2Vk IHZvaWQgKmFyZywgaW50IHBlbmRpbmcpCit7CisKKwlzaGVwX2NoYW4uc2hlcF9lcnJvciA9IGtw cm9jX2NyZWF0ZShuZnNzdmNfaW9kLAorCSAgICBzaGVwX2NoYW4uc2hlcF9pbnN0LCBOVUxMLCBS RkhJR0hQSUQsIDAsICJuZnNpb2QgJWQiLAorCSAgICBzaGVwX2NoYW4uc2hlcF9uaW9kKTsKK30K KwogaW50CiBuZnNfbmZzaW9kbmV3KGludCBzZXRfaW9kd2FudCkKIHsKLQlpbnQgZXJyb3IsIGk7 CisJaW50IGk7CiAJaW50IG5ld2lvZDsKIAogCWlmIChuZnNfbnVtYXN5bmMgPj0gbmZzX2lvZG1h eCkKQEAgLTE3OCwxMSArMTk0LDEzIEBACiAJCXJldHVybiAoLTEpOwogCWlmIChzZXRfaW9kd2Fu dCA+IDApCiAJCW5mc19pb2R3YW50W2ldID0gTkZTSU9EX0NSRUFURURfRk9SX05GU19BU1lOQ0lP OworCWJ6ZXJvKCZzaGVwX2NoYW4sIHNpemVvZihzaGVwX2NoYW4pKTsKKwlzaGVwX2NoYW4uc2hl cF9pbnN0ID0gbmZzX2FzeW5jZGFlbW9uICsgaTsKKwlzaGVwX2NoYW4uc2hlcF9uaW9kID0gbmV3 aW9kOwogCW10eF91bmxvY2soJm5mc19pb2RfbXR4KTsKLQllcnJvciA9IGtwcm9jX2NyZWF0ZShu ZnNzdmNfaW9kLCBuZnNfYXN5bmNkYWVtb24gKyBpLCBOVUxMLCBSRkhJR0hQSUQsCi0JICAgIDAs ICJuZnNpb2QgJWQiLCBuZXdpb2QpOworCXRhc2txdWV1ZV9lbnF1ZXVlKHRhc2txdWV1ZV90aHJl YWQsICZuZnNfbmZzaW9kbmV3X3Rhc2spOwogCW10eF9sb2NrKCZuZnNfaW9kX210eCk7Ci0JaWYg KGVycm9yKSB7CisJaWYgKHNoZXBfY2hhbi5zaGVwX2Vycm9yKSB7CiAJCWlmIChzZXRfaW9kd2Fu dCA+IDApCiAJCQluZnNfaW9kd2FudFtpXSA9IE5GU0lPRF9OT1RfQVZBSUxBQkxFOwogCQlyZXR1 cm4gKC0xKTsKSW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzLmgKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25m c2NsaWVudC9uZnMuaAkocmV2aXNpb24gMjExMjc5KQorKysgc3lzL25mc2NsaWVudC9uZnMuaAko d29ya2luZyBjb3B5KQpAQCAtMTI1LDYgKzEyNSw3IEBACiAKIGV4dGVybiBzdHJ1Y3QgbmZzc3Rh dHMgbmZzc3RhdHM7CiBleHRlcm4gc3RydWN0IG10eCBuZnNfaW9kX210eDsKK2V4dGVybiBzdHJ1 Y3QgdGFzayBuZnNfbmZzaW9kbmV3X3Rhc2s7CiAKIGV4dGVybiBpbnQgbmZzX251bWFzeW5jOwog ZXh0ZXJuIHVuc2lnbmVkIGludCBuZnNfaW9kbWF4OwpAQCAtMjUzLDYgKzI1NCw3IEBACiAJICAg IHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3RydWN0IHRocmVhZCAqdGQpOwogaW50CW5mc19yZWFkZGly cnBjKHN0cnVjdCB2bm9kZSAqLCBzdHJ1Y3QgdWlvICosIHN0cnVjdCB1Y3JlZCAqKTsKIGludAlu ZnNfbmZzaW9kbmV3KGludCk7Cit2b2lkCW5mc19uZnNpb2RuZXdfdHEoX191bnVzZWQgdm9pZCAq LCBpbnQpOwogaW50CW5mc19hc3luY2lvKHN0cnVjdCBuZnNtb3VudCAqLCBzdHJ1Y3QgYnVmICos IHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3QgdGhyZWFkICopOwogaW50CW5mc19kb2lvKHN0cnVjdCB2 bm9kZSAqLCBzdHJ1Y3QgYnVmICosIHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3QgdGhyZWFkICopOwog dm9pZAluZnNfZG9pb19kaXJlY3R3cml0ZSAoc3RydWN0IGJ1ZiAqKTsK --0015175cb21edccb15048e16bb7b-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 10:48:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48C991065670; Wed, 18 Aug 2010 10:48:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id DA8F08FC13; Wed, 18 Aug 2010 10:48:53 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 0EA682A28CDB; Wed, 18 Aug 2010 12:48:53 +0200 (CEST) Date: Wed, 18 Aug 2010 12:48:53 +0200 From: Ed Schouten To: Daichi GOTO Message-ID: <20100818104853.GB2978@hoeg.nl> References: <4C6B9F51.1060009@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZQ93ZA/51YEIDw4/" Content-Disposition: inline In-Reply-To: <4C6B9F51.1060009@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, ozawa@ongs.co.jp Subject: Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 10:48:54 -0000 --ZQ93ZA/51YEIDw4/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Daichi, I think Keith Packard of Xorg once wrote a commit message along the lines of "5000 lines of code removed, feature added" This seems to be similar, albeit on a smaller scale. ;-) Apart from this issue with unionfs, I am also experiencing another issue, where for some reason I cannot perform a second mount of the CD right after booting the system. Basically, my WIP FreeBSD boot CD does the following (but written in C): mount -t cd9660 /dev/iso9660/freebsd /mnt mount -t tmpfs none /tmp mount -t unionfs /tmp /mnt mount -t devfs none /mnt/dev chroot /mnt /sbin/init The first step fails with EBUSY. I use the following hack to get it working, but I don't think it's the proper way to solve it: %%% Index: sys/geom/geom_vfs.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 --- sys/geom/geom_vfs.c (revision 211093) +++ sys/geom/geom_vfs.c (working copy) @@ -162,8 +162,10 @@ =20 *cpp =3D NULL; bo =3D &vp->v_bufobj; +#if 0 if (bo->bo_private !=3D vp) return (EBUSY); +#endif =20 pp =3D g_dev_getprovider(vp->v_rdev); if (pp =3D=3D NULL) %%% I am really not that familiar with GEOM/VFS to understand the impact of this change. What does it actually mean if bo->bo_private !=3D vp? --=20 Ed Schouten WWW: http://80386.nl/ --ZQ93ZA/51YEIDw4/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxrupUACgkQ52SDGA2eCwVOWgCfRlwSVs8Fs3iGD2ekr/cwQmMB Y18An1UvOsrA+Xsys2nbvClJh8SoayaR =nCoj -----END PGP SIGNATURE----- --ZQ93ZA/51YEIDw4/-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 05:42:15 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAC01065672; Wed, 18 Aug 2010 05:42:15 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa04b.plala.or.jp (msa04.plala.or.jp [58.93.240.4]) by mx1.freebsd.org (Postfix) with ESMTP id ED3EE8FC12; Wed, 18 Aug 2010 05:42:14 +0000 (UTC) Received: from i125-202-12-13.s02.a026.ap.plala.or.jp ([125.202.12.13]) by msa04b.plala.or.jp with ESMTP id <20100818054213.GZOH6113.msa04b.plala.or.jp@i125-202-12-13.s02.a026.ap.plala.or.jp>; Wed, 18 Aug 2010 14:42:13 +0900 Date: Wed, 18 Aug 2010 14:42:12 +0900 Message-ID: <86ocd0a34b.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: gabor@FreeBSD.org, current@FreeBSD.org In-Reply-To: <86eiefhalp.wl%poyopoyo@puripuri.plala.or.jp> References: <86eiefhalp.wl%poyopoyo@puripuri.plala.or.jp> Mail-Followup-To: poyopoyo@puripuri.plala.or.jp, gabor@FreeBSD.org, current@FreeBSD.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-VirusScan: Outbound; msa04b; Wed, 18 Aug 2010 14:42:13 +0900 X-Mailman-Approved-At: Wed, 18 Aug 2010 11:13:35 +0000 Cc: Subject: Re: bsdgrep does not work with tail -f | grep combination X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 05:42:15 -0000 Hi Gabor and others, As Gabor committed r211364, bsdgrep now works nicely with tail -f. http://svn.freebsd.org/changeset/base/211364 Thank you very much. -- kuro From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 11:23:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 777A010656DE; Wed, 18 Aug 2010 11:23:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 28BA88FC13; Wed, 18 Aug 2010 11:23:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7IBN6xb059473; Wed, 18 Aug 2010 07:23:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7IBN68p059472; Wed, 18 Aug 2010 11:23:06 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Aug 2010 11:23:06 GMT Message-Id: <201008181123.o7IBN68p059472@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 11:23:07 -0000 TB --- 2010-08-18 09:47:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 09:47:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-08-18 09:47:11 - cleaning the object tree TB --- 2010-08-18 09:47:41 - cvsupping the source tree TB --- 2010-08-18 09:47:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-08-18 09:50:08 - building world TB --- 2010-08-18 09:50:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 09:50:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 09:50:08 - TARGET=sun4v TB --- 2010-08-18 09:50:08 - TARGET_ARCH=sparc64 TB --- 2010-08-18 09:50:08 - TZ=UTC TB --- 2010-08-18 09:50:08 - __MAKE_CONF=/dev/null TB --- 2010-08-18 09:50:08 - cd /src TB --- 2010-08-18 09:50:08 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 18 09:50:09 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 18 10:55:36 UTC 2010 TB --- 2010-08-18 10:55:36 - generating LINT kernel config TB --- 2010-08-18 10:55:36 - cd /src/sys/sun4v/conf TB --- 2010-08-18 10:55:36 - /usr/bin/make -B LINT TB --- 2010-08-18 10:55:36 - building LINT kernel TB --- 2010-08-18 10:55:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 10:55:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 10:55:36 - TARGET=sun4v TB --- 2010-08-18 10:55:36 - TARGET_ARCH=sparc64 TB --- 2010-08-18 10:55:36 - TZ=UTC TB --- 2010-08-18 10:55:36 - __MAKE_CONF=/dev/null TB --- 2010-08-18 10:55:36 - cd /src TB --- 2010-08-18 10:55:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 18 10:55:37 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT completed on Wed Aug 18 11:19:24 UTC 2010 TB --- 2010-08-18 11:19:24 - building GENERIC kernel TB --- 2010-08-18 11:19:24 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 11:19:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 11:19:24 - TARGET=sun4v TB --- 2010-08-18 11:19:24 - TARGET_ARCH=sparc64 TB --- 2010-08-18 11:19:24 - TZ=UTC TB --- 2010-08-18 11:19:24 - __MAKE_CONF=/dev/null TB --- 2010-08-18 11:19:24 - cd /src TB --- 2010-08-18 11:19:24 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Aug 18 11:19:24 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules -------------------------------------------------------------- cd /obj/sun4v.sparc64/src/sys/GENERIC; MAKEOBJDIRPREFIX=/obj/sun4v.sparc64 MACHINE_ARCH=sparc64 MACHINE=sun4v CPUTYPE= GROFF_BIN_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/sun4v.sparc64/src/tmp VERSION="FreeBSD 8.0-STABLE amd64 800504" INSTALL="sh /src/tools/install.sh" PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/sbin:/obj/sun4v.sparc64/src/tmp/legacy/usr/bin:/obj/sun4v.sparc64/src/tmp/legacy/usr/games:/obj/sun4v.sparc64/src/tmp/usr/sbin:/obj/sun4v.sparc64/src/tmp/usr/bin:/obj/sun4v.sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel modules-all -DNO_MODULES_OBJ make: don't know how to make modules-all. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-18 11:23:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-18 11:23:06 - ERROR: failed to build GENERIC kernel TB --- 2010-08-18 11:23:06 - 4043.42 user 965.02 system 5754.09 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 07:41:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 525461065679 for ; Wed, 18 Aug 2010 07:41:47 +0000 (UTC) (envelope-from gordon.tetlow@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 192438FC12 for ; Wed, 18 Aug 2010 07:41:46 +0000 (UTC) Received: by iwn36 with SMTP id 36so410543iwn.13 for ; Wed, 18 Aug 2010 00:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=XmMqi4nslWGSyAOTb4udhFzCehxxUSTEibe1YwCzFi0=; b=bgpj6BXt1kus8AXA6Dq0u9tSYPO+Ts1dUF6smMk1nXbKdZfPGw1HvTW1TqlciAz4Hx X2WuZcOhjZvm0IunXYksubdY4qe2z4vSSEd+EfErw1IwO325+PylJ0j2EaFqfrsHANN2 pDTfzqz/dses8dLX/NrEXEgoDT19rKxWSiVCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=fxnH42gQni+ILM/asMIRge0bcatYW1lMWDpJBM1lSnYldHeNOYu1ppHx6i395ihAgv pgNFu+85GkA9IrjeqeDvLAmTWHerXohvg6t3ekNyl7MTknDpPGyxiyE0zh5rLvByo5xE hlkQQP3nTC41iou8U4iEMTRfeekjuPjWSx4a0= MIME-Version: 1.0 Received: by 10.231.177.25 with SMTP id bg25mr8214288ibb.154.1282115480515; Wed, 18 Aug 2010 00:11:20 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.172.147 with HTTP; Wed, 18 Aug 2010 00:11:20 -0700 (PDT) Date: Wed, 18 Aug 2010 00:11:20 -0700 X-Google-Sender-Auth: Ny-VgSwSPIJ9eCB3z7oOHWNrJh8 Message-ID: From: Gordon Tetlow To: freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 18 Aug 2010 11:25:17 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:41:47 -0000 All, I sat down and rewrote the man tools from a relatively old codebase to a single shell script. My original motivation was to allow multiple configuration files so port installations did not have to mess with /etc/manpath.config (like perl for example) when needing to manipulate the manpath. After looking at the existing code, I figured I could rewrite it as a shell script relatively easily. Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, /usr/bin/whatis) http://people.freebsd.org/~gordon/man.sh Features of the new code: 1. BSD licensed (old code is GPL). 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf (purposefully changed the manpath.config file since it is a different syntax). 3. Allows ports to override the toolset used to display the manpage based on language. This was done to try to merge the functionality of the japanese/man port into the base system as much as possible. I've tried to make this mirror the functionality, directory search order, and arguments as the current base implementation. This brings me to my next point. I need some testers willing to try this out. It would be particularly great if I could get some foreign language testers with localized manpage installations. If something doesn't work the way you expect, please contact me and I can help debug it (using man -ddd will generally give me the debug information I need). Thanks, Gordon From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 11:31:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F5B210656A7; Wed, 18 Aug 2010 11:31:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 219EF8FC27; Wed, 18 Aug 2010 11:31:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7IBVHlq065337; Wed, 18 Aug 2010 07:31:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7IBVH0o065336; Wed, 18 Aug 2010 11:31:17 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 18 Aug 2010 11:31:17 GMT Message-Id: <201008181131.o7IBVH0o065336@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 11:31:18 -0000 TB --- 2010-08-18 09:18:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 09:18:34 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-18 09:18:34 - mkdir /tinderbox/HEAD/powerpc64 TB --- 2010-08-18 09:18:34 - mkdir /tinderbox/HEAD/powerpc64/powerpc TB --- 2010-08-18 09:18:34 - cleaning the object tree TB --- 2010-08-18 09:18:34 - cvsupping the source tree TB --- 2010-08-18 09:18:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-18 09:38:05 - building world TB --- 2010-08-18 09:38:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 09:38:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 09:38:05 - TARGET=powerpc TB --- 2010-08-18 09:38:05 - TARGET_ARCH=powerpc64 TB --- 2010-08-18 09:38:05 - TZ=UTC TB --- 2010-08-18 09:38:05 - __MAKE_CONF=/dev/null TB --- 2010-08-18 09:38:05 - cd /src TB --- 2010-08-18 09:38:05 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 18 09:38:06 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Aug 18 11:18:07 UTC 2010 TB --- 2010-08-18 11:18:07 - generating LINT kernel config TB --- 2010-08-18 11:18:07 - cd /src/sys/powerpc/conf TB --- 2010-08-18 11:18:07 - /usr/bin/make -B LINT TB --- 2010-08-18 11:18:07 - building LINT kernel TB --- 2010-08-18 11:18:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 11:18:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 11:18:07 - TARGET=powerpc TB --- 2010-08-18 11:18:07 - TARGET_ARCH=powerpc64 TB --- 2010-08-18 11:18:07 - TZ=UTC TB --- 2010-08-18 11:18:07 - __MAKE_CONF=/dev/null TB --- 2010-08-18 11:18:07 - cd /src TB --- 2010-08-18 11:18:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Aug 18 11:18:07 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-18 11:31:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-18 11:31:17 - ERROR: failed to build lint kernel TB --- 2010-08-18 11:31:17 - 4864.50 user 1282.72 system 7963.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 12:54:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03EC10656AB for ; Wed, 18 Aug 2010 12:54:51 +0000 (UTC) (envelope-from prvs=08467614c3=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 46D098FC22 for ; Wed, 18 Aug 2010 12:54:51 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OliAK-000EhM-A7 for freebsd-current@freebsd.org; Wed, 18 Aug 2010 14:54:48 +0200 Date: Wed, 18 Aug 2010 14:54:48 +0200 From: Oliver Brandmueller To: freebsd-current@freebsd.org Message-ID: <20100818125447.GR44426@e-Gitt.NET> Mail-Followup-To: freebsd-current@freebsd.org References: <4C6ABD04.3030506@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jCrbxBqMcLqd4mOl" Content-Disposition: inline In-Reply-To: <4C6ABD04.3030506@delphij.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 12:54:51 -0000 --jCrbxBqMcLqd4mOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 17, 2010 at 09:47:00AM -0700, Xin LI wrote: > It's not "gone" since Oracle can not withdraw code that is already > licensed under CDDL. They _may_ choose not to release anything new but > we already have a newer zfs version that have basic functionality usable > in p4. So all we need to direct some of the money we already spend for=20 supporting developers and certain developments to core ZFS developers no=20 longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS=20 development platform for the future. If you have the key developers, the=20 community will follow. Before someone starts argueing... I know, it's not that easy and I don't=20 have a clue how one would do that. This is most probably more like a=20 crazy idea than a plan that could actually work :-/ - Oliver --=20 | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | --jCrbxBqMcLqd4mOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxr2BcACgkQiqtMdzjafym/lACeNMTw8K1dm+YgAS0tcMv0U7Jq +nMAoMH+6FaqD8rVOi/mkJorVnjA5WKT =fMMP -----END PGP SIGNATURE----- --jCrbxBqMcLqd4mOl-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 13:09:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AB8A1065674 for ; Wed, 18 Aug 2010 13:09:21 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3BB8FC15 for ; Wed, 18 Aug 2010 13:09:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911] (unknown [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9C17B5C59; Wed, 18 Aug 2010 15:09:20 +0200 (CEST) Message-ID: <4C6BDB80.9000004@andric.com> Date: Wed, 18 Aug 2010 15:09:20 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6A7357.8000606@andric.com> <20100817091515.4510ebfd@kan.dnsalias.net> <4C6A9AE7.3060704@andric.com> <86aaokb7so.fsf@ds4.des.no> In-Reply-To: <86aaokb7so.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:09:21 -0000 On 2010-08-18 11:15, Dag-Erling Sm=C3=B8rgrav wrote: > I'm not a big fan of "reasonable chances" when it comes to the > toolchain. Me neither, which is why I created method 2 originally. :) The -isysroot method was invented by Roman Divacky in r198248. > No, what is used is a variant of method 1 *on top of* method 2 for a > very specific case. You need "a special version of clang" (method 2) > anyway to support cross-building. Eventually, clang should support building objects for all targets from one executable, but not in the short term, unfortunately... From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 13:13:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32AD11065696 for ; Wed, 18 Aug 2010 13:13:47 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E9D298FC0C for ; Wed, 18 Aug 2010 13:13:46 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 49DFD1FFC33; Wed, 18 Aug 2010 13:13:45 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E557F8454E; Wed, 18 Aug 2010 15:13:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dimitry Andric References: <4C6A7357.8000606@andric.com> <20100817091515.4510ebfd@kan.dnsalias.net> <4C6A9AE7.3060704@andric.com> <86aaokb7so.fsf@ds4.des.no> <4C6BDB80.9000004@andric.com> Date: Wed, 18 Aug 2010 15:13:44 +0200 In-Reply-To: <4C6BDB80.9000004@andric.com> (Dimitry Andric's message of "Wed, 18 Aug 2010 15:09:20 +0200") Message-ID: <86k4no9i7r.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Building world with clang X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:13:47 -0000 Dimitry Andric writes: > Dag-Erling Sm=C3=B8rgrav writes: > > No, what is used is a variant of method 1 *on top of* method 2 for a > > very specific case. You need "a special version of clang" (method 2) > > anyway to support cross-building. > Eventually, clang should support building objects for all targets from > one executable, but not in the short term, unfortunately... That doesn't matter. You still need two versions of the compiler. If you're cross-building sprac64 on an i386 machine, for instance, you need an i386 version of the compiler that produces sparc64 binaries *and* a sparc64 version that produces sparc64 binaries. The former is used only during the build, the latter is what will be installed on the target. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 13:43:36 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4C131065694 for ; Wed, 18 Aug 2010 13:43:36 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9182B8FC0A for ; Wed, 18 Aug 2010 13:43:36 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id B4FE314DC6DB; Wed, 18 Aug 2010 15:43:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6JTth5VC85g8; Wed, 18 Aug 2010 15:43:31 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 3B3C614DC6DA; Wed, 18 Aug 2010 15:43:31 +0200 (CEST) Message-ID: <4C6BE380.1080603@FreeBSD.org> Date: Wed, 18 Aug 2010 15:43:28 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: poyopoyo@puripuri.plala.or.jp, current@FreeBSD.org References: <86eiefhalp.wl%poyopoyo@puripuri.plala.or.jp> <86ocd0a34b.wl%poyopoyo@puripuri.plala.or.jp> In-Reply-To: <86ocd0a34b.wl%poyopoyo@puripuri.plala.or.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: bsdgrep does not work with tail -f | grep combination X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:43:36 -0000 Em 2010.08.18. 7:42, poyopoyo@puripuri.plala.or.jp escreveu: > Hi Gabor and others, > > As Gabor committed r211364, bsdgrep now works nicely with tail -f. > > http://svn.freebsd.org/changeset/base/211364 > > Thank you very much. Acknowledgements also go to you and other users. Without quality feedback I may not have found myself all reported bugs. Gabor From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 13:43:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B08E61065730 for ; Wed, 18 Aug 2010 13:43:44 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id E8DDF8FC1F for ; Wed, 18 Aug 2010 13:43:43 +0000 (UTC) Received: from nschwotgx03p.mx.bigpond.com ([124.188.161.100]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20100818134341.EHNW26010.nschwmtas06p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Wed, 18 Aug 2010 13:43:41 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20100818134341.YFOI16083.nschwotgx03p.mx.bigpond.com@johnny.reilly.home>; Wed, 18 Aug 2010 13:43:41 +0000 Date: Wed, 18 Aug 2010 23:43:41 +1000 From: Andrew Reilly To: Doug Barton Message-ID: <20100818134341.GA88861@johnny.reilly.home> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 18 Aug 2010 13:43:41 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090202.4C6BE38D.023D,ss=1,fgs=0 X-SIH-MSG-ID: oxk1F9P4TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRsMuxxD9EJhuGNGUjaajlTY3Rs9mK Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:43:44 -0000 On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: > got any other suggestions? This is very much a "sorry I asked" question, but is none-the less quite a good one, given the size of the hole to be plugged. I think that a reasonable answer for this sort of thing might be one of the dynamic languages that compiles to C, like (perhaps) one of the schemes (chicken, gambit-C, bigloo, etc). You get the benefit of flexibility and dynamism with good regexp and data structure ability, good performance, and only requiring the build tools available in the base system, as long as you don't want to be the developer: just ship the C code (as well as the source, of course). Unfortunately it seems that quite a lot of people have issues with lisp syntax these days. There are some other compile-to-C languages that might work too. [Aside: I think that the answer to this question might get a *lot* more interesting once we have llvm in the base system (it comes along with clang). There are (and I'm sure will be more) languages that compile down to llvm byte-code without the contortions required in going through C.] Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 13:46:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B84E1065672; Wed, 18 Aug 2010 13:46:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 02C258FC19; Wed, 18 Aug 2010 13:46:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7IDkN50035699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2010 16:46:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7IDkNYo015205; Wed, 18 Aug 2010 16:46:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7IDkNKs015204; Wed, 18 Aug 2010 16:46:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Aug 2010 16:46:23 +0300 From: Kostik Belousov To: pluknet Message-ID: <20100818134623.GU2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hD4TXpRh/LvuDKsa" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:46:28 -0000 --hD4TXpRh/LvuDKsa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: > On 18 August 2010 12:07, pluknet wrote: > > On 17 August 2010 20:04, Kostik Belousov wrote: > > > >> > >> Also please take a note of the John' suggestion to use the taskqueue. > > > > I decided to go this road. Thank you both. > > Now I do nfs buildkernel survive and prepare some benchmark results. > > >=20 > So, I modified the patch to defer proc_create() with taskqueue(9). > Below is `time make -j5 buildkernel WITHOUT_MODULES=3Dyes` perf. evaluati= on. > Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both > nfs-mounted over 1Gbit LAN. >=20 > clean old > 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w >=20 > clean new > 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w >=20 > Patch needs polishing, though it generally works. > Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. --hD4TXpRh/LvuDKsa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxr5C8ACgkQC3+MBN1Mb4gUFQCeMGYn5XUfyfY2Bm5SUjJHqSQ5 HBoAoOWMETGNQTdDG0fsNdowHsG1/YXG =CXex -----END PGP SIGNATURE----- --hD4TXpRh/LvuDKsa-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 14:38:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C97F11065696; Wed, 18 Aug 2010 14:38:03 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC2D8FC08; Wed, 18 Aug 2010 14:38:03 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 898BA73098; Wed, 18 Aug 2010 16:28:52 +0200 (CEST) Date: Wed, 18 Aug 2010 16:28:52 +0200 From: Luigi Rizzo To: Andrew Reilly Message-ID: <20100818142852.GA80221@onelab2.iet.unipi.it> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100818134341.GA88861@johnny.reilly.home> User-Agent: Mutt/1.4.2.3i Cc: Doug Barton , Ivan Voras , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 14:38:03 -0000 On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote: > On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: > > got any other suggestions? > > This is very much a "sorry I asked" question, but is none-the > less quite a good one, given the size of the hole to be plugged. > > I think that a reasonable answer for this sort of thing might be > one of the dynamic languages that compiles to C, like (perhaps) > one of the schemes (chicken, gambit-C, bigloo, etc). You get > the benefit of flexibility and dynamism with good regexp and > data structure ability, good performance, and only requiring the > build tools available in the base system, as long as you don't > want to be the developer: just ship the C code (as well as the > source, of course). slightly off topic but I disagree on the latter part. The whole point of having source code is to be able to make modifications, small or large, private or ones to be contributed back. As a teacher, i am very concerned about the ease-of-use for non-developer types: it is important to make it easy for people to experiments, as this is one of the ways people learn things. Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' tool is almost as bad as having no source (in fact, it is like the joke of supplying source for the GPL'd software in your brand new LCD tv or appliance. I'd like to know who will ever be able to build an updated image and upload it to the appliance) cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 15:18:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DE0D1065672 for ; Wed, 18 Aug 2010 15:18:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B77128FC15 for ; Wed, 18 Aug 2010 15:18:17 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA20372; Wed, 18 Aug 2010 18:18:13 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6BF9B0.9070900@icyb.net.ua> Date: Wed, 18 Aug 2010 18:18:08 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Marian Hettwer References: <4C6B987F.5050703@kernel32.de> In-Reply-To: <4C6B987F.5050703@kernel32.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.1-release + zfs v15 df(1) hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:18:18 -0000 on 18/08/2010 11:23 Marian Hettwer said the following: > Hi All, > > i installed freebsd 8.1-release on my workstation (based on the > 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. > > A df(1) doesn't return and is not killable and while taking a look > around in my process table, I could find several find's hanging around too. > > mhettwer 5976 0.0 0.0 6896 1088 13 D+ 5:55PM 0:00.00 df -h > mhettwer 5351 0.0 0.0 6896 1088 19 D+ 1:49PM 0:00.00 df -h Can you run procstat -k to see where exactly the processes are stuck? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 15:20:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFE9D106566B; Wed, 18 Aug 2010 15:20:14 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC138FC13; Wed, 18 Aug 2010 15:20:14 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id BFC432A28CDB; Wed, 18 Aug 2010 17:20:13 +0200 (CEST) Date: Wed, 18 Aug 2010 17:20:13 +0200 From: Ed Schouten To: Pawel Jakub Dawidek Message-ID: <20100818152013.GF2978@hoeg.nl> References: <4C6B9F51.1060009@freebsd.org> <20100818104853.GB2978@hoeg.nl> <20100818121550.GD2177@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zBZpvCNcoXwafAjP" Content-Disposition: inline In-Reply-To: <20100818121550.GD2177@garage.freebsd.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Daichi GOTO , freebsd-current@freebsd.org Subject: Re: Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:20:15 -0000 --zBZpvCNcoXwafAjP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Pawel Jakub Dawidek wrote: > What you are trying to do here is to mount /dev/iso9660/freebsd for the > second time? This is not supported. The check is there to prevent doing > this, as it will panic on you when you try to unmount first mount (not > really a problem in your case, as the first mount is /, so you probably > don't want to unmount it, but it is a problem in general). >=20 > You should be able to reproduce the panic with your patch applied by > doing the following: >=20 > # mount -t cd9660 /dev/iso9660/freebsd /mnt0 > # mount -t cd9660 /dev/iso9660/freebsd /mnt1 > # umount /mnt0 Ah, I see. Well, I changed my setup to use an md root now. Works quite nicely. Screenshot: http://80386.nl/pub/livecd.png Thanks for the explanation! --=20 Ed Schouten WWW: http://80386.nl/ --zBZpvCNcoXwafAjP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxr+i0ACgkQ52SDGA2eCwWKvwCcCnXjomyWP3sqeYnzMe5M8zHH 3SIAnRxazLWYyzLb6uSgYsDNFyR1OS4Q =6ev4 -----END PGP SIGNATURE----- --zBZpvCNcoXwafAjP-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 15:27:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF78106564A; Wed, 18 Aug 2010 15:27:51 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAD88FC23; Wed, 18 Aug 2010 15:27:51 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id o7IFReO0064574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 00:27:45 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 19 Aug 2010 00:27:40 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@freebsd.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.1-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 19 Aug 2010 00:27:45 +0900 (JST) X-Virus-Scanned: clamav-milter 0.96.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: current@freebsd.org Subject: CFR: importing openresolv X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:27:51 -0000 Hi, I wish to import openresolv 3.3.5 into our base tree. It makes merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ... into /etc/resolv.conf easier. http://roy.marples.name/projects/openresolv My patch against 9-CURRENT can be obtained from: http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 15:30:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2987106564A for ; Wed, 18 Aug 2010 15:30:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD4A8FC0C for ; Wed, 18 Aug 2010 15:30:30 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA20587; Wed, 18 Aug 2010 18:30:28 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6BFC93.4040303@icyb.net.ua> Date: Wed, 18 Aug 2010 18:30:27 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Alexey Tarasov References: <434A73A4-E2F4-4FC6-A7E4-8A4D514AF6D5@lexasoft.ru> In-Reply-To: <434A73A4-E2F4-4FC6-A7E4-8A4D514AF6D5@lexasoft.ru> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: STABLE kernel panic: privileged instruction fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:30:31 -0000 on 13/08/2010 00:45 Alexey Tarasov said the following: > Fatal trap 1: privileged instruction fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xffffff8040d2cc83 > stack pointer = 0x28:0xffffff8040d2ca80 > frame pointer = 0x28:0xffffff0060c0b740 I suspect that either stack is corrupted or non-code is executed (or both). Stack pointer seems to be too close to instruction pointer and too far from frame pointer. Can you try to use kgdb and disassemble code (or examine data) near instruction pointer address and also near frame pointer address? Also, you might want to rebuild kgdb with a recent change from head, so that it better maps symbols and addresses in kernel modules. > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 9388 (nginx) > trap number = 1 > panic: privileged instruction fault > cpuid = 1 > Uptime: 17d15h48m49s > Physical memory: 2032 MB > Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 > > > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff80590c59 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff8059108c in panic (fmt=0xffffffff80951fc4 "%s") > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff80878fd8 in trap_fatal (frame=0xffffff0060c0b740, eva=Variable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:857 > #4 0xffffffff808799ea in trap (frame=0xffffff8040d2c9d0) > at /usr/src/sys/amd64/amd64/trap.c:644 > #5 0xffffffff8085f983 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #6 0xffffff8040d2cc83 in ?? () > #7 0xffffff8040d2cb50 in ?? () > #8 0xffffff8040d2caf0 in ?? () > #9 0xffffff8040d2cbf0 in ?? () > #10 0xffffff0060c0b740 in ?? () > #11 0xffffffff80b83c60 in sysent () > #12 0xffffff8040d2cc80 in ?? () > #13 0xffffff8040d2cae0 in ?? () > #14 0xffffffff8059c431 in bintime (bt=0xffffffff80ad3140) > at /usr/src/sys/kern/kern_tc.c:200 > Previous frame inner to this frame (corrupt stack?) > (kgdb) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 16:17:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D84431065670 for ; Wed, 18 Aug 2010 16:17:10 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8C29A8FC18 for ; Wed, 18 Aug 2010 16:17:10 +0000 (UTC) Received: by vws7 with SMTP id 7so831830vws.13 for ; Wed, 18 Aug 2010 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=dMTgsL6s4qYQtGOQvC9TXsIWxm/kQDutzRpAXiQxmbk=; b=XbIGT67fo90YUxab9dnj+KwO1kdEr26PhQELkQwEwbU8RJiqDrTN4l6wm5l7dythpI JWW6ojH9pVEtPchLW2+rZp0JEJSlnNL66M/YjaAb+1B7tCUYW5vdQTRMgQi0PbgRMfbG sB/tO+K2p7Ei1e3rla1EIqJGCoWO5O/OBeXvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=G7pQQ350u1JfC04VuoE3iOXVp8Oq8cW+uAszkpYF3pjESNELtDsD1OjhHnM9mLkOsf XmvASPiET1VQHp526Hw2dCqe5CJDhSZN6ZCwi3EkUGrZst0rJP+s4DQxTnD/FTZ9kZc3 XUvMHbA1wPZumLuynCe8x3261sPe9zcI/5jJI= MIME-Version: 1.0 Received: by 10.220.59.202 with SMTP id m10mr5075059vch.188.1282146709118; Wed, 18 Aug 2010 08:51:49 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.220.49.70 with HTTP; Wed, 18 Aug 2010 08:51:48 -0700 (PDT) In-Reply-To: <20100818125447.GR44426@e-Gitt.NET> References: <4C6ABD04.3030506@delphij.net> <20100818125447.GR44426@e-Gitt.NET> Date: Wed, 18 Aug 2010 08:51:48 -0700 X-Google-Sender-Auth: dqUNH1kBqYqAH8czN0lMTptXieo Message-ID: From: Artem Belevich To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: ZFS will gone,FreeBSD will import btrfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:17:10 -0000 > So all we need to direct some of the money we already spend for > supporting developers and certain developments to core ZFS developers no > longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS > development platform for the future. If you have the key developers, the > community will follow. > I'd argue that we'll need pjd@ more than ever. I don't think that ex-OpenSolaris contributors are going to jump to FreeBSD. There's project Illumos which is essentially an OpenSolaris fork minus binary-only bits. My guess is that it's got a decent chance to become a viable OpenSolaris replacement. Interestingly enough, Illumos plans to import FreeBSD drivers (and some utils) to replace closed-source ones that used to come from Solaris. --Artem On Wed, Aug 18, 2010 at 5:54 AM, Oliver Brandmueller wrote: > Hi, > > On Tue, Aug 17, 2010 at 09:47:00AM -0700, Xin LI wrote: >> It's not "gone" since Oracle can not withdraw code that is already >> licensed under CDDL. =A0They _may_ choose not to release anything new bu= t >> we already have a newer zfs version that have basic functionality usable >> in p4. > > So all we need to direct some of the money we already spend for > supporting developers and certain developments to core ZFS developers no > longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS > development platform for the future. If you have the key developers, the > community will follow. > > Before someone starts argueing... I know, it's not that easy and I don't > have a clue how one would do that. This is most probably more like a > crazy idea than a plan that could actually work :-/ > > - Oliver > > -- > | Oliver Brandmueller =A0 =A0 =A0 =A0 =A0http://sysadm.in/ =A0 =A0 =A0 = =A0 ob@sysadm.in | > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ich bin das Internet. So= wahr ich Gott helfe. | > From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 16:25:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0D13B10656A6; Wed, 18 Aug 2010 16:25:24 +0000 (UTC) Date: Wed, 18 Aug 2010 16:25:24 +0000 From: Alexander Best To: Gordon Tetlow Message-ID: <20100818162523.GA14196@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:25:24 -0000 On Wed Aug 18 10, Gordon Tetlow wrote: > All, > > I sat down and rewrote the man tools from a relatively old codebase to a > single shell script. My original motivation was to allow multiple > configuration files so port installations did not have to mess with > /etc/manpath.config (like perl for example) when needing to manipulate the > manpath. After looking at the existing code, I figured I could rewrite it as > a shell script relatively easily. > > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, > /usr/bin/whatis) > http://people.freebsd.org/~gordon/man.sh wow! that's great. thanks a lot. :) could you have a look at gnu/4419? although your script seems to fix this issue partially, when *.[0-9] and *[0-9].gz manuals exist it will choose the uncompressed file and complain with "not in gzip format". it would be nice if your script would prefer compressed over uncompressed manuals. however i'm not sure if a different approach might be better. people with more in depth knowledge might want to comment on this. cheers. alex > > Features of the new code: > > 1. BSD licensed (old code is GPL). > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > (purposefully changed the manpath.config file since it is a different > syntax). > 3. Allows ports to override the toolset used to display the manpage based on > language. This was done to try to merge the functionality of the > japanese/man port into the base system as much as possible. > > I've tried to make this mirror the functionality, directory search order, > and arguments as the current base implementation. > > This brings me to my next point. I need some testers willing to try this > out. It would be particularly great if I could get some foreign language > testers with localized manpage installations. If something doesn't work the > way you expect, please contact me and I can help debug it (using man -ddd > will generally give me the debug information I need). > > Thanks, > Gordon -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 16:55:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E6C31065672 for ; Wed, 18 Aug 2010 16:55:08 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB278FC26 for ; Wed, 18 Aug 2010 16:55:07 +0000 (UTC) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7IF3lQ8020325 for ; Thu, 19 Aug 2010 01:03:47 +1000 Received: from camelot.theinternet.com.au (d110-32-232-206.bla800.nsw.optusnet.com.au [110.32.232.206]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7IF3gtT018025; Thu, 19 Aug 2010 01:03:43 +1000 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id 589BF17044; Thu, 19 Aug 2010 01:03:42 +1000 (EST) Date: Thu, 19 Aug 2010 01:03:42 +1000 From: Andrew Milton To: Luigi Rizzo Message-ID: <20100818150342.GA402@camelot.theinternet.com.au> Mail-Followup-To: Andrew Milton , Luigi Rizzo , freebsd-current@freebsd.org References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100818142852.GA80221@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100818142852.GA80221@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:55:08 -0000 +-------[ Luigi Rizzo ]---------------------- | On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote: | > On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: | > > got any other suggestions? | > | > This is very much a "sorry I asked" question, but is none-the | > less quite a good one, given the size of the hole to be plugged. | > | > I think that a reasonable answer for this sort of thing might be | > one of the dynamic languages that compiles to C, like (perhaps) | > one of the schemes (chicken, gambit-C, bigloo, etc). You get | > the benefit of flexibility and dynamism with good regexp and | > data structure ability, good performance, and only requiring the | > build tools available in the base system, as long as you don't | > want to be the developer: just ship the C code (as well as the | > source, of course). | | slightly off topic but I disagree on the latter part. | | The whole point of having source code is to be able to make | modifications, small or large, private or ones to be contributed | back. As a teacher, i am very concerned about the ease-of-use for | non-developer types: it is important to make it easy for people to | experiments, as this is one of the ways people learn things. I have to agree with Luigi. You have to work out your target audience, and that should be your first constraint to choosing the language. If the language has a syntax structure that's going to be hard to parse by non-developers at first glance (like forth or perl), then you're really limiting the userbase. C is scriptable and embeddable these days from a variety of projects, but, I wouldn't recommend that either necessarily (since C doesn't have dynamic typing), even if we could get 100% architecture coverage. -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 16:48:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC7F710656A6; Wed, 18 Aug 2010 16:48:22 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4308FC0A; Wed, 18 Aug 2010 16:48:21 +0000 (UTC) Received: by wwb24 with SMTP id 24so944957wwb.31 for ; Wed, 18 Aug 2010 09:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:content-type :x-mailer:message-id:date:to:content-transfer-encoding:mime-version; bh=zqpyBbi/ndL6q/YbP51DVZNpolF79fknmdqMO+thyn8=; b=dY1m9xwyqCVKYRXsqhEj4a0xbsUDPUSx1b19SSxQJpjwaghFxpAR9jFqofb8GGLeIa sERu8NRJulX4Nxv/qbBcLffAuhtabcNjQXVWONdcAKW/VI1Ybor83zCxBE5Iqx4O5ebU m+eetC5I1BGXytgLizUCM7P3zXgqPqujECjIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; b=i2m3Sh98cjnb7sC4lFUpnN/PiaZSM60jml9QwEjbeC5qG3H666i5JxXKE5WFul087+ i+Loid8Lt/rmCWVF+nUuBqMYTsvnfWuwtNkwIVJw379o9kkDGHGBR5/AWFcMp2xsXN1W fcWZyoFhRwwUB4Hw6N73mu86124GTeXKifyhs= Received: by 10.227.72.213 with SMTP id n21mr7390335wbj.66.1282148701624; Wed, 18 Aug 2010 09:25:01 -0700 (PDT) Received: from [77.54.24.165] (165.24.54.77.rev.vodafone.pt [77.54.24.165]) by mx.google.com with ESMTPS id a28sm376374wbe.21.2010.08.18.09.24.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 09:25:00 -0700 (PDT) From: Rui Paulo Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (8A400) Message-Id: Date: Wed, 18 Aug 2010 17:23:50 +0100 To: "arch@freebsd.org" , "current@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 8A400) X-Mailman-Approved-At: Wed, 18 Aug 2010 17:11:09 +0000 Cc: Subject: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:48:22 -0000 Hi, I've been chatting with the ICC ex-users and they seem to be ok with the rem= oval of the ICC bits from share/mk and other places.=20 The reason is that it doesn't work and no one has volunteered to fix it for m= any years. This seems to indicate that the interest in ICC is low.=20 If there's anyone against this, speak now or forever be silent. :-) -- Rui Paulo= From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 17:37:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 222A41065675 for ; Wed, 18 Aug 2010 17:37:47 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id EB68B8FC08 for ; Wed, 18 Aug 2010 17:37:46 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id 7CCA411B80D; Wed, 18 Aug 2010 12:37:46 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id C095RT4RC0AQ; Wed, 18 Aug 2010 12:37:46 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Wed, 18 Aug 2010 18:37:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> References: To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:37:47 -0000 On 18 Aug 2010, at 18:18, Garrett Cooper wrote: > On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok with = the removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to fix = it for many years. This seems to indicate that the interest in ICC is = low. >> If there's anyone against this, speak now or forever be silent. :-) >=20 > Later versions of icc are more gcc compliant aren't they? If so, > wouldn't this also be a non-issue to remove the bits, or are there > still some incompatibilities between gcc and icc that are worth > noting? I really don't know how compatible is the latest icc because no one ever = updated the ports version. This is actually a hint that no one really = uses this anymore. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 17:45:49 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F0A51065697; Wed, 18 Aug 2010 17:45:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9758D8FC1C; Wed, 18 Aug 2010 17:45:48 +0000 (UTC) Received: by bwz20 with SMTP id 20so1048629bwz.13 for ; Wed, 18 Aug 2010 10:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=oco37uhWHPS15IL89HVZos8k6wqtaYFmygBhWJS2N7k=; b=GlxG8c7H2jvRmXofnIbSou7C6tGbbV3aVueiP2/HQuyridaUbcMnl8fpAwbdsZw6wP 7RAydiPUKkQ2Y7AlD0aX2IsfDdrgPQ4U8gSw/nlpgUbeNiJalIROMnnXOfE/fv4aPtt7 llBEGB55d+iPGUjUDBcyy6RmJE85gkuivMiZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=nrb6d42m9eNS6dlmmQzkVp07XGpeYCh0itsbqXXHu7IzXsabD7aw6a7PBKbwZ6BkoJ j+JHiiwiS18jFdN8AEaTrUo8GphaERlOXah3aud1VTPTd3fWTaYVj7joZ2SeCLb/91xz vPMD0xxIQBPR00p/tJPlMVWe22e/cNyCx0M/M= MIME-Version: 1.0 Received: by 10.204.47.193 with SMTP id o1mr5659420bkf.134.1282151924459; Wed, 18 Aug 2010 10:18:44 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Wed, 18 Aug 2010 10:18:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 10:18:44 -0700 X-Google-Sender-Auth: q2fieduYVMFfXkP8Y5AWbZ4Z1Oo Message-ID: From: Garrett Cooper To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:45:49 -0000 On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: > Hi, > I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. > The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. > If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 17:48:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD9501065672; Wed, 18 Aug 2010 17:48:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BFA48FC13; Wed, 18 Aug 2010 17:48:00 +0000 (UTC) Received: by bwz20 with SMTP id 20so1050967bwz.13 for ; Wed, 18 Aug 2010 10:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pEppfNykRnKcB2kHv5rC5lJi1XX/9WsatuFvcIAocJc=; b=lwWtREhJwLCSl4A+M8ZYuo7cOrZPuJB9TKrz53kfbaNpDbeGvId1SoN3BEaulHcETQ vrhGkZBgLndg6Dy9d2wf6zmC9Uxg7CZwN9uwwsfJldcPLhiNJO61hOLSKfho1gQRiitY JRLqeeRyYphaTiO08+xLxncAcy4Ssuh+InCF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=J6L/h3LeuaUKrDsPRwN6vPyzZWBOeGimr3/uVNeOdeG178MI9ou57VAIS1aAb751vO 4yk8EiLgOXg24/u3gRm4riLVkTdD+pbRhefGa5ngkKqTfS6ysvIOVIhzgnK9trhibm1h tIoBxb96T7UrujPZpIdmtbVpyssXYlNdLcIqc= MIME-Version: 1.0 Received: by 10.204.45.213 with SMTP id g21mr5732851bkf.11.1282151950585; Wed, 18 Aug 2010 10:19:10 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Wed, 18 Aug 2010 10:19:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 10:19:10 -0700 X-Google-Sender-Auth: X3OP727PaO3lu0RGBkp4GjTtJi4 Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rui Paulo , "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:48:01 -0000 On Wed, Aug 18, 2010 at 10:18 AM, Garrett Cooper wrot= e: > On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >> Hi, >> I've been chatting with the ICC ex-users and they seem to be ok with the= removal of the ICC bits from share/mk and other places. >> The reason is that it doesn't work and no one has volunteered to fix it = for many years. This seems to indicate that the interest in ICC is low. >> If there's anyone against this, speak now or forever be silent. :-) > > =A0 =A0Later versions of icc are more gcc compliant aren't they? If so, Sorry -- wrong term. s/compliant/compatible/ :). > wouldn't this also be a non-issue to remove the bits, or are there > still some incompatibilities between gcc and icc that are worth > noting? > Thanks, > -Garrett > From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 17:48:53 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04241106566C; Wed, 18 Aug 2010 17:48:53 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id B0FEF8FC20; Wed, 18 Aug 2010 17:48:52 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id E752114DC6E9; Wed, 18 Aug 2010 19:48:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TI7-q8h0iLwR; Wed, 18 Aug 2010 19:48:49 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 9B96A14DC6E8; Wed, 18 Aug 2010 19:48:49 +0200 (CEST) Message-ID: <4C6C1CFE.6060900@FreeBSD.org> Date: Wed, 18 Aug 2010 19:48:46 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Barton References: <4C6505A4.9060203@FreeBSD.org> In-Reply-To: <4C6505A4.9060203@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: core@FreeBSD.org, Dimitry Andric , delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:48:53 -0000 Em 2010.08.13. 10:43, Doug Barton escreveu: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Gabor, > > I hope at this point it goes without saying that I have a lot of respect > for the work you've done on BSD grep, and I've already told you that I > think you're very courageous for taking the project on. I've been > testing and evaluating it for some time now, and I think I've given it a > fair trial. You've done a fairly good job of responding to bug reports, > and I understand that the exposure BSD grep has received as the default > in HEAD has been very valuable in exposing additional areas that need > work. However, with all that in mind I am officially asking you to > please change the default in HEAD to GNU grep. (Note, I am _not_ asking > you to remove BSD grep from the tree, just to change the default.) > > My reason is simple, performance. [...] I've just committed a patch with the kind help of Dimitry Andric, which gives BSD grep a huge performance boost. The performance is now almost comparable to GNU grep. I think with this, BSD grep may remain default if no other serious issues come up. Please report if you notice something weird. I know about some minor issues, which aren't fixed yet. I'll be out for 4 days as of tomorrow but when I come back I'll take care of these: - Infinite loop when reading directory on ZFS/NFS filesystem - Problems with context grepping When reply, please remove core@ from CC, let's not bother them with this, I just wanted to let them know that I'm not neglecting this issue but if still demanded for a good reason, I'll switch back to default GNU grep. Gabor From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 17:56:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1099A10656A3 for ; Wed, 18 Aug 2010 17:56:12 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id B5FB68FC1B for ; Wed, 18 Aug 2010 17:56:11 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 3BAED14DC6E7; Wed, 18 Aug 2010 19:56:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VG2GuWdfnlHa; Wed, 18 Aug 2010 19:56:04 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 72FEC14DC315; Wed, 18 Aug 2010 19:56:04 +0200 (CEST) Message-ID: <4C6C1EB1.5000004@FreeBSD.org> Date: Wed, 18 Aug 2010 19:56:01 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rui Paulo References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> In-Reply-To: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , netchild@FreeBSD.org, "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:56:12 -0000 Em 2010.08.18. 19:37, Rui Paulo escreveu: > On 18 Aug 2010, at 18:18, Garrett Cooper wrote: > >> On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >>> Hi, >>> I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. >>> The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. >>> If there's anyone against this, speak now or forever be silent. :-) >> Later versions of icc are more gcc compliant aren't they? If so, >> wouldn't this also be a non-issue to remove the bits, or are there >> still some incompatibilities between gcc and icc that are worth >> noting? > I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. IIRC, apart from the low interest, the problem was that because of ICC's license using ICC to test this mk stuff requires a commercial license because somehow it is considered a derivative work. It has also prevented us from providing better support. In 2006, I wanted to do some progress as part of my SoC project because that time there was more interest. Alexander (CC'd) may comment on this. I think he has a license for FreeBSD work but he is not allowed to give it out to a third party. Gabor From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 17:56:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9159910656A7; Wed, 18 Aug 2010 17:56:45 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 523CB8FC1E; Wed, 18 Aug 2010 17:56:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911] (unknown [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A16895C59; Wed, 18 Aug 2010 19:56:44 +0200 (CEST) Message-ID: <4C6C1EDC.5000206@andric.com> Date: Wed, 18 Aug 2010 19:56:44 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Rui Paulo References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> In-Reply-To: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:56:45 -0000 On 2010-08-18 19:37, Rui Paulo wrote: > I really don't know how compatible is the latest icc because no one > ever updated the ports version. This is actually a hint that no one > really uses this anymore. I recently installed the port, which has icc 8.1, but it fails to compile even simple C++ programs, because it cannot cope with the libstdc++ headers from g++ 4.2.1. You have to do all kinds of tricks, such as installing the gcc 3.4.x port, and pointing the Intel compiler to its libstdc++ headers and libraries, or nothing will work. Updating that port to icc 11.1 is probably not a trivial task, and making sure it compiles programs properly is even trickier... :) From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 18:27:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B591A10656A4; Wed, 18 Aug 2010 18:27:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7851F8FC13; Wed, 18 Aug 2010 18:27:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7IIGYqj084323; Wed, 18 Aug 2010 12:16:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 18 Aug 2010 12:16:35 -0600 (MDT) Message-Id: <20100818.121635.431102609571763034.imp@bsdimp.com> To: gabor@freebsd.org From: "M. Warner Losh" In-Reply-To: <4C6C1CFE.6060900@FreeBSD.org> References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dimitry@andric.com, dougb@freebsd.org, delphij@freebsd.org, current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:27:17 -0000 In message: <4C6C1CFE.6060900@FreeBSD.org> Gabor Kovesdan writes: : When reply, please remove core@ from CC, let's not bother them with : this, I just wanted to let them know that I'm not neglecting this : issue but if still demanded for a good reason, I'll switch back to : default GNU grep. So making it default turned out well in the end. Sure, there was pain involved (but this is current), but making it default exposed the pain that would otherwise have gone unnoticed. The big hue and cry, while excessive at times, did result in people actually running the profiling tools which pointed to the buffering as the number one thing to fix. That being fixed now, it looks like we can go to the next stage: benchmarking again. Thanks, Gabor and everybody else that contributed, for seeing this through. Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 18:42:07 2010 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD4171065672; Wed, 18 Aug 2010 18:42:07 +0000 (UTC) (envelope-from wkb@xs4all.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD288FC0A; Wed, 18 Aug 2010 18:42:07 +0000 (UTC) Received: from [10.5.50.14] (94-30-33-45.xdsl.murphx.net [94.30.33.45] (may be forged)) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id o7IIQU5I099347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Aug 2010 20:26:30 +0200 (CEST) (envelope-from wkb@xs4all.nl) References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> In-Reply-To: <4C6C1CFE.6060900@FreeBSD.org> Mime-Version: 1.0 (iPhone Mail 8A400) Content-Type: text/plain; charset=us-ascii Message-Id: <9E0F3D7B-7D7A-4B09-9E7A-073EECD2DA9B@xs4all.nl> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8A400) From: Wilko Bulte Date: Wed, 18 Aug 2010 19:26:31 +0100 To: Gabor Kovesdan X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Wed, 18 Aug 2010 18:49:17 +0000 Cc: "core@FreeBSD.ORG" , Dimitry Andric , Doug Barton , "delphij@FreeBSD.ORG" , "current@FreeBSD.ORG" Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:42:07 -0000 Op 18 aug. 2010 om 18:48 heeft Gabor Kovesdan het volgen= de geschreven: > Em 2010.08.13. 10:43, Doug Barton escreveu: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >>=20 >> Gabor, >>=20 >> I hope at this point it goes without saying that I have a lot of respect >> for the work you've done on BSD grep, and I've already told you that I >> think you're very courageous for taking the project on. I've been >> testing and evaluating it for some time now, and I think I've given it a >> fair trial. You've done a fairly good job of responding to bug reports, >> and I understand that the exposure BSD grep has received as the default >> in HEAD has been very valuable in exposing additional areas that need >> work. However, with all that in mind I am officially asking you to >> please change the default in HEAD to GNU grep. (Note, I am _not_ asking >> you to remove BSD grep from the tree, just to change the default.) >>=20 >> My reason is simple, performance. [...] >=20 > I've just committed a patch with the kind help of Dimitry Andric, which gi= ves BSD grep a huge performance boost. The performance is now almost compara= ble to GNU grep. I think with this, BSD grep may remain default if no other s= erious issues come up. Please report if you notice something weird. >=20 > I know about some minor issues, which aren't fixed yet. I'll be out for 4 d= ays as of tomorrow but when I come back I'll take care of these: > - Infinite loop when reading directory on ZFS/NFS filesystem > - Problems with context grepping >=20 > When reply, please remove core@ from CC, let's not bother them with this, I= just wanted to let them know that I'm not neglecting this issue but if stil= l demanded for a good reason, No worries there Gabor! Wilko > I'll switch back to default GNU grep. >=20 > Gabor >=20 >=20 From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 19:07:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FEF910656C5 for ; Wed, 18 Aug 2010 19:07:41 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 12F328FC24 for ; Wed, 18 Aug 2010 19:07:40 +0000 (UTC) Received: from MotorBookMKII.local (91-64-52-77-dynip.superkabel.de [91.64.52.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id EB81DB03B9; Wed, 18 Aug 2010 21:07:38 +0200 (CEST) Message-ID: <4C6C2F7A.5060908@kernel32.de> Date: Wed, 18 Aug 2010 21:07:38 +0200 From: Marian Hettwer User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C6B987F.5050703@kernel32.de> <4C6BF9B0.9070900@icyb.net.ua> In-Reply-To: <4C6BF9B0.9070900@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.1-release + zfs v15 df(1) hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:07:41 -0000 Hej there, Am 18.08.10 17:18, schrieb Andriy Gapon: > on 18/08/2010 11:23 Marian Hettwer said the following: >> Hi All, >> >> i installed freebsd 8.1-release on my workstation (based on the >> 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. >> >> A df(1) doesn't return and is not killable and while taking a look >> around in my process table, I could find several find's hanging around too. >> >> mhettwer 5976 0.0 0.0 6896 1088 13 D+ 5:55PM 0:00.00 df -h >> mhettwer 5351 0.0 0.0 6896 1088 19 D+ 1:49PM 0:00.00 df -h > Can you run procstat -k to see where exactly the processes are stuck? > for some reason, the stuck df and find processes are gone. And since df works again, I could see a nfs mount which I guessed caused the issue. Hm, so best guess, a hanging nfs mount is not good. I remember I mounted it without any special options. just "mount ip:/export /mnt" and probably forgot about it. I'll try and reproduce that tomorrow. I would say, a hanging nfs mount shouldn't lead to a hanging around df(1). all the best, Marian From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 19:11:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0BB410656B6; Wed, 18 Aug 2010 19:11:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57E048FC0C; Wed, 18 Aug 2010 19:11:45 +0000 (UTC) Received: by qwg5 with SMTP id 5so957978qwg.13 for ; Wed, 18 Aug 2010 12:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=K8kIG+859E5B5D11IRYPGLUzxLM93heilfj31x2IPI0=; b=e/UbFgRaj86lnaEGGjcZTDwh0wv643mPA3LFtQlBUh6sALOETB15ccs6A/HMEgvszC 8W+lxxXsjKJSl8X3sDHzsckYnpjwjLtKO49BtGKDtx34Ycp1H5WmFPPXCwe1OXHHi+XD IfmKe9AbR00vAM4WeQU/HHJcr/R9CqYapUGng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jz5EX+krBvMTTviG0C2BndEyOLszss3qwuTM7DfdazyOD3jFT5eGJfOLWFABR9s0G1 gP//Ku3avl9HRI3+YUnMXHXYpeOnEA449lRczLolzwSEUADzvNu9KeHzz5Zsjtr53yLs f9Qkfr+H7bpiVCnp7/vJqqTGkNpQVgVdxp2zM= MIME-Version: 1.0 Received: by 10.229.2.7 with SMTP id 7mr527623qch.277.1282158704243; Wed, 18 Aug 2010 12:11:44 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Wed, 18 Aug 2010 12:11:44 -0700 (PDT) In-Reply-To: <20100818134623.GU2396@deviant.kiev.zoral.com.ua> References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> <20100818134623.GU2396@deviant.kiev.zoral.com.ua> Date: Wed, 18 Aug 2010 23:11:44 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: multipart/mixed; boundary=00148537acda1cb5f5048e1dd696 Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:11:45 -0000 --00148537acda1cb5f5048e1dd696 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18 August 2010 17:46, Kostik Belousov wrote: > On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: >> On 18 August 2010 12:07, pluknet wrote: >> > On 17 August 2010 20:04, Kostik Belousov wrote: >> > >> >> >> >> Also please take a note of the John' suggestion to use the taskqueue. >> > >> > I decided to go this road. Thank you both. >> > Now I do nfs buildkernel survive and prepare some benchmark results. >> > >> >> So, I modified the patch to defer proc_create() with taskqueue(9). >> Below is `time make -j5 buildkernel WITHOUT_MODULES=3Dyes` perf. evaluat= ion. >> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both >> nfs-mounted over 1Gbit LAN. >> >> clean old >> 1137.985u 239.411s 7:42.15 298.0% =A0 =A0 =A0 6538+2133k 87+43388io 226p= f+0w >> >> clean new >> 1134.755u 240.032s 7:41.25 298.0% =A0 =A0 =A0 6553+2133k 87+43367io 224p= f+0w >> >> Patch needs polishing, though it generally works. >> Not sure if shep_chan (or whatever name it will get) needs locking. > As I said yesterday, if several requests to create nfsiod coming one > after another, you would loose all but the last. > > You should put the requests into the list, probably protected by > nfs_iod_mtx. > How about this patch? Still several things to ask. 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx h= eld. 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. 3) if (1) is fine, is it right to use fail: logic (i.e. set NFSIOD_NOT_AVAILABLE) on memory shortage? Not tested. There are debug printf() left intentionally to see how 3 contexts run under= load to each other. I attached these messages as well if that makes sense. --=20 wbr, pluknet --00148537acda1cb5f5048e1dd696 Content-Type: application/octet-stream; name="dmesg.out" Content-Disposition: attachment; filename="dmesg.out" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gd0k1q2c1 bmV3OiBuaXA6IDB4ZmZmZmZmMDAwMjdkZWM2MApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2 ZGY2MApuZXc6IG5pX2lvZDogMAp0cTogU0xJU1QgbmlwOiAweGZmZmZmZjAwMDI3ZGVjNjAKdHE6 IG5pcDogMHhmZmZmZmYwMDAyN2RlYzYwCnRxOiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmNjAK dHE6IG5pX2lvZDogMAppbnN0YW5jZTogMHhmZmZmZmZmZjgwZTZkZjYwCm15aW9kOiAwCm5ldzog bmlwOiAweGZmZmZmZjAwMDI1MGMwNDAKbmV3OiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmNjAK bmV3OiBuaV9pb2Q6IDAKdHE6IFNMSVNUIG5pcDogMHhmZmZmZmYwMDAyNTBjMDQwCnRxOiBuaXA6 IDB4ZmZmZmZmMDAwMjUwYzA0MAp0cTogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjYwCnRxOiBu aV9pb2Q6IDAKaW5zdGFuY2U6IDB4ZmZmZmZmZmY4MGU2ZGY2MApteWlvZDogMApuZXc6IG5pcDog MHhmZmZmZmYwMDAyN2RlYzQwCm5ldzogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjYwCm5ldzog bmlfaW9kOiAwCnRxOiBTTElTVCBuaXA6IDB4ZmZmZmZmMDAwMjdkZWM0MAp0cTogbmlwOiAweGZm ZmZmZjAwMDI3ZGVjNDAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY2MAp0cTogbmlfaW9k OiAwCmluc3RhbmNlOiAweGZmZmZmZmZmODBlNmRmNjAKbXlpb2Q6IDAKbmV3OiBuaXA6IDB4ZmZm ZmZmMDAwMmZlYTAwMApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY2NApuZXc6IG5pX2lv ZDogMQp0cTogU0xJU1QgbmlwOiAweGZmZmZmZjAwMDJmZWEwMDAKdHE6IG5pcDogMHhmZmZmZmYw MDAyZmVhMDAwbmV3OiBuaXA6IDB4ZmZmZmZmMDAwMjk2ZmM4MAp0cTogbmlfaW5zdDogMHhmZmZm ZmZmZjgwZTZkZjY0Cm5ldzogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjY4CnRxOiBuaV9pb2Q6 IDEKbmV3OiBuaV9pb2Q6IDIKaW5zdGFuY2U6IDB4ZmZmZmZmZmY4MGU2ZGY2NAoKbXlpb2Q6IDEK dHE6IFNMSVNUIG5pcDogMHhmZmZmZmYwMDAyOTZmYzgwCnRxOiBuaXA6IDB4ZmZmZmZmMDAwMjk2 ZmM4MG5ldzogbmlwOiAweGZmZmZmZjAwMDI5NmZjNjAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4 MGU2ZGY2OApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY2Ywp0cTogbmlfaW9kOiAyCm5l dzogbmlfaW9kOiAzCmluc3RhbmNlOiAweGZmZmZmZmZmODBlNmRmNjgKCm15aW9kOiAyCnRxOiBT TElTVCBuaXA6IDB4ZmZmZmZmMDAwMjk2ZmM2MAp0cTogbmlwOiAweGZmZmZmZjAwMDI5NmZjNjAK dHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY2Ywp0cTogbmlfaW9kOiAzCmluc3RhbmNlOiAw eGZmZmZmZmZmODBlNmRmNmMKbXlpb2Q6IDMKbmV3OiBuaXA6IDB4ZmZmZmZmMDAwMjUwZDY4MApu ZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY3MApuZXc6IG5pX2lvZDogNAp0cTogU0xJU1Qg bmlwOiAweGZmZmZmZjAwMDI1MGQ2ODAKdHE6IG5pcDogMHhmZmZmZmYwMDAyNTBkNjgwCnRxOiBu aV9pbnN0OiAweGZmZmZmZmZmODBlNmRmNzAKdHE6IG5pX2lvZDogNAppbnN0YW5jZTogMHhmZmZm ZmZmZjgwZTZkZjcwCm15aW9kOiA0Cm5ldzogbmlwOiAweGZmZmZmZjAwMDI1MGMwMjAKbmV3OiBu aV9pbnN0OiAweGZmZmZmZmZmODBlNmRmNzQKbmV3OiBuaV9pb2Q6IDUKdHE6IFNMSVNUIG5pcDog MHhmZmZmZmYwMDAyNTBjMDIwCnRxOiBuaXA6IDB4ZmZmZmZmMDAwMjUwYzAyMAp0cTogbmlfaW5z dDogMHhmZmZmZmZmZjgwZTZkZjc0CnRxOiBuaV9pb2Q6IDUKaW5zdGFuY2U6IDB4ZmZmZmZmZmY4 MGU2ZGY3NApteWlvZDogNQpuZXc6IG5pcDogMHhmZmZmZmYwMDAyN2RlYzAwCm5ldzogbmlfaW5z dDogMHhmZmZmZmZmZjgwZTZkZjc0Cm5ldzogbmlfaW9kOiA1CnRxOiBTTElTVCBuaXA6IDB4ZmZm ZmZmMDAwMjdkZWMwMAp0cTogbmlwOiAweGZmZmZmZjAwMDI3ZGVjMDAKdHE6IG5pX2luc3Q6IDB4 ZmZmZmZmZmY4MGU2ZGY3NAp0cTogbmlfaW9kOiA1Cmluc3RhbmNlOiAweGZmZmZmZmZmODBlNmRm NzQKbXlpb2Q6IDUKbmV3OiBuaXA6IDB4ZmZmZmZmMDAwMjUwYzAwMApuZXc6IG5pX2luc3Q6IDB4 ZmZmZmZmZmY4MGU2ZGY3OApuZXc6IG5pX2lvZDogNgp0cTogU0xJU1QgbmlwOiAweGZmZmZmZjAw MDI1MGMwMDAKdHE6IG5pcDogMHhmZmZmZmYwMDAyNTBjMDAwCnRxOiBuaV9pbnN0OiAweGZmZmZm ZmZmODBlNmRmNzgKdHE6IG5pX2lvZDogNgppbnN0YW5jZTogMHhmZmZmZmZmZjgwZTZkZjc4Cm15 aW9kOiA2Cm5ldzogbmlwOiAweGZmZmZmZjAwMDI5NmZjNDAKbmV3OiBuaV9pbnN0OiAweGZmZmZm ZmZmODBlNmRmN2MKbmV3OiBuaV9pb2Q6IDcKdHE6IFNMSVNUIG5pcDogMHhmZmZmZmYwMDAyOTZm YzQwCnRxOiBuaXA6IDB4ZmZmZmZmMDAwMjk2ZmM0MG5ldzogbmlwOiAweGZmZmZmZjAwMDI5NmZj MjAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY3YwpuZXc6IG5pX2luc3Q6IDB4ZmZmZmZm ZmY4MGU2ZGY4MApuZXc6IG5pX2lvZDogOAp0cTogbmlfaW9kOiA3Cgp0cTogU0xJU1QgbmlwOiAw eGZmZmZmZjAwMDI5NmZjMjAKdHE6IG5pcDogMHhmZmZmZmYwMDAyOTZmYzIwaW5zdGFuY2U6IDB4 ZmZmZmZmZmY4MGU2ZGY3Ywp0cTogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjgwCm15aW9kOiA3 CnRxOiBuaV9pb2Q6IDgKCmluc3RhbmNlOiAweGZmZmZmZmZmODBlNmRmODAKbXlpb2Q6IDgKbmV3 OiBuaXA6IDB4ZmZmZmZmMDAwMjdkZWJlMApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY4 NApuZXc6IG5pX2lvZDogOQp0cTogU0xJU1QgbmlwOiAweGZmZmZmZjAwMDI3ZGViZTAKdHE6IG5p cDogMHhmZmZmZmYwMDAyN2RlYmUwCnRxOiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmODQKdHE6 IG5pX2lvZDogOQppbnN0YW5jZTogMHhmZmZmZmZmZjgwZTZkZjg0Cm15aW9kOiA5Cm5ldzogbmlw OiAweGZmZmZmZjAwMDI3ZGViYzAKbmV3OiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmODgKbmV3 OiBuaV9pb2Q6IDEwCnRxOiBTTElTVCBuaXA6IDB4ZmZmZmZmMDAwMjdkZWJjMAp0cTogbmlwOiAw eGZmZmZmZjAwMDI3ZGViYzAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY4OAp0cTogbmlf aW9kOiAxMAppbnN0YW5jZTogMHhmZmZmZmZmZjgwZTZkZjg4Cm15aW9kOiAxMApuZXc6IG5pcDog MHhmZmZmZmYwMDAyN2RlYzAwCm5ldzogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjhjCm5ldzog bmlfaW9kOiAxMQp0cTogU0xJU1QgbmlwOiAweGZmZmZmZjAwMDI3ZGVjMDAKdHE6IG5pcDogMHhm ZmZmZmYwMDAyN2RlYzAwCnRxOiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmOGMKdHE6IG5pX2lv ZDogMTEKaW5zdGFuY2U6IDB4ZmZmZmZmZmY4MGU2ZGY4YwpteWlvZDogMTEKbmV3OiBuaXA6IDB4 ZmZmZmZmMDAwMjk2ZmMwMApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY5MApuZXc6IG5p X2lvZDogMTIKdHE6IFNMSVNUIG5pcDogMHhmZmZmZmYwMDAyOTZmYzAwCnRxOiBuaXA6IDB4ZmZm ZmZmMDAwMjk2ZmMwMAp0cTogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjkwCnRxOiBuaV9pb2Q6 IDEyCmluc3RhbmNlOiAweGZmZmZmZmZmODBlNmRmOTAKbXlpb2Q6IDEyCm5ldzogbmlwOiAweGZm ZmZmZjAwMDI5NmZiZTAKbmV3OiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmOTQKbmV3OiBuaV9p b2Q6IDEzCnRxOiBTTElTVCBuaXA6IDB4ZmZmZmZmMDAwMjk2ZmJlMAp0cTogbmlwOiAweGZmZmZm ZjAwMDI5NmZiZTAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY5NAp0cTogbmlfaW9kOiAx MwppbnN0YW5jZTogMHhmZmZmZmZmZjgwZTZkZjk0Cm15aW9kOiAxMwpuZXc6IG5pcDogMHhmZmZm ZmYwMDAyNTBkNjgwCm5ldzogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjk4Cm5ldzogbmlfaW9k OiAxNAp0cTogU0xJU1QgbmlwOiAweGZmZmZmZjAwMDI1MGQ2ODAKdHE6IG5pcDogMHhmZmZmZmYw MDAyNTBkNjgwCnRxOiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmOTgKdHE6IG5pX2lvZDogMTQK aW5zdGFuY2U6IDB4ZmZmZmZmZmY4MGU2ZGY5OApteWlvZDogMTQKbmV3OiBuaXA6IDB4ZmZmZmZm MDAwMjdkZWJhMApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGY5YwpuZXc6IG5pX2lvZDog MTUKdHE6IFNMSVNUIG5pcDogMHhmZmZmZmYwMDAyN2RlYmEwCnRxOiBuaXA6IDB4ZmZmZmZmMDAw MjdkZWJhMAp0cTogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZjljCnRxOiBuaV9pb2Q6IDE1Cmlu c3RhbmNlOiAweGZmZmZmZmZmODBlNmRmOWMKbXlpb2Q6IDE1Cm5ldzogbmlwOiAweGZmZmZmZjAw MDI5NmZiYzAKbmV3OiBuaV9pbnN0OiAweGZmZmZmZmZmODBlNmRmYTAKbmV3OiBuaV9pb2Q6IDE2 CnRxOiBTTElTVCBuaXA6IDB4ZmZmZmZmMDAwMjk2ZmJjMAp0cTogbmlwOiAweGZmZmZmZjAwMDI5 NmZiYzAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGZhMAp0cTogbmlfaW9kOiAxNgppbnN0 YW5jZTogMHhmZmZmZmZmZjgwZTZkZmEwCm15aW9kOiAxNgpuZXc6IG5pcDogMHhmZmZmZmYwMDAy N2RlYzYwCm5ldzogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZmE0Cm5ldzogbmlfaW9kOiAxNwp0 cTogU0xJU1QgbmlwOiAweGZmZmZmZjAwMDI3ZGVjNjAKdHE6IG5pcDogMHhmZmZmZmYwMDAyN2Rl YzYwbmV3OiBuaXA6IDB4ZmZmZmZmMDAwMjdkZWI4MAp0cTogbmlfaW5zdDogMHhmZmZmZmZmZjgw ZTZkZmE0Cm5ldzogbmlfaW5zdDogMHhmZmZmZmZmZjgwZTZkZmE4CnRxOiBuaV9pb2Q6IDE3Cm5l dzogbmlfaW9kOiAxOAppbnN0YW5jZTogMHhmZmZmZmZmZjgwZTZkZmE0CgpteWlvZDogMTcKdHE6 IFNMSVNUIG5pcDogMHhmZmZmZmYwMDAyN2RlYjgwCnRxOiBuaXA6IDB4ZmZmZmZmMDAwMjdkZWI4 MG5ldzogbmlwOiAweGZmZmZmZjAwMDI1MGMwNjAKdHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2 ZGZhOApuZXc6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGZhYwp0cTogbmlfaW9kOiAxOApuZXc6 IG5pX2lvZDogMTkKaW5zdGFuY2U6IDB4ZmZmZmZmZmY4MGU2ZGZhOAoKbXlpb2Q6IDE4CnRxOiBT TElTVCBuaXA6IDB4ZmZmZmZmMDAwMjUwYzA2MAp0cTogbmlwOiAweGZmZmZmZjAwMDI1MGMwNjAK dHE6IG5pX2luc3Q6IDB4ZmZmZmZmZmY4MGU2ZGZhYwp0cTogbmlfaW9kOiAxOQppbnN0YW5jZTog MHhmZmZmZmZmZjgwZTZkZmFjCm15aW9kOiAxOQo= --00148537acda1cb5f5048e1dd696 Content-Type: text/x-patch; charset=US-ASCII; name="nfsiod_tq_lock.diff" Content-Disposition: attachment; filename="nfsiod_tq_lock.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gd0k2byo2 SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX3N1YnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmZzY2xp ZW50L25mc19zdWJzLmMJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5cy9uZnNjbGllbnQvbmZzX3N1 YnMuYwkod29ya2luZyBjb3B5KQpAQCAtNTksNiArNTksNyBAQAogI2luY2x1ZGUgPHN5cy9zeXNl bnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogI2luY2x1ZGUgPHN5cy9zeXNwcm90by5o PgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5j bHVkZSA8dm0vdm1fb2JqZWN0Lmg+CkBAIC0xMTcsNiArMTE4LDcgQEAKIAogc3RydWN0IG5mc19i dWZxCW5mc19idWZxOwogc3RhdGljIHN0cnVjdCBtdHggbmZzX3hpZF9tdHg7CitzdHJ1Y3QgdGFz awluZnNfbmZzaW9kbmV3X3Rhc2s7CiAKIC8qCiAgKiBhbmQgdGhlIHJldmVyc2UgbWFwcGluZyBm cm9tIGdlbmVyaWMgdG8gVmVyc2lvbiAyIHByb2NlZHVyZSBudW1iZXJzCkBAIC0zNTQsNiArMzU2 LDcgQEAKIAkgKi8KIAltdHhfaW5pdCgmbmZzX2lvZF9tdHgsICJORlMgaW9kIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKIAltdHhfaW5pdCgmbmZzX3hpZF9tdHgsICJORlMgeGlkIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKKwlUQVNLX0lOSVQoJm5mc19uZnNpb2RuZXdfdGFzaywgMCwgbmZzX25mc2lv ZG5ld190cSwgTlVMTCk7CiAKIAluZnNfcGJ1Zl9mcmVlY250ID0gbnN3YnVmIC8gMiArIDE7CiAK SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX25mc2lvZC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZnNj bGllbnQvbmZzX25mc2lvZC5jCShyZXZpc2lvbiAyMTEyNzkpCisrKyBzeXMvbmZzY2xpZW50L25m c19uZnNpb2QuYwkod29ya2luZyBjb3B5KQpAQCAtNTksNiArNTksNyBAQAogI2luY2x1ZGUgPHN5 cy9mY250bC5oPgogI2luY2x1ZGUgPHN5cy9sb2NrZi5oPgogI2luY2x1ZGUgPHN5cy9tdXRleC5o PgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KIAogI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4K ICNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgpAQCAtNzUsNiArNzYsMTcgQEAKIAogc3RhdGljIHZv aWQJbmZzc3ZjX2lvZCh2b2lkICopOwogCitzdHJ1Y3QgbmZzaW9kX3N0ciB7CisJU0xJU1RfRU5U UlkobmZzaW9kX3N0cikgbmlfbGlzdDsKKwlpbnQgKm5pX2luc3Q7CisJaW50IG5pX2lvZDsKKwlp bnQgbmlfZXJyb3I7CisJaW50IG5pX2J1c3k7CisJaW50IG5pX2RvbmU7Cit9Oworc3RhdGljIFNM SVNUX0hFQUQoLCBuZnNpb2Rfc3RyKSBuZnNpb2RoZWFkID0KKyAgICBTTElTVF9IRUFEX0lOSVRJ QUxJWkVSKG5mc2lvZGhlYWQpOworCiBzdGF0aWMgaW50IG5mc19hc3luY2RhZW1vbltORlNfTUFY QVNZTkNEQUVNT05dOwogCiBTWVNDVExfREVDTChfdmZzX25mcyk7CkBAIC0xNTksMTEgKzE3MSwz NCBAQAogICAgIHNpemVvZiAobmZzX2lvZG1heCksIHN5c2N0bF9pb2RtYXgsICJJVSIsCiAgICAg Ik1heCBudW1iZXIgb2YgbmZzaW9kIGt0aHJlYWRzIik7CiAKK3ZvaWQKK25mc19uZnNpb2RuZXdf dHEoX191bnVzZWQgdm9pZCAqYXJnLCBpbnQgcGVuZGluZykKK3sKKwlzdHJ1Y3QgbmZzaW9kX3N0 ciAqbmlwOworCisJbXR4X2xvY2soJm5mc19pb2RfbXR4KTsKKwlTTElTVF9GT1JFQUNIKG5pcCwg Jm5mc2lvZGhlYWQsIG5pX2xpc3QpIHsKKwkJcHJpbnRmKCJ0cTogU0xJU1QgbmlwOiAlcFxuIiwg bmlwKTsKKwkJaWYgKG5pcC0+bmlfYnVzeSA9PSAwKSB7CisJCQluaXAtPm5pX2J1c3kgPSAxOwor CQkJYnJlYWs7CisJCX0KKwl9CisJbXR4X3VubG9jaygmbmZzX2lvZF9tdHgpOworCUtBU1NFUlQo bmlwICE9IE5VTEwsICgibmZzX25mc2lvZG5ld190cTogbmlwIGlzIE5VTEwiKSk7CisJcHJpbnRm KCJ0cTogbmlwOiAlcFxuIiwgbmlwKTsKKwlwcmludGYoInRxOiBuaV9pbnN0OiAlcFxuIiwgbmlw LT5uaV9pbnN0KTsKKwlwcmludGYoInRxOiBuaV9pb2Q6ICVkXG4iLCBuaXAtPm5pX2lvZCk7CisJ bmlwLT5uaV9lcnJvciA9IGtwcm9jX2NyZWF0ZShuZnNzdmNfaW9kLCBuaXAtPm5pX2luc3QsIE5V TEwsCisJICAgIFJGSElHSFBJRCwgMCwgIm5mc2lvZCAlZCIsIG5pcC0+bmlfaW9kKTsKKwluaXAt Pm5pX2RvbmUgPSAxOworfQorCiBpbnQKIG5mc19uZnNpb2RuZXcoaW50IHNldF9pb2R3YW50KQog ewotCWludCBlcnJvciwgaTsKLQlpbnQgbmV3aW9kOworCWludCBpLCBuZXdpb2QsIGVycm9yOwor CXN0cnVjdCBuZnNpb2Rfc3RyICpuaXAsICpuaXBfdGVtcDsKIAogCWlmIChuZnNfbnVtYXN5bmMg Pj0gbmZzX2lvZG1heCkKIAkJcmV0dXJuICgtMSk7CkBAIC0xNzgsMTcgKzIxMywzNCBAQAogCQly ZXR1cm4gKC0xKTsKIAlpZiAoc2V0X2lvZHdhbnQgPiAwKQogCQluZnNfaW9kd2FudFtpXSA9IE5G U0lPRF9DUkVBVEVEX0ZPUl9ORlNfQVNZTkNJTzsKKwluaXAgPSBtYWxsb2Moc2l6ZW9mKCpuaXAp LCBNX1RFTVAsIE1fTk9XQUlUIHwgTV9aRVJPKTsKKwlpZiAobmlwID09IE5VTEwpCisJCWdvdG8g ZmFpbDsKKwluaXAtPm5pX2luc3QgPSBuZnNfYXN5bmNkYWVtb24gKyBpOworCW5pcC0+bmlfaW9k ID0gbmV3aW9kOworCVNMSVNUX0lOU0VSVF9IRUFEKCZuZnNpb2RoZWFkLCBuaXAsIG5pX2xpc3Qp OwogCW10eF91bmxvY2soJm5mc19pb2RfbXR4KTsKLQllcnJvciA9IGtwcm9jX2NyZWF0ZShuZnNz dmNfaW9kLCBuZnNfYXN5bmNkYWVtb24gKyBpLCBOVUxMLCBSRkhJR0hQSUQsCi0JICAgIDAsICJu ZnNpb2QgJWQiLCBuZXdpb2QpOworCXByaW50ZigibmV3OiBuaXA6ICVwXG4iLCBuaXApOworCXBy aW50ZigibmV3OiBuaV9pbnN0OiAlcFxuIiwgbmlwLT5uaV9pbnN0KTsKKwlwcmludGYoIm5ldzog bmlfaW9kOiAlZFxuIiwgbmlwLT5uaV9pb2QpOworCXRhc2txdWV1ZV9lbnF1ZXVlKHRhc2txdWV1 ZV90aHJlYWQsICZuZnNfbmZzaW9kbmV3X3Rhc2spOwogCW10eF9sb2NrKCZuZnNfaW9kX210eCk7 Ci0JaWYgKGVycm9yKSB7Ci0JCWlmIChzZXRfaW9kd2FudCA+IDApCi0JCQluZnNfaW9kd2FudFtp XSA9IE5GU0lPRF9OT1RfQVZBSUxBQkxFOwotCQlyZXR1cm4gKC0xKTsKKwllcnJvciA9IG5pcC0+ bmlfZXJyb3I7CisJU0xJU1RfRk9SRUFDSF9TQUZFKG5pcCwgJm5mc2lvZGhlYWQsIG5pX2xpc3Qs IG5pcF90ZW1wKSB7CisJCWlmIChuaXAtPm5pX2J1c3kgIT0gMCAmJiBuaXAtPm5pX2RvbmUgIT0g MCkgeworCQkJU0xJU1RfUkVNT1ZFKCZuZnNpb2RoZWFkLCBuaXAsIG5mc2lvZF9zdHIsIG5pX2xp c3QpOworCQkJZnJlZShuaXAsIE1fVEVNUCk7CisJCQlicmVhazsKKwkJfQogCX0KKwlpZiAoZXJy b3IpCisJCWdvdG8gZmFpbDsKIAluZnNfbnVtYXN5bmMrKzsKIAlyZXR1cm4gKG5ld2lvZCk7Citm YWlsOgorCWlmIChzZXRfaW9kd2FudCA+IDApCisJCW5mc19pb2R3YW50W2ldID0gTkZTSU9EX05P VF9BVkFJTEFCTEU7CisJcmV0dXJuICgtMSk7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0yMzEsNiAr MjgzLDggQEAKIAogCW10eF9sb2NrKCZuZnNfaW9kX210eCk7CiAJbXlpb2QgPSAoaW50ICopaW5z dGFuY2UgLSBuZnNfYXN5bmNkYWVtb247CisJcHJpbnRmKCJpbnN0YW5jZTogJXBcbiIsIGluc3Rh bmNlKTsKKwlwcmludGYoIm15aW9kOiAlZFxuIiwgbXlpb2QpOwogCS8qCiAJICogTWFpbiBsb29w CiAJICovCkluZGV4OiBzeXMvbmZzY2xpZW50L25mcy5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZnNj bGllbnQvbmZzLmgJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5cy9uZnNjbGllbnQvbmZzLmgJKHdv cmtpbmcgY29weSkKQEAgLTEyNSw2ICsxMjUsNyBAQAogCiBleHRlcm4gc3RydWN0IG5mc3N0YXRz IG5mc3N0YXRzOwogZXh0ZXJuIHN0cnVjdCBtdHggbmZzX2lvZF9tdHg7CitleHRlcm4gc3RydWN0 IHRhc2sgbmZzX25mc2lvZG5ld190YXNrOwogCiBleHRlcm4gaW50IG5mc19udW1hc3luYzsKIGV4 dGVybiB1bnNpZ25lZCBpbnQgbmZzX2lvZG1heDsKQEAgLTI1Myw2ICsyNTQsNyBAQAogCSAgICBz dHJ1Y3QgdWNyZWQgKmNyZWQsIHN0cnVjdCB0aHJlYWQgKnRkKTsKIGludAluZnNfcmVhZGRpcnJw YyhzdHJ1Y3Qgdm5vZGUgKiwgc3RydWN0IHVpbyAqLCBzdHJ1Y3QgdWNyZWQgKik7CiBpbnQJbmZz X25mc2lvZG5ldyhpbnQpOwordm9pZAluZnNfbmZzaW9kbmV3X3RxKF9fdW51c2VkIHZvaWQgKiwg aW50KTsKIGludAluZnNfYXN5bmNpbyhzdHJ1Y3QgbmZzbW91bnQgKiwgc3RydWN0IGJ1ZiAqLCBz dHJ1Y3QgdWNyZWQgKiwgc3RydWN0IHRocmVhZCAqKTsKIGludAluZnNfZG9pbyhzdHJ1Y3Qgdm5v ZGUgKiwgc3RydWN0IGJ1ZiAqLCBzdHJ1Y3QgdWNyZWQgKiwgc3RydWN0IHRocmVhZCAqKTsKIHZv aWQJbmZzX2RvaW9fZGlyZWN0d3JpdGUgKHN0cnVjdCBidWYgKik7Cg== --00148537acda1cb5f5048e1dd696-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 19:17:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 044A31065694; Wed, 18 Aug 2010 19:17:58 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 95A278FC19; Wed, 18 Aug 2010 19:17:57 +0000 (UTC) Received: by qyk8 with SMTP id 8so371594qyk.13 for ; Wed, 18 Aug 2010 12:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AQ1wWHZPZ0MlaVGAEp5nvCZtycAokklS3GoA+Mv8Os0=; b=LD1mW3cpLuYcC1X1JczAacfa5NuIaNXP9lDQguGh1peZvYFtHP4MTJ1IfVqbsFOSHk Xxnq18CNWhDXHypuK3VF8IlnH8y2uISnSp03PZITkI/JtF9+1akIV0BGil4BWYntkDM5 CCS1gcS2SEcLW3U0/r2ScS3ifIVX+dEL6oOZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=k9mJDY1T/FTp+qh9nvYBO9XoTWsqsBkC1YRM60uLWY5xNgXDTycCablnf6qQ/NzkjC AwHkcV7LSX5L3foKeWXpyHJd0Myd3fkXCYZ5KLnFi0D0qCcot21Dwq4KWx+VwYbE1mmE AYwBS4095qwH+2KEToqUz+oMYJ6E+E4vdxA2g= MIME-Version: 1.0 Received: by 10.229.192.13 with SMTP id do13mr6365932qcb.30.1282159076807; Wed, 18 Aug 2010 12:17:56 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Wed, 18 Aug 2010 12:17:56 -0700 (PDT) In-Reply-To: References: <20100816185456.GU2396@deviant.kiev.zoral.com.ua> <20100817160445.GO2396@deviant.kiev.zoral.com.ua> <20100818134623.GU2396@deviant.kiev.zoral.com.ua> Date: Wed, 18 Aug 2010 23:17:56 +0400 Message-ID: From: pluknet To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:17:58 -0000 On 18 August 2010 23:11, pluknet wrote: > On 18 August 2010 17:46, Kostik Belousov wrote: >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: >>> On 18 August 2010 12:07, pluknet wrote: >>> > On 17 August 2010 20:04, Kostik Belousov wrote: >>> > >>> >> >>> >> Also please take a note of the John' suggestion to use the taskqueue= . >>> > >>> > I decided to go this road. Thank you both. >>> > Now I do nfs buildkernel survive and prepare some benchmark results. >>> > >>> >>> So, I modified the patch to defer proc_create() with taskqueue(9). >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=3Dyes` perf. evalua= tion. >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both >>> nfs-mounted over 1Gbit LAN. >>> >>> clean old >>> 1137.985u 239.411s 7:42.15 298.0% =A0 =A0 =A0 6538+2133k 87+43388io 226= pf+0w >>> >>> clean new >>> 1134.755u 240.032s 7:41.25 298.0% =A0 =A0 =A0 6553+2133k 87+43367io 224= pf+0w >>> >>> Patch needs polishing, though it generally works. >>> Not sure if shep_chan (or whatever name it will get) needs locking. >> As I said yesterday, if several requests to create nfsiod coming one >> after another, you would loose all but the last. >> >> You should put the requests into the list, probably protected by >> nfs_iod_mtx. >> > > How about this patch? Still several things to ask. > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx= held. > 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciate= d. > 3) if (1) is fine, is it right to use fail: logic (i.e. set > NFSIOD_NOT_AVAILABLE) > on memory shortage? Not tested. > > There are debug printf() left intentionally to see how 3 contexts run und= er load > to each other. I attached these messages as well if that makes sense. > Ah, yes. Sorry, forgot about that. This is from last run: 1139.225u 239.873s 7:44.90 296.6% 6524+2130k 77+43153io 220pf+0w --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 19:46:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C52B1065696 for ; Wed, 18 Aug 2010 19:46:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0178FC14 for ; Wed, 18 Aug 2010 19:46:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA23988; Wed, 18 Aug 2010 22:46:45 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Oloaz-000Kh7-JR; Wed, 18 Aug 2010 22:46:45 +0300 Message-ID: <4C6C38A3.7080900@icyb.net.ua> Date: Wed, 18 Aug 2010 22:46:43 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Marian Hettwer References: <4C6B987F.5050703@kernel32.de> <4C6BF9B0.9070900@icyb.net.ua> <4C6C2F7A.5060908@kernel32.de> In-Reply-To: <4C6C2F7A.5060908@kernel32.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.1-release + zfs v15 df(1) hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:46:50 -0000 on 18/08/2010 22:07 Marian Hettwer said the following: > I'll try and reproduce that tomorrow. I would say, a hanging nfs mount > shouldn't lead to a hanging around df(1). See df -n. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 19:59:53 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F131065670; Wed, 18 Aug 2010 19:59:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B70EB8FC21; Wed, 18 Aug 2010 19:59:52 +0000 (UTC) Received: by bwz20 with SMTP id 20so1198266bwz.13 for ; Wed, 18 Aug 2010 12:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=XHVsloaaPABMDShXzc0KK8EWW72NW25HyrNBuGnnGaM=; b=ToJjlYjiwarxeFDkHYNercM6fgcT/TmpTOdOeOMwHt2/iJZPRw1/L7GqADuTszW1Xy kezNwnUgGqYCNIpdNucMtGG9M5I+sKqHGHfiUSAjohLeh9w9UFuWVOslh/G9YupHctyL ZjxBTa8J7eJ0KOTdj/Cb+O9VY4meujp3BupmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MPUNLC/f17HAWDq2deR5Gyqh4iE+yyGa59BATG40xWYZQ+EEzypVGTDvbFKo00GVrl i/kSa86Y1zWMkUCHxHvgiyvQGE1DwNMkOeSgj0opqlL/dh8aLZIypGAbyhTRe/kBltiw 3NX6aPhPPm29lZh/Srps8OIR4ZNgQbg3/uNe8= MIME-Version: 1.0 Received: by 10.204.47.193 with SMTP id o1mr5793031bkf.134.1282161591407; Wed, 18 Aug 2010 12:59:51 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Wed, 18 Aug 2010 12:59:51 -0700 (PDT) In-Reply-To: <4C6C1EDC.5000206@andric.com> References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EDC.5000206@andric.com> Date: Wed, 18 Aug 2010 12:59:51 -0700 X-Google-Sender-Auth: pqm0BuWAGCn8P-SCe380Zo0eULU Message-ID: From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: "arch@freebsd.org" , Rui Paulo , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:59:53 -0000 On Wed, Aug 18, 2010 at 10:56 AM, Dimitry Andric wrote: > On 2010-08-18 19:37, Rui Paulo wrote: >> I really don't know how compatible is the latest icc because no one >> ever updated the ports version. This is actually a hint that no one >> really uses this anymore. > > I recently installed the port, which has icc 8.1, but it fails to > compile even simple C++ programs, because it cannot cope with the > libstdc++ headers from g++ 4.2.1. > > You have to do all kinds of tricks, such as installing the gcc 3.4.x > port, and pointing the Intel compiler to its libstdc++ headers and > libraries, or nothing will work. > > Updating that port to icc 11.1 is probably not a trivial task, and > making sure it compiles programs properly is even trickier... :) Yeah... I was referring to icc 11.x because of work that my old group was looking at doing back when I was working on Linux. Anything older than that probably has compatibility issues :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 20:09:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD88106566B for ; Wed, 18 Aug 2010 20:09:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BFBFC8FC0C for ; Wed, 18 Aug 2010 20:09:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5189246B96; Wed, 18 Aug 2010 16:09:22 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 719F48A04E; Wed, 18 Aug 2010 16:09:21 -0400 (EDT) From: John Baldwin To: pluknet Date: Wed, 18 Aug 2010 16:07:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008181607.52798.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 18 Aug 2010 16:09:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:09:23 -0000 On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: > On 18 August 2010 23:11, pluknet wrote: > > On 18 August 2010 17:46, Kostik Belousov wrote: > >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: > >>> On 18 August 2010 12:07, pluknet wrote: > >>> > On 17 August 2010 20:04, Kostik Belousov wrote: > >>> > > >>> >> > >>> >> Also please take a note of the John' suggestion to use the taskqueue. > >>> > > >>> > I decided to go this road. Thank you both. > >>> > Now I do nfs buildkernel survive and prepare some benchmark results. > >>> > > >>> > >>> So, I modified the patch to defer proc_create() with taskqueue(9). > >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. > >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both > >>> nfs-mounted over 1Gbit LAN. > >>> > >>> clean old > >>> 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w > >>> > >>> clean new > >>> 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w > >>> > >>> Patch needs polishing, though it generally works. > >>> Not sure if shep_chan (or whatever name it will get) needs locking. > >> As I said yesterday, if several requests to create nfsiod coming one > >> after another, you would loose all but the last. > >> > >> You should put the requests into the list, probably protected by > >> nfs_iod_mtx. > >> > > > > How about this patch? Still several things to ask. > > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held. > > 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. > > 3) if (1) is fine, is it right to use fail: logic (i.e. set > > NFSIOD_NOT_AVAILABLE) > > on memory shortage? Not tested. > > > > There are debug printf() left intentionally to see how 3 contexts run under load > > to each other. I attached these messages as well if that makes sense. > > > > Ah, yes. Sorry, forgot about that. Your task handler needs to run in a loop until the list of requests is empty. If multiple threads call taskqueue_enqueue() before your task is scheduled, they will be consolidated down to a single call of your task handler. - int error, i; - int newiod; + int i, newiod, error; You should sort these alphabetically if you are going to change this. I would probably just leave it as-is. Also, I'm not sure how this works as you don't actually wait for the task to complete. If the taskqueue_enqueue() doesn't preempt, then you may read ni_error as zero before the kproc has actually been created and return success even though an nfsiod hasn't been created. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 20:52:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D3E1065670 for ; Wed, 18 Aug 2010 20:52:34 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7122F8FC16 for ; Wed, 18 Aug 2010 20:52:34 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7IKq7a5032089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 06:52:08 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o7IKq7Dx055652; Thu, 19 Aug 2010 06:52:07 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o7IKq7AS055651; Thu, 19 Aug 2010 06:52:07 +1000 (EST) (envelope-from peter) Date: Thu, 19 Aug 2010 06:52:06 +1000 From: Peter Jeremy To: Dimitry Andric Message-ID: <20100818205206.GA55620@server.vk2pj.dyndns.org> References: <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <4C6AF13A.1080606@andric.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alan Cox , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:52:35 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Aug-17 22:29:46 +0200, Dimitry Andric wrote: >On 2010-08-17 18:29, Alan Cox wrote: >> Try it again on a memory resident file with the MAP_PREFAULT_READ option >> that is provided by this patch: >>=20 >> http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch > >A time trial gives: > > grep with normal mmap() 1396s > grep with prefault mmap() 1354s > grep with regular read() 1354s Is this with uncached (ie remount the filesystem on each test) or cached data? Which filesystem (and does it change for different filesystems (particularly between UFS and ZFS))? And one trial is not statistically valid - especially given the small differences. How about multiple multiple trials with ministat. --=20 Peter Jeremy --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxsR/YACgkQ/opHv/APuIe2CwCffugTuF6B2kgNvXM7wqDRcEa+ HRQAoJPIfOwIJGrQWc4DkF6qfWJcjeOK =0cg8 -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 21:12:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 287FA106564A for ; Wed, 18 Aug 2010 21:12:33 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id D91F78FC17 for ; Wed, 18 Aug 2010 21:12:32 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911] (unknown [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F41845C59; Wed, 18 Aug 2010 23:12:30 +0200 (CEST) Message-ID: <4C6C4CBF.1040200@andric.com> Date: Wed, 18 Aug 2010 23:12:31 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Peter Jeremy References: <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> <20100818205206.GA55620@server.vk2pj.dyndns.org> In-Reply-To: <20100818205206.GA55620@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:12:33 -0000 On 2010-08-18 22:52, Peter Jeremy wrote: >> grep with normal mmap() 1396s >> grep with prefault mmap() 1354s >> grep with regular read() 1354s > > Is this with uncached (ie remount the filesystem on each test) or cached > data? This is all on the same filesystem, and the test file is ~370MB, so eventually all data will be in RAM, most likely. E.g. normal mmap() seems to add a bit of overhead that explains the slower result. > Which filesystem (and does it change for different filesystems > (particularly between UFS and ZFS))? I only checked on UFS2. > And one trial is not statistically valid - especially given the small > differences. How about multiple multiple trials with ministat. The result were averages of three trials; they were fairly close to each other, but I didn't calculate the standard deviation. I was not aware of ministat, which looks like a real handy program. :) From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 21:47:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD111065672 for ; Wed, 18 Aug 2010 21:47:13 +0000 (UTC) (envelope-from gordon.tetlow@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 81C2B8FC18 for ; Wed, 18 Aug 2010 21:47:13 +0000 (UTC) Received: by iwn36 with SMTP id 36so1194761iwn.13 for ; Wed, 18 Aug 2010 14:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=5SEaXr+JNTAnBhRn9254ouk+B481+qvrGi/DIMyrYfM=; b=vOx0r1QbhaN0iKPHnf9A8qISKJeT/+3zmIb9I66f/dgunyNh9qOKrCV2Tt6VZkkEev PzRD/mR3P9zd6/8TiXh0QdaxGNXH6S5vekgPPyfPRxNhX5rRA9mXxUnueZyQ+xAZWVwq oXCOk3iTdXGFqwuicLZoqj1HGU4d91K3YQUI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=VvO3dxQnwq72vVTTIJyYliZ3rUnSO5ovLm0a3n+/YkkZq0lMYHRNeLjqCmgCjKYmnh HcsayZRYHiST3yhd7PKQiLS4PEwj7oNEyLrRUA4c9Jme3EHgGqxbE8b19lFQ+RATcK2E zCYYK6r2qmRdL5ZN0LFJxx1EaINRjo6zpFQlE= MIME-Version: 1.0 Received: by 10.231.191.74 with SMTP id dl10mr9858627ibb.157.1282168032794; Wed, 18 Aug 2010 14:47:12 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.172.147 with HTTP; Wed, 18 Aug 2010 14:47:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 14:47:12 -0700 X-Google-Sender-Auth: E-JYYtE5VKGoeBkKX6pS4ieNSOM Message-ID: From: Gordon Tetlow To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:47:13 -0000 On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow wrote: > All, > > I sat down and rewrote the man tools from a relatively old codebase to a > single shell script. My original motivation was to allow multiple > configuration files so port installations did not have to mess with > /etc/manpath.config (like perl for example) when needing to manipulate the > manpath. After looking at the existing code, I figured I could rewrite it as > a shell script relatively easily. > > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, > /usr/bin/whatis) > http://people.freebsd.org/~gordon/man.sh > > Features of the new code: > > 1. BSD licensed (old code is GPL). > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > (purposefully changed the manpath.config file since it is a different > syntax). > 3. Allows ports to override the toolset used to display the manpage based > on language. This was done to try to merge the functionality of the > japanese/man port into the base system as much as possible. > > I've tried to make this mirror the functionality, directory search order, > and arguments as the current base implementation. > > This brings me to my next point. I need some testers willing to try this > out. It would be particularly great if I could get some foreign language > testers with localized manpage installations. If something doesn't work the > way you expect, please contact me and I can help debug it (using man -ddd > will generally give me the debug information I need). > > Thanks, > Gordon > I did some additional testing with the japanese/man-doc port and found the following was necessary: 1. Install my script as /usr/bin/man 2. Install japanese/man-doc 3. Create a /usr/local/etc/man.d/ja-man-doc.conf with the following contents: EQN_JA /usr/local/bin/geqn COL_JA /bin/cat NROFF_JA /usr/local/bin/groff -S -Wall -mtty-char -man -Tnippon -dlang=ja_JP.eucJP PIC_JA /usr/local/bin/gpic TBL_JA /usr/local/bin/gtbl TROFF_JA /usr/local/bin/groff -man -dlang=ja_JP.eucJP MANLOCALE ja_JP.eucJP 4. Create a symlink from /usr/share/man/ja.eucJP -> /usr/local/man/ja 5. Set LC_CTYPE=ja_JP.eucJP 6. man ls When all is said and done, 3 should be handled by the man-doc port while 4 is a problem. The current base system man uses the following search order for localized manpages (which I have emulated): Look in /usr/share/man/. /usr/share/man/ ... /usr/local/man/. /usr/local/man/ ... Without step 4 from above, if you were to attempt to get a localized manpage for ls(1) that resides in /usr/local/man/., you would never see it because the english language manpage in /usr/share/man would be found first. The japanese man port gets around this by installing their own man implementation (jman) forcing /usr/local/man/ja before /usr/share/man in the search order. I'm interested in feedback about whether the search order should change or if I should leave it as is. From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 21:54:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0171F1065695 for ; Wed, 18 Aug 2010 21:54:42 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 880CF8FC0A for ; Wed, 18 Aug 2010 21:54:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911] (unknown [IPv6:2001:7b8:3a7:0:f4aa:bf1e:4470:d911]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C7CC55C59; Wed, 18 Aug 2010 23:54:40 +0200 (CEST) Message-ID: <4C6C56A1.9050405@andric.com> Date: Wed, 18 Aug 2010 23:54:41 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Peter Jeremy References: <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> <20100818205206.GA55620@server.vk2pj.dyndns.org> <4C6C4CBF.1040200@andric.com> In-Reply-To: <4C6C4CBF.1040200@andric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alan Cox , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:54:42 -0000 On 2010-08-18 23:12, Dimitry Andric wrote: >> And one trial is not statistically valid - especially given the small >> differences. How about multiple multiple trials with ministat. > > The result were averages of three trials Actually, since I kept using Doug's original grep-time-trial.sh, each of the three 'trials' consisted of running grep 100 times, and the listed time was the total elapsed time for those 100 runs. So I assume that will reasonably average out the differences between each individual run? Also, I'm not sure if the actual disk/fs reading performance will differ much between GNU grep and any other grep, since they will all basically read through the whole test file sequentially. For instance, when I profiled GNU grep with gprof, the top time results were: % cumulative self self total time seconds seconds calls ms/call ms/call name 99.1 0.59 0.59 11497 0.05 0.05 read [5] 0.6 0.59 0.00 11497 0.00 0.00 kwsexec [8] 0.1 0.59 0.00 0 100.00% .mcount (130) 0.1 0.59 0.00 1 0.62 594.77 grepfile [3] 0.1 0.60 0.00 11496 0.00 0.00 memmove [9] 0.0 0.60 0.00 4 0.03 0.03 memchr [10] 0.0 0.60 0.00 12541 0.00 0.00 memset [16] 0.0 0.60 0.00 11497 0.00 0.00 EGexecute [7] 0.0 0.60 0.00 11497 0.00 0.05 fillbuf [4] 0.0 0.60 0.00 11497 0.00 0.00 grepbuf [6] E.g. it looks like most of the time is spent in the read system call. If mmap'ing can help improve that, it would be nice, but I suspect the gains would be marginal. The actual performance difference is much more likely to be related to how efficiently grep parses out lines, and searches for regexps in there. BSD grep still has quite some room for improvement in that department. From owner-freebsd-current@FreeBSD.ORG Wed Aug 18 22:42:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C40491065675; Wed, 18 Aug 2010 22:42:47 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas01p.mx.bigpond.com (nschwmtas01p.mx.bigpond.com [61.9.189.137]) by mx1.freebsd.org (Postfix) with ESMTP id 027538FC14; Wed, 18 Aug 2010 22:42:46 +0000 (UTC) Received: from nschwotgx03p.mx.bigpond.com ([124.188.161.100]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20100818224244.VRGB1369.nschwmtas01p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Wed, 18 Aug 2010 22:42:44 +0000 Received: from ghanamia.reilly.home ([124.188.161.100]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20100818224244.HBUY16083.nschwotgx03p.mx.bigpond.com@ghanamia.reilly.home>; Wed, 18 Aug 2010 22:42:44 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Andrew Reilly In-Reply-To: <20100818142852.GA80221@onelab2.iet.unipi.it> Date: Thu, 19 Aug 2010 08:42:43 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <81DF8D90-59E4-41F5-BAB8-556403D2E100@bigpond.net.au> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100818142852.GA80221@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1081) X-Authentication-Info: Submitted using SMTP AUTH PLAIN at nschwotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 18 Aug 2010 22:42:43 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090204.4C6C61E4.0154,ss=1,fgs=0 X-SIH-MSG-ID: rR4wF9L/TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRsMuxxD9EJhiHNGUiaajgTY3Rs9mK Cc: Doug Barton , Ivan Voras , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:42:47 -0000 Hi Luigi, On 19/08/2010, at 00:28 , Luigi Rizzo wrote: > slightly off topic but I disagree on the latter part. I didn't expect everyone to agree. Not sure that I do, necessarily, = either. (A neat, small language like TCL or Lua is probably better for = most of the uses we're discussing here.) Just making a low-impact = suggestion to the problem of making use of a higher-level language than = C while not dragging large lumps of code into core, or accumulating = maintenance issues. > The whole point of having source code is to be able to make > modifications, small or large, private or ones to be contributed > back. As a teacher, i am very concerned about the ease-of-use for > non-developer types: it is important to make it easy for people to > experiments, as this is one of the ways people learn things. I'm not making any suggestion about preventing or discouraging = tinkering. After all, we used to carry f2c around in the base, in order = to support Fortran code. There's no particular reason *not* to provide = the front-end for (whatever language), but so long as it's readily = available in ports, and build-able form a base config, I don't see that = being in base is essential. > Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' > tool is almost as bad as having no source. This is an opinion I certainly don't share. There are many languages = that I don't like but that doesn't make them useful, or even = best-for-purpose in their niche. (a) I'm not suggesting that we don't = provide source, and (b) learning a new language is an excellent = excellent exercise for students, and one that they're going to have to = go through often, for the rest of their careers. > (in fact, it is like the > joke of supplying source for the GPL'd software in your brand new > LCD tv or appliance. I'd like to know who will ever be able to build > an updated image and upload it to the appliance) It's nothing of the sort, of course. In the scenario I suggested, the = task of updating the putative program would involve the editors = available in base, to edit the source shipped with the system. Only the = compilation of the edited source might or might not be gated by = installing the port for the putative compiler. Several of the examples = I gave originally come with an interpreter and debugging environment, so = even that potential argument need not be a blocker. Not a high bar to = entry, I suggest. Cheers, --=20 Andrew From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 00:01:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF6AB10656A8 for ; Thu, 19 Aug 2010 00:01:16 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3227A8FC13 for ; Thu, 19 Aug 2010 00:01:15 +0000 (UTC) Received: by bwz20 with SMTP id 20so1414760bwz.13 for ; Wed, 18 Aug 2010 17:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=KDiBQ896VI0aJUL/5qov9TIOCtxRmJXmE4eh70aoWjc=; b=uO32G4DUDWWa9EDdlDFBlUY1nbqwdg00Zdi9hB2j/FamBiscrnWRUuVpqo/rR3/v62 L+swwa+C65wnSQkqVvV4GORMrQ/G5+Sb2TI8eNixs+cpSMRsBFYP/K4NfCXYrphxohmU nmWUMkQBv0CS4FDoKfgD1Si7yT4xLQtdy6CSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=mvj+JKu2C4CgtQig2yhn2GJ9HKPlQPSOdjsDGHeHEVl7+brTLf3906a28FlT3yAFxl J2gFl125hcGFs7jqpGw1y5QRPnO+/pQS5MR6IfGzooiOsLupkJ4v2ijaX5Yt6tSLX6vW CH/Gk/HM0Wh4coTK856Encd0fd8N3fPQUb9fs= Received: by 10.204.73.211 with SMTP id r19mr6042058bkj.131.1282176075132; Wed, 18 Aug 2010 17:01:15 -0700 (PDT) Received: from localhost ([78.142.140.194]) by mx.google.com with ESMTPS id y19sm600091bkw.18.2010.08.18.17.01.12 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 17:01:14 -0700 (PDT) From: Anonymous To: Gordon Tetlow References: Date: Thu, 19 Aug 2010 04:01:01 +0400 In-Reply-To: (Gordon Tetlow's message of "Wed, 18 Aug 2010 00:11:20 -0700") Message-ID: <86sk2b79oi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:01:16 -0000 Gordon Tetlow writes: > I've tried to make this mirror the functionality, directory search order, > and arguments as the current base implementation. > > This brings me to my next point. I need some testers willing to try this > out. It would be particularly great if I could get some foreign language > testers with localized manpage installations. If something doesn't work the > way you expect, please contact me and I can help debug it (using man -ddd > will generally give me the debug information I need). It doesn't search in bin/../man nor in bin/.man. For example, my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config is default one and contains /usr/local/man which does not exist here. $ man -w mplayer rsync HOME/.bin/man/man1/mplayer.1 LOCALBASE/man/man1/rsync.1.gz $ echo $PATH LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin Unfortunately, if ~/.bin is in PATH it still will not search in ~/.man without touching MANPATH. But with man.sh it doesn't respect PATH at all. $ man -ddd -w mplayer rsync -- Using architecture: amd64:amd64 -- Using pager: less -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l -- Using manual path: /usr/share/man:/usr/share/openssl/man:/usr/local/man -- Using locale paths: en_US.UTF-8:en.UTF-8:. -- Searching for mplayer -- Searching section 1 -- Searching directory /usr/share/man/en.UTF-8/man1 -- Searching directory /usr/share/man/man1 -- Searching directory /usr/share/openssl/man/man1 -- Searching section 1aout -- Searching directory /usr/share/man/en.UTF-8/man1aout -- Searching directory /usr/share/man/man1aout -- Searching section 8 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8 -- Searching section 2 -- Searching directory /usr/share/man/en.UTF-8/man2 -- Searching directory /usr/share/man/man2 -- Searching section 3 -- Searching directory /usr/share/man/en.UTF-8/man3 -- Searching directory /usr/share/man/man3 -- Searching directory /usr/share/openssl/man/man3 -- Searching section n -- Searching section 4 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4 -- Searching section 5 -- Searching directory /usr/share/man/en.UTF-8/man5 -- Searching directory /usr/share/man/man5 -- Searching section 6 -- Searching directory /usr/share/man/en.UTF-8/man6 -- Searching directory /usr/share/man/man6 -- Searching section 7 -- Searching directory /usr/share/man/en.UTF-8/man7 -- Searching directory /usr/share/man/man7 -- Searching section 9 -- Searching directory /usr/share/man/en.UTF-8/man9 -- Searching directory /usr/share/man/man9 -- Searching section l No manual entry for mplayer -- Searching for rsync -- Searching section 1 -- Searching directory /usr/share/man/en.UTF-8/man1 -- Searching directory /usr/share/man/man1 -- Searching directory /usr/share/openssl/man/man1 -- Searching section 1aout -- Searching directory /usr/share/man/en.UTF-8/man1aout -- Searching directory /usr/share/man/man1aout -- Searching section 8 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8 -- Searching section 2 -- Searching directory /usr/share/man/en.UTF-8/man2 -- Searching directory /usr/share/man/man2 -- Searching section 3 -- Searching directory /usr/share/man/en.UTF-8/man3 -- Searching directory /usr/share/man/man3 -- Searching directory /usr/share/openssl/man/man3 -- Searching section n -- Searching section 4 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4 -- Searching section 5 -- Searching directory /usr/share/man/en.UTF-8/man5 -- Searching directory /usr/share/man/man5 -- Searching section 6 -- Searching directory /usr/share/man/en.UTF-8/man6 -- Searching directory /usr/share/man/man6 -- Searching section 7 -- Searching directory /usr/share/man/en.UTF-8/man7 -- Searching directory /usr/share/man/man7 -- Searching section 9 -- Searching directory /usr/share/man/en.UTF-8/man9 -- Searching directory /usr/share/man/man9 -- Searching section l No manual entry for rsync I guess there is one more bug. $ MANPATH=$HOME/.bin/man man mplayer zcat: HOME/.bin/man/man1/mplayer.1: not in gzip format $ MANPATH=$HOME/.bin/man man -ddd mplayer -- Using architecture: amd64:amd64 -- Using pager: less -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l -- Using locale paths: en_US.UTF-8:en.UTF-8:. -- Searching for mplayer -- Searching section 1 -- Searching directory HOME/.bin/man/man1 -- Found manpage HOME/.bin/man/man1/mplayer.1 -- Skipping catpage: not found or old -- Command: /usr/bin/zcat HOME/.bin/man/man1/mplayer.1 | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | less From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 00:04:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2F341065674 for ; Thu, 19 Aug 2010 00:04:04 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB968FC14 for ; Thu, 19 Aug 2010 00:04:04 +0000 (UTC) Received: by bwz20 with SMTP id 20so1416611bwz.13 for ; Wed, 18 Aug 2010 17:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=K4zZrVVRdPxmhDyBiqjOnXhadkcw/GuRv8QvrQOVRf0=; b=DO4dHpm2WHo+XZFn3o2sL94fE7R+adn0cT0OHsPgYmMp1RBoGel5hX/FfffH/7kxsy Icv872K7rRklpeDMJYQi5VjqsWBlp8UOoEP6fLU6BsGUTkFzFnbvxia8USrYCUzTliUz iBTxcddvbH+5N2Njfk7rKEni/ptzkYfBEkdgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=WkpoVKhm+Q2vmye8DtKI9i1EJoUcvKMwVU3oHntb4CsemlUxg1o20NQYVEjOqEEZ9Z d0Cwm/7ndYiP1eA5th+U6GO6YWFpYFxaVnYIXB+mTvfWjs2AWjFMMLtk+bzwVkYiwN8n fLJFA852JvEV6viIrRevSzbJll0rhW1ic41A0= Received: by 10.204.16.209 with SMTP id p17mr5913766bka.157.1282176243358; Wed, 18 Aug 2010 17:04:03 -0700 (PDT) Received: from localhost ([78.142.140.194]) by mx.google.com with ESMTPS id f10sm602720bkl.17.2010.08.18.17.04.00 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 17:04:02 -0700 (PDT) From: Anonymous To: Gordon Tetlow References: <86sk2b79oi.fsf@gmail.com> Date: Thu, 19 Aug 2010 04:03:55 +0400 In-Reply-To: <86sk2b79oi.fsf@gmail.com> (Anonymous's message of "Thu, 19 Aug 2010 04:01:01 +0400") Message-ID: <86lj8379jo.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:04:05 -0000 Anonymous writes: > Gordon Tetlow writes: > >> I've tried to make this mirror the functionality, directory search order, >> and arguments as the current base implementation. >> >> This brings me to my next point. I need some testers willing to try this >> out. It would be particularly great if I could get some foreign language >> testers with localized manpage installations. If something doesn't work the >> way you expect, please contact me and I can help debug it (using man -ddd >> will generally give me the debug information I need). > > It doesn't search in bin/../man nor in bin/.man. ^^^^^^^^ Oops, I meant bin/man there. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 00:04:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4404106567A for ; Thu, 19 Aug 2010 00:04:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 919CE8FC14 for ; Thu, 19 Aug 2010 00:04:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAM4RbEyDaFvO/2dsb2JhbACDGJ4wrkySIIEigyJzBIlt X-IronPort-AV: E=Sophos;i="4.56,230,1280721600"; d="scan'208";a="90991500" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 18 Aug 2010 20:04:52 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 94AF4B3F0A; Wed, 18 Aug 2010 20:04:54 -0400 (EDT) Date: Wed, 18 Aug 2010 20:04:54 -0400 (EDT) From: Rick Macklem To: pluknet Message-ID: <699547258.794609.1282176294566.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [137.207.32.112] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (zclient/6.0.7_GA_2476.RHEL4) Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:04:55 -0000 > On 18 August 2010 12:07, pluknet wrote: > > On 17 August 2010 20:04, Kostik Belousov wrote: > > > >> > >> Also please take a note of the John' suggestion to use the taskqueue. > > > > I decided to go this road. Thank you both. > > Now I do nfs buildkernel survive and prepare some benchmark results. > > > I'm away from home, so I can only do email and haven't looked at the patch, but I think you might want to consider avoiding the malloc() failure by calling malloc(... M_WAITOK); before grabbing the mutex. Then, set the pointer to NULL if you use it and free it at the end (I tend to test for non-NULL before calling free(), but others have pointed out that this isn't necessary.) I believe this is called "Dykstra's technique", although I used it a lot before I found out it had been published. I think handling the case where malloc() fails correctly could be difficult which is why I suggested the above. Good luck with the patch, rick From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 00:40:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48A6810656AA; Thu, 19 Aug 2010 00:40:54 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD6D8FC0A; Thu, 19 Aug 2010 00:40:53 +0000 (UTC) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 2015A12543B; Thu, 19 Aug 2010 09:23:35 +0900 (JST) Message-ID: <4C6C797C.5000409@ongs.co.jp> Date: Thu, 19 Aug 2010 09:23:24 +0900 From: Daichi GOTO User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100724 Thunderbird/3.0.6 MIME-Version: 1.0 To: ed@80386.nl, freebsd-current@freebsd.org, freebsd-fs@freebsd.org, ozawa@ongs.co.jp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: unionfs a little improvement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 00:40:54 -0000 Hi Ed and unionfs fan gyus. Ed pointed out a contradict behavior between current unionfs implementation and its manual, and sent me a patch. Thanks Ed ;) ---- Index: sys/fs/unionfs/union_vfsops.c =================================================================== --- sys/fs/unionfs/union_vfsops.c (revision 211093) +++ sys/fs/unionfs/union_vfsops.c (working copy) @@ -89,7 +89,6 @@ u_short ufile; unionfs_copymode copymode; unionfs_whitemode whitemode; - struct componentname fakecn; struct nameidata nd, *ndp; struct vattr va; @@ -280,26 +279,6 @@ mp->mnt_flag |= ump->um_uppervp->v_mount->mnt_flag & MNT_RDONLY; /* - * Check whiteout - */ - if ((mp->mnt_flag & MNT_RDONLY) == 0) { - memset(&fakecn, 0, sizeof(fakecn)); - fakecn.cn_nameiop = LOOKUP; - fakecn.cn_thread = td; - error = VOP_WHITEOUT(ump->um_uppervp, &fakecn, LOOKUP); - if (error) { - if (below) { - VOP_UNLOCK(ump->um_uppervp, 0); - vrele(upperrootvp); - } else - vput(ump->um_uppervp); - free(ump, M_UNIONFSMNT); - mp->mnt_data = NULL; - return (error); - } - } - - /* * Unlock the node */ VOP_UNLOCK(ump->um_uppervp, 0); ---- Ed's message here: ---- Just for fun I was hacking on a writable bootcd, using unionfs and tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents unionfs from mounting tmpfs on top. I do want to be able to use tmpfs, even if it means we can't get any whiteouts. The manpage says the following: Without whiteout support from the file system backing the upper layer, there is no way that delete and rename operations on lower layer objects can be done. EROFS is returned for this kind of operations along with any others which would make modifications to the lower layer, such as chmod(1). This seems to contradict the current behaviour, which is to deny the mount altogether. The attached patch makes it work, but instead of EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT(). ---- It looks like reasonable and patch is simple and effective I guess. If you unionfs guys or fs guys have some ideas around this patch, please teach me. After some tests and a couple of weeks after, I'll commit ed's patch if there is no objections. -- Daichi GOTO CEO | ONGS Inc. 81-42-316-7945 | daichi@ongs.co.jp | http://www.ongs.co.jp LinkedIn: http://linkedin.com/in/daichigoto From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 01:09:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32AAB1065695 for ; Thu, 19 Aug 2010 01:09:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id CF5218FC13 for ; Thu, 19 Aug 2010 01:08:59 +0000 (UTC) Received: by qyk8 with SMTP id 8so727801qyk.13 for ; Wed, 18 Aug 2010 18:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=2YA9ebtLifCp1B7Ag1VTqfTxjs5+CtJ+R+zOhvDb/C8=; b=K6MTbivVE29oODGJkAyx7osgOj6ElUWSPP3fMFn4jifAQyc3M3P1hRBcqzqFO7UDY2 vZSn5cNi5Dg9Pm/+5cswjyMtzXvsSbd//aqaFYm3rEW3fJbafrUffVrv7zjzZec81O+o 2EzZ1tgc/f6fEgPw8Bk2nRz5kJZ1OWy8zgd08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=lFAZGSHGvGVHj1mYpHEhgTQ+3D61fpbcdm+G3s4KXLdIgwGkyjoNe+YV1gwBycbSma 1QSXFAkSLqQzqvOPay3zVnfGF4dG5tS6BJz2hvAodLtU0Xt1px2CWkzy9RGQWc5lCoAi yd8zXfSVVkt+yCnQxhwQ6U8ForCIrh/4+ross= Received: by 10.224.37.19 with SMTP id v19mr6001082qad.15.1282180138942; Wed, 18 Aug 2010 18:08:58 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-84-182.dsl.klmzmi.sbcglobal.net [99.190.84.182]) by mx.google.com with ESMTPS id t4sm1022172qcs.28.2010.08.18.18.08.57 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 18:08:58 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C6C8428.70508@DataIX.net> Date: Wed, 18 Aug 2010 21:08:56 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Andriy Gapon References: <4C6B987F.5050703@kernel32.de> <4C6BF9B0.9070900@icyb.net.ua> <4C6C2F7A.5060908@kernel32.de> <4C6C38A3.7080900@icyb.net.ua> In-Reply-To: <4C6C38A3.7080900@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marian Hettwer Subject: Re: 8.1-release + zfs v15 df(1) hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 01:09:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2010 15:46, Andriy Gapon wrote: > on 18/08/2010 22:07 Marian Hettwer said the following: >> I'll try and reproduce that tomorrow. I would say, a hanging nfs mount >> shouldn't lead to a hanging around df(1). > > See df -n. > Going with this & making an addition. I usually add this to my periodic.conf: daily_status_disks_df_flags="-h -i -t ufs,zfs" Adding '-c' for a system that has ZFS produces results that are not correct for a total, but stating it more for reference. It might make sense to patch df(1) so it looks at the begging portion of the file-system up to the first '/' and get the value for free and used from that but this is tricky when refreserved, quota and other properties come into play and is a little beyond what df is meant for. But that subject is for another thread. I do wonder if it would make sense to just split the daily_status_disks* into daily_status_{FILESYSTEM} to look like this daily_status_ufs_df_flags etc... and keep daily_status_disks_df to be defined as daily_status_disks_df="ufs zfs xfs" Ignore random babbling meant to spur thought. ;) Regards, - -- jhell,v -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMbIQnAAoJEJBXh4mJ2FR+1lkH/3UbwkUE0L7AbivsIc1bjZA6 R+6lVv80xquXrgxZiMZWAhd40fqaduztM9hWzicL2yEVIsg+lp1WE4IRo2pyUdFs ZTDsa3RcDpXeTt2NmUdMHefd0RC0aRrrAmf1JGifUs2/UNHpT/5PP1fIl783P71J z8VFNcGcCmCSUcSdg8I14LDoFAqfbA0DkpTDyYrQVcHmNEp7aBgvJBNF+9/3y4R9 wC6+CbPVy93L3yOmxIfEM88oHtq4zfMRLcNreMAx+bQntzM7bA2xJrXV8Zkt5Jok RFqE7TScKyE89YulkosSFMs1OK0SwTFDHZdAIO4mM4V9mVcaaZ8iWTiGrlZRxoQ= =Kf91 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 02:27:59 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358FA106566B; Thu, 19 Aug 2010 02:27:59 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id A571C8FC0C; Thu, 19 Aug 2010 02:27:58 +0000 (UTC) Received: from alph.d.allbsd.org (p2176-ipbf406funabasi.chiba.ocn.ne.jp [124.86.72.176]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o7J2Rfl5080723; Thu, 19 Aug 2010 11:27:51 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o7J2RflA048064; Thu, 19 Aug 2010 11:27:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 19 Aug 2010 11:27:35 +0900 (JST) Message-Id: <20100819.112735.93156596.hrs@allbsd.org> To: gordon@FreeBSD.org From: Hiroki Sato In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Aug_19_11_27_35_2010_267)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Thu, 19 Aug 2010 11:27:54 +0900 (JST) X-Spam-Status: No, score=-99.2 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 02:27:59 -0000 ----Security_Multipart(Thu_Aug_19_11_27_35_2010_267)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gordon Tetlow wrote in : go> On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow wrote: go> go> > All, go> > go> > I sat down and rewrote the man tools from a relatively old codebase to a go> > single shell script. My original motivation was to allow multiple go> > configuration files so port installations did not have to mess with go> > /etc/manpath.config (like perl for example) when needing to manipulate the go> > manpath. After looking at the existing code, I figured I could rewrite it as go> > a shell script relatively easily. go> > go> > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, go> > /usr/bin/whatis) go> > http://people.freebsd.org/~gordon/man.sh go> > go> > Features of the new code: go> > go> > 1. BSD licensed (old code is GPL). go> > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf go> > (purposefully changed the manpath.config file since it is a different go> > syntax). go> > 3. Allows ports to override the toolset used to display the manpage based go> > on language. This was done to try to merge the functionality of the go> > japanese/man port into the base system as much as possible. go> > go> > I've tried to make this mirror the functionality, directory search order, go> > and arguments as the current base implementation. go> > go> > This brings me to my next point. I need some testers willing to try this go> > out. It would be particularly great if I could get some foreign language go> > testers with localized manpage installations. If something doesn't work the go> > way you expect, please contact me and I can help debug it (using man -ddd go> > will generally give me the debug information I need). go> > go> > Thanks, go> > Gordon go> > go> go> I did some additional testing with the japanese/man-doc port and found the go> following was necessary: Great, I will test it and get back to you! -- Hiroki ----Security_Multipart(Thu_Aug_19_11_27_35_2010_267)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkxslpcACgkQTyzT2CeTzy0AvgCfZodk90pF2qn97ef00hOXZ875 KY0AoKp9P2C1pZegg6qETeJakf9ReIpc =yaht -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Aug_19_11_27_35_2010_267)---- From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 03:04:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1464106566B; Thu, 19 Aug 2010 03:04:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F190B8FC13; Thu, 19 Aug 2010 03:04:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7J34WlA089467; Wed, 18 Aug 2010 23:04:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7J34Wa4089466; Thu, 19 Aug 2010 03:04:32 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Aug 2010 03:04:32 GMT Message-Id: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 03:04:34 -0000 TB --- 2010-08-19 01:12:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-19 01:12:25 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-19 01:12:25 - cleaning the object tree TB --- 2010-08-19 01:13:00 - cvsupping the source tree TB --- 2010-08-19 01:13:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-19 01:13:18 - building world TB --- 2010-08-19 01:13:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-19 01:13:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-19 01:13:18 - TARGET=powerpc TB --- 2010-08-19 01:13:18 - TARGET_ARCH=powerpc64 TB --- 2010-08-19 01:13:18 - TZ=UTC TB --- 2010-08-19 01:13:18 - __MAKE_CONF=/dev/null TB --- 2010-08-19 01:13:18 - cd /src TB --- 2010-08-19 01:13:18 - /usr/bin/make -B buildworld >>> World build started on Thu Aug 19 01:13:21 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Aug 19 02:51:08 UTC 2010 TB --- 2010-08-19 02:51:08 - generating LINT kernel config TB --- 2010-08-19 02:51:08 - cd /src/sys/powerpc/conf TB --- 2010-08-19 02:51:08 - /usr/bin/make -B LINT TB --- 2010-08-19 02:51:08 - building LINT kernel TB --- 2010-08-19 02:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-19 02:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-19 02:51:08 - TARGET=powerpc TB --- 2010-08-19 02:51:08 - TARGET_ARCH=powerpc64 TB --- 2010-08-19 02:51:08 - TZ=UTC TB --- 2010-08-19 02:51:08 - __MAKE_CONF=/dev/null TB --- 2010-08-19 02:51:08 - cd /src TB --- 2010-08-19 02:51:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Aug 19 02:51:08 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-19 03:04:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-19 03:04:31 - ERROR: failed to build lint kernel TB --- 2010-08-19 03:04:31 - 4834.63 user 1183.45 system 6726.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 06:41:48 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8020710656AB for ; Thu, 19 Aug 2010 06:41:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA898FC1B for ; Thu, 19 Aug 2010 06:41:47 +0000 (UTC) Received: (qmail 22895 invoked by uid 399); 19 Aug 2010 06:41:47 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Aug 2010 06:41:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6CD229.1010401@FreeBSD.org> Date: Wed, 18 Aug 2010 23:41:45 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Gabor Kovesdan X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: delphij@FreeBSD.org, current@FreeBSD.org Subject: BSD grep performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 06:41:48 -0000 On 08/18/2010 10:48, Gabor Kovesdan wrote: > I've just committed a patch with the kind help of Dimitry Andric, > which gives BSD grep a huge performance boost. Agreed, as I reported earlier. > The performance is now almost comparable to GNU grep. I think you're using a very liberal definition of "comparable." http://people.freebsd.org/~dougb/grep-time-trial.sh.txt http://people.freebsd.org/~dougb/grep-time-trial-2.sh.txt ./grep-time-trial GNU grep Elapsed time: 2 seconds BSD grep Elapsed time: 15 seconds ./grep-time-trial-2 GNU grep Elapsed time: 3 seconds BSD grep Elapsed time: 11 seconds > I think with this, BSD grep may remain default if no other serious > issues come up. I'm not going to re-state my opinion here except to say it hasn't changed. Even if the performance were not an issue I think the bugs mentioned below combined with your 4-day absence should also have been considerations. However, in regards to this particular case I think it's pretty obvious that I'm either alone, or in a very non-vocal group; so c'est la vie. However, from the standpoint of committer relations I think that first stating that you would change the default, then not doing so before all of the outstanding issues were resolved is not what I would consider a good model for others to follow. FWIW, Doug > Please report if you notice something weird. > > I know about some minor issues, which aren't fixed yet. I'll be out > for 4 days as of tomorrow but when I come back I'll take care of > these:- Infinite loop when reading directory on ZFS/NFS filesystem > - Problems with context grepping From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 06:52:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B865C1065697 for ; Thu, 19 Aug 2010 06:52:41 +0000 (UTC) (envelope-from gordon.tetlow@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7C1438FC15 for ; Thu, 19 Aug 2010 06:52:41 +0000 (UTC) Received: by iwn36 with SMTP id 36so1753532iwn.13 for ; Wed, 18 Aug 2010 23:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=42ZGD+Y6uix8OvnsOvHoz3OGq7FBN3a2YuiU021J0C4=; b=G4aDffT7cGWGsf652FxNTuL0PhLqamTql0ea1lwwAQx+g49uZWeIJAWhqHs8ndf9sK ZTCzpKcb4d48ScEl+dCvX39Mw0sZ6WamxxHqCRtLUUIincaW7WssjoHXa6YVDKibHMSz +SBXB55ZSlzp9TRG5nJHRYedhy13WcVh0hzX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=FYHc3mbR6WeJst5NADiPKv7VB0Sng18XgMqA9aMhycp3o2P1rS7zEjKvInDvRjRfNX bDrFu+l56dlnPMGpTZstAP5bFBPVfUEOhHtF65hVMcAw6BWNVP5xC1je55Ctwxa86Gpl t0DOS8nicjNvM4t2o8C3u8Pzx7/ji6+YN2EVw= MIME-Version: 1.0 Received: by 10.231.32.69 with SMTP id b5mr10417665ibd.153.1282200760720; Wed, 18 Aug 2010 23:52:40 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.172.147 with HTTP; Wed, 18 Aug 2010 23:52:40 -0700 (PDT) In-Reply-To: <86sk2b79oi.fsf@gmail.com> References: <86sk2b79oi.fsf@gmail.com> Date: Wed, 18 Aug 2010 23:52:40 -0700 X-Google-Sender-Auth: tHKoT6F9zT0PAQFKpx2NyosCI4Q Message-ID: From: Gordon Tetlow To: Anonymous Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 06:52:41 -0000 On Wed, Aug 18, 2010 at 5:01 PM, Anonymous wrote: > Gordon Tetlow writes: > > It doesn't search in bin/../man nor in bin/.man. For example, > my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config > is default one and contains /usr/local/man which does not exist here. > Guess I missed that pretty badly in my port. I'll go back and retool the logic for this but that'll take a bit of time. I guess there is one more bug. > > $ MANPATH=$HOME/.bin/man man mplayer > zcat: HOME/.bin/man/man1/mplayer.1: not in gzip format > $ MANPATH=$HOME/.bin/man man -ddd mplayer > -- Using architecture: amd64:amd64 > -- Using pager: less > -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l > -- Using locale paths: en_US.UTF-8:en.UTF-8:. > -- Searching for mplayer > -- Searching section 1 > -- Searching directory HOME/.bin/man/man1 > -- Found manpage HOME/.bin/man/man1/mplayer.1 > -- Skipping catpage: not found or old > -- Command: /usr/bin/zcat HOME/.bin/man/man1/mplayer.1 | /usr/bin/tbl > | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | less > Fixed. Switched to using zcat -f which works on both compressed and uncompressed files. (Yay for being lazy!) Thanks for the report! Gordon From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 07:01:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 071221065675; Thu, 19 Aug 2010 07:01:39 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 807D48FC1A; Thu, 19 Aug 2010 07:01:38 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9D48F844010; Thu, 19 Aug 2010 09:01:32 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 7D8D7121D; Thu, 19 Aug 2010 09:01:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282201289; bh=bTfdyjSJASlRVuoCiqXwl6+tv7TATDAJKCG92SC/tDg=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tpo0/9BltALan4JAn8BKXEgEkpSrM2103t5PHypsqy7GeB0oJ7E3pW72/KLVSzCP0 leVwb6OjqsSEvlkO/VxJFEjQFBqBMqx76qcZOu5JNfkwxAilexXJbRs4hRv8GwNlgJ ugiOPQZ5ipuyOdCU3Jmvj8PFanHcZkxJntfYzNabXd+HYb8phRqs70CkkKSrPomiEv Lxnt350CLxu52vTzseAH1PLHThaRSswNT85JPl5MDo1bncZIosdYLY7Ic5TTroRO+I NeNgxlJMI2+t7gKNlTEXCHnvpLLQlRAClSnoB1Q+nQTgc+ocDkj3bmXKppAYUxw0uz Fuy5mKP+coXnQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J71TtV063469; Thu, 19 Aug 2010 09:01:29 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 09:01:28 +0200 Message-ID: <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> Date: Thu, 19 Aug 2010 09:01:28 +0200 From: Alexander Leidinger To: Gabor Kovesdan References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> In-Reply-To: <4C6C1EB1.5000004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9D48F844010.A3BB8 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282806096.07128@jHNj0DEEXL94bT1D83Y40g X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , Rui Paulo , "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:01:39 -0000 Quoting Gabor Kovesdan (from Wed, 18 Aug 2010 19:56:01 +0200): > Em 2010.08.18. 19:37, Rui Paulo escreveu: >> On 18 Aug 2010, at 18:18, Garrett Cooper wrote: >> >>> On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo wrote: >>>> Hi, >>>> I've been chatting with the ICC ex-users and they seem to be ok >>>> with the removal of the ICC bits from share/mk and other places. >>>> The reason is that it doesn't work and no one has volunteered to >>>> fix it for many years. This seems to indicate that the interest >>>> in ICC is low. >>>> If there's anyone against this, speak now or forever be silent. :-) >>> Later versions of icc are more gcc compliant aren't they? If so, >>> wouldn't this also be a non-issue to remove the bits, or are there >>> still some incompatibilities between gcc and icc that are worth >>> noting? >> I really don't know how compatible is the latest icc because no one >> ever updated the ports version. This is actually a hint that no one >> really uses this anymore. > IIRC, apart from the low interest, the problem was that because of > ICC's license using ICC to test this mk stuff requires a commercial > license because somehow it is considered a derivative work. It has If we wanted to ship binaries, we would have to compile them with the commercial license. > also prevented us from providing better support. In 2006, I wanted > to do some progress as part of my SoC project because that time > there was more interest. Alexander (CC'd) may comment on this. I > think he has a license for FreeBSD work but he is not allowed to > give it out to a third party. At some point I got a license (IIRC for 2-users) which could have been installed in the cluster, but this would have meant to install a license server somewhere. The license was also the only commercial license I had which would have allowed to run the amd64... ehrm... em64t version of icc. This was for icc 9.x and I have some doubts this license will work with icc 11.x. If someone would get icc 11.x up and runnig as a port (similar to what we have for outdated icc version in the ports collection), I would have a look if my contact at Intel is still working there in a position which allows him to get a commercial license for us. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The happiest time in any man's life is just after the first divorce. -- J. K. Galbraith From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 07:08:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EAF4106566B; Thu, 19 Aug 2010 07:08:33 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 25B2C8FC0A; Thu, 19 Aug 2010 07:08:32 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id A5D9F844010; Thu, 19 Aug 2010 08:49:55 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3D5CF121A; Thu, 19 Aug 2010 08:49:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282200592; bh=gJ4qzPmXXI8Qx2BjJEHMUqCjoZqkDMiydv8NwggM0t0=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Sc7lB4/uFHNhsVgq6/P8J7tebYLsqdTH8UGTlqMphTPFBEbpKyHA3DTnahl0WuC4r iZrl/I4+amEyDKl6A626zg+up5lQEIhWF+dFCnYWzFayVZLB7qeFqRhC7Tn4Y43pdX dSoCyEIVFfM7PM+FpLTx7T+5kkqW1zXa5p4Je3tOre8ZCV21rz44Q1a7/IrR/LIysV pr5+xEPPDMu9GV+7zd4cRiqcFOpHE8YbyBztWkn45qBAia9KSxKHRGUB1T5i3OjRD6 dmbH7bR4GQjKaSA6H1psW8vpx2wPhCqLbNCuS+nxQVkXlYltemAYqKCykVUoFurL1r fXZupDq4Deiow== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J6npCi060562; Thu, 19 Aug 2010 08:49:51 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 08:49:51 +0200 Message-ID: <20100819084951.17534pzw4h7ff8kk@webmail.leidinger.net> Date: Thu, 19 Aug 2010 08:49:51 +0200 From: Alexander Leidinger To: Dimitry Andric References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EDC.5000206@andric.com> In-Reply-To: <4C6C1EDC.5000206@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: A5D9F844010.A456C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282805397.60455@PSIoOQN3UvfgRNVLR9XL8Q X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , Rui Paulo , "current@freebsd.org" , Garrett Cooper Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:08:33 -0000 Quoting Dimitry Andric (from Wed, 18 Aug 2010 19:56:44 +0200): > Updating that port to icc 11.1 is probably not a trivial task, and > making sure it compiles programs properly is even trickier... :) It is not as trivial as a normal "configure;make;make install" port, but with the existing ports already having sorted out a lot of the big problems I think it is more a question of time, interest, and lack of fear for doing it (I'm available to answer questions -- as far as I remember -- regarding the things being done in the old icc ports, in case someone has time, interest... and no fear). Bye, Alexander. -- Alimony is like buying oats for a dead horse. -- Arthur Baer http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 07:33:24 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A98E1065697; Thu, 19 Aug 2010 07:33:24 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 495BF8FC1A; Thu, 19 Aug 2010 07:33:24 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlzQL-0008NW-5R; Thu, 19 Aug 2010 09:20:29 +0200 Message-ID: <4C6CDB3A.1010200@continum.net> Date: Thu, 19 Aug 2010 09:20:26 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Leidinger References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> In-Reply-To: <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:33:24 -0000 Hello, Alexander Leidinger wrote: > If someone would get icc 11.x up and runnig as a port (similar to what > we have for outdated icc version in the ports collection), I would have > a look if my contact at Intel is still working there in a position which > allows him to get a commercial license for us. A while ago it was stated by MySQL AB, that their dbms performs about 20% better when compiled with icc instead of gcc. Is this (still) true? Cheers, -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 07:45:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC0810656A3 for ; Thu, 19 Aug 2010 07:45:47 +0000 (UTC) (envelope-from gordon.tetlow@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70DD68FC1A for ; Thu, 19 Aug 2010 07:45:47 +0000 (UTC) Received: by iwn36 with SMTP id 36so1802565iwn.13 for ; Thu, 19 Aug 2010 00:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=K4mbKYYUfmIxtEpZBVqBEbH1y+/zc5J1t7NOQfR4Dtw=; b=t2MILPv+lgEWfSZKdFLErXwAYZdibnQm7q22zUqkVArTjaPdJf4Ad02IrFrk6nXaTx dwPhGratZElv3kGeUOFzRf0i45zFV3+nhdHWBpcPAl5BMh4mthnIor+8K7ljwuuoE4Hj jm8oS4SewXF9VwPAtXiOWqJ/wbk9KWJOrThYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=EYER46BeEwPrTCg7+oVDqqLQZiPBIn6hqXAKCaYviOwkxxK5P/ifD+Vrtq+vZwDJ5V UtbKXwkmpGsJ4Qhih4sugth/VvVjw76Y/81+BsO4nRGaVVbtvQ/Balc/PBvj2MERJxj3 31jhHmCGAPrK2DvaqHZcpDnXJn/MiJ7NPC3J0= MIME-Version: 1.0 Received: by 10.231.183.67 with SMTP id cf3mr10169740ibb.187.1282203946177; Thu, 19 Aug 2010 00:45:46 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.172.147 with HTTP; Thu, 19 Aug 2010 00:45:46 -0700 (PDT) In-Reply-To: References: <86sk2b79oi.fsf@gmail.com> Date: Thu, 19 Aug 2010 00:45:46 -0700 X-Google-Sender-Auth: kAitxL6k-E_rxBOo0CrFQNdNjEI Message-ID: From: Gordon Tetlow To: Anonymous Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:45:47 -0000 On Wed, Aug 18, 2010 at 11:52 PM, Gordon Tetlow wrote: > On Wed, Aug 18, 2010 at 5:01 PM, Anonymous wrote: > >> Gordon Tetlow writes: >> >> It doesn't search in bin/../man nor in bin/.man. For example, >> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config >> is default one and contains /usr/local/man which does not exist here. >> > > Guess I missed that pretty badly in my port. I'll go back and retool the > logic for this but that'll take a bit of time. > Added. Latest version at http://people.freebsd.org/~gordon/man.sh It's a slightly different heuristic than the existing man implementation since I don't support the notion of MANPATH_MAP. Here's the order: Default manpaths (/usr/share/man:/usr/share/openssl/man:/usr/local/man) Parse $PATH (path/man:path/MAN:(if ending in /bin)path/../man) Parse config files Thanks! Gordon From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 08:40:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EAFC106564A; Thu, 19 Aug 2010 08:40:13 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id F099A8FC1B; Thu, 19 Aug 2010 08:40:12 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id CD9911FFC34; Thu, 19 Aug 2010 08:40:11 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A800784559; Thu, 19 Aug 2010 10:40:11 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: FreeBSD Tinderbox References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> Date: Thu, 19 Aug 2010 10:40:11 +0200 In-Reply-To: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> (FreeBSD Tinderbox's message of "Thu, 19 Aug 2010 03:04:32 GMT") Message-ID: <86occzdmhg.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: powerpc64@freebsd.org, current@freebsd.org, nwhitehorn@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:40:13 -0000 FreeBSD Tinderbox writes: >>>> Kernel build for LINT started on Thu Aug 19 02:51:08 UTC 2010 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from intege= r of different size > /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': > /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to intege= r of different size > /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to intege= r of different size > /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': > /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to intege= r of different size > /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': > /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to intege= r of different size > *** Error code 1 > > Stop in /obj/powerpc.powerpc64/src/sys/LINT. Line 705 in ofw_standard.c is return ((void *)args.baseaddr); args.baseaddr is a cell_t, which is defined in : typedef uint32_t cell_t; which I assume is correct for powerpc (32-bits), but probably not for powerpc64. Note that it is defined as uint64_t on sparc64 and sun4v, and in sys/boot as unsigned long int, which is the correct size on both 32-bit and 64-bit machines (assuming I32LP64). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 08:42:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 021F21065695; Thu, 19 Aug 2010 08:42:28 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E29A58FC0C; Thu, 19 Aug 2010 08:42:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7J8gPXU075860; Thu, 19 Aug 2010 08:42:26 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C6D5EF2.2040603@freebsd.org> Date: Thu, 19 Aug 2010 16:42:26 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Gabor Kovesdan References: <4C6505A4.9060203@FreeBSD.org> <20100814155346.GA6510@nagual.pp.ru> <4C66C0A4.3000301@FreeBSD.org> In-Reply-To: <4C66C0A4.3000301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: delphij@freebsd.org, Andrey Chernov , Doug Barton , core@freebsd.org, current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:42:28 -0000 Gabor Kovesdan wrote: > Yes, I'm sorry for my slow reaction, I got a flu some time ago and that > prevented me from fixing the bugs earlier. I have several fixes in my > working copy, which are being discussed with my mentor. Probably, today > or tomorrow they will be committed. > > Gabor > When will the grep -H print file name for me ? it is rather painful that the feature is missing. :-( So I can not use it with find: find . -exec grep -H {} world \; I don't know which file contains the word world. Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 08:49:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFCC510656CB; Thu, 19 Aug 2010 08:49:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6813C8FC18; Thu, 19 Aug 2010 08:49:21 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1F0E784401F; Thu, 19 Aug 2010 10:49:17 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id DC2251228; Thu, 19 Aug 2010 10:49:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282207754; bh=MMnpNYCh9xfNdsRwmim3DMbpeqKZ3GFo3xK0t9w3R+4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QwHwEtv6C3z32G6hMNgcfKYoMRzFUM3K31Fe4CLTUQCQ6kab3HBUzaP0A9iIUW9FY qjwl1gvkswIClqpxyXdyy4zetH3YA0RVklnt/ZU2PbBAqHVTJ39bR/RLgxD7yn37dO nIbKVuO81j+QfNScjWG3dXNukz/D+ByKXTGzqjgHy9t439b28A932PvDfgJwsPJV5t ARWzZgNwqL1m/cB2I89hiM49g/2ijRajzYs6LzaN+p5Vg1i7DvfOLuOjrttd65Z/7P bfXiERsM0OlIl+qVHTZ214DwEPPh0B6sXhnqbVseL278CnVg4CXN+M29rous8E9R+U A9mhM6XvLweiA== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J8nD9B088137; Thu, 19 Aug 2010 10:49:13 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 10:49:13 +0200 Message-ID: <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> Date: Thu, 19 Aug 2010 10:49:13 +0200 From: Alexander Leidinger To: "V. T. Mueller, Continum" References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <4C6CDB3A.1010200@continum.net> In-Reply-To: <4C6CDB3A.1010200@continum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1F0E784401F.A3B5A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282812557.69011@xA28Ox3wydp61jXod2ihPg X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:49:22 -0000 Quoting "V. T. Mueller, Continum" (from Thu, 19 Aug 2010 09:20:26 +0200): > Hello, > > Alexander Leidinger wrote: >> If someone would get icc 11.x up and runnig as a port (similar to >> what we have for outdated icc version in the ports collection), I >> would have a look if my contact at Intel is still working there in >> a position which allows him to get a commercial license for us. > > A while ago it was stated by MySQL AB, that their dbms performs > about 20% better when compiled with icc instead of gcc. Is this > (still) true? This looks overly simplified. "It runs better on CPU X with benchmark Y on Mainboard Z when you use gcc A.B.C with options D and compare it to icc E.F.G with options H." is something you can use in such cases, but it doesn't tell you if it will be the case on your machines with your workload. If you want to know if it is faster on your machines with your workload, then there is only one way to find it out: try it (be warned, due to the amount of optimization options available in gcc/icc, something like this will take a lot of time, as there are a lot of combinations to try). Bye, Alexander. -- Today is the first day of the rest of your life. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 08:53:15 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74661065679; Thu, 19 Aug 2010 08:53:15 +0000 (UTC) (envelope-from prvs=1847987112=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C36128FC1D; Thu, 19 Aug 2010 08:53:14 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 19 Aug 2010 09:42:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 19 Aug 2010 09:42:51 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011088538.msg; Thu, 19 Aug 2010 09:42:51 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1847987112=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <950D7AECAF38488A981B3045DEB1EEA3@multiplay.co.uk> From: "Steven Hartland" To: "Doug Barton" , "Gabor Kovesdan" References: <4C6CD229.1010401@FreeBSD.org> Date: Thu, 19 Aug 2010 09:42:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: BSD grep performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:53:15 -0000 Out of interest I tried the first test here add ack into the mix we I've grown to like as a developer as it uses some nice sensible defaults for every day use avoiding svn etc. Its a pure perl app so wasn't expecting it to be particularly quick in the single file case, its much quicker in the multi file case, but it seems to do quite well. ./grep-time-trial.sh GNU grep 2.5.4 Elapsed time: 2 seconds GNU grep 2.5.1-FreeBSD (base on 8.1-RELEASE) Elapsed time: 2 seconds BSD grep ( from ports 2.5.1 ) Elapsed time: 48 seconds ack 1.92 ( perl 5.8.9 ) Elapsed time: 4 seconds Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:13:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476151065697; Thu, 19 Aug 2010 09:13:23 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 02EFE8FC19; Thu, 19 Aug 2010 09:13:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id F0E8D1FFC34; Thu, 19 Aug 2010 09:13:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C8A1984559; Thu, 19 Aug 2010 11:13:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Luigi Rizzo References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100818142852.GA80221@onelab2.iet.unipi.it> Date: Thu, 19 Aug 2010 11:13:21 +0200 In-Reply-To: <20100818142852.GA80221@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Wed, 18 Aug 2010 16:28:52 +0200") Message-ID: <86k4nndky6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Ivan Voras , Andrew Reilly , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:13:23 -0000 Luigi Rizzo writes: > Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' > tool is almost as bad as having no source (in fact, it is like the > joke of supplying source for the GPL'd software in your brand new > LCD tv or appliance. I'd like to know who will ever be able to build > an updated image and upload it to the appliance) Actually, the GPL requires that you provide the source in a buildable condition (even if you only ship patches), and most mid-to-high-end AV equipment these days will load and run (or flash) software from a USB mass storage device or CD / DVD. That's certainly the case for my Sony Bravia TV (http://products.sel.sony.com/opensource/source_bivl.shtml) and my NAD Bluray player (not Linux, AFAIK). Furthermore, the GPLv3 forbids the use of GPLv3 software on devices that can't be flashed by the user (the "TiVo clause"), although the bits that are most commonly used in embedded devices (Linux itself and busybox) are still under GPLv2. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:15:21 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97F4A106566C; Thu, 19 Aug 2010 09:15:21 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 554E78FC18; Thu, 19 Aug 2010 09:15:21 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1Om1DX-0001Zi-3S; Thu, 19 Aug 2010 11:15:23 +0200 Message-ID: <4C6CF627.20205@continum.net> Date: Thu, 19 Aug 2010 11:15:19 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Leidinger References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <4C6CDB3A.1010200@continum.net> <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> In-Reply-To: <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:15:21 -0000 Alexander Leidinger wrote: >> Alexander Leidinger wrote: >>> If someone would get icc 11.x up and runnig as a port (similar to >>> what we have for outdated icc version in the ports collection), I >>> would have a look if my contact at Intel is still working there in a >>> position which allows him to get a commercial license for us. >> >> A while ago it was stated by MySQL AB, that their dbms performs about >> 20% better when compiled with icc instead of gcc. Is this (still) true? > > This looks overly simplified. "It runs better on CPU X with benchmark Y > on Mainboard Z when you use gcc A.B.C with options D and compare it to > icc E.F.G with options H." is something you can use in such cases, but > it doesn't tell you if it will be the case on your machines with your > workload. > > If you want to know if it is faster on your machines with your workload, > then there is only one way to find it out: try it (be warned, due to the > amount of optimization options available in gcc/icc, something like this > will take a lot of time, as there are a lot of combinations to try). Sounds reasonable. But doesn't that mean, that there is no need to (take the hassle to) support icc in the future? Especially while folks are being keen on abandon gcc for clang? Cheers vt -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:16:26 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D3A106566C; Thu, 19 Aug 2010 09:16:26 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5B88FC13; Thu, 19 Aug 2010 09:16:25 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 6A7681FFC34; Thu, 19 Aug 2010 09:16:24 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B479484559; Thu, 19 Aug 2010 11:16:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> Date: Thu, 19 Aug 2010 11:16:23 +0200 In-Reply-To: <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> (Alexander Leidinger's message of "Thu, 19 Aug 2010 09:01:28 +0200") Message-ID: <86fwybdkt4.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "arch@freebsd.org" , Garrett Cooper , Rui Paulo , Gabor Kovesdan , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:16:26 -0000 Alexander Leidinger writes: > If someone would get icc 11.x up and runnig as a port (similar to what > we have for outdated icc version in the ports collection), I would > have a look if my contact at Intel is still working there in a > position which allows him to get a commercial license for us. Does that really matter? We're not going to start building releases with icc, are we? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:18:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A108E10656AA; Thu, 19 Aug 2010 09:18:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF578FC16; Thu, 19 Aug 2010 09:18:48 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 896B91FFC37; Thu, 19 Aug 2010 09:18:47 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 42C7984559; Thu, 19 Aug 2010 11:18:47 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "M. Warner Losh" References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> Date: Thu, 19 Aug 2010 11:18:47 +0200 In-Reply-To: <20100818.121635.431102609571763034.imp@bsdimp.com> (M. Warner Losh's message of "Wed, 18 Aug 2010 12:16:35 -0600 (MDT)") Message-ID: <86bp8zdkp4.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: dimitry@andric.com, dougb@freebsd.org, delphij@freebsd.org, gabor@freebsd.org, current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:18:48 -0000 "M. Warner Losh" writes: > So making it default turned out well in the end. Sure, there was pain > involved (but this is current), but making it default exposed the pain > that would otherwise have gone unnoticed. The big hue and cry, while > excessive at times, did result in people actually running the > profiling tools which pointed to the buffering as the number one thing > to fix. There is a lesson here: people who are unsatisfied with the performance of ${TOOL} should profile it before they start a flamefest on -current. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:22:30 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 469831065693; Thu, 19 Aug 2010 09:22:30 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 080C78FC15; Thu, 19 Aug 2010 09:22:29 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3F6C41FFC36; Thu, 19 Aug 2010 09:22:29 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 0C2E1845D4; Thu, 19 Aug 2010 11:22:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <4C6CD229.1010401@FreeBSD.org> Date: Thu, 19 Aug 2010 11:22:28 +0200 In-Reply-To: <4C6CD229.1010401@FreeBSD.org> (Doug Barton's message of "Wed, 18 Aug 2010 23:41:45 -0700") Message-ID: <867hjndkiz.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: delphij@FreeBSD.org, Gabor Kovesdan , current@FreeBSD.org Subject: Re: BSD grep performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:22:30 -0000 Doug Barton writes: > I'm not going to re-state my opinion here except to say it hasn't > changed. Even if the performance were not an issue I think the bugs > mentioned below combined with your 4-day absence should also have been > considerations. However, in regards to this particular case I think > it's pretty obvious that I'm either alone, or in a very non-vocal > group; so c'est la vie. "This is madness!" "Madness? This... is... CURRENT!" DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:29:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25CB81065695; Thu, 19 Aug 2010 09:29:27 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B27BC8FC16; Thu, 19 Aug 2010 09:29:26 +0000 (UTC) Received: by qyk4 with SMTP id 4so1808057qyk.13 for ; Thu, 19 Aug 2010 02:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=X6rA0DmopZ7+++yjtRaibrXMrMz3wqMiJ8zfNYKwjuc=; b=YLT+h+A4OT/5u6GbiwrYZq08HGHKfX6kKd5qUVPBFk+w63i+YeWVrXgu08AIOBMgrk wC0amNPaSFexUs6vK1fOc+dMl3RJ0XyIh7nSm4jmURrE4Yg99UNqm0knuL91zudJ+Mhm Ef5gx5D6BsyIopFQM+z+4FtOfgkkKSdNuyyj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EvlRpabD6aAAhB7M7shF2jdjEuMKo2bYZ4LEWbKoJ4HBclzMaoHa6BPErYgI2zSF9m zGDs2jsoFdOL0phnbOWHpeH6bxbIep087oI/bUhkfo09oR5mmFN1jzCpAU7ZuEgvFjls 8f9GZVKtjgFKNccVzpEeqRcpZBxceMPnkZ4MY= MIME-Version: 1.0 Received: by 10.224.75.211 with SMTP id z19mr6307020qaj.185.1282210165862; Thu, 19 Aug 2010 02:29:25 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Thu, 19 Aug 2010 02:29:25 -0700 (PDT) In-Reply-To: <201008181607.52798.jhb@freebsd.org> References: <201008181607.52798.jhb@freebsd.org> Date: Thu, 19 Aug 2010 13:29:25 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: multipart/mixed; boundary=001485ebae8876b28f048e29d13d Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:29:27 -0000 --001485ebae8876b28f048e29d13d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19 August 2010 00:07, John Baldwin wrote: > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: >> On 18 August 2010 23:11, pluknet wrote: >> > On 18 August 2010 17:46, Kostik Belousov wrote: >> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: >> >>> On 18 August 2010 12:07, pluknet wrote: >> >>> > On 17 August 2010 20:04, Kostik Belousov wro= te: >> >>> > >> >>> >> >> >>> >> Also please take a note of the John' suggestion to use the taskqu= eue. >> >>> > >> >>> > I decided to go this road. Thank you both. >> >>> > Now I do nfs buildkernel survive and prepare some benchmark result= s. >> >>> > >> >>> >> >>> So, I modified the patch to defer proc_create() with taskqueue(9). >> >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=3Dyes` perf. > evaluation. >> >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both >> >>> nfs-mounted over 1Gbit LAN. >> >>> >> >>> clean old >> >>> 1137.985u 239.411s 7:42.15 298.0% =A0 =A0 =A0 6538+2133k 87+43388io = 226pf+0w >> >>> >> >>> clean new >> >>> 1134.755u 240.032s 7:41.25 298.0% =A0 =A0 =A0 6553+2133k 87+43367io = 224pf+0w >> >>> >> >>> Patch needs polishing, though it generally works. >> >>> Not sure if shep_chan (or whatever name it will get) needs locking. >> >> As I said yesterday, if several requests to create nfsiod coming one >> >> after another, you would loose all but the last. >> >> >> >> You should put the requests into the list, probably protected by >> >> nfs_iod_mtx. >> >> >> > >> > How about this patch? Still several things to ask. >> > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_= mtx > held. >> > 2) Probably busy/done gymnastics is a wrong mess. Your help is > appreciated. >> > 3) if (1) is fine, is it right to use fail: logic (i.e. set >> > NFSIOD_NOT_AVAILABLE) >> > on memory shortage? Not tested. >> > >> > There are debug printf() left intentionally to see how 3 contexts run > under load >> > to each other. I attached these messages as well if that makes sense. >> > >> >> Ah, yes. Sorry, forgot about that. > > Your task handler needs to run in a loop until the list of requests is em= pty. > If multiple threads call taskqueue_enqueue() before your task is schedule= d, > they will be consolidated down to a single call of your task handler. Thanks for your suggestions. So I converted nfs_nfsiodnew_tq() into loop, and as such I changed a cleanup SLIST_FOREACH() as well to free a bulk of (potentially consolidated) completed requests in one pass. kproc_create() is still out of the SLIST_FOREACH() to avoid calling it with nfs_iod_mtx held. > > - =A0 =A0 =A0 int error, i; > - =A0 =A0 =A0 int newiod; > + =A0 =A0 =A0 int i, newiod, error; > > You should sort these alphabetically if you are going to change this. =A0= I would > probably just leave it as-is. Err.. that's resulted after a set of changes. Thanks for noting that. > > Also, I'm not sure how this works as you don't actually wait for the task= to > complete. =A0If the taskqueue_enqueue() doesn't preempt, then you may rea= d > ni_error as zero before the kproc has actually been created and return su= ccess > even though an nfsiod hasn't been created. > I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with task handler. That was part to think about, as I didn't find such a use pat= tern. It seems though that tasks are launched now strictly one-by-one, without visible parallelism (as far as debug printf()s don't overlap anymore). --=20 wbr, pluknet --001485ebae8876b28f048e29d13d Content-Type: application/octet-stream; name="nfsiod_tq_lock.2.diff" Content-Disposition: attachment; filename="nfsiod_tq_lock.2.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gd1esq641 SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX3N1YnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmZzY2xp ZW50L25mc19zdWJzLmMJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5cy9uZnNjbGllbnQvbmZzX3N1 YnMuYwkod29ya2luZyBjb3B5KQpAQCAtNTksNiArNTksNyBAQAogI2luY2x1ZGUgPHN5cy9zeXNl bnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogI2luY2x1ZGUgPHN5cy9zeXNwcm90by5o PgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5j bHVkZSA8dm0vdm1fb2JqZWN0Lmg+CkBAIC0xMTcsNiArMTE4LDcgQEAKIAogc3RydWN0IG5mc19i dWZxCW5mc19idWZxOwogc3RhdGljIHN0cnVjdCBtdHggbmZzX3hpZF9tdHg7CitzdHJ1Y3QgdGFz awluZnNfbmZzaW9kbmV3X3Rhc2s7CiAKIC8qCiAgKiBhbmQgdGhlIHJldmVyc2UgbWFwcGluZyBm cm9tIGdlbmVyaWMgdG8gVmVyc2lvbiAyIHByb2NlZHVyZSBudW1iZXJzCkBAIC0zNTQsNiArMzU2 LDcgQEAKIAkgKi8KIAltdHhfaW5pdCgmbmZzX2lvZF9tdHgsICJORlMgaW9kIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKIAltdHhfaW5pdCgmbmZzX3hpZF9tdHgsICJORlMgeGlkIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKKwlUQVNLX0lOSVQoJm5mc19uZnNpb2RuZXdfdGFzaywgMCwgbmZzX25mc2lv ZG5ld190cSwgTlVMTCk7CiAKIAluZnNfcGJ1Zl9mcmVlY250ID0gbnN3YnVmIC8gMiArIDE7CiAK SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX25mc2lvZC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZnNj bGllbnQvbmZzX25mc2lvZC5jCShyZXZpc2lvbiAyMTEyNzkpCisrKyBzeXMvbmZzY2xpZW50L25m c19uZnNpb2QuYwkod29ya2luZyBjb3B5KQpAQCAtNTksNiArNTksNyBAQAogI2luY2x1ZGUgPHN5 cy9mY250bC5oPgogI2luY2x1ZGUgPHN5cy9sb2NrZi5oPgogI2luY2x1ZGUgPHN5cy9tdXRleC5o PgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KIAogI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4K ICNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgpAQCAtNzUsNiArNzYsMTcgQEAKIAogc3RhdGljIHZv aWQJbmZzc3ZjX2lvZCh2b2lkICopOwogCitzdHJ1Y3QgbmZzaW9kX3N0ciB7CisJU0xJU1RfRU5U UlkobmZzaW9kX3N0cikgbmlfbGlzdDsKKwlpbnQgKm5pX2luc3Q7CisJaW50IG5pX2lvZDsKKwlp bnQgbmlfZXJyb3I7CisJaW50IG5pX2J1c3k7CisJaW50IG5pX2RvbmU7Cit9Oworc3RhdGljIFNM SVNUX0hFQUQoLCBuZnNpb2Rfc3RyKSBuZnNpb2RoZWFkID0KKyAgICBTTElTVF9IRUFEX0lOSVRJ QUxJWkVSKG5mc2lvZGhlYWQpOworCiBzdGF0aWMgaW50IG5mc19hc3luY2RhZW1vbltORlNfTUFY QVNZTkNEQUVNT05dOwogCiBTWVNDVExfREVDTChfdmZzX25mcyk7CkBAIC0xNTksMTEgKzE3MSw0 MyBAQAogICAgIHNpemVvZiAobmZzX2lvZG1heCksIHN5c2N0bF9pb2RtYXgsICJJVSIsCiAgICAg Ik1heCBudW1iZXIgb2YgbmZzaW9kIGt0aHJlYWRzIik7CiAKK3ZvaWQKK25mc19uZnNpb2RuZXdf dHEoX191bnVzZWQgdm9pZCAqYXJnLCBpbnQgcGVuZGluZykKK3sKKwlzdHJ1Y3QgbmZzaW9kX3N0 ciAqbmlwOworCisJZm9yICg7OykgeworCQltdHhfbG9jaygmbmZzX2lvZF9tdHgpOworCQlTTElT VF9GT1JFQUNIKG5pcCwgJm5mc2lvZGhlYWQsIG5pX2xpc3QpIHsKKwkJCWlmIChuaXAtPm5pX2J1 c3kgPT0gMCkgeworCQkJCW5pcC0+bmlfYnVzeSA9IDE7CisJCQkJLyoKKwkJCQkgKiBTbyB3ZSBj YWxsIGtwcm9jX2NyZWF0ZSgpCisJCQkJICogYWZ0ZXIgZHJvcHBpbmcgbmZzX2lvZF9tdHggbG9j ay4KKwkJCQkgKi8KKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCQltdHhfdW5sb2NrKCZuZnNfaW9k X210eCk7CisJCS8qIENvbXBsZXRlIHRoZSB0YXNrIGlmIHRoZSBsaXN0IG9mIHJlcXVlc3RzIGlz IGVtcHR5LiAqLworCQlpZiAobmlwID09IE5VTEwpCisJCQlicmVhazsKKy8vCQlLQVNTRVJUKG5p cCAhPSBOVUxMLCAoIm5mc19uZnNpb2RuZXdfdHE6IG5pcCBpcyBOVUxMIikpOworCQlwcmludGYo InRxOiBuaXA6ICVwXG4iLCBuaXApOworCQlwcmludGYoInRxOiBuaV9pbnN0OiAlcFxuIiwgbmlw LT5uaV9pbnN0KTsKKwkJcHJpbnRmKCJ0cTogbmlfaW9kOiAlZFxuIiwgbmlwLT5uaV9pb2QpOwor CQluaXAtPm5pX2Vycm9yID0ga3Byb2NfY3JlYXRlKG5mc3N2Y19pb2QsIG5pcC0+bmlfaW5zdCwg TlVMTCwKKwkJICAgIFJGSElHSFBJRCwgMCwgIm5mc2lvZCAlZCIsIG5pcC0+bmlfaW9kKTsKKwkJ bmlwLT5uaV9kb25lID0gMTsKKwl9Cit9CisKIGludAogbmZzX25mc2lvZG5ldyhpbnQgc2V0X2lv ZHdhbnQpCiB7CiAJaW50IGVycm9yLCBpOwogCWludCBuZXdpb2Q7CisJc3RydWN0IG5mc2lvZF9z dHIgKm5pcCwgKm5pcF90ZW1wOwogCiAJaWYgKG5mc19udW1hc3luYyA+PSBuZnNfaW9kbWF4KQog CQlyZXR1cm4gKC0xKTsKQEAgLTE3OCwxNyArMjIyLDM1IEBACiAJCXJldHVybiAoLTEpOwogCWlm IChzZXRfaW9kd2FudCA+IDApCiAJCW5mc19pb2R3YW50W2ldID0gTkZTSU9EX0NSRUFURURfRk9S X05GU19BU1lOQ0lPOworCW5pcCA9IG1hbGxvYyhzaXplb2YoKm5pcCksIE1fVEVNUCwgTV9OT1dB SVQgfCBNX1pFUk8pOworCWlmIChuaXAgPT0gTlVMTCkKKwkJZ290byBmYWlsOworCW5pcC0+bmlf aW5zdCA9IG5mc19hc3luY2RhZW1vbiArIGk7CisJbmlwLT5uaV9pb2QgPSBuZXdpb2Q7CisJU0xJ U1RfSU5TRVJUX0hFQUQoJm5mc2lvZGhlYWQsIG5pcCwgbmlfbGlzdCk7CiAJbXR4X3VubG9jaygm bmZzX2lvZF9tdHgpOwotCWVycm9yID0ga3Byb2NfY3JlYXRlKG5mc3N2Y19pb2QsIG5mc19hc3lu Y2RhZW1vbiArIGksIE5VTEwsIFJGSElHSFBJRCwKLQkgICAgMCwgIm5mc2lvZCAlZCIsIG5ld2lv ZCk7CisJcHJpbnRmKCJuZXc6IG5pcDogJXBcbiIsIG5pcCk7CisJcHJpbnRmKCJuZXc6IG5pX2lu c3Q6ICVwXG4iLCBuaXAtPm5pX2luc3QpOworCXByaW50ZigibmV3OiBuaV9pb2Q6ICVkXG4iLCBu aXAtPm5pX2lvZCk7CisJdGFza3F1ZXVlX2VucXVldWUodGFza3F1ZXVlX3RocmVhZCwgJm5mc19u ZnNpb2RuZXdfdGFzayk7CisJdGFza3F1ZXVlX2RyYWluKHRhc2txdWV1ZV90aHJlYWQsICZuZnNf bmZzaW9kbmV3X3Rhc2spOwogCW10eF9sb2NrKCZuZnNfaW9kX210eCk7Ci0JaWYgKGVycm9yKSB7 Ci0JCWlmIChzZXRfaW9kd2FudCA+IDApCi0JCQluZnNfaW9kd2FudFtpXSA9IE5GU0lPRF9OT1Rf QVZBSUxBQkxFOwotCQlyZXR1cm4gKC0xKTsKKwllcnJvciA9IG5pcC0+bmlfZXJyb3I7CisJU0xJ U1RfRk9SRUFDSF9TQUZFKG5pcCwgJm5mc2lvZGhlYWQsIG5pX2xpc3QsIG5pcF90ZW1wKSB7CisJ CWlmIChuaXAtPm5pX2J1c3kgIT0gMCAmJiBuaXAtPm5pX2RvbmUgIT0gMCkgeworCQkJU0xJU1Rf UkVNT1ZFKCZuZnNpb2RoZWFkLCBuaXAsIG5mc2lvZF9zdHIsIG5pX2xpc3QpOworCQkJZnJlZShu aXAsIE1fVEVNUCk7CisvLwkJCWJyZWFrOworCQl9CiAJfQorCWlmIChlcnJvcikKKwkJZ290byBm YWlsOwogCW5mc19udW1hc3luYysrOwogCXJldHVybiAobmV3aW9kKTsKK2ZhaWw6CisJaWYgKHNl dF9pb2R3YW50ID4gMCkKKwkJbmZzX2lvZHdhbnRbaV0gPSBORlNJT0RfTk9UX0FWQUlMQUJMRTsK KwlyZXR1cm4gKC0xKTsKIH0KIAogc3RhdGljIHZvaWQKQEAgLTIzMSw2ICsyOTMsOCBAQAogCiAJ bXR4X2xvY2soJm5mc19pb2RfbXR4KTsKIAlteWlvZCA9IChpbnQgKilpbnN0YW5jZSAtIG5mc19h c3luY2RhZW1vbjsKKwlwcmludGYoImluc3RhbmNlOiAlcFxuIiwgaW5zdGFuY2UpOworCXByaW50 ZigibXlpb2Q6ICVkXG4iLCBteWlvZCk7CiAJLyoKIAkgKiBNYWluIGxvb3AKIAkgKi8KSW5kZXg6 IHN5cy9uZnNjbGllbnQvbmZzLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25mc2NsaWVudC9uZnMuaAko cmV2aXNpb24gMjExMjc5KQorKysgc3lzL25mc2NsaWVudC9uZnMuaAkod29ya2luZyBjb3B5KQpA QCAtMTI1LDYgKzEyNSw3IEBACiAKIGV4dGVybiBzdHJ1Y3QgbmZzc3RhdHMgbmZzc3RhdHM7CiBl eHRlcm4gc3RydWN0IG10eCBuZnNfaW9kX210eDsKK2V4dGVybiBzdHJ1Y3QgdGFzayBuZnNfbmZz aW9kbmV3X3Rhc2s7CiAKIGV4dGVybiBpbnQgbmZzX251bWFzeW5jOwogZXh0ZXJuIHVuc2lnbmVk IGludCBuZnNfaW9kbWF4OwpAQCAtMjUzLDYgKzI1NCw3IEBACiAJICAgIHN0cnVjdCB1Y3JlZCAq Y3JlZCwgc3RydWN0IHRocmVhZCAqdGQpOwogaW50CW5mc19yZWFkZGlycnBjKHN0cnVjdCB2bm9k ZSAqLCBzdHJ1Y3QgdWlvICosIHN0cnVjdCB1Y3JlZCAqKTsKIGludAluZnNfbmZzaW9kbmV3KGlu dCk7Cit2b2lkCW5mc19uZnNpb2RuZXdfdHEoX191bnVzZWQgdm9pZCAqLCBpbnQpOwogaW50CW5m c19hc3luY2lvKHN0cnVjdCBuZnNtb3VudCAqLCBzdHJ1Y3QgYnVmICosIHN0cnVjdCB1Y3JlZCAq LCBzdHJ1Y3QgdGhyZWFkICopOwogaW50CW5mc19kb2lvKHN0cnVjdCB2bm9kZSAqLCBzdHJ1Y3Qg YnVmICosIHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3QgdGhyZWFkICopOwogdm9pZAluZnNfZG9pb19k aXJlY3R3cml0ZSAoc3RydWN0IGJ1ZiAqKTsK --001485ebae8876b28f048e29d13d-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:32:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42D0B1065674 for ; Thu, 19 Aug 2010 09:32:16 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE5498FC21 for ; Thu, 19 Aug 2010 09:32:15 +0000 (UTC) Received: by qwg5 with SMTP id 5so1688655qwg.13 for ; Thu, 19 Aug 2010 02:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YPZU7k1gyB0vg7BFPBRHUL8YRH1m0QohJjIc1mw+0QI=; b=VMJfsOyFQDTVYjTxIQnKCKLlFK0ghjcYkjWBNACGVz9MShFUNjcL41HyNgc0R2l63C wVtvoReqfwijZpuMC1xfbBLw+KVKeGTVDJEch8MZcmv42fnI6YjEIm+m2SrjI5LqtNz6 D92jWLGkiOa2OPU2DIZYAcHmRAjkE9O24mNok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QykA8GoRLscm6YUt7PJRfu/WlMKoZr/pZoF6m9BlJ0NivjLjVPlfPS487CKWSR9/px /DwY4MQiy5btmdwos4Yw3n3/becOk6mxMCtme7HCkuKL7oj4D8EBdkE4usOKc2l3FmLm znFAjREdocw0RfkC2dRVDUau/6P3AWSvWLjC4= MIME-Version: 1.0 Received: by 10.229.231.3 with SMTP id jo3mr6978025qcb.21.1282210335168; Thu, 19 Aug 2010 02:32:15 -0700 (PDT) Received: by 10.229.31.12 with HTTP; Thu, 19 Aug 2010 02:32:15 -0700 (PDT) In-Reply-To: <699547258.794609.1282176294566.JavaMail.root@erie.cs.uoguelph.ca> References: <699547258.794609.1282176294566.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 19 Aug 2010 13:32:15 +0400 Message-ID: From: pluknet To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:32:16 -0000 On 19 August 2010 04:04, Rick Macklem wrote: >> On 18 August 2010 12:07, pluknet wrote: >> > On 17 August 2010 20:04, Kostik Belousov wrote: >> > >> >> >> >> Also please take a note of the John' suggestion to use the taskqueue. >> > >> > I decided to go this road. Thank you both. >> > Now I do nfs buildkernel survive and prepare some benchmark results. >> > >> > I'm away from home, so I can only do email and haven't looked at the > patch, but I think you might want to consider avoiding the malloc() > failure by calling malloc(... M_WAITOK); before grabbing the mutex. > Then, set the pointer to NULL if you use it and free it at the end > (I tend to test for non-NULL before calling free(), but others have > pointed out that this isn't necessary.) > > I believe this is called "Dykstra's technique", although I used it > a lot before I found out it had been published. > > I think handling the case where malloc() fails correctly could > be difficult which is why I suggested the above. > > Good luck with the patch, rick Nice :) I need to step back and get a timeout to re-think how to use this technique. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:35:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C721F1065674; Thu, 19 Aug 2010 09:35:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 537D98FC08; Thu, 19 Aug 2010 09:35:56 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9363E84401F; Thu, 19 Aug 2010 11:35:52 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 535E0131D; Thu, 19 Aug 2010 11:35:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282210549; bh=5matR11KF5ijYIveF2wYUB1SdB6xXYhJZOuJA6YgYS0=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U2pSnT4QQtsv8TRNBvfX+lCNbH1mgsvBF3S2LZpWHBOXnoAyhMPDfwcal8Gx3D8+Q Q8zQYMPuJJnv+AO01sjqiEjORFyX9CqN45xzRwqnVsu+Mz+XdEdlPVJx8CX/VY+L6R kvWm0EODBPeF4FolDSwM0GBWgo8r8g2JADZ2QJ24tJAHU5H+YguXFF3E+kEFCjDgW+ DDflFaRqM5P7cpvQQszsTHa7Enp0mZO7rrV5sQWfSYYgii7kC+oOUVKFG1HxCtstg/ 7NxM/PzxYUZ1NPCSf+WDEe9Cc+7/f+VTvLTXZ+5xpjNPrkI2t04v7PWfWDBv2QzTV7 i+Nmj3DxY4u1A== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J9ZmPJ098964; Thu, 19 Aug 2010 11:35:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 11:35:48 +0200 Message-ID: <20100819113548.72614imi2zxx9log@webmail.leidinger.net> Date: Thu, 19 Aug 2010 11:35:48 +0200 From: Alexander Leidinger To: Dag-Erling =?utf-8?b?U23Dg8K4cmdyYXY=?= References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> In-Reply-To: <86fwybdkt4.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9363E84401F.A3A09 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282815354.46504@TNcdKCGoqAeBzYWNaCCDwA X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , Garrett Cooper , Rui Paulo , Gabor Kovesdan , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:35:56 -0000 Quoting Dag-Erling Sm=C3=83=C2=B8rgrav (from Thu, 19 Aug 2010 = =20 11:16:23 +0200): > Alexander Leidinger writes: >> If someone would get icc 11.x up and runnig as a port (similar to what >> we have for outdated icc version in the ports collection), I would >> have a look if my contact at Intel is still working there in a >> position which allows him to get a commercial license for us. > > Does that really matter? We're not going to start building releases > with icc, are we? It could matter for ports, I do not know if it matters for parts in =20 src. The commercial license is also the only way that we could get icc =20 installed on machines in the FreeBSD cluster (if there's interest to =20 have another compiler *for FreeBSD development* to check the source =20 against... the warnng and error messages are better that those of gcc, =20 I do not know how they compare to clang). Bye, Alexander. --=20 Fry: I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 09:39:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B29C11065674; Thu, 19 Aug 2010 09:39:45 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 469398FC1D; Thu, 19 Aug 2010 09:39:45 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B444.dip.t-dialin.net [87.179.180.68]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D177984401F; Thu, 19 Aug 2010 11:39:41 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id AF17E131E; Thu, 19 Aug 2010 11:39:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282210778; bh=+vTgaJp4xziEB4bSjiyQwO6hmT1R/+y5IEOY7cU0Va4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pm0GZ4Q+vMAYdVP759J1faQGjoRwf4E/+V3KvmlnHaZc/VvzjuMPqVlxhZYI+T8xI +Ci/yiUxJe2kgCXSc2rZRelM+FLodb2vUda0lNamphqrwt27bN/o3Rs+IImdxWuLYb PNGneRVxfGX4fBU+ElGarZK7y99Ot+8O4TKHQ1QufpNVfq2ve1baaVT0HWLanVPood 7+fLg9/uy+3FEsnsRcI6+PM2rsNHxNGgR6yuZnpjd+EfkRz9ys++ZigjeIq9ozY0WL WyL6j8w+zbPTYNtQ8Koohejlfk3QuyvDEfvvRvTp2SisbGcN10FjfB/bI8Z6Nk6iWx Cb/xtjpoJV8OQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7J9dc8B099808; Thu, 19 Aug 2010 11:39:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 19 Aug 2010 11:39:38 +0200 Message-ID: <20100819113938.374618ltvdhg0nok@webmail.leidinger.net> Date: Thu, 19 Aug 2010 11:39:38 +0200 From: Alexander Leidinger To: "V. T. Mueller, Continum" References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <4C6CDB3A.1010200@continum.net> <20100819104913.19722klqtkcfy2gw@webmail.leidinger.net> <4C6CF627.20205@continum.net> In-Reply-To: <4C6CF627.20205@continum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: D177984401F.A4592 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282815583.37408@LyvHyYbHlLrYG0ujARWH8g X-EBL-Spam-Status: No Cc: "arch@freebsd.org" , "current@freebsd.org" Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:39:45 -0000 Quoting "V. T. Mueller, Continum" (from Thu, 19 Aug 2010 11:15:19 +0200): > Alexander Leidinger wrote: >>> Alexander Leidinger wrote: >>>> If someone would get icc 11.x up and runnig as a port (similar to >>>> what we have for outdated icc version in the ports collection), I >>>> would have a look if my contact at Intel is still working there >>>> in a position which allows him to get a commercial license for us. >>> >>> A while ago it was stated by MySQL AB, that their dbms performs >>> about 20% better when compiled with icc instead of gcc. Is this >>> (still) true? >> >> This looks overly simplified. "It runs better on CPU X with >> benchmark Y on Mainboard Z when you use gcc A.B.C with options D >> and compare it to icc E.F.G with options H." is something you can >> use in such cases, but it doesn't tell you if it will be the case >> on your machines with your workload. >> >> If you want to know if it is faster on your machines with your >> workload, then there is only one way to find it out: try it (be >> warned, due to the amount of optimization options available in >> gcc/icc, something like this will take a lot of time, as there are >> a lot of combinations to try). > > Sounds reasonable. But doesn't that mean, that there is no need to > (take the hassle to) support icc in the future? Especially while > folks are being keen on abandon gcc for clang? It may matter in the HPC community where optimization to a specific CPU matters (it doesn't matter that much for MySQL). There it does not matter much to have the kernel compiled with icc, but a icc port would be handy for them. Bye, Alexander. -- I hold it, that a little rebellion, now and then, is a good thing... -- Thomas Jefferson http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 10:01:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E6A8106566B for ; Thu, 19 Aug 2010 10:01:42 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id C86358FC1E for ; Thu, 19 Aug 2010 10:01:41 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id 1B55E6B1AD7; Thu, 19 Aug 2010 14:00:19 +0400 (MSD) Received: from [92.241.160.200] (unknown [92.241.160.200]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id 5FC1F2848C; Thu, 19 Aug 2010 14:01:38 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <4C6BFC93.4040303@icyb.net.ua> Date: Thu, 19 Aug 2010 14:01:35 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <434A73A4-E2F4-4FC6-A7E4-8A4D514AF6D5@lexasoft.ru> <4C6BFC93.4040303@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, Alexey Tarasov Subject: Re: STABLE kernel panic: privileged instruction fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:01:42 -0000 Hello Andriy! On Aug 18, 2010, at 7:30 PM, Andriy Gapon wrote: > on 13/08/2010 00:45 Alexey Tarasov said the following: >> Fatal trap 1: privileged instruction fault while in kernel mode >> cpuid =3D 1; apic id =3D 01 >> instruction pointer =3D 0x20:0xffffff8040d2cc83 >> stack pointer =3D 0x28:0xffffff8040d2ca80 >> frame pointer =3D 0x28:0xffffff0060c0b740 >=20 > I suspect that either stack is corrupted or non-code is executed (or = both). > Stack pointer seems to be too close to instruction pointer and too far = from frame > pointer. >=20 > Can you try to use kgdb and disassemble code (or examine data) near = instruction > pointer address and also near frame pointer address? > Also, you might want to rebuild kgdb with a recent change from head, = so that it > better maps symbols and addresses in kernel modules. We have the similar discussion with Kostik Belousov here: = http://lists.freebsd.org/pipermail/freebsd-stable/2010-August/058287.html I'm installing new kernel with DDB on the servers now and waiting for = the panic. Thank you for your reply! -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(") From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 10:32:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4806610656A3; Thu, 19 Aug 2010 10:32:25 +0000 (UTC) Date: Thu, 19 Aug 2010 10:32:25 +0000 From: Alexander Best To: Gordon Tetlow Message-ID: <20100819103225.GA28703@freebsd.org> References: <20100818162523.GA14196@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100818162523.GA14196@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: CFR: Replace man/manpath/whatis/apropos with a shell script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:32:25 -0000 On Wed Aug 18 10, Alexander Best wrote: > On Wed Aug 18 10, Gordon Tetlow wrote: > > All, > > > > I sat down and rewrote the man tools from a relatively old codebase to a > > single shell script. My original motivation was to allow multiple > > configuration files so port installations did not have to mess with > > /etc/manpath.config (like perl for example) when needing to manipulate the > > manpath. After looking at the existing code, I figured I could rewrite it as > > a shell script relatively easily. > > > > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, > > /usr/bin/whatis) > > http://people.freebsd.org/~gordon/man.sh > > wow! that's great. thanks a lot. :) > > could you have a look at gnu/4419? although your script seems to fix this issue > partially, when *.[0-9] and *[0-9].gz manuals exist it will choose the > uncompressed file and complain with "not in gzip format". this seems to have been fixed by switching to `zcat -f`. thanks a lot. :) i guess gnu/4419 can be closed once your script enters the tree. cheers. alex > > it would be nice if your script would prefer compressed over uncompressed > manuals. > > however i'm not sure if a different approach might be better. people with more > in depth knowledge might want to comment on this. > > cheers. > alex > > > > > Features of the new code: > > > > 1. BSD licensed (old code is GPL). > > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf > > (purposefully changed the manpath.config file since it is a different > > syntax). > > 3. Allows ports to override the toolset used to display the manpage based on > > language. This was done to try to merge the functionality of the > > japanese/man port into the base system as much as possible. > > > > I've tried to make this mirror the functionality, directory search order, > > and arguments as the current base implementation. > > > > This brings me to my next point. I need some testers willing to try this > > out. It would be particularly great if I could get some foreign language > > testers with localized manpage installations. If something doesn't work the > > way you expect, please contact me and I can help debug it (using man -ddd > > will generally give me the debug information I need). > > > > Thanks, > > Gordon > > -- > a13x -- a13x From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 10:33:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C496A106567A; Thu, 19 Aug 2010 10:33:47 +0000 (UTC) (envelope-from stein@wopr.ife.no) Received: from wopr.ife.no (wopr.ife.no [128.39.4.3]) by mx1.freebsd.org (Postfix) with ESMTP id EBD8B8FC17; Thu, 19 Aug 2010 10:33:46 +0000 (UTC) Received: from rikers.ife.no (rikers.ife.no [128.39.229.243]) by wopr.ife.no (8.9.3/8.9.3) with ESMTP id LAA25865; Thu, 19 Aug 2010 11:57:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stein Morten Sandbech In-Reply-To: <20100819092939.8824410657B8@hub.freebsd.org> Date: Thu, 19 Aug 2010 11:57:47 +0200 Content-Transfer-Encoding: 7bit Message-Id: <29BC1E84-9C05-4021-B8B9-E78825BEC571@wopr.ife.no> References: <20100819092939.8824410657B8@hub.freebsd.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1081) Cc: davidxu@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Stein. Sandbech" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:33:47 -0000 Hi, GNU grep is OK. However standard BSD grep also work: find . -exec grep -i world {} /dev/null \; or even: find . -exec grep -in world {} /dev/null \; if you want linenumbers ... hth Stein Morten On Aug 19, 2010, at 11:29, freebsd-current-request@freebsd.org wrote: > Date: Thu, 19 Aug 2010 16:42:26 +0000 > From: David Xu > Subject: Re: Official request: Please make GNU grep the default > To: Gabor Kovesdan > Cc: delphij@freebsd.org, Andrey Chernov , Doug > Barton , core@freebsd.org, current@freebsd.org > Message-ID: <4C6D5EF2.2040603@freebsd.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Gabor Kovesdan wrote: > >> Yes, I'm sorry for my slow reaction, I got a flu some time ago and that >> prevented me from fixing the bugs earlier. I have several fixes in my >> working copy, which are being discussed with my mentor. Probably, today >> or tomorrow they will be committed. >> >> Gabor >> > > When will the grep -H print file name for me ? it is rather painful > that the feature is missing. :-( > So I can not use it with find: > > find . -exec grep -H {} world \; > I don't know which file contains the word world. > > Regards, > David Xu From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 10:47:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F77B10656A4 for ; Thu, 19 Aug 2010 10:47:26 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 31D6B8FC14 for ; Thu, 19 Aug 2010 10:47:25 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1Om2ee-0002wS-3m; Thu, 19 Aug 2010 12:47:28 +0200 Message-ID: <4C6D0BBB.90304@continum.net> Date: Thu, 19 Aug 2010 12:47:23 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> In-Reply-To: <86bp8zdkp4.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:47:26 -0000 Dag-Erling Smørgrav wrote: > There is a lesson here: people who are unsatisfied with the performance > of ${TOOL} should profile it before they start a flamefest on -current. If you're alluding to Dougs original email, I will strictly disagree. He found a performance issue which noone had seen or brought up before and gave feedback to Gabor in a constructive and distinctively polite manner. I would also second, that changing back the default immediately then would have been the better choice. That others supported Gabor in doing profiling and suggesting improvements is a fine thing, and contributes to what makes this community stand out from others. In other words: as long as there are unresolved issues, the default should be set to GNU grep. This doesn't stop anyone from improving the BSD grep we're all waiting for. It only does good to those who rely on using grep - expecting correctness and speed. My $0.02 vt -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 11:13:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF1010656A9 for ; Thu, 19 Aug 2010 11:13:40 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 40BF78FC20 for ; Thu, 19 Aug 2010 11:13:40 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3EC6D1FFC33; Thu, 19 Aug 2010 11:13:39 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1E5C684559; Thu, 19 Aug 2010 13:13:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "V. T. Mueller\, Continum" References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> Date: Thu, 19 Aug 2010 13:13:39 +0200 In-Reply-To: <4C6D0BBB.90304@continum.net> (V. T. Mueller's message of "Thu, 19 Aug 2010 12:47:23 +0200") Message-ID: <867hjmdfdo.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:13:40 -0000 "V. T. Mueller, Continum" writes: > If you're alluding to Dougs original email, I will strictly disagree. > He found a performance issue which noone had seen or brought up before > and gave feedback to Gabor in a constructive and distinctively polite > manner. It would have been far more "constructive and distinctively polite" to take ten minutes to build and run a profiling version of grep, and include the results in the OP. > I would also second, that changing back the default immediately then > would have been the better choice. No, it would only have ensured that nobody except Gabor used it. > In other words: as long as there are unresolved issues, the default > should be set to GNU grep. This doesn't stop anyone from improving the > BSD grep we're all waiting for. It only does good to those who rely on > using grep - expecting correctness and speed. Based on my 12 years of experience in this project, you are very, very wrong. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 11:33:00 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E93E010656A8 for ; Thu, 19 Aug 2010 11:33:00 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id A6B9D8FC17 for ; Thu, 19 Aug 2010 11:33:00 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1Om3Ml-0006Q9-3d; Thu, 19 Aug 2010 13:33:03 +0200 Message-ID: <4C6D166A.8080907@continum.net> Date: Thu, 19 Aug 2010 13:32:58 +0200 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> <867hjmdfdo.fsf@ds4.des.no> In-Reply-To: <867hjmdfdo.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:33:01 -0000 Dag-Erling Smørgrav wrote: >> In other words: as long as there are unresolved issues, the default >> should be set to GNU grep. This doesn't stop anyone from improving the >> BSD grep we're all waiting for. It only does good to those who rely on >> using grep - expecting correctness and speed. > > Based on my 12 years of experience in this project, you are very, very > wrong. An 'argumentation' like the above is simply a killer phrase that ends every discussion. OTOH, absence of valid argumentation doesn't necessarily mean that your statement has to be wrong. I'm always willing to learn. Since you've also tried to correct me about constructive and polite behaviour - might I suggest that you add a few words about what is right in your opinion, when telling folks they are wrong? This would add to both, I guess. Cheers vt -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 12:15:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DA921065675 for ; Thu, 19 Aug 2010 12:15:58 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7B68FC24 for ; Thu, 19 Aug 2010 12:15:58 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 412251FFC33; Thu, 19 Aug 2010 12:15:57 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1103084559; Thu, 19 Aug 2010 14:15:57 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "V. T. Mueller\, Continum" References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> <867hjmdfdo.fsf@ds4.des.no> <4C6D166A.8080907@continum.net> Date: Thu, 19 Aug 2010 14:15:56 +0200 In-Reply-To: <4C6D166A.8080907@continum.net> (V. T. Mueller's message of "Thu, 19 Aug 2010 13:32:58 +0200") Message-ID: <86pqxebxxf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 12:15:58 -0000 "V. T. Mueller, Continum" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Based on my 12 years of experience in this project, you are very, > > very wrong. > An 'argumentation' like the above is simply a killer phrase that ends > every discussion. An 'argumentation' like the above is simply a killer phrase that ends every discussion, especially when it's based on selective quoting. Here's what you left out: > I would also second, that changing back the default immediately then > would have been the better choice. No, it would only have ensured that nobody except Gabor used it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 12:57:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73F5106566B for ; Thu, 19 Aug 2010 12:57:55 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 022BC8FC1B for ; Thu, 19 Aug 2010 12:57:54 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7JB0XjR017538 for ; Thu, 19 Aug 2010 21:00:33 +1000 Received: from camelot.theinternet.com.au (d110-32-232-206.bla800.nsw.optusnet.com.au [110.32.232.206]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o7JB03td017749; Thu, 19 Aug 2010 21:00:05 +1000 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id 691D117044; Thu, 19 Aug 2010 21:00:03 +1000 (EST) Date: Thu, 19 Aug 2010 21:00:03 +1000 From: Andrew Milton To: "V. T. Mueller, Continum" Message-ID: <20100819110003.GN402@camelot.theinternet.com.au> References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6D0BBB.90304@continum.net> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 12:57:55 -0000 +-------[ V. T. Mueller, Continum ]---------------------- | | In other words: as long as there are unresolved issues, the default | should be set to GNU grep. This doesn't stop anyone from improving the | BSD grep we're all waiting for. It only does good to those who rely on | using grep - expecting correctness and speed. When did -current become -stable? -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 13:27:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74828106566B for ; Thu, 19 Aug 2010 13:27:32 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id CAAC98FC08 for ; Thu, 19 Aug 2010 13:27:31 +0000 (UTC) Received: (qmail invoked by alias); 19 Aug 2010 13:27:29 -0000 Received: from baloo.cs.uni-paderborn.de (EHLO baloo.cs.uni-paderborn.de) [131.234.21.116] by mail.gmx.net (mp013) with SMTP; 19 Aug 2010 15:27:29 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX18goVUM1LYgbVJhpiMTTpfmyGrTPWxxZuIG1gCDRA TwvuOnkjlyRN+J Received: from [127.0.0.1] by baloo.cs.uni-paderborn.de with esmtp (Exim 4.70) (envelope-from ) id L7EIPP-00068G-P6 for freebsd-current@freebsd.org; Thu, 19 Aug 2010 15:27:25 +0200 Message-ID: <4C6D313C.8000501@gmx.de> Date: Thu, 19 Aug 2010 15:27:24 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net> In-Reply-To: <20100819113548.72614imi2zxx9log@webmail.leidinger.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:27:32 -0000 Am 19.08.2010 11:35, schrieb Alexander Leidinger: > > Quoting Dag-Erling Smørgrav (from Thu, 19 Aug 2010 > 11:16:23 +0200): > >> Alexander Leidinger writes: >>> If someone would get icc 11.x up and runnig as a port (similar to what >>> we have for outdated icc version in the ports collection), I would >>> have a look if my contact at Intel is still working there in a >>> position which allows him to get a commercial license for us. >> >> Does that really matter? We're not going to start building releases >> with icc, are we? > > It could matter for ports, I do not know if it matters for parts in > src. The commercial license is also the only way that we could get icc > installed on machines in the FreeBSD cluster (if there's interest to > have another compiler *for FreeBSD development* to check the source > against... the warnng and error messages are better that those of gcc, > I do not know how they compare to clang). Clang is a mixed experience. I've used it only for C so far, and there are some code issues that it doesn't check at all yet; issues that GCC or ICC would complain about. ICC11 warnings (I've only used it on Linux for the software where I'm upstream maintainer) seem plentiful if you request remarks, too. However, clang diagnostics are easier to understand than GCCs and usually more helpful - which was a design goal. Note that devel/clang ships with a static analyzer that should now finally work, as of clang-2.7_2. It can trace call trees back and pinpoint how, for instance, your code forgets to check NULL dereference, where there are dead initializations or assignments, or similar. I found it to be a bit more solid than GCC in my use cases, but note it's advertised as work-in-progress. Details/Usage: http://clang-analyzer.llvm.org/scan-build.html -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 13:35:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F131E1065693; Thu, 19 Aug 2010 13:35:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF2F48FC24; Thu, 19 Aug 2010 13:35:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5D31046B32; Thu, 19 Aug 2010 09:35:26 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6015D8A04F; Thu, 19 Aug 2010 09:35:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 19 Aug 2010 09:22:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <4C673F02.8000805@FreeBSD.org> <4C6C4CBF.1040200@andric.com> <4C6C56A1.9050405@andric.com> In-Reply-To: <4C6C56A1.9050405@andric.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008190922.54056.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Aug 2010 09:35:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dimitry Andric , Alan Cox , current@freebsd.org, Peter Jeremy Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:35:27 -0000 On Wednesday, August 18, 2010 5:54:41 pm Dimitry Andric wrote: > On 2010-08-18 23:12, Dimitry Andric wrote: > >> And one trial is not statistically valid - especially given the small > >> differences. How about multiple multiple trials with ministat. > > > > The result were averages of three trials > > Actually, since I kept using Doug's original grep-time-trial.sh, each of > the three 'trials' consisted of running grep 100 times, and the listed > time was the total elapsed time for those 100 runs. So I assume that > will reasonably average out the differences between each individual run? You need the distribution, not just the averages so you can detect outliers and determine the standard deviation and confidence intervals. You could use ministat on a file that contained all 100 runtimes perhaps. I would use at least 10 trials though, 3 is a bit small. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 13:35:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F131E1065693; Thu, 19 Aug 2010 13:35:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF2F48FC24; Thu, 19 Aug 2010 13:35:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5D31046B32; Thu, 19 Aug 2010 09:35:26 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6015D8A04F; Thu, 19 Aug 2010 09:35:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 19 Aug 2010 09:22:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <4C673F02.8000805@FreeBSD.org> <4C6C4CBF.1040200@andric.com> <4C6C56A1.9050405@andric.com> In-Reply-To: <4C6C56A1.9050405@andric.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008190922.54056.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Aug 2010 09:35:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dimitry Andric , Alan Cox , current@freebsd.org, Peter Jeremy Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:35:27 -0000 On Wednesday, August 18, 2010 5:54:41 pm Dimitry Andric wrote: > On 2010-08-18 23:12, Dimitry Andric wrote: > >> And one trial is not statistically valid - especially given the small > >> differences. How about multiple multiple trials with ministat. > > > > The result were averages of three trials > > Actually, since I kept using Doug's original grep-time-trial.sh, each of > the three 'trials' consisted of running grep 100 times, and the listed > time was the total elapsed time for those 100 runs. So I assume that > will reasonably average out the differences between each individual run? You need the distribution, not just the averages so you can detect outliers and determine the standard deviation and confidence intervals. You could use ministat on a file that contained all 100 runtimes perhaps. I would use at least 10 trials though, 3 is a bit small. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 13:35:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63571065697 for ; Thu, 19 Aug 2010 13:35:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B27538FC18 for ; Thu, 19 Aug 2010 13:35:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3C94646B45; Thu, 19 Aug 2010 09:35:28 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 58E9B8A050; Thu, 19 Aug 2010 09:35:27 -0400 (EDT) From: John Baldwin To: pluknet Date: Thu, 19 Aug 2010 09:34:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008181607.52798.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008190934.28365.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Aug 2010 09:35:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:35:29 -0000 On Thursday, August 19, 2010 5:29:25 am pluknet wrote: > On 19 August 2010 00:07, John Baldwin wrote: > > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: > >> On 18 August 2010 23:11, pluknet wrote: > >> > On 18 August 2010 17:46, Kostik Belousov wrote: > >> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: > >> >>> On 18 August 2010 12:07, pluknet wrote: > >> >>> > On 17 August 2010 20:04, Kostik Belousov wrote: > >> >>> > > >> >>> >> > >> >>> >> Also please take a note of the John' suggestion to use the taskqueue. > >> >>> > > >> >>> > I decided to go this road. Thank you both. > >> >>> > Now I do nfs buildkernel survive and prepare some benchmark results. > >> >>> > > >> >>> > >> >>> So, I modified the patch to defer proc_create() with taskqueue(9). > >> >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. > > evaluation. > >> >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both > >> >>> nfs-mounted over 1Gbit LAN. > >> >>> > >> >>> clean old > >> >>> 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w > >> >>> > >> >>> clean new > >> >>> 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w > >> >>> > >> >>> Patch needs polishing, though it generally works. > >> >>> Not sure if shep_chan (or whatever name it will get) needs locking. > >> >> As I said yesterday, if several requests to create nfsiod coming one > >> >> after another, you would loose all but the last. > >> >> > >> >> You should put the requests into the list, probably protected by > >> >> nfs_iod_mtx. > >> >> > >> > > >> > How about this patch? Still several things to ask. > >> > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx > > held. > >> > 2) Probably busy/done gymnastics is a wrong mess. Your help is > > appreciated. > >> > 3) if (1) is fine, is it right to use fail: logic (i.e. set > >> > NFSIOD_NOT_AVAILABLE) > >> > on memory shortage? Not tested. > >> > > >> > There are debug printf() left intentionally to see how 3 contexts run > > under load > >> > to each other. I attached these messages as well if that makes sense. > >> > > >> > >> Ah, yes. Sorry, forgot about that. > > > > Your task handler needs to run in a loop until the list of requests is empty. > > If multiple threads call taskqueue_enqueue() before your task is scheduled, > > they will be consolidated down to a single call of your task handler. > > Thanks for your suggestions. > > So I converted nfs_nfsiodnew_tq() into loop, and as such > I changed a cleanup SLIST_FOREACH() as well to free a bulk of > (potentially consolidated) completed requests in one pass. > kproc_create() is still out of the SLIST_FOREACH() to avoid calling it > with nfs_iod_mtx held. > > > > > - int error, i; > > - int newiod; > > + int i, newiod, error; > > > > You should sort these alphabetically if you are going to change this. I would > > probably just leave it as-is. > > Err.. that's resulted after a set of changes. Thanks for noting that. > > > > > Also, I'm not sure how this works as you don't actually wait for the task to > > complete. If the taskqueue_enqueue() doesn't preempt, then you may read > > ni_error as zero before the kproc has actually been created and return success > > even though an nfsiod hasn't been created. > > > > I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with > task handler. That was part to think about, as I didn't find such a use pattern. > It seems though that tasks are launched now strictly one-by-one, without > visible parallelism (as far as debug printf()s don't overlap anymore). Ah, if it is safe to sleep then I have a couple of suggestions: - Use M_WAITOK to malloc() so you don't have to worry about the failure case (I see Rick already suggested this). - Use something like this in the code that schedules the task: mtx_unlock(&nfs_iod_mtx); nip = malloc(..., M_WAITOK); /* Initialize nip. */ mtx_lock(&nfs_iod_mtx); SLIST_INSERT_HEAD(...); /* Maybe use STAILQ_INSERT_TAIL() instead? */ taskqueue_enqueue(...); while (!nip->done) mtx_sleep(nip, &nfs_iod_mtx, ...); mtx_unlock(&nfs_iod_mtx); error = nip->ni_error; free(nip); /* Existing if (error), etc. code */ and something like this in the task handler: mtx_lock(&nfs_iod_mtx); while ((nip = STAILQ_FIRST(...)) != NULL) { STAILQ_REMOVE_HEAD(...); mtx_unlock(&nfs_iod_mtx); /* Create thread, setting ni_error, etc. */ mtx_lock(&nfsd_iod_mtx); wakeup(nip); } mtx_unlock(&nfs_iod_mtx); The sleep/wakeup pattern is far more common than using taskqueue_drain() for this sort of thing. Using STAILQ instead of SLIST would give you "fairer" FIFO processing btw. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 13:38:56 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3E11106564A; Thu, 19 Aug 2010 13:38:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 724238FC12; Thu, 19 Aug 2010 13:38:56 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 74D5A1FFC34; Thu, 19 Aug 2010 13:38:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 29F1784528; Thu, 19 Aug 2010 15:38:55 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gabor Kovesdan References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> Date: Thu, 19 Aug 2010 15:38:54 +0200 Message-ID: <86aaoirac1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: delphij@FreeBSD.org, Dimitry Andric , Doug Barton , core@FreeBSD.org, current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:38:56 -0000 Gabor Kovesdan writes: > I've just committed a patch with the kind help of Dimitry Andric, > which gives BSD grep a huge performance boost. The performance is now > almost comparable to GNU grep. Not quite, as Doug pointed out. I don't know what benchmark you're using, but I'm using a greatly simplified variant of Doug's: % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/usr.bin/grep/grep = -q "^xfce4-wm" /usr/ports/INDEX-9 ; done'=20 sh -c 13.57s user 7.06s system 99% cpu 20.783 total % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/gnu/usr.bin/grep/g= rep -q "^xfce4-wm" /usr/ports/INDEX-9 ; done' sh -c 7.98s user 7.47s system 100% cpu 15.424 total The bottleneck is now in quite an unexpected location: % cumulative self self total=20=20=20=20=20=20=20=20= =20=20=20 time seconds seconds calls ms/call ms/call name=20=20=20=20 38.8 0.03 0.03 12717 0.00 0.00 memchr [5] 35.6 0.07 0.03 395 0.08 0.08 _read [6] 16.4 0.08 0.01 0 100.00% _mcount [7] 1.7 0.08 0.00 12362 0.00 0.00 memset [9] 1.5 0.08 0.00 0 100.00% .mcount (110) 1.5 0.08 0.00 0 43.41% re_search_internal [8] 0.8 0.08 0.00 820 0.00 0.00 memcpy [12] 0.6 0.09 0.00 37045 0.00 0.00 free [13] 0.6 0.09 0.00 12332 0.00 0.01 grep_fgetln [4] 0.6 0.09 0.00 1 0.49 66.27 procfile [3] 0.4 0.09 0.00 0 100.00% re_string_construct_c= ommon [26] 0.3 0.09 0.00 1 0.25 0.34 _Read_RuneMagi [27] 0.1 0.09 0.00 261 0.00 0.00 arena_avail_comp [39] 0.1 0.09 0.00 155 0.00 0.00 arena_malloc [24] 0.1 0.09 0.00 153 0.00 0.00 arena_bin_malloc_easy= [40] 0.1 0.09 0.00 54 0.00 0.00 arena_avail_tree_inse= rt [35] 0.1 0.09 0.00 5 0.02 0.02 arena_purge [37] 0.1 0.09 0.00 3 0.04 0.44 setlocale [10] 0.1 0.09 0.00 1 0.12 0.46 __wrap_setrunelocale = [21] 0.1 0.09 0.00 0 21.76% re_string_destruct [1= 4] 0.1 0.09 0.00 0 100.00% regexec [38] The culprit seems to be the first memchr() in grep_fgetln(). For some reason, even with -O2, it is not inlined: % echo "disassemble grep_fgetln" | gdb -q -batch -x /dev/stdin /usr/obj/usr= /src/usr.bin/grep/grep | grep memchr 0x000000000040291e : callq 0x40176c 0x00000000004029fa : callq 0x40176c DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 14:12:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6EB01065673; Thu, 19 Aug 2010 14:12:12 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 838108FC08; Thu, 19 Aug 2010 14:12:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:18ec:2038:19e5:d1cb] (unknown [IPv6:2001:7b8:3a7:0:18ec:2038:19e5:d1cb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A8A0F5C59; Thu, 19 Aug 2010 16:12:10 +0200 (CEST) Message-ID: <4C6D3BBB.7030104@andric.com> Date: Thu, 19 Aug 2010 16:12:11 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: alc@freebsd.org References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 14:12:13 -0000 On 2010-08-17 23:24, Alan Cox wrote: >> So normal mmap is ~3% slower, and prefault mmap does not seem to make >> any measurable difference. I guess the added complexity is not really >> worth it, for now. > > Do you know what fraction of this time is being spent in the kernel? I ran 100 trials again, but now using "time -a -o logfile", so I could run ministat over the accumulated results. This gives: x gnugrep + bsdgrep-r210927 (the initial version that started this thread) * bsdgrep-r211490 (current version) % bsdgrep-r211490-mmap-plain # bsdgrep-r211490-mmap-prefault Real time: N Min Max Median Avg Stddev x 100 1.15 1.98 1.18 1.2122 0.11159613 + 100 8.57 14.26 8.79 9.1823 1.0496126 * 100 2.81 6.57 2.91 3.0189 0.4304259 % 100 2.34 4.03 2.99 3.0022 0.12635992 # 100 2.85 3.49 2.88 2.8981 0.075232904 User time: N Min Max Median Avg Stddev x 100 0 0.07 0.03 0.0239 0.015627934 + 100 1.6 3.33 1.9 1.976 0.30264824 * 100 0.29 1 0.39 0.4004 0.08696824 % 100 1.8 3.56 2.73 2.7274 0.13260117 # 100 2.78 3.04 2.81 2.8238 0.04039652 System time: N Min Max Median Avg Stddev x 100 1.08 1.91 1.15 1.1809 0.10953617 + 100 6.55 10.9 6.94 7.1905 0.77911809 * 100 2.38 5.5 2.53 2.6061 0.35068445 % 100 0.18 0.53 0.25 0.2645 0.053586049 # 100 0.03 0.54 0.06 0.0668 0.052259647 E.g. it looks like bsdgrep with 'plain' mmap performs almost the same as the regular bsdgrep (both around 3.0s average), but with mmap much more of the time is spent in user mode. And it seems prefaulting does help now! I guess it also makes sense to add madvise(..., MADV_SEQUENTIAL)? > Does > the value of "sysctl vm.pmap.pde.mappings" increase as a result of your > test? If not, there is still room for improvement in the results with > mmap(). It always stays at 0, I have never seen any other value. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 15:24:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A5A106567A; Thu, 19 Aug 2010 15:24:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA3A8FC1C; Thu, 19 Aug 2010 15:24:38 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA11039; Thu, 19 Aug 2010 18:24:37 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6D4CB4.20601@icyb.net.ua> Date: Thu, 19 Aug 2010 18:24:36 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Doug Barton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:24:40 -0000 on 12/08/2010 23:57 Doug Barton said the following: > My "runaway intr" problem with flash has been continuing all along, but > since no one has been interested in helping with it I haven't reported > it for a while. However, today, for the first time, it happened when I > had not run flash at all since I booted. > > My system: > Dell D620, C2D, i386, SMP, r210908 > > swi4: clock is the culprit again this time, but when flash triggers this > problem I sometimes see hdac as the culprit, FYI. > > > last pid: 19763; load averages: 1.05, 1.40, 1.18 up 0+01:58:20 > 13:41:19 > 129 processes: 3 running, 106 sleeping, 20 waiting > CPU 0: 20.8% user, 0.0% nice, 6.9% system, 8.5% interrupt, 63.8% idle > CPU 1: 56.9% user, 0.0% nice, 8.5% system, 1.5% interrupt, 33.1% idle > Mem: 182M Active, 1279M Inact, 187M Wired, 18M Cache, 112M Buf, 334M Free > Swap: 1024M Total, 1024M Free > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 10 root 171 ki31 0K 16K RUN 1 87:55 63.72% {idle: > cpu1} > 10 root 171 ki31 0K 16K RUN 0 88:03 60.69% {idle: > cpu0} > 1621 dougb 102 0 162M 141M select 0 14:19 29.54% Xorg > 11 root -32 - 0K 160K WAIT 0 0:33 5.76% {swi4: > clock} > 1668 dougb 97 0 36808K 20864K select 0 0:38 3.61% {initial > thread > 1692 dougb 8 0 11136K 2284K nanslp 0 2:13 2.15% wmwlmon > 19763 dougb 96 0 9912K 2076K CPU1 1 0:01 1.57% top > 17 root 96 - 0K 8K syncer 1 0:48 1.17% syncer > 1684 dougb 96 0 11020K 2108K select 1 1:10 1.12% wmbsdbatt > 1762 dougb 96 0 36284K 15540K select 0 0:04 0.39% {initial > thread > 11 root -64 - 0K 160K WAIT 0 0:03 0.15% {irq22: > uhci2} > 783 root 96 0 9684K 1232K select 0 0:21 0.10% moused > 1663 dougb 96 0 21388K 8912K select 1 0:15 0.10% openbox > 11 root -32 - 0K 160K WAIT 1 0:17 0.05% {swi4: > clock} > 1817 dougb 96 0 90820K 53672K select 0 3:23 0.00% {initial > thread > 0 root -16 0 0K 64K sched 0 0:26 0.00% {swapper} I am sorry, but I don't see anything dramatically wrong here. So "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be called "runaway intr"? A lot of CPU time is idle and a lot is used by userland processes (e.g. Xorg). Can you provide data that better illustrate your problem? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 15:34:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6FC10656C8 for ; Thu, 19 Aug 2010 15:34:29 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay012.isp.belgacom.be (mailrelay012.isp.belgacom.be [195.238.6.179]) by mx1.freebsd.org (Postfix) with ESMTP id B78188FC1B for ; Thu, 19 Aug 2010 15:34:28 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAGzqbExbsdUI/2dsb2JhbACTOY0acr4OhTcE Received: from 8.213-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.213.8]) by relay.skynet.be with ESMTP; 19 Aug 2010 17:34:26 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o7JFYPDO005211; Thu, 19 Aug 2010 17:34:26 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Thu, 19 Aug 2010 17:34:15 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <86aaoirac1.fsf@ds4.des.no> In-Reply-To: <86aaoirac1.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2110530.gFL3sNdave"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201008191734.25162.tijl@coosemans.org> Cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= , Dimitry Andric , Gabor Kovesdan Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:34:29 -0000 --nextPart2110530.gFL3sNdave Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Thursday 19 August 2010 15:38:54 Dag-Erling Sm=F8rgrav wrote: > Gabor Kovesdan writes: >> I've just committed a patch with the kind help of Dimitry Andric, >> which gives BSD grep a huge performance boost. The performance is >> now almost comparable to GNU grep. >=20 > Not quite, as Doug pointed out. I don't know what benchmark you're > using, but I'm using a greatly simplified variant of Doug's: >=20 > % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/usr.bin/grep/gre= p -q "^xfce4-wm" /usr/ports/INDEX-9 ; done' > sh -c 13.57s user 7.06s system 99% cpu 20.783 total > % time sh -c 'for n in $(jot 1000) ; do /usr/obj/usr/src/gnu/usr.bin/grep= /grep -q "^xfce4-wm" /usr/ports/INDEX-9 ; done' > sh -c 7.98s user 7.47s system 100% cpu 15.424 total >=20 > The bottleneck is now in quite an unexpected location: >=20 > % cumulative self self total =20 > time seconds seconds calls ms/call ms/call name =20 > 38.8 0.03 0.03 12717 0.00 0.00 memchr [5] > 35.6 0.07 0.03 395 0.08 0.08 _read [6] > 16.4 0.08 0.01 0 100.00% _mcount [7] > 1.7 0.08 0.00 12362 0.00 0.00 memset [9] > 1.5 0.08 0.00 0 100.00% .mcount (110) > 1.5 0.08 0.00 0 43.41% re_search_internal = [8] > 0.8 0.08 0.00 820 0.00 0.00 memcpy [12] > 0.6 0.09 0.00 37045 0.00 0.00 free [13] > 0.6 0.09 0.00 12332 0.00 0.01 grep_fgetln [4] > 0.6 0.09 0.00 1 0.49 66.27 procfile [3] > 0.4 0.09 0.00 0 100.00% re_string_construct= _common [26] > 0.3 0.09 0.00 1 0.25 0.34 _Read_RuneMagi [27] > 0.1 0.09 0.00 261 0.00 0.00 arena_avail_comp [3= 9] > 0.1 0.09 0.00 155 0.00 0.00 arena_malloc [24] > 0.1 0.09 0.00 153 0.00 0.00 arena_bin_malloc_ea= sy [40] > 0.1 0.09 0.00 54 0.00 0.00 arena_avail_tree_in= sert [35] > 0.1 0.09 0.00 5 0.02 0.02 arena_purge [37] > 0.1 0.09 0.00 3 0.04 0.44 setlocale [10] > 0.1 0.09 0.00 1 0.12 0.46 __wrap_setrunelocal= e [21] > 0.1 0.09 0.00 0 21.76% re_string_destruct = [14] > 0.1 0.09 0.00 0 100.00% regexec [38] >=20 > The culprit seems to be the first memchr() in grep_fgetln(). For some > reason, even with -O2, it is not inlined: >=20 > % echo "disassemble grep_fgetln" | gdb -q -batch -x /dev/stdin /usr/obj/u= sr/src/usr.bin/grep/grep | grep memchr > 0x000000000040291e : callq 0x40176c > 0x00000000004029fa : callq 0x40176c The base system gcc doesn't have a built-in version of memchr to inline. --nextPart2110530.gFL3sNdave Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iF4EABEIAAYFAkxtTwAACgkQfoCS2CCgtisAkwD9H+rFVCNMWWLeII5ypHPhhQ3D AxdYjKL5+cUOj5CdlNIA/3f7VpB3j7s+vDkfXEKeAWvlX6/nwe3E7tmNLquc5wLj =p7mQ -----END PGP SIGNATURE----- --nextPart2110530.gFL3sNdave-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 16:16:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA39F1065693 for ; Thu, 19 Aug 2010 16:16:58 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8FF838FC2A for ; Thu, 19 Aug 2010 16:16:58 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 3FAE62C2B58; Thu, 19 Aug 2010 10:51:40 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JXL+S8p4evpY; Thu, 19 Aug 2010 10:51:32 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 183CB2C2A81; Thu, 19 Aug 2010 10:51:32 -0500 (CDT) Message-ID: <4C6D5302.4030602@cs.rice.edu> Date: Thu, 19 Aug 2010 10:51:30 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Dimitry Andric References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> <4C6D3BBB.7030104@andric.com> In-Reply-To: <4C6D3BBB.7030104@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:16:58 -0000 Dimitry Andric wrote: > On 2010-08-17 23:24, Alan Cox wrote: > >>> So normal mmap is ~3% slower, and prefault mmap does not seem to make >>> any measurable difference. I guess the added complexity is not really >>> worth it, for now. >>> >> Do you know what fraction of this time is being spent in the kernel? >> > > I ran 100 trials again, but now using "time -a -o logfile", so I could > run ministat over the accumulated results. This gives: > > x gnugrep > + bsdgrep-r210927 (the initial version that started this thread) > * bsdgrep-r211490 (current version) > % bsdgrep-r211490-mmap-plain > # bsdgrep-r211490-mmap-prefault > > Real time: > N Min Max Median Avg Stddev > x 100 1.15 1.98 1.18 1.2122 0.11159613 > + 100 8.57 14.26 8.79 9.1823 1.0496126 > * 100 2.81 6.57 2.91 3.0189 0.4304259 > % 100 2.34 4.03 2.99 3.0022 0.12635992 > # 100 2.85 3.49 2.88 2.8981 0.075232904 > > User time: > N Min Max Median Avg Stddev > x 100 0 0.07 0.03 0.0239 0.015627934 > + 100 1.6 3.33 1.9 1.976 0.30264824 > * 100 0.29 1 0.39 0.4004 0.08696824 > % 100 1.8 3.56 2.73 2.7274 0.13260117 > # 100 2.78 3.04 2.81 2.8238 0.04039652 > > System time: > N Min Max Median Avg Stddev > x 100 1.08 1.91 1.15 1.1809 0.10953617 > + 100 6.55 10.9 6.94 7.1905 0.77911809 > * 100 2.38 5.5 2.53 2.6061 0.35068445 > % 100 0.18 0.53 0.25 0.2645 0.053586049 > # 100 0.03 0.54 0.06 0.0668 0.052259647 > > E.g. it looks like bsdgrep with 'plain' mmap performs almost the same > as the regular bsdgrep (both around 3.0s average), but with mmap much > more of the time is spent in user mode. > > That makes sense to me. With traditional I/O, such as read(2), the copyout to user space fills the processor's data cache with the data to be processed. Grep's core algorithm in user space shouldn't be experiencing cache misses to obtain the data. By and large, the cache misses will have occurred in the kernel. However, once you switch to mmap(2), the kernel never touches the data, and all cache misses occur in user space. You ought to be able to confirm this with pmcstat's sampling mode set to sample L2 cache misses. Here is what actually puzzles me about these results. With traditional I/O, even after the optimizations to bsdgrep, the system time for gnugrep is still less than half that of the optimized bsdgrep. I haven't looked at the changes, but I would have thought the system time for gnugrep and bsdgrep would be almost the same. > And it seems prefaulting does help now! I guess it also makes sense to > add madvise(..., MADV_SEQUENTIAL)? > > This won't matter as long as you are working with memory resident files. With a memory resident file, it would only be a waste of cycles. > >> Does >> the value of "sysctl vm.pmap.pde.mappings" increase as a result of your >> test? If not, there is still room for improvement in the results with >> mmap(). >> > > It always stays at 0, I have never seen any other value. > Addressing this issue would mostly affect the system time, which is already tiny for mmap-prefault, so I wouldn't be concerned about this (yet). Did you ever describe your test machine? If so, I'm sorry, but I missed that. Is it running an amd64 or i386 kernel? Can you briefly describe what kind of processor and memory it has? Regards, Alan From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 16:23:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3101B1065670; Thu, 19 Aug 2010 16:23:01 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id E803F8FC16; Thu, 19 Aug 2010 16:23:00 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 6DB43582C5; Thu, 19 Aug 2010 11:02:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 9BbJf2bveM5H; Thu, 19 Aug 2010 11:02:08 -0500 (CDT) Received: from wanderer.tachypleus.net (99-108-141-168.lightspeed.sntcca.sbcglobal.net [99.108.141.168]) by mail.icecube.wisc.edu (Postfix) with ESMTP id CF064582C4; Thu, 19 Aug 2010 11:02:07 -0500 (CDT) Message-ID: <4C6D557E.6080406@freebsd.org> Date: Thu, 19 Aug 2010 09:02:06 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100727 Thunderbird/3.0.6 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> In-Reply-To: <86occzdmhg.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:23:01 -0000 On 08/19/10 01:40, Dag-Erling Smørgrav wrote: > FreeBSD Tinderbox writes: > >>>>> Kernel build for LINT started on Thu Aug 19 02:51:08 UTC 2010 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >>>>> >> [...] >> /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size >> /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': >> /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size >> /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size >> /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': >> /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size >> /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': >> /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size >> *** Error code 1 >> >> Stop in /obj/powerpc.powerpc64/src/sys/LINT. >> > Line 705 in ofw_standard.c is > > return ((void *)args.baseaddr); > > args.baseaddr is a cell_t, which is defined in: > > typedef uint32_t cell_t; > > which I assume is correct for powerpc (32-bits), but probably not for > powerpc64. Note that it is defined as uint64_t on sparc64 and sun4v, > and in sys/boot as unsigned long int, which is the correct size on both > 32-bit and 64-bit machines (assuming I32LP64). > The problem is that until yesterday, you could not build a powerpc64 LINT, and so it was trying to build a PPC32 kernel with a 64-bit toolchain. An actual powerpc64 kernel does not include ofw_standard.c. This should be fixed now with r211483, so long as the LINT config is made with TARGET_ARCH set (and is not reused for 32 and 64-bit builds). There is a seat-belt mechanism I should add soon that will complain earlier about architecture mismatches like this. Thanks for your patience. -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 16:27:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 930F81065673 for ; Thu, 19 Aug 2010 16:27:51 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56D338FC1C for ; Thu, 19 Aug 2010 16:27:51 +0000 (UTC) Received: by gxk24 with SMTP id 24so956911gxk.13 for ; Thu, 19 Aug 2010 09:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.231.4 with SMTP id jo4mr63761qcb.22.1282233654319; Thu, 19 Aug 2010 09:00:54 -0700 (PDT) Received: by 10.229.95.145 with HTTP; Thu, 19 Aug 2010 09:00:54 -0700 (PDT) X-Originating-IP: [93.203.58.222] In-Reply-To: <20100818134341.GA88861@johnny.reilly.home> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Date: Thu, 19 Aug 2010 18:00:54 +0200 Message-ID: From: "C. P. Ghost" To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Ivan Voras , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:27:51 -0000 On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly wro= te: > On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: >> got any other suggestions? > > This is very much a "sorry I asked" question, but is none-the > less quite a good one, given the size of the hole to be plugged. > > I think that a reasonable answer for this sort of thing might be > one of the dynamic languages that compiles to C, like (perhaps) > one of the schemes (chicken, gambit-C, bigloo, etc). =A0You get > the benefit of flexibility and dynamism with good regexp and > data structure ability, good performance, and only requiring the > build tools available in the base system, as long as you don't > want to be the developer: just ship the C code (as well as the > source, of course). > > Unfortunately it seems that quite a lot of people have issues > with lisp syntax these days. +1 for a scheme shell, but not for the heavy-weight variety that compiles to C, as that would tie them to a subset of ${ARCH}es. After all LISP-like syntax is *still* more common and prevalent than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps that use it as a small language. So we can expect more users to be at least partially familiar with it. And there *are* lightweight MIT- or BSD-licensed scheme interpreters out there too: http://community.schemewiki.org/?scheme-faq-standards#implementations -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 16:40:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F2CE106564A for ; Thu, 19 Aug 2010 16:40:39 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C0118FC26 for ; Thu, 19 Aug 2010 16:40:38 +0000 (UTC) Received: by qyk4 with SMTP id 4so2294609qyk.13 for ; Thu, 19 Aug 2010 09:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=IkS7FWqRCWuGGnbTaHzwixVWVctawt0wQ5fd/LbSPdk=; b=mqJ79zXCds3wmINqSzVlmjRlC+924Enyp0WEm2RbxAwIbF5q6teyZ4iCQMAvoqkytW pB7OKpzXF/lD/CjRM5exQrGFbmA0Dxsdb7iHco/qUIxVv1yKQnHUpt5GEcxYsjF4G2xY zoLxpEkXyL1XQGYusBM76df/G5j5a51xsdYWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=c/ngs+Fih77f8iZfNDL4A3/90LYWwwDo1W0n3Fq0gGRNMX2pGCTTeA4M+kV40vMzhb vXNKkezOqwnUMgzNZajIRyMUrXkEjSkNLkndgwsyr4hFnThLf1eBJXhPCDRaBp1nCgjV PMuyq+HOjDKqC/SjSSLj7XHieIqdeWncs8jsw= MIME-Version: 1.0 Received: by 10.224.28.134 with SMTP id m6mr67320qac.150.1282236038373; Thu, 19 Aug 2010 09:40:38 -0700 (PDT) Sender: ivoras@gmail.com Received: by 10.229.236.132 with HTTP; Thu, 19 Aug 2010 09:40:37 -0700 (PDT) In-Reply-To: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Date: Thu, 19 Aug 2010 18:40:37 +0200 X-Google-Sender-Auth: BOwD0BxAKy39_x2hoHwQgg-opKY Message-ID: From: Ivan Voras To: "C. P. Ghost" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:40:39 -0000 On 19/08/2010, C. P. Ghost wrote: > On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly > wrote: >> On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: >>> got any other suggestions? >> >> This is very much a "sorry I asked" question, but is none-the >> less quite a good one, given the size of the hole to be plugged. >> >> I think that a reasonable answer for this sort of thing might be >> one of the dynamic languages that compiles to C, like (perhaps) >> one of the schemes (chicken, gambit-C, bigloo, etc). You get >> the benefit of flexibility and dynamism with good regexp and >> data structure ability, good performance, and only requiring the >> build tools available in the base system, as long as you don't >> want to be the developer: just ship the C code (as well as the >> source, of course). >> >> Unfortunately it seems that quite a lot of people have issues >> with lisp syntax these days. > > +1 for a scheme shell, but not for the heavy-weight variety that > compiles to C, as that would tie them to a subset of ${ARCH}es. > > After all LISP-like syntax is *still* more common and prevalent > than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps > that use it as a small language. So we can expect more users > to be at least partially familiar with it. And there *are* lightweight > MIT- or BSD-licensed scheme interpreters out there too: > > http://community.schemewiki.org/?scheme-faq-standards#implementations Will have to disagree on that - part of the point of having such a thing would be to attract young developers, and while the CS crowd will be happy with LISP, anyone starting programming after the first .com bubble will probably be repulsed by non-Algol-like syntaxes. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 17:18:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78DE91065694 for ; Thu, 19 Aug 2010 17:18:21 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 008E48FC17 for ; Thu, 19 Aug 2010 17:18:20 +0000 (UTC) Received: by bwz20 with SMTP id 20so2221471bwz.13 for ; Thu, 19 Aug 2010 10:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=C7mbXcoSa+IpM8p/1a21BMUwkIjN4PtortN2WKmYHZ4=; b=ISkmH61CAu4tA44Z3JBcRzi7xPNRwUa1ArnVbMnh4KqMx9xQJ4wg1p5UGwZkp1T67N bG+/47OBxPPGX2qvGm6sVod5PXZMoR0OLq1qo1pwWPk8POGhy9TMPJ6PPjlCYJWa9ImC PiCeCjvYqaF5bC50URQGSRKMk9EQZZzB9EMSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=bgv7gJhMZcJ61y+TdBZo1sWh2CZM7x6JHQ9q4y0GYgNCq61CRTteV0Irb7bTZTmu0B hAOPK8vRbaJRKPm6TfKZfjOEeEHdkhkbPt0G8rgDa9/Pxca4lav1Hep/TYT4fv/MNqhk gxmDaaCU8TUKiQo76TmKmPHh1EymETe3ynJE0= MIME-Version: 1.0 Received: by 10.204.6.75 with SMTP id 11mr66011bky.95.1282236537125; Thu, 19 Aug 2010 09:48:57 -0700 (PDT) Sender: pali.gabor@googlemail.com Received: by 10.204.73.8 with HTTP; Thu, 19 Aug 2010 09:48:57 -0700 (PDT) In-Reply-To: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Date: Thu, 19 Aug 2010 18:48:57 +0200 X-Google-Sender-Auth: kJG-uC75B2VqIy7HjjfKSw7kh2I Message-ID: From: Gabor PALI To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:18:21 -0000 Folks, Sorry for chiming in, just a quick idea. If you find the "get a high-level language that compiled to C" idea good, it might be worth to take look at Feldspar [1]. It is about defining a domain-specific language for a given domain (Digital Signal Processing) that compiles to standard ISO C99. It is an embedded language in Haskell (*), it requires some research work from the side of implementation, but it looks interesting to me. :g [1] http://feldspar.inf.elte.hu/feldspar/ (*) "A domain-specific language for writing compilers." :) From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 17:30:39 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EA6010656A4 for ; Thu, 19 Aug 2010 17:30:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD7E8FC19 for ; Thu, 19 Aug 2010 17:30:38 +0000 (UTC) Received: (qmail 9416 invoked by uid 399); 19 Aug 2010 17:30:37 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Aug 2010 17:30:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6D6A3C.9020507@FreeBSD.org> Date: Thu, 19 Aug 2010 10:30:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C6D4CB4.20601@icyb.net.ua> In-Reply-To: <4C6D4CB4.20601@icyb.net.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:30:39 -0000 On 08/19/2010 08:24, Andriy Gapon wrote: > I am sorry, but I don't see anything dramatically wrong here. So > "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be > called "runaway intr"? That's the symptom. > A lot of CPU time is idle and a lot is used by userland processes > (e.g. Xorg). Can you provide data that better illustrate your > problem? The problem is that when this happens, the system becomes unusable. Videos stop playing, switching between windows takes more and more time, mail client is painfully slow, etc. If I leave the system alone when this starts happening the clock eventually consumes all CPU, the system freezes, or it crashes. Since the last 2 require a full fsck to recover from I tend to power down first. :) BTW, something interesting happened the other day. I was having this problem over and over with the same hulu video, so I finally switched to windows in order to just finish watching it. After about 5 minutes watching the same show in windows the video started to stall just like it had in freebsd, but after about 5 seconds of that it "caught up" with itself, and I was able to watch the last 20 or so minutes without any problems. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 17:40:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60C25106564A; Thu, 19 Aug 2010 17:40:53 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 33EC78FC13; Thu, 19 Aug 2010 17:40:52 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 1AAE25B89; Thu, 19 Aug 2010 10:22:27 -0700 (PDT) To: "C. P. Ghost" In-reply-to: Your message of "Thu, 19 Aug 2010 18:00:54 +0200." References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Comments: In-reply-to "C. P. Ghost" message dated "Thu, 19 Aug 2010 18:00:54 +0200." Date: Thu, 19 Aug 2010 10:22:26 -0700 From: Bakul Shah Message-Id: <20100819172227.1AAE25B89@mail.bitblocks.com> Cc: Doug Barton , Ivan Voras , Andrew Reilly , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:40:53 -0000 On Thu, 19 Aug 2010 18:00:54 +0200 "C. P. Ghost" wrote: > On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly wro= > te: > > On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: > >> got any other suggestions? > > > > This is very much a "sorry I asked" question, but is none-the > > less quite a good one, given the size of the hole to be plugged. > > > > I think that a reasonable answer for this sort of thing might be > > one of the dynamic languages that compiles to C, like (perhaps) > > one of the schemes (chicken, gambit-C, bigloo, etc). =A0You get > > the benefit of flexibility and dynamism with good regexp and > > data structure ability, good performance, and only requiring the > > build tools available in the base system, as long as you don't > > want to be the developer: just ship the C code (as well as the > > source, of course). > > > > Unfortunately it seems that quite a lot of people have issues > > with lisp syntax these days. > > +1 for a scheme shell, but not for the heavy-weight variety that > compiles to C, as that would tie them to a subset of ${ARCH}es. +1 for Scheme! It has a lot in its favor (see below). But this is an abstract discussion. Until there are plenty of useful system scripts (in one of these languages) that people really want, nothing is going to change. There is no reason to wait until something is in the base. And we don't have to argue about which language. I would suggest setting up a wiki page to list all the system scripts people want to write and get cracking in your favorite language! May the best effort win :-) At the very least we will get some useful tools out of this effort. I will certainly help out with Scheme. -- bakul Scheme has many interpreters & compilers so you can write Scheme scripts to be interpreted and at some point compile them for better performance if necessary. Scheme has some excellent text books, a precise definition for a given standard, it changes slowly, has IDEs and so on. If you stick to the R4RS subset, almost every scheme interprpter/compiler will handle it. It has a very powerful macro facility. Its interpreters can be very small. s9fes and tinyscheme for example are about 5K lines of C code each. "Stalin" compiles Scheme to some extremely tight C code by doing global program analysis. And there are many other systems in between. slib is a library of a lot of useful packages that can be used with most Schemes. Many of these interpreters can be used from C/C++. Many provide a C-FFI to call C functions. Tinyscheme packages all of Scheme state in a single structure so one can easily create a separate Scheme interpreter per thread. There is even a vi clone written in 4K lines s9fes Scheme! Still beta but already useful. These many choices can be very confusing but we can pick one and stick to writing R4RS portable Scheme code. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 17:42:31 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D4A1065679; Thu, 19 Aug 2010 17:42:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1EFCF8FC1B; Thu, 19 Aug 2010 17:42:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA13154; Thu, 19 Aug 2010 20:42:28 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C6D6D03.4000101@icyb.net.ua> Date: Thu, 19 Aug 2010 20:42:27 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Doug Barton References: <4C6D4CB4.20601@icyb.net.ua> <4C6D6A3C.9020507@FreeBSD.org> In-Reply-To: <4C6D6A3C.9020507@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:42:31 -0000 on 19/08/2010 20:30 Doug Barton said the following: > On 08/19/2010 08:24, Andriy Gapon wrote: >> I am sorry, but I don't see anything dramatically wrong here. So >> "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be >> called "runaway intr"? > > That's the symptom. OK, I see. Perhaps you will find this message (and its ancestor thread) interesting: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-February/023447.html I believe that your issue is different, but perhaps that stuff will inspire you to use ktr(4) and schedgraph to properly debug this issue. I strongly believe that you have some sort of a scheduling issue and ktr seems to be the way to investigate it. Perhaps, you can first try the following dtrace script. It should give a better view of what statclock sees, but I am not sure if that information will be sufficient. /********************************************************/ fbt::statclock:entry /curthread->td_oncpu == 0/ { @stacks0[stack()] = count(); counts0++; } fbt::statclock:entry /curthread->td_oncpu == 1/ { @stacks1[stack()] = count(); counts1++; } fbt::statclock:entry { @stacks[pid, tid, stack()] = count(); counts++; } END { printf("\n"); printf("***** CPU 0:\n"); normalize(@stacks0, counts0 / 100); trunc(@stacks0, 5); printa("%k%@u\n\n", @stacks0); printf("\n\n"); printf("***** CPU 1:\n"); normalize(@stacks1, counts1 / 100); trunc(@stacks1, 5); printa("%k%@u\n\n", @stacks1); printf("\n\n"); printf("***** Top Processes:\n"); normalize(@stacks, counts / 200); trunc(@stacks, 20); printa(@stacks); } /********************************************************/ You would run this script when the problem hits, few seconds should be sufficient. You may want to play with values in trunc() calls, you may also want to filter gathered statistics (using conditions in /.../) by pid/tid if you spot anything interesting unusual. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 17:45:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFDC2106564A; Thu, 19 Aug 2010 17:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 81FE18FC1D; Thu, 19 Aug 2010 17:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8B29241C756; Thu, 19 Aug 2010 19:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 3cQ3an521QM4; Thu, 19 Aug 2010 19:45:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 127CB41C752; Thu, 19 Aug 2010 19:45:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E9C014448EC; Thu, 19 Aug 2010 17:43:48 +0000 (UTC) Date: Thu, 19 Aug 2010 17:43:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Doug Barton In-Reply-To: <4C6D6A3C.9020507@FreeBSD.org> Message-ID: <20100819174314.E48418@maildrop.int.zabbadoz.net> References: <4C6D4CB4.20601@icyb.net.ua> <4C6D6A3C.9020507@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:45:08 -0000 On Thu, 19 Aug 2010, Doug Barton wrote: > On 08/19/2010 08:24, Andriy Gapon wrote: >> I am sorry, but I don't see anything dramatically wrong here. So >> "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be >> called "runaway intr"? > > That's the symptom. Have you ever posted a vmstat -i for when this actually happens? /bz -- Bjoern A. Zeeb This signature is about you not me. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 18:07:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DDAC1065675; Thu, 19 Aug 2010 18:07:06 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 061498FC14; Thu, 19 Aug 2010 18:07:05 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o7JI75D8009911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 20:07:05 +0200 (CEST) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1282241225; bh=B2NM9b3qKG74lcF5jzZYwrpqbIuKuzeKLsq1BoeI2+o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=iftpYf1NOeWaQGGTrRDxeyreXgMZHf8PJa5vEm2VTv83b7i13Lq6N+tgOUTBYZr0X YPceyH03VM5hqcLPBiCysuWmFLu1YIkW6QVNP9QS+zuuXs10GzwbFtZJkn3gaXFYy6 59P/J2EyqsUfnKYaPisOwczJARuEHkBGOL2OLPjU= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o7JI75Gq009910; Thu, 19 Aug 2010 20:07:05 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 19 Aug 2010 20:07:05 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: David Xu Message-ID: <20100819180704.GE80306@acme.spoerlein.net> Mail-Followup-To: David Xu , current@freebsd.org References: <4C6505A4.9060203@FreeBSD.org> <20100814155346.GA6510@nagual.pp.ru> <4C66C0A4.3000301@FreeBSD.org> <4C6D5EF2.2040603@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6D5EF2.2040603@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:07:06 -0000 On Thu, 19.08.2010 at 16:42:26 +0000, David Xu wrote: > Gabor Kovesdan wrote: > > > Yes, I'm sorry for my slow reaction, I got a flu some time ago and that > > prevented me from fixing the bugs earlier. I have several fixes in my > > working copy, which are being discussed with my mentor. Probably, today > > or tomorrow they will be committed. > > > > Gabor > > > > When will the grep -H print file name for me ? it is rather painful > that the feature is missing. :-( > So I can not use it with find: > > find . -exec grep -H {} world \; > I don't know which file contains the word world. Workaround: find . -exec grep word {} + (yeah, not what you asked for ...) Uli From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 18:34:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58D3C1065672 for ; Thu, 19 Aug 2010 18:34:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 003E68FC0A for ; Thu, 19 Aug 2010 18:34:57 +0000 (UTC) Received: (qmail 16306 invoked by uid 399); 19 Aug 2010 18:34:57 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Aug 2010 18:34:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6D794F.4090801@FreeBSD.org> Date: Thu, 19 Aug 2010 11:34:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> <867hjmdfdo.fsf@ds4.des.no> In-Reply-To: <867hjmdfdo.fsf@ds4.des.no> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:34:58 -0000 On 08/19/2010 04:13, Dag-Erling Smørgrav wrote: > It would have been far more "constructive and distinctively polite" to > take ten minutes to build and run a profiling version of grep, and > include the results in the OP. Meta-comment first. des and I are both people of strong opinions, and we agree on more than we disagree on. I have no problem with him stating his opinion here, and I don't care if he agrees with me after I state mine. :) There are 2 questions, did I do the right thing, and how should people report problems in general. As for myself, while I have some facility in C it's not my strong suit. Yes, I could have produced a profiling version of grep, but it would have taken me a lot more than 10 minutes because I don't even build the profiled libs on a regular basis. In this specific case I also didn't think it was "my job" to do so. Gabor is the one developing BSD grep, as far as I'm concerned it's up to him to get its performance up to par. I certainly have no objection to others helping him, and I'm glad that raising the issue of performance has resulted in more attention and assistance being directed at the problem. But I feel that I did my part by providing simple to reproduce test cases that Gabor could use. More generally however I think that we need to be realistic with what we expect people to do about reporting problems. We WANT more "regular users" to use -current early on in the development cycle, and if they see problems to report them. Chastising people for not doing profiling runs of things that they are reporting problems with is not going to accomplish that goal. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 18:36:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC2491065693; Thu, 19 Aug 2010 18:36:00 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 32DCE8FC28; Thu, 19 Aug 2010 18:35:59 +0000 (UTC) Received: by yxe42 with SMTP id 42so1029497yxe.13 for ; Thu, 19 Aug 2010 11:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.80.6 with SMTP id d6mr309115anb.64.1282242959149; Thu, 19 Aug 2010 11:35:59 -0700 (PDT) Received: by 10.101.7.36 with HTTP; Thu, 19 Aug 2010 11:35:59 -0700 (PDT) X-Originating-IP: [93.203.58.222] In-Reply-To: <20100819172227.1AAE25B89@mail.bitblocks.com> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100819172227.1AAE25B89@mail.bitblocks.com> Date: Thu, 19 Aug 2010 20:35:59 +0200 Message-ID: From: "C. P. Ghost" To: Bakul Shah Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Ivan Voras , Andrew Reilly , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:36:00 -0000 On Thu, Aug 19, 2010 at 7:22 PM, Bakul Shah wrote: > +1 for Scheme! It has a lot in its favor (see below). > > But this is an abstract discussion. Until there are plenty of > useful system scripts (in one of these languages) that people > really want, nothing is going to change. Yes, it's abstract: I want my bikeshed named Gauche (lang/gauche): ;-) http://practical-scheme.net/gauche/ But seriously, the point isn't so much which specific interpreter we use (if we go down this road), it's about libraries: most sysadmin tasks require some basic networking and I/O, and a FFI to seamlessly call out C functions from .so libs. Ideally a shell with a REPL loop, but even that isn't strictly necessary for the scripts. And, of course, instead of writing 1,001 sysadmin scripts with endless code duplication and reinventing of the wheel, common sysadmin tasks should also be made into reusable functions, grouped into modules. We're talking about a major task here, and no matter if it will be in the base or as a port, it's something that will take some time to emerge, so it's not a realistic option in the short (or even middle) term. > There is no reason to wait until something is in the base. > And we don't have to argue about which language. I would > suggest setting up a wiki page to list all the system scripts > people want to write and get cracking in your favorite > language! May the best effort win :-) At the very least we > will get some useful tools out of this effort. =A0I will > certainly help out with Scheme. Funny idea. I only hope we won't end up with a typical post-dot-com young developer distribution, a la: 60% PHP (yuck!) 25% Java (and XML-everywhere) 15% ${OTHERS} ;-) > Scheme has many interpreters & compilers so you can write > Scheme scripts to be interpreted and at some point compile > them for better performance if necessary. Scheme has some > excellent text books, a precise definition for a given > standard, it changes slowly, has IDEs and so on. If you stick > to the R4RS subset, almost every scheme interprpter/compiler > will handle it. =A0It has a very powerful macro facility. =A0Its > interpreters can be very small. s9fes and tinyscheme for > example are about 5K lines of C code each. =A0"Stalin" compiles > Scheme to some extremely tight C code by doing global program > analysis. =A0And there are many other systems in between. =A0slib > is a library of a lot of useful packages that can be used > with most Schemes. =A0Many of these interpreters can be used > from C/C++. =A0Many provide a C-FFI to call C functions. > Tinyscheme packages all of Scheme state in a single structure > so one can easily create a separate Scheme interpreter per > thread. =A0There is even a vi clone written in 4K lines s9fes > Scheme! =A0Still beta but already useful. > > These many choices can be very confusing but we can pick one > and stick to writing R4RS portable Scheme code. Yes, but see above w.r.t. the needed library. And, again, it's an academic discussion, as much as I'd love to do sysadmin scripts in Scheme myself. -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 18:48:44 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 452DB1065696 for ; Thu, 19 Aug 2010 18:48:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C5AFF8FC0C for ; Thu, 19 Aug 2010 18:48:43 +0000 (UTC) Received: (qmail 7486 invoked by uid 399); 19 Aug 2010 18:48:42 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Aug 2010 18:48:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6D7C89.7040601@FreeBSD.org> Date: Thu, 19 Aug 2010 11:48:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: "arch@freebsd.org" , "current@freebsd.org" References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EDC.5000206@andric.com> <20100819084951.17534pzw4h7ff8kk@webmail.leidinger.net> In-Reply-To: <20100819084951.17534pzw4h7ff8kk@webmail.leidinger.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:48:44 -0000 I think sometimes we act as if code that is removed from the tree is gone forever, with no possibility of it ever returning. I don't understand this attitude. :) If something is unsupported it should be removed, Q.E.D. There is no reason to think of possible reasons that we might want it to stay. Meanwhile, FYI, ports/lang/icc7 has been marked DEPRECATED since 8/8 with removal scheduled for 2010-09-01 based on the distinfo not containing a SHA256 line and (AFAICS) no distfiles available. If and only if someone wants to actively develop a newer version the old port will remain in the repo and can still be used as the basis of a repo copy to a newer version if that is necessary and/or desirable. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 18:53:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 345A6106566B; Thu, 19 Aug 2010 18:53:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F1BC38FC13; Thu, 19 Aug 2010 18:53:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7JIrs28071377; Thu, 19 Aug 2010 14:53:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7JIrsYo071368; Thu, 19 Aug 2010 18:53:54 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 19 Aug 2010 18:53:54 GMT Message-Id: <201008191853.o7JIrsYo071368@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:53:55 -0000 TB --- 2010-08-19 16:59:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-19 16:59:50 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-19 16:59:50 - cleaning the object tree TB --- 2010-08-19 17:00:31 - cvsupping the source tree TB --- 2010-08-19 17:00:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-19 17:01:45 - building world TB --- 2010-08-19 17:01:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-19 17:01:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-19 17:01:45 - TARGET=powerpc TB --- 2010-08-19 17:01:45 - TARGET_ARCH=powerpc64 TB --- 2010-08-19 17:01:45 - TZ=UTC TB --- 2010-08-19 17:01:45 - __MAKE_CONF=/dev/null TB --- 2010-08-19 17:01:45 - cd /src TB --- 2010-08-19 17:01:45 - /usr/bin/make -B buildworld >>> World build started on Thu Aug 19 17:01:46 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Aug 19 18:40:01 UTC 2010 TB --- 2010-08-19 18:40:01 - generating LINT kernel config TB --- 2010-08-19 18:40:01 - cd /src/sys/powerpc/conf TB --- 2010-08-19 18:40:01 - /usr/bin/make -B LINT TB --- 2010-08-19 18:40:01 - building LINT kernel TB --- 2010-08-19 18:40:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-19 18:40:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-19 18:40:01 - TARGET=powerpc TB --- 2010-08-19 18:40:01 - TARGET_ARCH=powerpc64 TB --- 2010-08-19 18:40:01 - TZ=UTC TB --- 2010-08-19 18:40:01 - __MAKE_CONF=/dev/null TB --- 2010-08-19 18:40:01 - cd /src TB --- 2010-08-19 18:40:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Aug 19 18:40:01 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/powerpc/fpu/fpu_emu.c: In function 'fpu_execute': /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'vm_offset_t' /src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'register_t' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-19 18:53:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-19 18:53:53 - ERROR: failed to build lint kernel TB --- 2010-08-19 18:53:53 - 4836.18 user 1209.40 system 6843.79 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 20:22:57 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 363DB1065674; Thu, 19 Aug 2010 20:22:57 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id E89D48FC16; Thu, 19 Aug 2010 20:22:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:18ec:2038:19e5:d1cb] (unknown [IPv6:2001:7b8:3a7:0:18ec:2038:19e5:d1cb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E3BC35C59; Thu, 19 Aug 2010 22:22:55 +0200 (CEST) Message-ID: <4C6D92A1.8030109@andric.com> Date: Thu, 19 Aug 2010 22:22:57 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: David Xu References: <4C6505A4.9060203@FreeBSD.org> <20100814155346.GA6510@nagual.pp.ru> <4C66C0A4.3000301@FreeBSD.org> <4C6D5EF2.2040603@freebsd.org> In-Reply-To: <4C6D5EF2.2040603@freebsd.org> Content-Type: multipart/mixed; boundary="------------090409070507040103030506" Cc: delphij@freebsd.org, Gabor Kovesdan , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:22:57 -0000 This is a multi-part message in MIME format. --------------090409070507040103030506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2010-08-19 18:42, David Xu wrote: > When will the grep -H print file name for me ? it is rather painful > that the feature is missing. :-( > So I can not use it with find: > > find . -exec grep -H {} world \; > I don't know which file contains the word world. I think you mean: find . -exec grep -H world {} \; instead? In any case, the fix is trivial, please try the attachment. --------------090409070507040103030506 Content-Type: text/plain; name="bsdgrep-fix-H.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bsdgrep-fix-H.diff" diff --git a/usr.bin/grep/grep.c b/usr.bin/grep/grep.c index 3cb277c..cc710ef 100644 --- a/usr.bin/grep/grep.c +++ b/usr.bin/grep/grep.c @@ -682,8 +682,6 @@ main(int argc, char *argv[]) if (dirbehave == DIR_RECURSE) c = grep_tree(aargv); else { - if (aargc == 1) - hflag = true; for (c = 0; aargc--; ++aargv) { if ((finclude || fexclude) && !file_matching(*aargv)) continue; --------------090409070507040103030506-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 20:26:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9580F1065673; Thu, 19 Aug 2010 20:26:50 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 487C68FC1C; Thu, 19 Aug 2010 20:26:50 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1OmBRR-0006Gw-2L; Thu, 19 Aug 2010 21:10:25 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OmBRQ-0001Ti-Oz; Thu, 19 Aug 2010 21:10:24 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o7JKAOJr020309; Thu, 19 Aug 2010 21:10:24 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o7JKAOuB020308; Thu, 19 Aug 2010 21:10:24 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Thu, 19 Aug 2010 21:10:24 +0100 From: Anton Shterenlikht To: Alexander Leidinger Message-ID: <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100819113548.72614imi2zxx9log@webmail.leidinger.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Rui Paulo , "current@freebsd.org" , Garrett Cooper , "arch@freebsd.org" , Gabor Kovesdan , Dag-Erling =?iso-8859-1?Q?Sm=C3=3F=3Frgrav?= Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:26:50 -0000 On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote: > > Quoting Dag-Erling SmÃ??rgrav (from Thu, 19 Aug 2010 > 11:16:23 +0200): > > > Alexander Leidinger writes: > >> If someone would get icc 11.x up and runnig as a port (similar to what > >> we have for outdated icc version in the ports collection), I would > >> have a look if my contact at Intel is still working there in a > >> position which allows him to get a commercial license for us. > > > > Does that really matter? We're not going to start building releases > > with icc, are we? > > It could matter for ports, I do not know if it matters for parts in > src. The commercial license is also the only way that we could get icc > installed on machines in the FreeBSD cluster (if there's interest to > have another compiler *for FreeBSD development* to check the source > against... the warnng and error messages are better that those of gcc, > I do not know how they compare to clang). If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then this becomes a somewhat different discussion. One of the stubmling blocks for HPC on FreeBSD (just one of many, perhaps not even the major one) is a complete lack of good quality commercial compilers. All weÃ'got is gcc or clang. Both are not really that great, and definitely inferior to commercial compilers, e.g. Intel. What IÃ'm saying is that it would be great if Intel sold a compiler for FreeBSD. I'd ve bought a copy. But from what others have said, my impression is that the ICC port is unlikely to fill this void. P.S. My interests and expertise are in computational mechanics, not in compilers, so feel free to correct me if IÃ'm wrong. P.P.S. Regarding FreeBSD HPC see also this thead: http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html (FreeBSD, GPGPU and OpenCL/CUDA) -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 21:08:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97941065674 for ; Thu, 19 Aug 2010 21:08:49 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE3348FC18 for ; Thu, 19 Aug 2010 21:08:47 +0000 (UTC) Received: by eyx24 with SMTP id 24so1527421eyx.13 for ; Thu, 19 Aug 2010 14:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=Bl5Of34SpdB6q5+uNWn7X3cCp+22hCfVafSOxEkzW+g=; b=B3ekWBiYPTxjxRoDMCjSE0ClB76FOOQCEZMOjWet0MGgO5Pl/1aME43sFmrqAyFy1P kFJlYDCkm7IP1IeMX5uo078hDk9J97u9H3Z7pHmCGz7GcY67Zlyhr4A72ODlS8H1o4mW 8xLRHVXgC3G9NHiHsXq+tNCzPBMKPF7tLnmxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=Zlwgn/kFgR9ev09I/Imbpv3gdww3qaXSD1eGfoNmewJhviZFqgGoJ2zafINu8OjIp/ K4rFcyhiF8EjMhG/a9xOqTfqz6my27wX1Ta0sNHut3Vg1iPo5CNIQ+Vbwk06McRyEgPc 6EpUhBZBHaAt0+Rl7q6WKDUtnGtowKENdTBhg= Received: by 10.213.17.147 with SMTP id s19mr677913eba.31.1282252125783; Thu, 19 Aug 2010 14:08:45 -0700 (PDT) Received: from localhost ([178.125.17.222]) by mx.google.com with ESMTPS id v59sm3380553eeh.10.2010.08.19.14.08.44 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 14:08:45 -0700 (PDT) Date: Fri, 20 Aug 2010 00:08:45 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Message-ID: <20100820000845.378f4fb3@gmail.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ndisgen is broken (bsdgrep) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:08:49 -0000 Hi, [tiger@laptop]~%which egrep /usr/bin/egrep [tiger@laptop]~%egrep --version egrep (BSD grep) 2.5.1-FreeBSD [tiger@laptop]~% fetch http://tiger.ipfw.ru/files/rt3090_ndiswrapper.tar.gz [tiger@laptop]~% tar xf rt3090_ndiswrapper.tar.gz [tiger@laptop]~%cd rt3090_ndiswrapper/ [tiger@laptop]~/temp/rt3090_ndiswrapper%ndisgen rt2860.inf rt2860.sys ================================================================== ------------------ Windows(r) driver converter ------------------- ================================================================== INF file validation I don't recognize this file format. It may not be a valid .INF file. Press enter to try again, or ^C to quit. with gnugrep all works fine... [tiger@laptop]~%uname -a FreeBSD laptop.minsk.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #9 r211484M: Thu Aug 19 12:31:20 EEST 2010 root@laptop.minsk.domain:/usr/obj/usr/src/sys/b450 i386 on another box (HEAD, amd64 r210780) same error Thanks in advance.... -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 21:42:03 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F8C1065698; Thu, 19 Aug 2010 21:42:03 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7CD8FC08; Thu, 19 Aug 2010 21:42:02 +0000 (UTC) Received: by wwb31 with SMTP id 31so1252279wwb.31 for ; Thu, 19 Aug 2010 14:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=CHXOdMiZxv4qVpyj9RweA7fGmDOVIfjD5CXbntGnCC0=; b=unV95JrdUmyL9ebPHlkP2PFT/aK+15FZP/rLbXKEEpAiBUW4L42T9c/oyjYuGhqjzC Hd8soKijSlgwEs2pZxYvKWDo4IJ38swJLo1O9OWe0PRVMdblqyPC2SLuN5W32HIxfZOR lfVY4ibFlaraZkVO7U7ZyKMfEM94D2yTMtrM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=OTosrQx4teG0I6hmC4mY2EcZ95jUIOxm6JFex214AOH5AhhFvBDq+fGW8jbmjyp4PG UWr1aXNdGUyXr81w/Qn+mfFvGWn53vPZ9aUhj8lJZJCg1a4gXKc2QOeTi5UdB/IkwNaL bMhE7DfIlBS6KaHvVlhCpJNxQX/NQPDUmoRR0= MIME-Version: 1.0 Received: by 10.216.1.208 with SMTP id 58mr384354wed.22.1282254121382; Thu, 19 Aug 2010 14:42:01 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Thu, 19 Aug 2010 14:42:01 -0700 (PDT) Date: Thu, 19 Aug 2010 21:42:01 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gabor@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:42:03 -0000 Gabor: One more thing to look into, in addition to the context problems, ndisgen breakage, and problems on certain file systems: At r211506, 'grep -wq' does not seem to work properly (in the very least, it is not the same as with GNU grep), and has broken the 'check-categories' target (and hence builds) of all ports with 'lisp' in CATEGORIES. Regards, b. P.S. I hope that you have recovered from your influenza, and are feeling better now. From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 21:54:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 629261065673; Thu, 19 Aug 2010 21:54:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 19CED8FC1A; Thu, 19 Aug 2010 21:54:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B1FDF46B45; Thu, 19 Aug 2010 17:54:58 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9FAFA8A03C; Thu, 19 Aug 2010 17:54:57 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 19 Aug 2010 13:39:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <4C6505A4.9060203@FreeBSD.org> <4C6D3BBB.7030104@andric.com> In-Reply-To: <4C6D3BBB.7030104@andric.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008191339.54279.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 19 Aug 2010 17:54:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: alc@freebsd.org, Dimitry Andric Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:54:59 -0000 On Thursday, August 19, 2010 10:12:11 am Dimitry Andric wrote: > On 2010-08-17 23:24, Alan Cox wrote: > >> So normal mmap is ~3% slower, and prefault mmap does not seem to make > >> any measurable difference. I guess the added complexity is not really > >> worth it, for now. > > > > Do you know what fraction of this time is being spent in the kernel? > > I ran 100 trials again, but now using "time -a -o logfile", so I could > run ministat over the accumulated results. This gives: > > x gnugrep > + bsdgrep-r210927 (the initial version that started this thread) > * bsdgrep-r211490 (current version) > % bsdgrep-r211490-mmap-plain > # bsdgrep-r211490-mmap-prefault > > Real time: > N Min Max Median Avg Stddev > x 100 1.15 1.98 1.18 1.2122 0.11159613 > + 100 8.57 14.26 8.79 9.1823 1.0496126 > * 100 2.81 6.57 2.91 3.0189 0.4304259 > % 100 2.34 4.03 2.99 3.0022 0.12635992 > # 100 2.85 3.49 2.88 2.8981 0.075232904 > > User time: > N Min Max Median Avg Stddev > x 100 0 0.07 0.03 0.0239 0.015627934 > + 100 1.6 3.33 1.9 1.976 0.30264824 > * 100 0.29 1 0.39 0.4004 0.08696824 > % 100 1.8 3.56 2.73 2.7274 0.13260117 > # 100 2.78 3.04 2.81 2.8238 0.04039652 > > System time: > N Min Max Median Avg Stddev > x 100 1.08 1.91 1.15 1.1809 0.10953617 > + 100 6.55 10.9 6.94 7.1905 0.77911809 > * 100 2.38 5.5 2.53 2.6061 0.35068445 > % 100 0.18 0.53 0.25 0.2645 0.053586049 > # 100 0.03 0.54 0.06 0.0668 0.052259647 > > E.g. it looks like bsdgrep with 'plain' mmap performs almost the same > as the regular bsdgrep (both around 3.0s average), but with mmap much > more of the time is spent in user mode. I would add user and system time together and compare the total time. Given that statclock only fires at 128 hz, and we use those counts to subdivide rux_runtime, I don't put much faith in user vs system time for benchmarks, only the total runtime in rux_runtime (which is user + system) is truly accurate. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 23:04:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C6B106567A for ; Thu, 19 Aug 2010 23:04:22 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F30D8FC13 for ; Thu, 19 Aug 2010 23:04:21 +0000 (UTC) Received: by wyj26 with SMTP id 26so3248264wyj.13 for ; Thu, 19 Aug 2010 16:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=+JUYHKyEHDFLzfHqIVAGtsFA4I9KvHelDIRU7BP+l4Q=; b=Ko+X0gDj2dZiwUS9RGbBhUQ92rTUxMkFrbAlspcU8t9ScidvmMRb9als9Y2yTexEAx Y4V4TVs5Y+TQWeQnaxxMMOzuNqdEBpHGM2/2By5bQUOq+tSlC2QMtmW/LoEcEVD4fLin +xEHFVk9rpzo3da3i3tMVMRk8plNhZtcF4Y3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VdFm6irK9T3hAnk+gDt5PvNYd8xYdD/v1aW4H9weZXjPIwXe76VZ3tKtnurVCnka0V NgxsiIk98V+SniNbPgcNjI+v/r72i75S2OoGoQvNUcveYAyq41bk+UAgWmIDfPjxwBMP 0SJ11XCm26zlpjZrPZof2u7lqxTlwdBuoJbMA= MIME-Version: 1.0 Received: by 10.216.46.15 with SMTP id q15mr377562web.103.1282259060156; Thu, 19 Aug 2010 16:04:20 -0700 (PDT) Received: by 10.216.86.10 with HTTP; Thu, 19 Aug 2010 16:04:20 -0700 (PDT) Date: Thu, 19 Aug 2010 18:04:20 -0500 Message-ID: From: Chris Ruiz To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 Subject: recent ath changes related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:04:22 -0000 I run a PCI Atheros card in hostap mode on CURRENT. ath0@pci0:6:0:0: class=0x020000 card=0x5a001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR2312)' class = network subclass = ethernet Everything works fine with r211193 but with newer kernels I receive the same panic related to the ath0 tasq. the panic - http://tinypic.com/r/11t3g39/4 the backtrace - http://tinypic.com/r/nv4786/4 Sorry about the pics, I don't have access to serial or dcons. -- Chris Ruiz ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Thu Aug 19 23:52:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DCD51065695 for ; Thu, 19 Aug 2010 23:52:40 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id 009F68FC1A for ; Thu, 19 Aug 2010 23:52:39 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20100819235238.RADZ26010.nschwmtas06p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Thu, 19 Aug 2010 23:52:38 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100819235237.SPJT13035.nschwotgx02p.mx.bigpond.com@johnny.reilly.home>; Thu, 19 Aug 2010 23:52:37 +0000 Date: Fri, 20 Aug 2010 09:52:37 +1000 From: Andrew Reilly To: "C. P. Ghost" Message-ID: <20100819235237.GA5859@johnny.reilly.home> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Thu, 19 Aug 2010 23:52:37 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090202.4C6DC3C5.01E8,ss=1,fgs=0 X-SIH-MSG-ID: qREyGNHuXAD+xDJw0jPvNAJ+xA/u8yI74J0WRdJsoQQZSkfduMHeU677NrMwhNn21TdcNBmPO2MqYKT0X4/QsuM= Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:52:40 -0000 I didn't want to prolong this now mostly off-topic discussion too much, but: On Thu, Aug 19, 2010 at 06:00:54PM +0200, C. P. Ghost wrote: > +1 for a scheme shell, but not for the heavy-weight variety that > compiles to C, as that would tie them to a subset of ${ARCH}es. Why do you say that? Most of the C-generators that I know of produce fairly standards-compliant C code that should just work anywhere. Sure there are some (with sophisticated memory managers, mostly) that get intimate with the platform, but presumably we would have to stay away from those for this sort of exercise... Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 00:47:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B9FD1065698; Fri, 20 Aug 2010 00:47:42 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by mx1.freebsd.org (Postfix) with ESMTP id C8A798FC12; Fri, 20 Aug 2010 00:47:41 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20100820004740.GANG23327.nskntmtas03p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Fri, 20 Aug 2010 00:47:40 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100820004739.HZSA13584.nskntotgx03p.mx.bigpond.com@johnny.reilly.home>; Fri, 20 Aug 2010 00:47:39 +0000 Date: Fri, 20 Aug 2010 10:47:39 +1000 From: Andrew Reilly To: Ivan Voras Message-ID: <20100820004739.GA6576@johnny.reilly.home> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Fri, 20 Aug 2010 00:47:39 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090207.4C6DD0AC.0080,ss=1,fgs=0 X-SIH-MSG-ID: rx0wEtX+TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rVMfpRsMuxxDxMJhqFNGUnaajkTY3Rs9mK Cc: freebsd-current@freebsd.org, "C. P. Ghost" Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 00:47:42 -0000 On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote: > Will have to disagree on that - part of the point of having such a > thing would be to attract young developers, and while the CS crowd > will be happy with LISP, anyone starting programming after the first > .com bubble will probably be repulsed by non-Algol-like syntaxes. I suspect that you're right, though that disappoints me somewhat. The only other language that I'm aware of that does a reasonable compiles-to-C and has an algol-like syntax is Eiffel (specifically SmartEiffel), but I haven't used it for years, and don't know how it's travelling. It's also nowhere near as dynamic and "fun" a programming experience, IMO. Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 01:08:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FFCD1065673 for ; Fri, 20 Aug 2010 01:08:58 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7C68FC15; Fri, 20 Aug 2010 01:08:58 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o7K18tk7041081; Fri, 20 Aug 2010 01:08:57 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C6DD5A8.3030701@freebsd.org> Date: Fri, 20 Aug 2010 01:08:56 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: "Stein. Sandbech" References: <20100819092939.8824410657B8@hub.freebsd.org> <29BC1E84-9C05-4021-B8B9-E78825BEC571@wopr.ife.no> In-Reply-To: <29BC1E84-9C05-4021-B8B9-E78825BEC571@wopr.ife.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:08:58 -0000 But I think BSD grep should be compatible with GNU grep, because almost all scripts are written for GNU grep before BSD grep appears, it is not practical to rewrite all existing scripts. Anyway, thanks for your help. David Xu Stein Morten Sandbech wrote: > Hi, > > GNU grep is OK. However standard BSD grep also work: > > find . -exec grep -i world {} /dev/null \; > > or even: > > find . -exec grep -in world {} /dev/null \; > > if you want linenumbers ... > > hth > > Stein Morten > > > > On Aug 19, 2010, at 11:29, freebsd-current-request@freebsd.org wrote: > >> Date: Thu, 19 Aug 2010 16:42:26 +0000 >> From: David Xu >> Subject: Re: Official request: Please make GNU grep the default >> To: Gabor Kovesdan >> Cc: delphij@freebsd.org, Andrey Chernov , Doug >> Barton , core@freebsd.org, current@freebsd.org >> Message-ID: <4C6D5EF2.2040603@freebsd.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Gabor Kovesdan wrote: >> >>> Yes, I'm sorry for my slow reaction, I got a flu some time ago and that >>> prevented me from fixing the bugs earlier. I have several fixes in my >>> working copy, which are being discussed with my mentor. Probably, today >>> or tomorrow they will be committed. >>> >>> Gabor >>> >> When will the grep -H print file name for me ? it is rather painful >> that the feature is missing. :-( >> So I can not use it with find: >> >> find . -exec grep -H {} world \; >> I don't know which file contains the word world. >> >> Regards, >> David Xu > > From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 01:49:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26E581065698; Fri, 20 Aug 2010 01:49:04 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from x2045.x.rootbsd.net (x2045.x.rootbsd.net [208.86.227.221]) by mx1.freebsd.org (Postfix) with ESMTP id C41D48FC08; Fri, 20 Aug 2010 01:49:03 +0000 (UTC) Received: from x2045.x.rootbsd.net (localhost [127.0.0.1]) by x2045.x.rootbsd.net (8.14.3/8.14.3) with ESMTP id o7K17OR2052248; Fri, 20 Aug 2010 01:07:24 GMT (envelope-from estrabd@gmail.com) Received: (from estrabd@localhost) by x2045.x.rootbsd.net (8.14.3/8.14.3/Submit) id o7K17NWk052246; Fri, 20 Aug 2010 01:07:23 GMT (envelope-from estrabd@gmail.com) X-Authentication-Warning: x2045.x.rootbsd.net: estrabd set sender to estrabd@gmail.com using -f Date: Fri, 20 Aug 2010 01:07:23 +0000 From: "B. Estrade" To: Andrew Reilly Message-ID: <20100820010723.GL18105@x2045.x.rootbsd.net> References: <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100820004739.GA6576@johnny.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100820004739.GA6576@johnny.reilly.home> User-Agent: Mutt/1.4.2.3i mailed-by: B. Estrade Cc: freebsd-current@freebsd.org, "C. P. Ghost" , Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 01:49:04 -0000 On Fri, Aug 20, 2010 at 10:47:39AM +1000, Andrew Reilly wrote: > On Thu, Aug 19, 2010 at 06:40:37PM +0200, Ivan Voras wrote: > > Will have to disagree on that - part of the point of having such a > > thing would be to attract young developers, and while the CS crowd > > will be happy with LISP, anyone starting programming after the first > > .com bubble will probably be repulsed by non-Algol-like syntaxes. > > I suspect that you're right, though that disappoints me > somewhat. The only other language that I'm aware of that does a > reasonable compiles-to-C and has an algol-like syntax is Eiffel > (specifically SmartEiffel), but I haven't used it for years, > and don't know how it's travelling. It's also nowhere near as > dynamic and "fun" a programming experience, IMO. Don't assume that the "CS crowd" are LISP or FP sycophants or that having to program in C is unattractive to new blood (a term I prefer over "young developers"). FWIW, I use Perl to prototype all sorts of algorithms and data structures - and most recently, Qore (I maintain the lang/qore port). But I don't believe either should be in base when it's so dead simple to install them from ports. Cheers, Brett > > Cheers, > > -- > Andrew > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- B. Estrade From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 05:48:56 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6F521065679; Fri, 20 Aug 2010 05:48:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 74A2E8FC13; Fri, 20 Aug 2010 05:48:56 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 1064813DF46; Fri, 20 Aug 2010 09:32:20 +0400 (MSD) Date: Fri, 20 Aug 2010 09:31:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1163150765.20100820093144@serebryakov.spb.ru> To: Gabor Kovesdan In-Reply-To: <4C66C010.3040308@FreeBSD.org> References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 05:48:56 -0000 Hello, Gabor. You wrote 14 =E0=E2=E3=F3=F1=F2=E0 2010 =E3., 20:10:56: > 2, GNU grep uses internal optimizations to get that performance. I think > it's a wrong approach because the regex library itself should be=20 > optimized instead to keep BSD grep clean and simple and to provide the > same efficiency for all utilities that are linked to the regex library. > Our libc-regex is definitely need to be replaced at some point in the=20 > future but that's a more complex item. See the following references: > http://wiki.freebsd.org/BSDgrep > http://wiki.freebsd.org/Regex You don't have these links on Wiki page, so I post them here. I hope, you've read these articles, but it is better to duplicate links, than miss them. http://swtch.com/~rsc/regexp/regexp1.html http://swtch.com/~rsc/regexp/ And it iw very strange to see TRE soooo slow, because it seems, it is based on "fast" linear approcach, when gnu-regexp is old, slow, one... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 05:55:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2678C10656A5 for ; Fri, 20 Aug 2010 05:55:39 +0000 (UTC) (envelope-from szilveszter.adam@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0A88FC13 for ; Fri, 20 Aug 2010 05:55:38 +0000 (UTC) Received: by fxm4 with SMTP id 4so1851185fxm.13 for ; Thu, 19 Aug 2010 22:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=uR0oMRFaftgeg3DUVHuQnJU8Xdya5MlddGS6bUc+RSg=; b=hj9ewu3QUzqHRIMGl6owyWxGc+5seb/fkhZo7T5J1opz+MMSEIIOPqgoOAIZAVq3ZH 7By3xMfsZmSF4Fsr4JUpwpbw6WmISVGswQ5cV44ZdI40ysyKd8zrs8JtkNXgOFc4iOam X2Lu4qLI4M8ntFoUxc5//Gy+8K8VLdQVqd6PU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=h13P0OEgNPyo2DwxQhv6WoPsJmsB4mx5+g0r+6x5yQWWqjMB2Ow0UaT43ebGyLRmF3 v4Jxy+Zqqb1RT2o9CQltdR/oQe8wHEACwkumLWQAxvgSYWqIyuY0LDAHnVxuu4k250z8 m/J4Q6w7DVysz4Pb7iwquyPsgkOwl6M6X0AMo= Received: by 10.223.110.134 with SMTP id n6mr603842fap.79.1282282082331; Thu, 19 Aug 2010 22:28:02 -0700 (PDT) Received: from baranyfelhocske.buza.adamsfamily.xx (178-164-252-137.pool.digikabel.hu [178.164.252.137]) by mx.google.com with ESMTPS id t6sm1036228faa.27.2010.08.19.22.28.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 22:28:01 -0700 (PDT) Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.4/8.14.4) with ESMTP id o7K5Rxln001800 for ; Fri, 20 Aug 2010 07:27:59 +0200 (CEST) (envelope-from szilveszter.adam@gmail.com) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.4/8.14.4/Submit) id o7K5Rx57001799 for freebsd-current@freebsd.org; Fri, 20 Aug 2010 07:27:59 +0200 (CEST) (envelope-from szilveszter.adam@gmail.com) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to szilveszter.adam@gmail.com using -f Date: Fri, 20 Aug 2010 07:27:59 +0200 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20100820052759.GA1780@baranyfelhocske.buza.adamsfamily.xx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 05:55:39 -0000 On Thu, Aug 19, 2010 at 09:42:01PM +0000, b. f. wrote: > Gabor: > > One more thing to look into, in addition to the context problems, > ndisgen breakage, and problems on certain file systems: > > At r211506, 'grep -wq' does not seem to work properly (in the very > least, it is not the same as with GNU grep), and has broken the > 'check-categories' target (and hence builds) of all ports with 'lisp' > in CATEGORIES. Seconded. This also breaks the ports using bsd.apache.mk, and what's worse, it does so silently. I have been bitten by this myself with www/apache22, several core modules have not been built resulting in a useless apache installation. So, I believe there is more to do here than just performance optimisation. -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 06:13:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F6151065698; Fri, 20 Aug 2010 06:13:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0579E8FC0C; Fri, 20 Aug 2010 06:13:55 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3CC8813DF46; Fri, 20 Aug 2010 09:54:16 +0400 (MSD) Date: Fri, 20 Aug 2010 09:53:41 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1314297023.20100820095341@serebryakov.spb.ru> To: Doug Barton In-Reply-To: References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 06:13:56 -0000 Hello, Doug. You wrote 16 =E0=E2=E3=F3=F1=F2=E0 2010 =E3., 10:15:55: > lua too "flavor of the day," not enough track record of stability, > not enough installed base/proven utility To be honest, lua is used in TONS of (commercial and, often, console) games as scripting engine, without any issues with stability or speed. Console games are very special world, where stability is holy cow, BTW. >> some JavaScript engines probably fit the description. > Yikes! Sorry I asked. :) Best scripting language ever :) Mixup of Lisp and Self, disguised to looks like "traditional" language. And, yes, I'm serious here. But JavaScript have one problem: both good open-source engines (SpiderMonkey and V8) don't have good "system" library for file/io/process operations. They are too-browser specific. They can be easily stipped down to bare engines (very small, very efficient), but in such case here is huge amount of work by writing all native objects and operations needed for system scripting. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 06:32:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7750106564A for ; Fri, 20 Aug 2010 06:32:26 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 759FE8FC14 for ; Fri, 20 Aug 2010 06:32:26 +0000 (UTC) Received: (qmail 16508 invoked by uid 399); 20 Aug 2010 06:32:25 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Aug 2010 06:32:25 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6E2178.3020902@FreeBSD.org> Date: Thu, 19 Aug 2010 23:32:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4C6D4CB4.20601@icyb.net.ua> <4C6D6A3C.9020507@FreeBSD.org> <20100819174314.E48418@maildrop.int.zabbadoz.net> In-Reply-To: <20100819174314.E48418@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Runaway intr, not flash related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 06:32:27 -0000 On 08/19/2010 10:43, Bjoern A. Zeeb wrote: > On Thu, 19 Aug 2010, Doug Barton wrote: > >> On 08/19/2010 08:24, Andriy Gapon wrote: >>> I am sorry, but I don't see anything dramatically wrong here. So >>> "swi4: clock" uses 5.76% of WCPU, is that such a big deal to be >>> called "runaway intr"? >> >> That's the symptom. > > Have you ever posted a vmstat -i for when this actually happens? Yes. At the time I was told that it was uninteresting, but I'll include it again next time. Thanks, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 06:56:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F03421065694 for ; Fri, 20 Aug 2010 06:56:54 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id ADAB78FC15 for ; Fri, 20 Aug 2010 06:56:54 +0000 (UTC) Received: by qyk4 with SMTP id 4so3091918qyk.13 for ; Thu, 19 Aug 2010 23:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.87.1 with SMTP id u1mr611318qal.292.1282287413814; Thu, 19 Aug 2010 23:56:53 -0700 (PDT) Received: by 10.229.25.130 with HTTP; Thu, 19 Aug 2010 23:56:53 -0700 (PDT) X-Originating-IP: [91.14.61.29] In-Reply-To: References: Date: Fri, 20 Aug 2010 08:56:53 +0200 Message-ID: From: Bernhard Schmidt To: Chris Ruiz Content-Type: multipart/mixed; boundary=00c09f8a4d8ccce85d048e3bcd34 Cc: freebsd-current Current Subject: Re: recent ath changes related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 06:56:55 -0000 --00c09f8a4d8ccce85d048e3bcd34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt wr= ote: > On Fri, Aug 20, 2010 at 01:04, Chris Ruiz wrote: >> I run a PCI Atheros card in hostap mode on CURRENT. >> >> ath0@pci0:6:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x5a001385 chip= =3D0x0013168c >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Atheros Communications Inc.' >> =A0 =A0device =A0 =A0 =3D '802.11a/b/g Wireless Adapter (AR2312)' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> >> Everything works fine with r211193 but with newer kernels I receive >> the same panic related to the ath0 tasq. > > > I guess this also happens with post-r211314 kernels? Seems like I missed you wrap a few ieee80211_ratectl_node_init() calls. Please try attached patch, it should fix it. --=20 Bernhard --00c09f8a4d8ccce85d048e3bcd34 Content-Type: text/x-diff; charset=US-ASCII; name="node_init.diff" Content-Disposition: attachment; filename="node_init.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gd2ostx50 SW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfbm9kZS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9u ZXQ4MDIxMS9pZWVlODAyMTFfbm9kZS5jCShyZXZpc2lvbiAyMTE1MjQpCisrKyBzeXMvbmV0ODAy MTEvaWVlZTgwMjExX25vZGUuYwkod29ya2luZyBjb3B5KQpAQCAtODE3LDggKzgxNyw3IEBAIGll ZWU4MDIxMV9zdGFfam9pbihzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAsIHN0cnVjCiAJaWYgKGll ZWU4MDIxMV9pc2VycF9yYXRlc2V0KCZuaS0+bmlfcmF0ZXMpKQogCQluaS0+bmlfZmxhZ3MgfD0g SUVFRTgwMjExX05PREVfRVJQOwogCWllZWU4MDIxMV9ub2RlX3NldHVwdHhwYXJtcyhuaSk7Ci0J aWYgKHZhcC0+aXZfY2FwcyAmIElFRUU4MDIxMV9DX1JBVEVDVEwpCi0JCWllZWU4MDIxMV9yYXRl Y3RsX25vZGVfaW5pdChuaSk7CisJaWVlZTgwMjExX3JhdGVjdGxfbm9kZV9pbml0KG5pKTsKIAog CXJldHVybiBpZWVlODAyMTFfc3RhX2pvaW4xKGllZWU4MDIxMV9yZWZfbm9kZShuaSkpOwogfQpJ bmRleDogc3lzL25ldDgwMjExL2llZWU4MDIxMV9zdGEuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0 ODAyMTEvaWVlZTgwMjExX3N0YS5jCShyZXZpc2lvbiAyMTE1MjQpCisrKyBzeXMvbmV0ODAyMTEv aWVlZTgwMjExX3N0YS5jCSh3b3JraW5nIGNvcHkpCkBAIC0xNTk3LDggKzE1OTcsNyBAQCBzdGFf cmVjdl9tZ210KHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmksIHN0cnVjdCBtYgogCQkJICAgICBJ RUVFODAyMTFfRl9KT0lOIHwgSUVFRTgwMjExX0ZfRE9CUlMpOwogCQkJaWVlZTgwMjExX3NldHVw X2Jhc2ljX2h0cmF0ZXMobmksIGh0aW5mbyk7CiAJCQlpZWVlODAyMTFfbm9kZV9zZXR1cHR4cGFy bXMobmkpOwotCQkJaWYgKHZhcC0+aXZfY2FwcyAmIElFRUU4MDIxMV9DX1JBVEVDVEwpCi0JCQkJ aWVlZTgwMjExX3JhdGVjdGxfbm9kZV9pbml0KG5pKTsKKwkJCWllZWU4MDIxMV9yYXRlY3RsX25v ZGVfaW5pdChuaSk7CiAJCX0gZWxzZSB7CiAjaWZkZWYgSUVFRTgwMjExX1NVUFBPUlRfU1VQRVJH CiAJCQlpZiAoSUVFRTgwMjExX0FUSF9DQVAodmFwLCBuaSwgSUVFRTgwMjExX05PREVfQVRIKSkK SW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfcmF0ZWN0bC5oCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9uZXQ4MDIxMS9pZWVlODAyMTFfcmF0ZWN0bC5oCShyZXZpc2lvbiAyMTE1MjQpCisrKyBzeXMv bmV0ODAyMTEvaWVlZTgwMjExX3JhdGVjdGwuaAkod29ya2luZyBjb3B5KQpAQCAtNzcsNyArNzcs OCBAQCBpZWVlODAyMTFfcmF0ZWN0bF9ub2RlX2luaXQoc3RydWN0IGllZWU4MDIxMV9ub2RlCiB7 CiAJY29uc3Qgc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwID0gbmktPm5pX3ZhcDsKIAotCXZhcC0+ aXZfcmF0ZS0+aXJfbm9kZV9pbml0KG5pKTsKKwlpZiAodmFwLT5pdl9jYXBzICYgSUVFRTgwMjEx X0NfUkFURUNUTCkKKwkJdmFwLT5pdl9yYXRlLT5pcl9ub2RlX2luaXQobmkpOwogfQogCiBzdGF0 aWMgdm9pZCBfX2lubGluZQo= --00c09f8a4d8ccce85d048e3bcd34-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 06:57:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C9DB1065709 for ; Fri, 20 Aug 2010 06:57:21 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8D98FC17 for ; Fri, 20 Aug 2010 06:57:21 +0000 (UTC) Received: by mail-qy0-f182.google.com with SMTP id 4so3091918qyk.13 for ; Thu, 19 Aug 2010 23:57:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.3 with SMTP id 3mr250174qch.266.1282285882574; Thu, 19 Aug 2010 23:31:22 -0700 (PDT) Received: by 10.229.25.130 with HTTP; Thu, 19 Aug 2010 23:31:22 -0700 (PDT) X-Originating-IP: [91.14.61.29] In-Reply-To: References: Date: Fri, 20 Aug 2010 08:31:22 +0200 Message-ID: From: Bernhard Schmidt To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Current Subject: Re: recent ath changes related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 06:57:21 -0000 On Fri, Aug 20, 2010 at 01:04, Chris Ruiz wrote: > I run a PCI Atheros card in hostap mode on CURRENT. > > ath0@pci0:6:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x5a001385 chip= =3D0x0013168c > rev=3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Atheros Communications Inc.' > =A0 =A0device =A0 =A0 =3D '802.11a/b/g Wireless Adapter (AR2312)' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet > > Everything works fine with r211193 but with newer kernels I receive > the same panic related to the ath0 tasq. I guess this also happens with post-r211314 kernels? > the panic - > http://tinypic.com/r/11t3g39/4 > > the backtrace - > http://tinypic.com/r/nv4786/4 > > Sorry about the pics, =A0I don't have access to serial or dcons. > > -- Chris Ruiz > > ----------------------------------------- > http://twitter.com/chrisattack > http://chrisattack.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Bernhard From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 07:05:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBC8610656A3 for ; Fri, 20 Aug 2010 07:05:31 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 91DD88FC26 for ; Fri, 20 Aug 2010 07:05:31 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B12A.dip.t-dialin.net [87.179.177.42]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 254A2844010; Fri, 20 Aug 2010 09:05:25 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 09F0613DC; Fri, 20 Aug 2010 09:05:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1282287922; bh=Dp5suOfU4xFyhAHbiUY+TbeST+Ne278XS9ZBxEzN+vU=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SFg3HoH4937VeXrF/DF3azBMg0y/Fps+BPOkCJUrIIfzFfYfR53kZ5/nzr5QVoG0n ZzVDkml/3TDtLp5uS5oYFsTkTJh5VYQB4AeH2f7nQf1XtrxLCwfA0JpqmBi3O4ClkH ZWq7Rc+3DebunU8TocD3AJiJWPhjYcUlbg93LIfsa+eqvi4G6YM/4WpMaoKriG/n0t KLulvocAXvenX4ahgLZif3rXUiVA1m5Uy2gplPJCsG9IbiYZLGtlNG4+4fBnb8xAt5 2GLO5Y1h6QcnXw5ednhuNR3Y5KYpBsDDnUKUpjVLgEM4qPVhaZQq7jvFdwwI+LepTK trCMoIJuQUp9A== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o7K75LMP002969; Fri, 20 Aug 2010 09:05:21 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 20 Aug 2010 09:05:21 +0200 Message-ID: <20100820090521.63233enpg5276tes@webmail.leidinger.net> Date: Fri, 20 Aug 2010 09:05:21 +0200 From: Alexander Leidinger To: Anton Shterenlikht References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net> <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 254A2844010.A501C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.023, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_BM 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1282892728.90181@AhQk1S1lWlD3ygl+Doyosw X-EBL-Spam-Status: No Cc: current@freebsd.org Subject: HPC/CUDA on FreeBSD (was: Re: Removal of ICC (intel compiler) bits from mk) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 07:05:32 -0000 Hi, I'm taking out arch and some people from the CC and only keep =20 current@. This is getting off topic for the initial thread. Quoting Anton Shterenlikht (from Thu, 19 Aug =20 2010 21:10:24 +0100): > On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote: >> >> Quoting Dag-Erling Sm=C3=83??rgrav (from Thu, 19 Aug 2010 >> 11:16:23 +0200): >> >> > Alexander Leidinger writes: >> >> If someone would get icc 11.x up and runnig as a port (similar to wha= t >> >> we have for outdated icc version in the ports collection), I would >> >> have a look if my contact at Intel is still working there in a >> >> position which allows him to get a commercial license for us. >> > >> > Does that really matter? We're not going to start building releases >> > with icc, are we? >> >> It could matter for ports, I do not know if it matters for parts in >> src. The commercial license is also the only way that we could get icc >> installed on machines in the FreeBSD cluster (if there's interest to >> have another compiler *for FreeBSD development* to check the source >> against... the warnng and error messages are better that those of gcc, >> I do not know how they compare to clang). > > If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then > this becomes a somewhat different discussion. One of the stubmling > blocks for HPC on FreeBSD (just one of many, perhaps not even the > major one) is a complete lack of good quality commercial compilers. > All we=C3=83'got is gcc or clang. Both are not really that great, and > definitely inferior to commercial compilers, e.g. Intel. What I=C3=83'm > saying is that it would be great if Intel sold a compiler for FreeBSD. > I'd ve bought a copy. But from what others have said, my impression is th= at > the ICC port is unlikely to fill this void. After I (and other people which provided patches) ported icc to =20 FreeBSD someone from IIRC Asia took the port as an example and ported =20 Intels Fortran compiler to FreeBSD in the same way (he was able to use =20 a lot of the icc port, only some minor modifications where necessary). I had the impression that this was used for HPC. > P.S. My interests and expertise are in computational mechanics, not in > compilers, so feel free to correct me if I=C3=83'm wrong. In general: The resulting code (for icc and ifc) was working. The =20 application binary code itself was/is the same (modulo differences in =20 system headers), the "only" things which need to be changed are the =20 startup code and the libs. We managed to do that. > P.P.S. Regarding FreeBSD HPC see also this thead: > http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.= html > (FreeBSD, GPGPU and OpenCL/CUDA) That's not the way we would like it to be, but at least it is possible: http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freeb= sdamd64-nvidia-driver/ When I was working on icc, I had an idea about a liblinux2freebsd =20 which would provide common linux-symbols and map them to =20 FreeBSD-equivalents (together with some predefined objdump/objcopy/... =20 scripts to modify linux libs) so that you can take a linux lib and use =20 it to create native FreeBSD programs. Sort of like the NDIS layer in =20 the kernel to run Windows binary drivers. Unfortunately I never got =20 the time to work on this. Something like this could have maybe been =20 used to "mangle" the linux cuda libs to be used on FreeBSD natively. Bye, Alexander. --=20 Neither spread the germs of gossip nor encourage others to do so. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 09:05:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 244DA10656A4; Fri, 20 Aug 2010 09:05:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CFEBC8FC13; Fri, 20 Aug 2010 09:05:27 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DDB6D1FFC34; Fri, 20 Aug 2010 09:05:25 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B7FC18456E; Fri, 20 Aug 2010 11:05:25 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Anton Shterenlikht References: <65F17C45-55C1-4349-A4D1-A3D6AD0D9A80@FreeBSD.org> <4C6C1EB1.5000004@FreeBSD.org> <20100819090128.22597bbvyogdw9wk@webmail.leidinger.net> <86fwybdkt4.fsf@ds4.des.no> <20100819113548.72614imi2zxx9log@webmail.leidinger.net> <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> Date: Fri, 20 Aug 2010 11:05:25 +0200 In-Reply-To: <20100819201024.GA20254@mech-cluster241.men.bris.ac.uk> (Anton Shterenlikht's message of "Thu, 19 Aug 2010 21:10:24 +0100") Message-ID: <86d3tdy7qi.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Rui Paulo , "current@freebsd.org" , Garrett Cooper , "arch@freebsd.org" , Gabor Kovesdan , Alexander Leidinger Subject: Re: Removal of ICC (intel compiler) bits from mk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:05:28 -0000 Anton Shterenlikht writes: >> It could matter for ports, I do not know if it matters for parts in=20=20 >> src. The commercial license is also the only way that we could get icc= =20=20 >> installed on machines in the FreeBSD cluster [...] > If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, Not "FreeBSD clusters", but "*the* FreeBSD cluster", i.e. the .f.o machines hosted by Y!. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 09:06:58 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20A15106566B; Fri, 20 Aug 2010 09:06:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 96FF78FC14; Fri, 20 Aug 2010 09:06:57 +0000 (UTC) Received: by iwn36 with SMTP id 36so3160409iwn.13 for ; Fri, 20 Aug 2010 02:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=tNN1r0XB+KlxdJvQSvChg2j3gfg45GZsaTtpGoIxnVA=; b=kKzoc7O1D7wOoWbtwEm0ErLjKZ1k4G1YLhJ/HuxDj20E6lPrvg0fA4iqEZl0T7ANf2 7tYpeZ1fHta5Go6vcSAeepJitQqj2lihZuMVmn1kkwSiGj5y9hLLjDmFWjEBEIHNeJDg vXPjwEoYzy9DIKDJm9d9IjNiQptwnL4PLtyhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ide/izpEwjUe2VdYwwUFLG7pPqVkJdOMMxdRxdGbO4//KZH7EActo3M03jblxkP7Tc mgOX1ZslLxBLTbD4LMJa0Hh1vvfLf/FojECUKUs5GNdBq+vnmMrBIzf5LOCXN2y8JhIa dSyVUWF8/jXVnOUZZs+WrQeHArW5ak+p860+o= MIME-Version: 1.0 Received: by 10.231.19.3 with SMTP id y3mr1188426iba.156.1282295216792; Fri, 20 Aug 2010 02:06:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.168.14 with HTTP; Fri, 20 Aug 2010 02:06:56 -0700 (PDT) In-Reply-To: <86aaoirac1.fsf@ds4.des.no> References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <86aaoirac1.fsf@ds4.des.no> Date: Fri, 20 Aug 2010 17:06:56 +0800 X-Google-Sender-Auth: JP6i15qk7E-WF3mR29KOxJySnyY Message-ID: From: Adrian Chadd To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , current@freebsd.org, core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Dimitry Andric Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:06:58 -0000 2010/8/19 Dag-Erling Sm=F8rgrav : > =A0time =A0 seconds =A0 seconds =A0 =A0calls =A0ms/call =A0ms/call =A0nam= e > =A038.8 =A0 =A0 =A0 0.03 =A0 =A0 0.03 =A0 =A012717 =A0 =A0 0.00 =A0 =A0 0= .00 =A0memchr [5] > =A035.6 =A0 =A0 =A0 0.07 =A0 =A0 0.03 =A0 =A0 =A0395 =A0 =A0 0.08 =A0 =A0= 0.08 =A0_read [6] > =A016.4 =A0 =A0 =A0 0.08 =A0 =A0 0.01 =A0 =A0 =A0 =A00 =A0100.00% =A0 =A0= =A0 =A0 =A0 _mcount [7] memchr()? Really? I've just looked at grep_fgetln(). Surely memchr() isn't required there. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 09:10:22 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1DC91065673; Fri, 20 Aug 2010 09:10:22 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8287F8FC0C; Fri, 20 Aug 2010 09:10:22 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 629961FFC33; Fri, 20 Aug 2010 09:10:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 37E288456E; Fri, 20 Aug 2010 11:10:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Barton References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> <867hjmdfdo.fsf@ds4.des.no> <4C6D794F.4090801@FreeBSD.org> Date: Fri, 20 Aug 2010 11:10:21 +0200 In-Reply-To: <4C6D794F.4090801@FreeBSD.org> (Doug Barton's message of "Thu, 19 Aug 2010 11:34:55 -0700") Message-ID: <868w41y7ia.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:10:22 -0000 Doug Barton writes: > There are 2 questions, did I do the right thing, and how should people > report problems in general. As for myself, while I have some facility > in C it's not my strong suit. Yes, I could have produced a profiling > version of grep, but it would have taken me a lot more than 10 minutes > because I don't even build the profiled libs on a regular basis. That's fair. I didn't use to do that because it increases build time considerably, but now I do. If you have profiling libraries installed, you can build a profiling version of grep (or any program) like so: % cd /usr/src/usr.bin/grep % make clean % make DEBUG_FLAGS=3D"-pg -g" -DNO_SHARED Do *not" make install, because the result will be dog slow and you don't want to use it in production. Every time you run it, it will leave a file named grep.gmon in your current directory, so: % /usr/obj/usr/src/usr.bin/grep/grep -q "^xfce4-wm" /usr/ports/INDEX-9 % gprof /usr/obj/usr/src/usr.bin/grep/grep grep.gmon | less > More generally however I think that we need to be realistic with what > we expect people to do about reporting problems. This is not about "what we expect people to do" but about "what I expect *you*, an experienced FreeBSD committer, to do" :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 09:26:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5402210656A7; Fri, 20 Aug 2010 09:26:35 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0E74E8FC17; Fri, 20 Aug 2010 09:26:34 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 5E7381FFC33; Fri, 20 Aug 2010 09:26:33 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 349588456E; Fri, 20 Aug 2010 11:26:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Whitehorn References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> Date: Fri, 20 Aug 2010 11:26:33 +0200 In-Reply-To: <4C6D557E.6080406@freebsd.org> (Nathan Whitehorn's message of "Thu, 19 Aug 2010 09:02:06 -0700") Message-ID: <86sk29ws6u.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:26:35 -0000 Nathan Whitehorn writes: > The problem is that until yesterday, you could not build a powerpc64 > LINT, and so it was trying to build a PPC32 kernel with a 64-bit > toolchain. An actual powerpc64 kernel does not include > ofw_standard.c. This should be fixed now with r211483, so long as the > LINT config is made with TARGET_ARCH set (and is not reused for 32 and > 64-bit builds). There is a seat-belt mechanism I should add soon that > will complain earlier about architecture mismatches like this. Thanks > for your patience. >>> stage 3.2: building everything [...] /src/sys/powerpc/fpu/fpu_emu.c: In function 'fpu_execute': /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsi= gned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsi= gned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsi= gned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsi= gned int', but argument 5 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsi= gned int', but argument 3 has type 'long int' /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsi= gned int', but argument 4 has type 'vm_offset_t' /src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsi= gned int', but argument 3 has type 'register_t' *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 09:53:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 258CA1065672 for ; Fri, 20 Aug 2010 09:53:30 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mxf2.bahnhof.se (mxf2.bahnhof.se [213.80.101.26]) by mx1.freebsd.org (Postfix) with ESMTP id CA89C8FC1D for ; Fri, 20 Aug 2010 09:53:29 +0000 (UTC) Received: from localhost (mxf2.local [127.0.0.1]) by mxf2-reinject (Postfix) with ESMTP id 67265969660 for ; Fri, 20 Aug 2010 11:36:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MXF2) X-Spam-Flag: YES X-Spam-Score: 5.068 X-Spam-Level: ***** X-Spam-Status: Yes, score=5.068 tagged_above=-99 required=5 tests=[DNS_FROM_RFC_POST=1.708, J_CHICKENPOX_44=0.6, RATWARE_GECKO_BUILD=1.691, SPF_NEUTRAL=1.069] X-Spam-Report: * 1.7 RATWARE_GECKO_BUILD Bulk email fingerprint (Gecko faked) found * 1.1 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) * [SPF failed: Please see http://www.openspf.org/why.html?sender=niclas.zeising%40gmail.com&ip=79.136.90.99&receiver=mxf2.bahnhof.se] * 0.6 J_CHICKENPOX_44 BODY: 4alpha-pock-4alpha * 1.7 DNS_FROM_RFC_POST RBL: Envelope sender in * postmaster.rfc-ignorant.org Received: from mxf2.bahnhof.se ([127.0.0.1]) by localhost (mxf2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3T4A-h8WFNq for ; Fri, 20 Aug 2010 11:36:32 +0200 (CEST) Received: from [10.32.0.4] (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) by mxf2.bahnhof.se (Postfix) with ESMTP id 828AA969554 for ; Fri, 20 Aug 2010 11:36:32 +0200 (CEST) Message-ID: <4C6E4C9D.8030306@gmail.com> Date: Fri, 20 Aug 2010 11:36:29 +0200 From: Niclas Zeising User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <20100818.121635.431102609571763034.imp@bsdimp.com> <86bp8zdkp4.fsf@ds4.des.no> <4C6D0BBB.90304@continum.net> <867hjmdfdo.fsf@ds4.des.no> <4C6D794F.4090801@FreeBSD.org> <868w41y7ia.fsf@ds4.des.no> In-Reply-To: <868w41y7ia.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [SPAM] Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 09:53:30 -0000 On 2010-08-20 11:10, Dag-Erling Smørgrav wrote: > > If you have profiling libraries installed, you can build a profiling > version of grep (or any program) like so: > > % cd /usr/src/usr.bin/grep > % make clean > % make DEBUG_FLAGS="-pg -g" -DNO_SHARED > > Do *not" make install, because the result will be dog slow and you don't > want to use it in production. Every time you run it, it will leave a > file named grep.gmon in your current directory, so: > As a side note, this maybe should be posted in the handbook and/or on the wiki for reference, so people who want to profile slow applications know how to do it. Regards! //Niclas From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 10:51:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2B81065695; Fri, 20 Aug 2010 10:51:46 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6154F8FC08; Fri, 20 Aug 2010 10:51:46 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 063F21FFC33; Fri, 20 Aug 2010 10:51:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D16E8844E9; Fri, 20 Aug 2010 12:51:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <86aaoirac1.fsf@ds4.des.no> Date: Fri, 20 Aug 2010 12:51:44 +0200 In-Reply-To: (Adrian Chadd's message of "Fri, 20 Aug 2010 17:06:56 +0800") Message-ID: <86zkwhr1z3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , current@freebsd.org, core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Dimitry Andric Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:51:46 -0000 Adrian Chadd writes: > I've just looked at grep_fgetln(). Surely memchr() isn't required there. Of course it is, how else are you going to locate the '\n'? OTOH, I'm not sure grep_fgetln() is needed at all. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 10:57:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB141065670; Fri, 20 Aug 2010 10:57:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E00EB8FC14; Fri, 20 Aug 2010 10:57:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7KAvnJ1083569; Fri, 20 Aug 2010 06:57:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7KAvnHb083568; Fri, 20 Aug 2010 10:57:49 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 20 Aug 2010 10:57:49 GMT Message-Id: <201008201057.o7KAvnHb083568@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 10:57:50 -0000 TB --- 2010-08-20 08:41:47 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-20 08:41:47 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-20 08:41:47 - cleaning the object tree TB --- 2010-08-20 08:42:39 - cvsupping the source tree TB --- 2010-08-20 08:42:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-20 08:44:17 - building world TB --- 2010-08-20 08:44:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-20 08:44:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-20 08:44:17 - TARGET=powerpc TB --- 2010-08-20 08:44:17 - TARGET_ARCH=powerpc64 TB --- 2010-08-20 08:44:17 - TZ=UTC TB --- 2010-08-20 08:44:17 - __MAKE_CONF=/dev/null TB --- 2010-08-20 08:44:17 - cd /src TB --- 2010-08-20 08:44:17 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 20 08:44:17 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Aug 20 10:26:25 UTC 2010 TB --- 2010-08-20 10:26:25 - generating LINT kernel config TB --- 2010-08-20 10:26:25 - cd /src/sys/powerpc/conf TB --- 2010-08-20 10:26:25 - /usr/bin/make -B LINT TB --- 2010-08-20 10:26:25 - building LINT kernel TB --- 2010-08-20 10:26:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-20 10:26:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-20 10:26:25 - TARGET=powerpc TB --- 2010-08-20 10:26:25 - TARGET_ARCH=powerpc64 TB --- 2010-08-20 10:26:25 - TZ=UTC TB --- 2010-08-20 10:26:25 - __MAKE_CONF=/dev/null TB --- 2010-08-20 10:26:25 - cd /src TB --- 2010-08-20 10:26:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 20 10:26:25 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Aug 20 10:52:26 UTC 2010 TB --- 2010-08-20 10:52:26 - building GENERIC kernel TB --- 2010-08-20 10:52:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-20 10:52:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-20 10:52:26 - TARGET=powerpc TB --- 2010-08-20 10:52:26 - TARGET_ARCH=powerpc64 TB --- 2010-08-20 10:52:26 - TZ=UTC TB --- 2010-08-20 10:52:26 - __MAKE_CONF=/dev/null TB --- 2010-08-20 10:52:26 - cd /src TB --- 2010-08-20 10:52:26 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Aug 20 10:52:26 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-20 10:57:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-20 10:57:49 - ERROR: failed to build GENERIC kernel TB --- 2010-08-20 10:57:49 - 5629.71 user 1551.20 system 8161.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 12:36:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD0F1065695; Fri, 20 Aug 2010 12:36:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 022458FC08; Fri, 20 Aug 2010 12:36:28 +0000 (UTC) Received: by yxe42 with SMTP id 42so1407997yxe.13 for ; Fri, 20 Aug 2010 05:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=uFoQHqycCswY5c8PJ6X/Cqbc40UaWernRBuuy5Q5FZ0=; b=t7oA2TcYdqv+7uKc1fzwj/PRR3PF4aBYXpHZ7sqUKiFkeWJCWdrHtoGRKEr6EXvQ/q R0IvF8bIEZsTl6VcRWN/dNR9uVlEx0TsvxqRS7s/v0FBUEUVgCGjf8e29Q/8dx0Nx1tm xp0Xc4jhpgznzs49zhLf37HwNPakLd9j6+47Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iuPEY/DAwgbPPoCKHXirjpOxADqHCNGQBwTtn0+Zamx1Ql4mROoxRZq2+ZwkqYQqq8 u79+sGS47mYPcmieb+hPmqOeLx0glmeAM8IW1Mlg+si2z6OJQxhTBUFEm14JbL7gliR7 q4Vz6l3DH5dGyqknGaKufSjiW24WY9i1rBp1A= MIME-Version: 1.0 Received: by 10.101.127.5 with SMTP id e5mr1534674ann.138.1282307787855; Fri, 20 Aug 2010 05:36:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.168.14 with HTTP; Fri, 20 Aug 2010 05:36:26 -0700 (PDT) In-Reply-To: <86zkwhr1z3.fsf@ds4.des.no> References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <86aaoirac1.fsf@ds4.des.no> <86zkwhr1z3.fsf@ds4.des.no> Date: Fri, 20 Aug 2010 20:36:26 +0800 X-Google-Sender-Auth: Z1qVmn4pJhLaqcSY5CkbHhXBGdA Message-ID: From: Adrian Chadd To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , current@freebsd.org, core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Dimitry Andric Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:36:29 -0000 2010/8/20 Dag-Erling Sm=F8rgrav : > Adrian Chadd writes: >> I've just looked at grep_fgetln(). Surely memchr() isn't required there. > > Of course it is, how else are you going to locate the '\n'? =A0OTOH, I'm > not sure grep_fgetln() is needed at all. It seems a bit strange that memchr(), which should be hitting data that's in the cache (as it was recently read, right?) is showing up so high in the profiling results. memchr() in libc/string/memchr.c looks like how I'd inline it, so, hm. Have you tried this in pmc? Adrian From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 12:45:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 613401065674; Fri, 20 Aug 2010 12:45:31 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1568FC0A; Fri, 20 Aug 2010 12:45:30 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 13D031FFC34; Fri, 20 Aug 2010 12:45:30 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C22AE8456E; Fri, 20 Aug 2010 14:45:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd References: <4C6505A4.9060203@FreeBSD.org> <4C6C1CFE.6060900@FreeBSD.org> <86aaoirac1.fsf@ds4.des.no> <86zkwhr1z3.fsf@ds4.des.no> Date: Fri, 20 Aug 2010 14:45:29 +0200 In-Reply-To: (Adrian Chadd's message of "Fri, 20 Aug 2010 20:36:26 +0800") Message-ID: <8662z5o3km.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , current@freebsd.org, core@freebsd.org, delphij@freebsd.org, Gabor Kovesdan , Dimitry Andric Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:45:31 -0000 Adrian Chadd writes: > Have you tried this in pmc? No. I can't figure out how to use pmcstat, but I did find a bug in it: if you specify an output file with -o, but the command line is otherwise incomplete or incorrect, it will print usage information to the output file instead of stderr. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 14:25:52 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1698D1065697; Fri, 20 Aug 2010 14:25:52 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id DB2618FC12; Fri, 20 Aug 2010 14:25:51 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L7G00100DB2SS00@smtpauth2.wiscmail.wisc.edu>; Fri, 20 Aug 2010 08:25:50 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.72.125]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L7G00CBEDB0LV40@smtpauth2.wiscmail.wisc.edu>; Fri, 20 Aug 2010 08:25:50 -0500 (CDT) Date: Fri, 20 Aug 2010 08:25:48 -0500 From: Nathan Whitehorn In-reply-to: <86sk29ws6u.fsf@ds4.des.no> To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Message-id: <4C6E825C.5060509@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.72.125 X-Spam-PmxInfo: Server=avs-11, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.8.20.131215, SenderIP=76.210.72.125 References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100729 Thunderbird/3.0.6 Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:25:52 -0000 On 08/20/10 04:26, Dag-Erling Smørgrav wrote: > Nathan Whitehorn writes: > >> The problem is that until yesterday, you could not build a powerpc64 >> LINT, and so it was trying to build a PPC32 kernel with a 64-bit >> toolchain. An actual powerpc64 kernel does not include >> ofw_standard.c. This should be fixed now with r211483, so long as the >> LINT config is made with TARGET_ARCH set (and is not reused for 32 and >> 64-bit builds). There is a seat-belt mechanism I should add soon that >> will complain earlier about architecture mismatches like this. Thanks >> for your patience. >> > >>>> stage 3.2: building everything >>>> > [...] > /src/sys/powerpc/fpu/fpu_emu.c: In function 'fpu_execute': > /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' > /src/sys/powerpc/fpu/fpu_emu.c:329: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' > /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' > /src/sys/powerpc/fpu/fpu_emu.c:359: warning: format '%x' expects type 'unsigned int', but argument 5 has type 'long int' > /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long int' > /src/sys/powerpc/fpu/fpu_emu.c:376: warning: format '%x' expects type 'unsigned int', but argument 4 has type 'vm_offset_t' > /src/sys/powerpc/fpu/fpu_emu.c:778: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'register_t' > *** Error code 1 > > Stop in /obj/powerpc.powerpc64/src/sys/LINT. > OK, that one is fixed now too. :) Next up: tinderbox needs to build GENERIC64, not GENERIC, on powerpc64. make buildkernel is programmed to do the right thing is you don't pass a KERNCONF, but tinderbox apparently passes GENERIC explicitly. This one's in your court! -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 16:11:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 430A010656A4 for ; Fri, 20 Aug 2010 16:11:07 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id E595A8FC16 for ; Fri, 20 Aug 2010 16:11:04 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OmUBJ-0006pD-Um for current@freebsd.org; Fri, 20 Aug 2010 18:11:02 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmUBI-0000Oy-J5 for current@freebsd.org; Fri, 20 Aug 2010 18:11:00 +0200 Message-Id: To: current@freebsd.org From: "Ian FREISLICH" X-Attribution: BOFH Date: Fri, 20 Aug 2010 18:11:00 +0200 Cc: Subject: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:11:07 -0000 Hi I have a system that relies on Fuse and OWFS to manage the power at my house. I get the following panic when writing to to one of the PIO devices: The panic isn't really helpful because it looks like the stack frame has been broken. Have others seen this? I've tried rebuilding everything from a clean slate but it doesn't help. The machine used to be -STABLE, which worked until 21 April 2010, but no kernel since has worked. brane.freislich.nom.za dumped core - see /var/crash/vmcore.7 Fri Aug 20 16:07:17 SAST 2010 FreeBSD brane.freislich.nom.za 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Aug 20 13:53:55 SAST 2010 ianf@brane.freislich.nom.za:/usr/obj/usr/src/sys/BRANE i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xe75d3b50 frame pointer = 0x28:0xe75d3c14 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 56578 (sh) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at kdb_backtrace+0x29 panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b trap(e75d3b10) at trap+0x423 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- uart_z8530_class(c784ab00,ffffff9c,284052c4,0,402,...) at 0 kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at syscallenter+0x343 syscall(e75d3d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, ebp = 0xbfbfea28 --- Uptime: 1h49m31s Physical memory: 2007 MB Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 No symbol "stopped_cpus" in current context. No symbol "stoppcbs" in current context. Reading symbols from /boot/kernel/puc.ko...Reading symbols from /boot/kernel/puc.ko.symbols...done. done. Loaded symbols for /boot/kernel/puc.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc05b4923 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc05b4b4f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc0759543 in trap_fatal (frame=0xe75d3b10, eva=0) at /usr/src/sys/i386/i386/trap.c:941 #4 0xc07597ab in trap_pfault (frame=0xe75d3b10, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:854 #5 0xc0759cb3 in trap (frame=0xe75d3b10) at /usr/src/sys/i386/i386/trap.c:529 #6 0xc074365c in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x00000000 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 8 0 0 0 - DLs ?? 306287:15.00 [kernel] 0 1 0 0 44 0 8032 496 wait DLs ?? 8248871:42.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? 4280098:17.00 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? 32358964:51.00 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 25140601:54.00 [g_down] 0 5 0 0 -16 0 0 0 pftm DL ?? 709006:55.00 [pfpurge] 0 6 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd 0 7 0 0 -16 0 0 0 psleep DL ?? 111034:23.00 [pagedaem 0 8 0 0 -16 0 0 0 psleep DL ?? 50:11.00 [vmdaemon 0 9 0 0 76 0 0 0 pgzero DL ?? 2229:36.00 [pagezero 0 10 0 0 171 0 0 0 - RL ?? -32573570:-46.55 [idle] 0 11 0 0 -60 0 0 0 - WL ?? -29804148:-20.55 [intr] 0 12 0 0 -16 0 0 0 - DL ?? 15760116:47.00 [yarrow] 0 13 0 0 -64 0 0 0 - DL ?? 9764491:03.00 [usb] 0 14 0 0 -16 0 0 0 tzpoll DL ?? 5327193:44.00 [acpi_the 0 15 0 0 -16 0 0 0 coolin DL ?? 94312:20.00 [acpi_coo 0 16 0 0 44 0 0 0 psleep DL ?? 24015582:25.00 [bufdaemo 0 17 0 0 44 0 0 0 syncer DL ?? 1458594:59.00 [syncer] 0 18 0 0 -16 0 0 0 vlruwt DL ?? 539998:14.00 [vnlru] 0 19 0 0 44 0 0 0 sdflus DL ?? 33298541:20.00 [softdepf 0 27845 1 0 76 0 1640 892 pause Ds ?? 6213:05.00 [adjkernt 0 28536 1 0 76 0 9712 1212 select Ds ?? 3559:40.00 [moused] 0 28553 1 0 44 0 8032 696 select Ds ?? 847133:08.00 [devd] 0 28572 1 0 76 0 9800 1596 sbwait Ds ?? 294006:26.00 [pflogd] 64 28574 28572 0 44 0 9800 1656 bpf D ?? 3335558:42.00 [pflogd] 0 28779 1 0 44 0 9616 1472 select Ds ?? 1190554:09.00 [syslogd] 53 28794 1 0 44 0 35992 19368 kqread Ds ?? 14804697:15.00 [named] 0 28818 1 0 44 0 9644 1504 select Ds ?? 208787:24.00 [rpcbind] 0 28988 1 0 76 0 9532 1416 select Ds ?? 105927:50.00 [lpd] 70 29103 1 0 44 0 44336 5116 select Ds ?? 2997888:33.00 [postgres 70 29105 29103 0 44 0 44336 5424 select Ds ?? 14961987:51.00 [postgres 70 29106 29103 0 44 0 12528 4184 select Ds ?? 1038570:19.00 [postgres 26 29201 1 0 44 0 14144 3900 select Ds ?? 980587:29.00 [exim-4.7 0 29262 1 0 44 0 12988 3968 select Ds ?? 76126:28.00 [sshd] 0 29273 1 0 52 0 9644 1524 nanslp Ds ?? 1104871:52.00 [cron] 0 29305 1 0 76 0 9676 1332 select Ds ?? 11270:29.00 [inetd] 0 29339 1 0 76 0 9616 1252 ttyin Ds+ ?? 55592:11.00 [getty] 0 29340 1 0 76 0 9616 1252 ttyin Ds+ ?? 42957:15.00 [getty] 0 29341 1 0 76 0 9616 1252 ttyin Ds+ ?? 41741:08.00 [getty] 0 29342 1 0 76 0 9616 1252 ttyin Ds+ ?? 43682:07.00 [getty] 0 29343 1 0 76 0 9616 1252 ttyin Ds+ ?? 42346:22.00 [getty] 0 29344 1 0 76 0 9616 1252 ttyin Ds+ ?? 43069:56.00 [getty] 0 29345 1 0 76 0 9616 1252 ttyin Ds+ ?? 43107:53.00 [getty] 0 29346 1 0 76 0 9616 1252 ttyin Ds+ ?? 44075:21.00 [getty] 0 29347 1 0 44 0 10048 1928 wait Ds ?? 387233:46.00 [login] 0 39521 29347 0 44 0 9892 1764 ttyin D+ ?? 544541:14.00 [sh] 0 44418 1 0 44 0 11228 2640 select Ds ?? 5839856:06.00 [ntpd] 1000 45103 97479 0 44 0 11212 4844 select D ?? -31017170:-55.55 [perl] 0 56378 1 0 54 0 11492 1916 fu_msg Ds ?? 87736:30.00 [owfs] 1000 56578 97479 0 44 0 9892 1532 - R+ ?? 0:00.00 [sh] 0 57989 1 0 44 0 10188 2428 select Ds ?? -23813812:-31.55 [screen] 0 57990 57989 0 51 0 10828 2548 ttyin Ds+ ?? 656705:26.00 [bash] 0 75221 29262 0 46 0 15712 4756 sbwait Ds ?? 1397537:31.00 [sshd] 1000 75223 75221 0 44 0 15712 4780 select D ?? 10666399:15.00 [sshd] 1000 75224 75223 0 45 0 10828 2544 wait Ds ?? 190136:43.00 [bash] 0 75227 75224 0 44 0 10044 1908 wait D ?? 168236:33.00 [su] 0 75228 75227 0 44 0 10828 2524 wait D ?? 124223:03.00 [bash] 0 75229 75228 0 44 0 10188 2280 pause D+ ?? 404415:12.00 [screen] 0 97423 29262 0 46 0 15712 4756 sbwait Ds ?? 1470712:26.00 [sshd] 1000 97469 97423 0 44 0 15712 4748 select D ?? 11267771:57.00 [sshd] 1000 97479 97469 0 44 0 10828 2468 wait Ds ?? 311046:58.00 [bash] ------------------------------------------------------------------------ vmstat -s 5927091 cpu context switches 2037250 device interrupts 1337655 software interrupts 49077340 traps 173266014 system calls 19 kernel threads created 332276 fork() calls 123727 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 15900 vnode pager pageins 66917 vnode pager pages paged in 376 vnode pager pageouts 376 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 581 pages reactivated 8460226 copy-on-write faults 2068 copy-on-write optimized faults 29553775 zero fill pages zeroed 1343392 zero fill pages prezeroed 11 intransit blocking page faults 46831577 total VM faults taken 0 pages affected by kernel thread creation 317038645 pages affected by fork() 112597829 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 42931623 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 9615 pages active 101549 pages inactive 27 pages in VM cache 36303 pages wired down 357114 pages free 4096 bytes per page 25766502 total name lookups cache hits (88% pos + 8% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) sigio 1 1K - 1 32 filedesc 91 64K - 456335 16,32,64,128,256,512,1024,2048,4096 kenv 77 7K - 81 16,32,64,128,4096 kqueue 2 5K - 1275 128,256,1024,4096 proc-args 42 3K - 310324 16,32,64,128,256 drm_maps 1 1K - 1 64 ithread 102 9K - 103 16,64,128 KTRACE 100 13K - 100 128 drm_driver 4 5K - 8 16,64,256,4096 linker 86 81K - 148 16,32,64,128,512,1024,4096 lockf 23 2K - 1163 32,64 drm_sarea 1 1K - 1 16 temp 149 211K - 691955 16,32,64,128,256,512,1024,2048,4096 devbuf 3134 4146K - 3309 16,32,64,128,256,512,1024,2048,4096 drm_dma 1 1K - 1 16 module 216 14K - 217 64,128 kbdmux 7 18K - 7 16,256,1024,2048 mtx_pool 2 8K - 2 4096 osd 2 1K - 2 16,32 subproc 147 266K - 456112 256,4096 proc 2 8K - 2 4096 session 33 3K - 372 64 pgrp 39 3K - 586 64 cred 66 7K - 2074138 64,128 uidinfo 7 2K - 87 64,1024 plimit 19 5K - 7121 256 CAM periph 2 1K - 5 16,32,128 sysctltmp 0 0K - 19899 16,32,64,128 sysctloid 3061 93K - 3196 16,32,64 sysctl 0 0K - 102808 16,32,64 umtx 280 27K - 280 64,128 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 ddb_capture 1 48K - 1 bus-sc 65 107K - 1521 16,32,64,128,256,512,1024,2048 bus 762 38K - 4231 16,32,64,128,256,512,1024 devstat 4 9K - 4 16,4096 eventhandler 76 4K - 77 32,64,128 kobj 162 324K - 179 2048 Per-cpu 1 1K - 1 16 agp 1 1K - 1 16 rman 206 13K - 574 16,32,64 CAM XPT 5 2K - 12 16,32,64,1024 sbuf 0 0K - 343 16,32,64,128,256,512,1024,2048,4096 CAM dev queue 1 1K - 1 128 CAM queue 3 1K - 7 16 stack 0 0K - 2 128 taskqueue 9 1K - 9 16,64 Unitno 14 1K - 782 16,64 iov 0 0K - 25538 16,64,128,256 select 67 5K - 67 64 ioctlops 0 0K - 169970 16,32,64,128,256,512,1024 msg 4 25K - 4 1024,4096 sem 4 101K - 4 1024,4096 shm 4 15K - 68 1024 tty 26 13K - 141 512,2048 pts 3 1K - 116 128 mbuf_tag 0 0K - 1 32 shmfd 1 4K - 1 4096 ppbusdev 1 1K - 1 128 pcb 23 7K - 1717 16,512,1024,2048 soname 6 1K - 9156 16,32,128 acl 0 0K - 20564 4096 biobuf 71 142K - 9314 2048 vfscache 1 512K - 1 cl_savebuf 0 0K - 8192 32,64 vfs_hash 1 256K - 1 vnodes 3 1K - 11 32,128 vnodemarker 0 0K - 1749 512 mount 94 3K - 210 16,32,64,128,256 BPF 9 65K - 10 16,64,256 ether_multi 7 1K - 8 16,32,64 ifaddr 40 9K - 40 16,32,256,2048 ifnet 6 6K - 6 64,1024 entropy 1024 64K - 1024 64 clone 4 16K - 5 4096 arpcom 2 1K - 2 16 lltable 8 2K - 8 128,256 ata_generic 2 2K - 2 1024 UART 12 6K - 12 16,256,1024 USBdev 39 9K - 39 32,128,256,1024,2048 USB 66 77K - 74 16,32,64,128,1024,2048,4096 ad_driver 1 1K - 1 32 routetbl 11 2K - 148 16,32,64,128,256 igmp 5 1K - 5 128 acd_driver 1 2K - 1 2048 CAM SIM 1 1K - 1 128 in_multi 2 1K - 2 128 hostcache 1 16K - 1 syncache 1 72K - 1 savedino 0 0K - 49275 256 freework 1 1K - 163160 64 newdirblk 0 0K - 9617 32 dirrem 1 1K - 141359 64 mkdir 0 0K - 18624 64 diradd 1 1K - 142994 64 freefile 3 1K - 127270 32 freeblks 1 1K - 121940 64 freefrag 0 0K - 59952 64 indirdep 1 1K - 1613 64 newblk 3 65K - 324053 128 bmsafemap 2 5K - 1909 128,4096 inodedep 15 260K - 219956 256 pagedep 2 65K - 19292 128 ufs_dirhash 228 44K - 1425 16,32,64,128,256,512 ufs_mount 12 69K - 21 256,2048,4096 UMAHash 1 1K - 3 256,512,1024 DEVFS1 137 35K - 251 256 vm_pgdata 2 65K - 2 64 DEVFS3 162 21K - 276 128 atkbddev 1 1K - 1 32 memdesc 1 4K - 1 4096 nexusdev 4 1K - 4 16 DEVFS 27 1K - 28 16,64 linux 14 1K - 14 32,64 DEVFSP 2 1K - 2 32 pfs_nodes 169 22K - 169 128 drm_ctxbitmap 1 4K - 1 4096 GEOM 69 15K - 167 16,64,128,512,1024,2048 isadev 8 1K - 8 64 drm_agplists 1 1K - 1 64 io_apic 2 2K - 2 1024 cdev 9 2K - 9 128 acpica 1863 97K - 71981 16,32,64,128,256,512,1024 acpitask 1 1K - 1 1024 pci_link 16 2K - 16 64,128 acpisem 15 2K - 15 64,128 PUC 4 1K - 4 32,256 apmdev 1 1K - 1 64 acpidev 57 2K - 57 32 acpipwr 1 1K - 1 32 fuse_messaging 5 2K - 8 128,256,512,1024 fuse_filehandles 1 1K - 44 64 fuse_vnode 29 8K - 29 256 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 128, 0, 89, 1, 89, 0, 0 UMA Zones: 152, 0, 89, 7, 89, 0, 0 UMA Slabs: 284, 0, 1402, 12, 1899, 0, 0 UMA RCntSlabs: 544, 0, 204, 6, 204, 0, 0 UMA Hash: 128, 0, 2, 28, 3, 0, 0 16 Bucket: 76, 0, 36, 14, 36, 0, 0 32 Bucket: 140, 0, 59, 25, 59, 0, 0 64 Bucket: 268, 0, 58, 12, 58, 0, 0 128 Bucket: 524, 0, 2005, 4, 2005,2324, 0 VM OBJECT: 136, 0, 28684, 12931, 5719386, 0, 0 MAP: 140, 0, 7, 49, 7, 0, 0 KMAP ENTRY: 72, 57505, 30, 129, 16796, 0, 0 MAP ENTRY: 72, 0, 1046, 438,10907676, 0, 0 DP fakepg: 72, 0, 0, 0, 0, 0, 0 SG fakepg: 72, 0, 0, 0, 0, 0, 0 mt_zone: 76, 0, 209, 41, 209, 0, 0 16: 16, 0, 2676, 369, 218984, 0, 0 32: 32, 0, 2329, 11796, 591034, 0, 0 64: 64, 0, 4567, 43223, 1961616, 0, 0 128: 128, 0, 1945, 7865, 1511081, 0, 0 256: 256, 0, 729, 20556, 769786, 0, 0 512: 512, 0, 163, 53, 295755, 0, 0 1024: 1024, 0, 54, 122, 15622, 0, 0 2048: 2048, 0, 271, 1671, 9689, 0, 0 4096: 4096, 0, 115, 36, 486502, 0, 0 Files: 56, 0, 130, 272, 3534124, 0, 0 TURNSTILE: 72, 0, 141, 39, 141, 0, 0 umtx pi: 52, 0, 0, 0, 0, 0, 0 PROC: 680, 0, 60, 24, 456022, 0, 0 THREAD: 704, 0, 124, 16, 282, 0, 0 SLEEPQUEUE: 44, 0, 141, 95, 141, 0, 0 VMSPACE: 240, 0, 42, 38, 456003, 0, 0 cpuset: 40, 0, 2, 182, 2, 0, 0 mbuf_packet: 256, 0, 256, 140, 71609, 0, 0 mbuf: 256, 0, 2, 394, 140999, 0, 0 mbuf_cluster: 2048, 25600, 384, 6, 384, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 9, 75, 0, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 140, 0, 0, 3164, 929046, 0, 0 ttyinq: 152, 0, 480, 66, 8565, 0, 0 ttyoutq: 256, 0, 251, 34, 4444, 0, 0 ata_request: 208, 0, 1, 797, 235403, 0, 0 ata_composite: 180, 0, 0, 0, 0, 0, 0 VNODE: 272, 0, 34124, 12104, 196226, 0, 0 VNODEPOLL: 60, 0, 1, 125, 1, 0, 0 NAMEI: 1024, 0, 0, 12, 8349730, 0, 0 S VFS Cache: 72, 0, 35128, 11300, 414636, 0, 0 L VFS Cache: 292, 0, 331, 59, 1277, 0, 0 DIRHASH: 1024, 0, 368, 192, 1551, 0, 0 pipe: 392, 0, 4, 26, 204010, 0, 0 ksiginfo: 80, 0, 74, 982, 733, 0, 0 itimer: 220, 0, 1, 35, 4, 0, 0 KNOTE: 72, 0, 6, 100, 11843, 0, 0 socket: 412, 25605, 42, 57, 2341, 0, 0 ipq: 32, 904, 0, 0, 0, 0, 0 udp_inpcb: 220, 25614, 9, 81, 1781, 0, 0 udpcb: 8, 25781, 9, 194, 1781, 0, 0 tcp_inpcb: 220, 25614, 13, 41, 230, 0, 0 tcpcb: 632, 25602, 12, 12, 230, 0, 0 tcptw: 52, 5184, 1, 143, 82, 0, 0 syncache: 112, 15365, 0, 70, 129, 0, 0 hostcache: 76, 15400, 9, 91, 18, 0, 0 tcpreass: 20, 1690, 0, 169, 9552, 0, 0 sackhole: 20, 0, 0, 169, 71, 0, 0 ripcb: 220, 25614, 0, 36, 21, 0, 0 unpcb: 172, 25622, 20, 26, 305, 0, 0 rtentry: 108, 0, 4, 68, 4, 0, 0 pfsrctrpl: 124, 0, 0, 0, 0, 0, 0 pfrulepl: 828, 0, 0, 0, 0, 0, 0 pfstatepl: 284, 10010, 0, 0, 0, 0, 0 pfaltqpl: 224, 0, 0, 0, 0, 0, 0 pfpooladdrpl: 68, 0, 0, 0, 0, 0, 0 pfrktable: 1240, 0, 0, 0, 0, 0, 0 pfrkentry: 156, 0, 0, 0, 0, 0, 0 pfrkentry2: 156, 0, 0, 0, 0, 0, 0 pffrent: 16, 5075, 0, 0, 0, 0, 0 pffrag: 48, 0, 0, 0, 0, 0, 0 pffrcache: 48, 10062, 0, 0, 0, 0, 0 pffrcent: 12, 50141, 0, 0, 0, 0, 0 pfstatescrub: 28, 0, 0, 0, 0, 0, 0 pfiaddrpl: 100, 0, 0, 0, 0, 0, 0 pfospfen: 108, 0, 0, 0, 0, 0, 0 pfosfp: 28, 0, 0, 0, 0, 0, 0 selfd: 28, 0, 112, 142,60027973, 0, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0, 0 Mountpoints: 648, 0, 6, 6, 9, 0, 0 FFS inode: 116, 0, 34049, 12151, 195941, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 34049, 12136, 195941, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 2 0 irq0: attimer0 834491 2418 irq3: uart1 33065 95 irq4: uart0 154540 447 irq14: ata0 232411 673 irq15: ata1 25 0 irq16: uhci0 21 0 irq19: uhci1 16 0 irq20: puc0 uart2+ 636041 1843 irq23: ehci0 18283 52 irq24: re0 128350 372 cpu0:timer 6570306 19044 Total 8607551 24949 ------------------------------------------------------------------------ pstat -T 130/12328 files 0M/1996M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ad0s1b 4088976 0 4088976 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics iostat: kvm_getcptime: invalid address (0x0) iostat: disabling CPU time statistics ad0 KB/t tps MB/s 13.86 673 9.11 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 2 32571392 29103 29103 14:19:22 16:00:29 14:19:22 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 5432001 --rw------- pgsql pgsql pgsql pgsql 17 14:19:22 14:19:22 s 65537 5432002 --rw------- pgsql pgsql pgsql pgsql 17 14:19:22 14:19:22 s 65538 5432003 --rw------- pgsql pgsql pgsql pgsql 17 14:19:22 14:19:22 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmap: 30 (# of entries in semaphore map) semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 616 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: kvm_nlist: can't get names ------------------------------------------------------------------------ netstat -s tcp: 74465 packets sent 50412 data packets (5860981 bytes) 85 data packets (52300 bytes) retransmitted 4 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 19347 ack-only packets (276 delayed) 0 URG only packets 0 window probe packets 4340 window update packets 281 control packets 62397 packets received 27848 acks (for 5858054 bytes) 568 duplicate acks 0 acks for unsent data 25262 packets (25484049 bytes) received in-sequence 55 completely duplicate packets (54515 bytes) 1 old duplicate packet 1 packet with some dup. data (416 bytes duped) 9552 out-of-order packets (9355410 bytes) 0 packets (0 bytes) of data after window 0 window probes 108 window update packets 17 packets received after close 637 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 24 discarded due to memory problems 79 connection requests 129 connection accepts 0 bad connection attempts 0 listen queue overflows 60 ignored RSTs in the windows 207 connections established (including accepts) 217 connections closed (including 21 drops) 186 connections updated cached RTT on close 186 connections updated cached RTT variance on close 1 connection updated cached ssthresh on close 1 embryonic connection dropped 27814 segments updated rtt (of 19294 attempts) 25 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 1 correct ACK header prediction 23157 correct data packet header predictions 129 syncache entries added 1 retransmitted 2 dupsyn 0 dropped 129 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 129 cookies sent 0 cookies received 43 SACK recovery episodes 58 segment rexmits in SACK recovery episodes 29868 byte rexmits in SACK recovery episodes 467 SACK options (SACK blocks) received 7893 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 3240 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 56 dropped due to no socket 101 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 3083 delivered 3576 datagrams output 0 times multicast source filter matched ip: 65718 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 65658 packets for this host 60 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 78171 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 56 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: destination unreachable: 56 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: echo reply: 21 destination unreachable: 60 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent carp: 0 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 0 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error pfsync: 0 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets discarded for bad ttl 0 packets shorter than header 0 packets discarded for bad version 0 packets discarded for bad HMAC 0 packets discarded for bad action 0 packets discarded for short packet 0 states discarded for bad values 0 stale states 0 failed state lookup/inserts 0 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error 0 send error arp: 258 ARP requests sent 181 ARP replies sent 2046 ARP requests received 113 ARP replies received 2159 ARP packets received 255 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ------------------------------------------------------------------------ netstat -m 258/534/792 mbufs in use (current/cache/total) 244/146/390/25600 mbuf clusters in use (current/cache/total/max) 256/140 mbuf+clusters out of packet secondary zone in use (current/cache) 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) 552K/461K/1014K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop re0 1500 00:30:4f:52:39:70 64608 0 0 75086 0 0 0 re0 1500 41.154.0.8/29 41.154.0.9 63726 - - 74902 - - - re1* 1500 00:01:29:2d:41:49 0 0 0 0 0 0 0 pfsyn 1460 0 0 0 0 0 0 0 lo0 16384 3269 0 0 3269 0 0 0 lo0 16384 your-net localhost 1891 - - 3269 - - - pflog 33200 0 0 0 0 0 0 0 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 41.154.0.14 UGS 0 74808 re0 41.154.0.8/29 link#1 U 0 94 re0 41.154.0.9 link#1 UHS 0 1378 lo0 127.0.0.1 link#4 UH 0 1891 lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c782e1a0 tcp4 0 0 127.0.0.1.22341 127.0.0.1.5432 TIME_WAIT c78bb000 tcp4 0 48 41.154.0.9.22 196.7.162.28.42945 ESTABLISHED c78bbc58 tcp4 0 0 41.154.0.9.22 196.7.162.28.59568 ESTABLISHED c77d1768 tcp4 0 0 *.22 *.* LISTEN c7809278 tcp4 0 0 127.0.0.1.587 *.* LISTEN c78094f0 tcp4 0 0 127.0.0.1.25 *.* LISTEN c77d1000 tcp4 0 0 41.154.0.9.587 *.* LISTEN c77d0768 tcp4 0 0 41.154.0.9.25 *.* LISTEN c77d0000 tcp4 0 0 *.5432 *.* LISTEN c77d0278 tcp4 0 0 *.515 *.* LISTEN c77d04f0 tcp4 0 0 *.111 *.* LISTEN c77d09e0 tcp4 0 0 127.0.0.1.953 *.* LISTEN c77d0c58 tcp4 0 0 41.154.0.9.53 *.* LISTEN c5000a50 udp4 0 0 41.154.0.9.60130 192.0.2.1.53 c50007bc udp4 0 0 127.0.0.1.123 *.* c77d60dc udp4 0 0 41.154.0.9.123 *.* c4fff1b8 udp4 0 0 *.123 *.* c50006e0 udp4 0 0 127.0.0.1.32314 127.0.0.1.32314 c5000528 udp4 0 0 *.862 *.* c4fffb2c udp4 0 0 *.111 *.* c4fff294 udp4 0 0 41.154.0.9.53 *.* c4fff370 udp4 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c75f0ac0 stream 0 0 0 c75f0b6c 0 0 c75f0b6c stream 0 0 0 c75f0ac0 0 0 c75f0764 stream 0 0 0 c75f06b8 0 0 c75f06b8 stream 0 0 0 c75f0764 0 0 c75f0d70 stream 0 0 0 c75f0ec8 0 0 c75f0ec8 stream 0 0 0 c75f0d70 0 0 c75f0968 stream 0 0 c721abb0 0 0 0 /tmp/.s.PGSQL.5432 c75f060c stream 0 0 c5480110 0 0 0 /var/run/printer c75f0408 stream 0 0 c5480dd0 0 0 0 /var/run/rpcbind.sock c75f02b0 stream 0 0 0 c75f035c 0 0 c75f035c stream 0 0 0 c75f02b0 0 0 c75f0c18 stream 0 0 c5435880 0 0 0 /var/run/devd.pipe c75f1000 dgram 0 0 0 c75f0000 0 c75f0204 c75f0204 dgram 0 0 0 c75f0000 0 c75f0560 c75f0a14 dgram 0 0 0 c75f00ac 0 0 c75f0560 dgram 0 0 0 c75f0000 0 c75f04b4 c75f04b4 dgram 0 0 0 c75f0000 0 c75f0158 c75f0158 dgram 0 0 0 c75f0000 0 0 c75f0000 dgram 0 0 c5489660 0 c75f1000 0 /var/run/logpriv c75f00ac dgram 0 0 c5489550 0 c75f0a14 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.ssh tcp4 0/0/20 localhost.submission tcp4 0/0/20 localhost.smtp tcp4 0/0/20 41.154.0.9.submission tcp4 0/0/20 41.154.0.9.smtp tcp4 0/0/80 *.postgresql tcp4 0/0/5 *.printer tcp4 0/0/128 *.sunrpc tcp4 0/0/128 localhost.rndc tcp4 0/0/3 41.154.0.9.domain unix 0/0/80 /tmp/.s.PGSQL.5432 unix 0/0/5 /var/run/printer unix 0/0/128 /var/run/rpcbind.sock unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W ianf sh 56578 root / 2 drwxr-xr-x 1024 r ianf sh 56578 wd /usr 11846887 drwxr-xr-x 6144 r ianf sh 56578 text / 17809 -r-xr-xr-x 120784 r ianf sh 56578 0 /dev 152 crw--w---- pts/3 rw ianf sh 56578 1 /dev 152 crw--w---- pts/3 rw ianf sh 56578 2 /dev 152 crw--w---- pts/3 rw ianf sh 56578 10 /usr 11894944 -rwxr-xr-x 243 r ianf sh 56578 11 /dev 152 crw--w---- pts/3 rw root owfs 56378 root / 2 drwxr-xr-x 1024 r root owfs 56378 wd / 2 drwxr-xr-x 1024 r root owfs 56378 text /usr 24494430 -rwxr-xr-x 41342 r root owfs 56378 0 /dev 15 crw-rw-rw- null rw root owfs 56378 1 /dev 15 crw-rw-rw- null rw root owfs 56378 2 /dev 15 crw-rw-rw- null rw root owfs 56378 3 /dev 120 crw------- ttyU1 rw root owfs 56378 4 /dev 109 crw------- ttyU0 rw root owfs 56378 5 /dev 153 crw-rw---- fuse0 rw ianf perl 45103 root / 2 drwxr-xr-x 1024 r ianf perl 45103 wd /usr 11846887 drwxr-xr-x 6144 r ianf perl 45103 text /usr 24494623 -rwxr-xr-x 4712 r ianf perl 45103 0 /dev 152 crw--w---- pts/3 rw ianf perl 45103 1 /dev 152 crw--w---- pts/3 rw ianf perl 45103 2 /dev 152 crw--w---- pts/3 rw ianf perl 45103 3 /dev 76 crw-rw---- cuau1 rw ianf bash 97479 root / 2 drwxr-xr-x 1024 r ianf bash 97479 wd /usr 11846887 drwxr-xr-x 6144 r ianf bash 97479 text /usr 24496001 -rwxr-xr-x 632468 r ianf bash 97479 0 /dev 152 crw--w---- pts/3 rw ianf bash 97479 1 /dev 152 crw--w---- pts/3 rw ianf bash 97479 2 /dev 152 crw--w---- pts/3 rw ianf bash 97479 255 /dev 152 crw--w---- pts/3 rw ianf sshd 97469 root / 2 drwxr-xr-x 1024 r ianf sshd 97469 wd / 2 drwxr-xr-x 1024 r ianf sshd 97469 text /usr 42158090 -r-xr-xr-x 232420 r ianf sshd 97469 0 /dev 15 crw-rw-rw- null rw ianf sshd 97469 1 /dev 15 crw-rw-rw- null rw ianf sshd 97469 2 /dev 15 crw-rw-rw- null rw ianf sshd 97469 3* internet stream tcp c78bb000 ianf sshd 97469 4* local stream c75f0b6c <-> c75f0ac0 ianf sshd 97469 5* pipe c500d498 <-> c500d550 0 rw ianf sshd 97469 6* pipe c500d550 <-> c500d498 0 rw ianf sshd 97469 7* pseudo-terminal master pts/3 rw ianf sshd 97469 9* pseudo-terminal master pts/3 rw ianf sshd 97469 10* pseudo-terminal master pts/3 rw root sshd 97423 root / 2 drwxr-xr-x 1024 r root sshd 97423 wd / 2 drwxr-xr-x 1024 r root sshd 97423 text /usr 42158090 -r-xr-xr-x 232420 r root sshd 97423 0 /dev 15 crw-rw-rw- null r root sshd 97423 1 /dev 15 crw-rw-rw- null rw root sshd 97423 2 /dev 15 crw-rw-rw- null rw root sshd 97423 3* internet stream tcp c78bb000 root sshd 97423 4* pseudo-terminal master pts/3 rw root sshd 97423 5* local stream c75f0ac0 <-> c75f0b6c root screen 75229 root / 2 drwxr-xr-x 1024 r root screen 75229 wd /usr 11846887 drwxr-xr-x 6144 r root screen 75229 text /usr 24495939 -rwsr-xr-x 301192 r root screen 75229 0 /dev 149 crw--w---- pts/2 rw root screen 75229 1 /dev 149 crw--w---- pts/2 rw root screen 75229 2 /dev 149 crw--w---- pts/2 rw root bash 75228 root / 2 drwxr-xr-x 1024 r root bash 75228 wd /usr 11846887 drwxr-xr-x 6144 r root bash 75228 text /usr 24496001 -rwxr-xr-x 632468 r root bash 75228 0 /dev 149 crw--w---- pts/2 rw root bash 75228 1 /dev 149 crw--w---- pts/2 rw root bash 75228 2 /dev 149 crw--w---- pts/2 rw root bash 75228 255 /dev 149 crw--w---- pts/2 rw root su 75227 root / 2 drwxr-xr-x 1024 r root su 75227 wd /usr 11846887 drwxr-xr-x 6144 r root su 75227 text /usr 38296097 -r-sr-xr-x 14676 r root su 75227 0 /dev 149 crw--w---- pts/2 rw root su 75227 1 /dev 149 crw--w---- pts/2 rw root su 75227 2 /dev 149 crw--w---- pts/2 rw ianf bash 75224 root / 2 drwxr-xr-x 1024 r ianf bash 75224 wd /usr 11846887 drwxr-xr-x 6144 r ianf bash 75224 text /usr 24496001 -rwxr-xr-x 632468 r ianf bash 75224 0 /dev 149 crw--w---- pts/2 rw ianf bash 75224 1 /dev 149 crw--w---- pts/2 rw ianf bash 75224 2 /dev 149 crw--w---- pts/2 rw ianf bash 75224 255 /dev 149 crw--w---- pts/2 rw ianf sshd 75223 root / 2 drwxr-xr-x 1024 r ianf sshd 75223 wd / 2 drwxr-xr-x 1024 r ianf sshd 75223 text /usr 42158090 -r-xr-xr-x 232420 r ianf sshd 75223 0 /dev 15 crw-rw-rw- null rw ianf sshd 75223 1 /dev 15 crw-rw-rw- null rw ianf sshd 75223 2 /dev 15 crw-rw-rw- null rw ianf sshd 75223 3* internet stream tcp c78bbc58 ianf sshd 75223 4* local stream c75f0ec8 <-> c75f0d70 ianf sshd 75223 5* pipe c500c000 <-> c500c0b8 0 rw ianf sshd 75223 6* pipe c500c0b8 <-> c500c000 0 rw ianf sshd 75223 7* pseudo-terminal master pts/2 rw ianf sshd 75223 9* pseudo-terminal master pts/2 rw ianf sshd 75223 10* pseudo-terminal master pts/2 rw root sshd 75221 root / 2 drwxr-xr-x 1024 r root sshd 75221 wd / 2 drwxr-xr-x 1024 r root sshd 75221 text /usr 42158090 -r-xr-xr-x 232420 r root sshd 75221 0 /dev 15 crw-rw-rw- null r root sshd 75221 1 /dev 15 crw-rw-rw- null rw root sshd 75221 2 /dev 15 crw-rw-rw- null rw root sshd 75221 3* internet stream tcp c78bbc58 root sshd 75221 4* pseudo-terminal master pts/2 rw root sshd 75221 5* local stream c75f0d70 <-> c75f0ec8 root bash 57990 root / 2 drwxr-xr-x 1024 r root bash 57990 wd /var 234887 drwxr-xr-x 1024 r root bash 57990 text /usr 24496001 -rwxr-xr-x 632468 r root bash 57990 0 /dev 151 crw--w---- pts/1 rw root bash 57990 1 /dev 151 crw--w---- pts/1 rw root bash 57990 2 /dev 151 crw--w---- pts/1 rw root bash 57990 255 /dev 151 crw--w---- pts/1 rw root screen 57989 root / 2 drwxr-xr-x 1024 r root screen 57989 wd /usr 11846887 drwxr-xr-x 6144 r root screen 57989 text /usr 24495939 -rwsr-xr-x 301192 r root screen 57989 0 /dev 15 crw-rw-rw- null r root screen 57989 1 /dev 15 crw-rw-rw- null w root screen 57989 2 /dev 15 crw-rw-rw- null w root screen 57989 3 /tmp 95 prwx------ 0 r root screen 57989 4 /dev 149 crw--w---- pts/2 rw root screen 57989 5 /var 70466 -rw-r--r-- 591 r root screen 57989 6* pseudo-terminal master pts/1 rw root ntpd 44418 root / 2 drwxr-xr-x 1024 r root ntpd 44418 wd / 2 drwxr-xr-x 1024 r root ntpd 44418 text /usr 42158375 -r-xr-xr-x 349228 r root ntpd 44418 0 /dev 15 crw-rw-rw- null rw root ntpd 44418 1 /dev 15 crw-rw-rw- null rw root ntpd 44418 2 /dev 15 crw-rw-rw- null rw root ntpd 44418 3* local dgram c75f1000 <-> c75f0000 root ntpd 44418 4 /var 164440 -rw-r--r-- 57025 w root ntpd 44418 5 /var 164422 -rw-r--r-- 1741190 w root ntpd 44418 6 /dev 36 crw-rw---- cuau2 rw root ntpd 44418 7 /var 211400 -rw-r--r-- 3584 rw root ntpd 44418 8 /dev 42 crw-rw---- cuau3 rw root ntpd 44418 9 /var 211401 -rw-r--r-- 3584 rw root ntpd 44418 10 /var 164441 -rw-r--r-- 20164 w root ntpd 44418 20* internet dgram udp c4fff1b8 root ntpd 44418 21* internet dgram udp c77d60dc root ntpd 44418 22* internet dgram udp c50007bc root ntpd 44418 23* route raw 0 c77e680c root sh 39521 root / 2 drwxr-xr-x 1024 r root sh 39521 wd / 16461 drwxr-xr-x 512 r root sh 39521 text / 17809 -r-xr-xr-x 120784 r root sh 39521 0 /dev 67 crw------- ttyu0 rw root sh 39521 1 /dev 67 crw------- ttyu0 rw root sh 39521 2 /dev 67 crw------- ttyu0 rw root sh 39521 10 /dev 67 crw------- ttyu0 rw root login 29347 root / 2 drwxr-xr-x 1024 r root login 29347 wd / 16461 drwxr-xr-x 512 r root login 29347 text /usr 38295942 -r-sr-xr-x 21924 r root login 29347 0 /dev 67 crw------- ttyu0 rw root login 29347 1 /dev 67 crw------- ttyu0 rw root login 29347 2 /dev 67 crw------- ttyu0 rw root login 29347 3* local dgram c75f0204 <-> c75f0000 root getty 29346 root / 2 drwxr-xr-x 1024 r root getty 29346 wd / 2 drwxr-xr-x 1024 r root getty 29346 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29346 0 /dev 53 crw------- ttyv7 rw root getty 29346 1 /dev 53 crw------- ttyv7 rw root getty 29346 2 /dev 53 crw------- ttyv7 rw root getty 29345 root / 2 drwxr-xr-x 1024 r root getty 29345 wd / 2 drwxr-xr-x 1024 r root getty 29345 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29345 0 /dev 52 crw------- ttyv6 rw root getty 29345 1 /dev 52 crw------- ttyv6 rw root getty 29345 2 /dev 52 crw------- ttyv6 rw root getty 29344 root / 2 drwxr-xr-x 1024 r root getty 29344 wd / 2 drwxr-xr-x 1024 r root getty 29344 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29344 0 /dev 51 crw------- ttyv5 rw root getty 29344 1 /dev 51 crw------- ttyv5 rw root getty 29344 2 /dev 51 crw------- ttyv5 rw root getty 29343 root / 2 drwxr-xr-x 1024 r root getty 29343 wd / 2 drwxr-xr-x 1024 r root getty 29343 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29343 0 /dev 50 crw------- ttyv4 rw root getty 29343 1 /dev 50 crw------- ttyv4 rw root getty 29343 2 /dev 50 crw------- ttyv4 rw root getty 29342 root / 2 drwxr-xr-x 1024 r root getty 29342 wd / 2 drwxr-xr-x 1024 r root getty 29342 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29342 0 /dev 49 crw------- ttyv3 rw root getty 29342 1 /dev 49 crw------- ttyv3 rw root getty 29342 2 /dev 49 crw------- ttyv3 rw root getty 29341 root / 2 drwxr-xr-x 1024 r root getty 29341 wd / 2 drwxr-xr-x 1024 r root getty 29341 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29341 0 /dev 48 crw------- ttyv2 rw root getty 29341 1 /dev 48 crw------- ttyv2 rw root getty 29341 2 /dev 48 crw------- ttyv2 rw root getty 29340 root / 2 drwxr-xr-x 1024 r root getty 29340 wd / 2 drwxr-xr-x 1024 r root getty 29340 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29340 0 /dev 47 crw------- ttyv1 rw root getty 29340 1 /dev 47 crw------- ttyv1 rw root getty 29340 2 /dev 47 crw------- ttyv1 rw root getty 29339 root / 2 drwxr-xr-x 1024 r root getty 29339 wd / 2 drwxr-xr-x 1024 r root getty 29339 text /usr 20584686 -r-xr-xr-x 21760 r root getty 29339 0 /dev 46 crw------- ttyv0 rw root getty 29339 1 /dev 46 crw------- ttyv0 rw root getty 29339 2 /dev 46 crw------- ttyv0 rw root inetd 29305 root / 2 drwxr-xr-x 1024 r root inetd 29305 wd / 2 drwxr-xr-x 1024 r root inetd 29305 text /usr 42158316 -r-xr-xr-x 42736 r root inetd 29305 0 /dev 15 crw-rw-rw- null rw root inetd 29305 1 /dev 15 crw-rw-rw- null rw root inetd 29305 2 /dev 15 crw-rw-rw- null rw root inetd 29305 3 /var 70522 -rw------- 5 w root inetd 29305 4* pipe c500d000 <-> c500d0b8 0 rw root inetd 29305 5* pipe c500d0b8 <-> c500d000 0 rw root cron 29273 root / 2 drwxr-xr-x 1024 r root cron 29273 wd /var 211495 drwxr-x--- 512 r root cron 29273 text /usr 42158176 -r-xr-xr-x 34464 r root cron 29273 0 /dev 15 crw-rw-rw- null rw root cron 29273 1 /dev 15 crw-rw-rw- null rw root cron 29273 2 /dev 15 crw-rw-rw- null rw root cron 29273 3 /var 70521 -rw------- 5 w root sshd 29262 root / 2 drwxr-xr-x 1024 r root sshd 29262 wd / 2 drwxr-xr-x 1024 r root sshd 29262 text /usr 42158090 -r-xr-xr-x 232420 r root sshd 29262 0 /dev 15 crw-rw-rw- null rw root sshd 29262 1 /dev 15 crw-rw-rw- null rw root sshd 29262 2 /dev 15 crw-rw-rw- null rw root sshd 29262 3* internet stream tcp c77d1768 mailnull exim-4.72-0 29201 root / 2 drwxr-xr-x 1024 r mailnull exim-4.72-0 29201 wd /var 93953 drwxr-x--- 512 r mailnull exim-4.72-0 29201 text /usr 24541512 -rwsr-xr-x 877756 r mailnull exim-4.72-0 29201 0 /dev 15 crw-rw-rw- null rw mailnull exim-4.72-0 29201 1 /dev 15 crw-rw-rw- null rw mailnull exim-4.72-0 29201 2 /dev 15 crw-rw-rw- null rw mailnull exim-4.72-0 29201 3* internet stream tcp c77d0768 mailnull exim-4.72-0 29201 4* internet stream tcp c77d1000 mailnull exim-4.72-0 29201 5* internet stream tcp c78094f0 mailnull exim-4.72-0 29201 6* internet stream tcp c7809278 mailnull exim-4.72-0 29201 9 /var 187908 -rw-r----- 903663 w pgsql postgres 29106 root / 2 drwxr-xr-x 1024 r pgsql postgres 29106 wd /usr 24944078 drwx------ 512 r pgsql postgres 29106 text /usr 24495550 -rwxr-xr-x 2968772 r pgsql postgres 29106 0 /dev 15 crw-rw-rw- null rw pgsql postgres 29106 1 /dev 15 crw-rw-rw- null rw pgsql postgres 29106 2 /dev 15 crw-rw-rw- null rw pgsql postgres 29106 5* local dgram c75f0a14 <-> c75f00ac pgsql postgres 29106 6* internet dgram udp c50006e0 pgsql postgres 29105 root / 2 drwxr-xr-x 1024 r pgsql postgres 29105 wd /usr 24944078 drwx------ 512 r pgsql postgres 29105 text /usr 24495550 -rwxr-xr-x 2968772 r pgsql postgres 29105 0 /dev 15 crw-rw-rw- null rw pgsql postgres 29105 1 /dev 15 crw-rw-rw- null rw pgsql postgres 29105 2 /dev 15 crw-rw-rw- null rw pgsql postgres 29105 5* local dgram c75f0a14 <-> c75f00ac pgsql postgres 29105 6* internet dgram udp c50006e0 pgsql postgres 29105 7 /usr 24988964 -rw------- 16777216 rw pgsql postgres 29103 root / 2 drwxr-xr-x 1024 r pgsql postgres 29103 wd /usr 24944078 drwx------ 512 r pgsql postgres 29103 text /usr 24495550 -rwxr-xr-x 2968772 r pgsql postgres 29103 0 /dev 15 crw-rw-rw- null rw pgsql postgres 29103 1 /dev 15 crw-rw-rw- null rw pgsql postgres 29103 2 /dev 15 crw-rw-rw- null rw pgsql postgres 29103 3* internet stream tcp c77d0000 pgsql postgres 29103 4* local stream c75f0968 pgsql postgres 29103 5* local dgram c75f0a14 <-> c75f00ac pgsql postgres 29103 6* internet dgram udp c50006e0 root lpd 28988 root / 2 drwxr-xr-x 1024 r root lpd 28988 wd / 2 drwxr-xr-x 1024 r root lpd 28988 text /usr 42158332 -r-xr-xr-x 76384 r root lpd 28988 0 /dev 15 crw-rw-rw- null rw root lpd 28988 1 /dev 15 crw-rw-rw- null rw root lpd 28988 2 /dev 15 crw-rw-rw- null rw root lpd 28988 3* local dgram c75f0560 <-> c75f0000 root lpd 28988 4 /var 93997 -rw-rw-r-- 6 w root lpd 28988 5* local stream c75f060c root lpd 28988 6* internet stream tcp c77d0278 root rpcbind 28818 root / 2 drwxr-xr-x 1024 r root rpcbind 28818 wd / 2 drwxr-xr-x 1024 r root rpcbind 28818 text /usr 42158494 -r-xr-xr-x 39588 r root rpcbind 28818 0 /dev 15 crw-rw-rw- null rw root rpcbind 28818 1 /dev 15 crw-rw-rw- null rw root rpcbind 28818 2 /dev 15 crw-rw-rw- null rw root rpcbind 28818 3 /var 70509 -r--r--r-- 0 r root rpcbind 28818 5* local stream c75f0408 root rpcbind 28818 6* local dgram c75f04b4 <-> c75f0000 root rpcbind 28818 7* internet dgram udp c4fffb2c root rpcbind 28818 8* internet dgram udp c5000528 root rpcbind 28818 9* internet stream tcp c77d04f0 bind named 28794 root / 2 drwxr-xr-x 1024 r bind named 28794 wd / 32958 drwxr-xr-x 512 r bind named 28794 text /usr 42158313 -r-xr-xr-x 1957456 r bind named 28794 0 /dev 15 crw-rw-rw- null rw bind named 28794 1 /dev 15 crw-rw-rw- null rw bind named 28794 2 /dev 15 crw-rw-rw- null rw bind named 28794 3* local dgram c75f0158 <-> c75f0000 bind named 28794 4 /dev 15 crw-rw-rw- null rw bind named 28794 5* pipe c500c188 <-> c500c240 0 rw bind named 28794 7* pipe c500c240 <-> c500c188 0 rw bind named 28794 9 /dev 25 crw-rw-rw- random r bind named 28794 20* internet stream tcp c77d0c58 bind named 28794 21* internet stream tcp c77d09e0 bind named 28794 512* internet dgram udp c4fff294 bind named 28794 514* internet dgram udp c5000a50 root syslogd 28779 root / 2 drwxr-xr-x 1024 r root syslogd 28779 wd / 2 drwxr-xr-x 1024 r root syslogd 28779 text /usr 42158509 -r-xr-xr-x 35984 r root syslogd 28779 0 /dev 15 crw-rw-rw- null rw root syslogd 28779 1 /dev 15 crw-rw-rw- null rw root syslogd 28779 2 /dev 15 crw-rw-rw- null rw root syslogd 28779 3 /var 70494 -rw------- 5 w root syslogd 28779 4* local dgram c75f00ac root syslogd 28779 5* local dgram c75f0000 root syslogd 28779 6* internet dgram udp c4fff370 root syslogd 28779 7 /dev 14 crw------- klog r root syslogd 28779 9 - - bad - root syslogd 28779 10 /var 164534 -rw-r--r-- 3799383 w root syslogd 28779 11 /var 164577 -rw------- 60 w root syslogd 28779 12 /var 164497 -rw------- 9340748 w root syslogd 28779 13 /var 164530 -rw-r----- 778934 w root syslogd 28779 14 /var 164459 -rw-r--r-- 51244 w root syslogd 28779 15 /var 164463 -rw------- 14969 w root syslogd 28779 16 /var 164436 -rw------- 18198 w root syslogd 28779 17 /var 164506 -rw------- 41941 w root syslogd 28779 18 /var 164563 -rw-r----- 60 w _pflogd pflogd 28574 root /var 12 dr-xr-xr-x 512 r _pflogd pflogd 28574 wd /var 12 dr-xr-xr-x 512 r _pflogd pflogd 28574 jail /var 12 dr-xr-xr-x 512 r _pflogd pflogd 28574 text / 1463 -r-xr-xr-x 18880 r _pflogd pflogd 28574 0 /dev 15 crw-rw-rw- null rw _pflogd pflogd 28574 1 /dev 15 crw-rw-rw- null rw _pflogd pflogd 28574 2 /dev 15 crw-rw-rw- null rw _pflogd pflogd 28574 3 /dev 11 crw------- bpf rw _pflogd pflogd 28574 4 /var 164557 -rw------- 24 rw _pflogd pflogd 28574 5* local stream c75f02b0 <-> c75f035c root pflogd 28572 root / 2 drwxr-xr-x 1024 r root pflogd 28572 wd / 2 drwxr-xr-x 1024 r root pflogd 28572 text / 1463 -r-xr-xr-x 18880 r root pflogd 28572 0 /dev 15 crw-rw-rw- null rw root pflogd 28572 1 /dev 15 crw-rw-rw- null rw root pflogd 28572 2 /dev 15 crw-rw-rw- null rw root pflogd 28572 3 /dev 11 crw------- bpf rw root pflogd 28572 4* local stream c75f035c <-> c75f02b0 root devd 28553 root / 2 drwxr-xr-x 1024 r root devd 28553 wd / 2 drwxr-xr-x 1024 r root devd 28553 text / 1402 -r-xr-xr-x 404976 r root devd 28553 0 /dev 15 crw-rw-rw- null rw root devd 28553 1 /dev 15 crw-rw-rw- null rw root devd 28553 2 /dev 15 crw-rw-rw- null rw root devd 28553 3 / 33227 drwxr-xr-x 512 r root devd 28553 4 /dev 4 crw------- devctl r root devd 28553 5* local stream c75f0c18 root devd 28553 6 /var 70476 -rw------- 5 w root moused 28536 root / 2 drwxr-xr-x 1024 r root moused 28536 wd / 2 drwxr-xr-x 1024 r root moused 28536 text /usr 42158367 -r-xr-xr-x 36220 r root moused 28536 0 /dev 15 crw-rw-rw- null rw root moused 28536 1 /dev 15 crw-rw-rw- null rw root moused 28536 2 /dev 15 crw-rw-rw- null rw root moused 28536 3 /dev 138 crw-r--r-- ums0 rw root moused 28536 4 /dev 62 crw------- consolectl rw root moused 28536 5 /var 70471 -rw------- 5 w root adjkerntz 27845 root / 2 drwxr-xr-x 1024 r root adjkerntz 27845 wd / 2 drwxr-xr-x 1024 r root adjkerntz 27845 text / 11 -r-xr-xr-x 7448 r root adjkerntz 27845 0 /dev 15 crw-rw-rw- null rw root adjkerntz 27845 1 /dev 15 crw-rw-rw- null rw root adjkerntz 27845 2 /dev 15 crw-rw-rw- null rw root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 61 -r-xr-xr-x 664972 r ------------------------------------------------------------------------ dmesg Setting hostuuid: fe134458-976b-11dc-8f0f-006008101031. Setting hostid: 0x43bda48f. Entropy harvesting: interrupts ethernet point_to_point kickstart . Fast boot: skipping disk checks. Mounting local file systems: . Setting hostname: brane.freislich.nom.za . Starting Network: lo0 re0 re1 pfsync0 pflog0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:30:4f:52:39:70 inet 41.154.0.9 netmask 0xfffffff8 broadcast 41.154.0.15 media: Ethernet autoselect (none) status: no carrier re1: flags=8802 metric 0 mtu 1500 options=389b ether 00:01:29:2d:41:49 media: Ethernet autoselect (100baseTX ) status: no carrier pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 pflog0: flags=0<> metric 0 mtu 33200 Starting devd. Starting Network: re1. re1: flags=8802 metric 0 mtu 1500 options=389b ether 00:01:29:2d:41:49 media: Ethernet autoselect (100baseTX ) status: no carrier Starting Network: pfsync0. pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 Starting Network: pflog0. pflog0: flags=0<> metric 0 mtu 33200 Configuring keyboard: keymap keyrate . Starting ums0 moused . Starting pflog. Aug 20 14:19:12 pflogd[28572]: [priv]: msg PRIV_OPEN_LOG received add net default: gateway 41.154.0.14 Generating host.conf. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files . Starting syslogd. No core dumps found. Additional ABI support: linux . Starting named. Aug 20 14:19:13 brane named[28794]: the working directory is not writable Setting date via ntp. 20 Aug 14:19:13 ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 20 Aug 14:19:14 ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 20 Aug 14:19:15 ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 20 Aug 14:19:16 ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 re0: link state changed to UP 20 Aug 14:19:17 ntpdate[28802]: no server suitable for synchronization found Starting rpcbind. Aug 20 14:19:17 brane rpcbind: cannot create socket for udp6 Clearing /tmp (X related). Starting lpd. Updating motd: . Starting fusefs. KLD fuse.ko: depends on kernel - not available or version mismatch kldload: can't load /usr/local/modules/fuse.ko : File exists Starting owfs. fuse: failed to open fuse device: No such file or directory Starting ntpd. /etc/rc: WARNING: run_rc_command: cannot run /usr/local/bin/spamd Starting default moused moused: unable to open /dev/psm0: No such file or directory . /etc/rc: WARNING: run_rc_command: cannot run /usr/local/sbin/clamd /etc/rc: WARNING: run_rc_command: cannot run /usr/local/bin/freshclam Starting exim. /etc/rc: WARNING: run_rc_command: cannot run /usr/local/sbin/httpd Configuring syscons: keymap keyrate blanktime allscreens . Starting sshd. Starting cron. Local package initialization: popd /usr/local/etc/rc.d/050.popd.sh: /usr/local/libexec/popd: not found popd-ssl /usr/local/etc/rc.d/050.popd.sh: /usr/local/libexec/popd: not found . Starting inetd. Starting background file system checks in 60 seconds. Fri Aug 20 14:19:25 SAST 2010 Aug 20 14:20:44 brane su: ianf to root on /dev/pts/0 Aug 20 14:24:26 brane login: ROOT LOGIN (root) ON ttyu0 Aug 20 14:27:06 brane su: ianf to root on /dev/pts/0 Aug 20 15:05:42 brane su: BAD SU ianf to root on /dev/pts/2 Aug 20 15:05:48 brane su: ianf to root on /dev/pts/2 Aug 20 15:10:14 brane su: ianf to root on /dev/pts/3 Aug 20 15:10:36 brane named[28794]: client 41.161.16.217#52348: zone transfer 'freislich.nom.za/AXFR/IN' denied Aug 20 15:18:19 brane su: ianf to root on /dev/pts/3 fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xe75d3b50 frame pointer = 0x28:0xe75d3c14 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 56578 (sh) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at kdb_backtrace+0x29 panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b trap(e75d3b10) at trap+0x423 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- uart_z8530_class(c784ab00,ffffff9c,284052c4,0,402,...) at 0 kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at syscallenter+0x343 syscall(e75d3d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, ebp = 0xbfbfea28 --- Uptime: 1h49m31s Physical memory: 2007 MB Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 ------------------------------------------------------------------------ kernel config config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE ------------------------------------------------------------------------ ddb capture buffer -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 16:27:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD78B1065673 for ; Fri, 20 Aug 2010 16:27:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9F48FC0C for ; Fri, 20 Aug 2010 16:27:23 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=8mUlEYGF/1ewVNyGLrc5XeWvvpKOEXP975HI1NO5ccA= c=1 sm=1 a=Q9fys5e9bTEA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=xdooqjuZVRVLhjVpcOQA:9 a=LkqdK_wYdIGHvBcow6AA:7 a=aPB4Z4JV9xnEhVbbuK7EmN3DcQoA:4 a=PUjeQqilurYA:10 a=71KNwuU-lXsA:10 a=bMGklc-xEJVyO-dt:21 a=paP0taZAZnitxIOs:21 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 9632666 for freebsd-current@freebsd.org; Fri, 20 Aug 2010 18:26:41 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 20 Aug 2010 18:23:35 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008201823.36022.hselasky@c2i.net> Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:27:25 -0000 On Friday 20 August 2010 18:11:00 Ian FREISLICH wrote: > Hi > > I have a system that relies on Fuse and OWFS to manage the power > at my house. I get the following panic when writing to to one of > the PIO devices: > > The panic isn't really helpful because it looks like the stack frame > has been broken. > > Have others seen this? I've tried rebuilding everything from a > clean slate but it doesn't help. The machine used to be -STABLE, > which worked until 21 April 2010, but no kernel since has worked. > > brane.freislich.nom.za dumped core - see /var/crash/vmcore.7 > > Fri Aug 20 16:07:17 SAST 2010 > > FreeBSD brane.freislich.nom.za 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Aug > 20 13:53:55 SAST 2010 > ianf@brane.freislich.nom.za:/usr/obj/usr/src/sys/BRANE i386 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are welcome to change it and/or distribute copies of it under certain > conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xe75d3b50 > frame pointer = 0x28:0xe75d3c14 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 56578 (sh) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at > kdb_backtrace+0x29 panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf > trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 > trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b > trap(e75d3b10) at trap+0x423 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- > uart_z8530_class(c784ab00,ffffff9c,284052c4,0,402,...) at 0 > kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 > open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 > syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at > syscallenter+0x343 syscall(e75d3d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, > ebp = 0xbfbfea28 --- Uptime: 1h49m31s > Physical memory: 2007 MB > Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 > > No symbol "stopped_cpus" in current context. > No symbol "stoppcbs" in current context. > Reading symbols from /boot/kernel/puc.ko...Reading symbols from > /boot/kernel/puc.ko.symbols...done. done. > Loaded symbols for /boot/kernel/puc.ko > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /usr/local/modules/fuse.ko...done. > Loaded symbols for /usr/local/modules/fuse.ko > #0 doadump () at pcpu.h:231 > 231 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:231 > #1 0xc05b4923 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xc05b4b4f in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 0xc0759543 in trap_fatal (frame=0xe75d3b10, eva=0) > at /usr/src/sys/i386/i386/trap.c:941 > #4 0xc07597ab in trap_pfault (frame=0xe75d3b10, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:854 > #5 0xc0759cb3 in trap (frame=0xe75d3b10) at > /usr/src/sys/i386/i386/trap.c:529 #6 0xc074365c in calltrap () at > /usr/src/sys/i386/i386/exception.s:166 #7 0x00000000 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > ------------------------------------------------------------------------ > ps -axl > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME > COMMAND 0 0 0 0 8 0 0 0 - DLs ?? > 306287:15.00 [kernel] 0 1 0 0 44 0 8032 496 wait DLs > ?? 8248871:42.00 [init] 0 2 0 0 -8 0 0 0 - DL > ?? 4280098:17.00 [g_event] 0 3 0 0 -8 0 0 0 - > DL ?? 32358964:51.00 [g_up] 0 4 0 0 -8 0 0 0 - > DL ?? 25140601:54.00 [g_down] 0 5 0 0 -16 0 0 > 0 pftm DL ?? 709006:55.00 [pfpurge] 0 6 0 0 -16 0 0 > 0 ccb_sc DL ?? 0:00.00 [xpt_thrd 0 7 0 0 -16 0 0 > 0 psleep DL ?? 111034:23.00 [pagedaem 0 8 0 0 -16 0 > 0 0 psleep DL ?? 50:11.00 [vmdaemon 0 9 0 0 76 0 > 0 0 pgzero DL ?? 2229:36.00 [pagezero 0 10 0 0 171 0 > 0 0 - RL ?? -32573570:-46.55 [idle] 0 11 0 0 > -60 0 0 0 - WL ?? -29804148:-20.55 [intr] 0 12 > 0 0 -16 0 0 0 - DL ?? 15760116:47.00 [yarrow] 0 > 13 0 0 -64 0 0 0 - DL ?? 9764491:03.00 [usb] 0 > 14 0 0 -16 0 0 0 tzpoll DL ?? 5327193:44.00 > [acpi_the 0 15 0 0 -16 0 0 0 coolin DL ?? > 94312:20.00 [acpi_coo 0 16 0 0 44 0 0 0 psleep DL > ?? 24015582:25.00 [bufdaemo 0 17 0 0 44 0 0 0 syncer > DL ?? 1458594:59.00 [syncer] 0 18 0 0 -16 0 0 0 > vlruwt DL ?? 539998:14.00 [vnlru] 0 19 0 0 44 0 0 > 0 sdflus DL ?? 33298541:20.00 [softdepf 0 27845 1 0 76 0 > 1640 892 pause Ds ?? 6213:05.00 [adjkernt 0 28536 1 0 76 0 > 9712 1212 select Ds ?? 3559:40.00 [moused] 0 28553 1 0 44 > 0 8032 696 select Ds ?? 847133:08.00 [devd] 0 28572 1 0 76 > 0 9800 1596 sbwait Ds ?? 294006:26.00 [pflogd] 64 28574 28572 0 > 44 0 9800 1656 bpf D ?? 3335558:42.00 [pflogd] 0 28779 1 > 0 44 0 9616 1472 select Ds ?? 1190554:09.00 [syslogd] 53 28794 > 1 0 44 0 35992 19368 kqread Ds ?? 14804697:15.00 [named] 0 > 28818 1 0 44 0 9644 1504 select Ds ?? 208787:24.00 > [rpcbind] 0 28988 1 0 76 0 9532 1416 select Ds ?? > 105927:50.00 [lpd] 70 29103 1 0 44 0 44336 5116 select Ds ?? > 2997888:33.00 [postgres 70 29105 29103 0 44 0 44336 5424 select Ds > ?? 14961987:51.00 [postgres 70 29106 29103 0 44 0 12528 4184 > select Ds ?? 1038570:19.00 [postgres 26 29201 1 0 44 0 14144 > 3900 select Ds ?? 980587:29.00 [exim-4.7 0 29262 1 0 44 0 > 12988 3968 select Ds ?? 76126:28.00 [sshd] 0 29273 1 0 52 0 > 9644 1524 nanslp Ds ?? 1104871:52.00 [cron] 0 29305 1 0 76 > 0 9676 1332 select Ds ?? 11270:29.00 [inetd] 0 29339 1 0 76 > 0 9616 1252 ttyin Ds+ ?? 55592:11.00 [getty] 0 29340 1 0 > 76 0 9616 1252 ttyin Ds+ ?? 42957:15.00 [getty] 0 29341 1 0 > 76 0 9616 1252 ttyin Ds+ ?? 41741:08.00 [getty] 0 29342 1 > 0 76 0 9616 1252 ttyin Ds+ ?? 43682:07.00 [getty] 0 29343 1 > 0 76 0 9616 1252 ttyin Ds+ ?? 42346:22.00 [getty] 0 29344 1 > 0 76 0 9616 1252 ttyin Ds+ ?? 43069:56.00 [getty] 0 29345 > 1 0 76 0 9616 1252 ttyin Ds+ ?? 43107:53.00 [getty] 0 29346 > 1 0 76 0 9616 1252 ttyin Ds+ ?? 44075:21.00 [getty] 0 29347 > 1 0 44 0 10048 1928 wait Ds ?? 387233:46.00 [login] 0 39521 > 29347 0 44 0 9892 1764 ttyin D+ ?? 544541:14.00 [sh] 0 44418 > 1 0 44 0 11228 2640 select Ds ?? 5839856:06.00 [ntpd] 1000 > 45103 97479 0 44 0 11212 4844 select D ?? -31017170:-55.55 > [perl] 0 56378 1 0 54 0 11492 1916 fu_msg Ds ?? 87736:30.00 > [owfs] 1000 56578 97479 0 44 0 9892 1532 - R+ ?? > 0:00.00 [sh] 0 57989 1 0 44 0 10188 2428 select Ds ?? > -23813812:-31.55 [screen] 0 57990 57989 0 51 0 10828 2548 ttyin > Ds+ ?? 656705:26.00 [bash] 0 75221 29262 0 46 0 15712 4756 > sbwait Ds ?? 1397537:31.00 [sshd] 1000 75223 75221 0 44 0 15712 > 4780 select D ?? 10666399:15.00 [sshd] 1000 75224 75223 0 45 0 > 10828 2544 wait Ds ?? 190136:43.00 [bash] 0 75227 75224 0 44 0 > 10044 1908 wait D ?? 168236:33.00 [su] 0 75228 75227 0 44 0 > 10828 2524 wait D ?? 124223:03.00 [bash] 0 75229 75228 0 44 0 > 10188 2280 pause D+ ?? 404415:12.00 [screen] 0 97423 29262 0 46 > 0 15712 4756 sbwait Ds ?? 1470712:26.00 [sshd] 1000 97469 97423 > 0 44 0 15712 4748 select D ?? 11267771:57.00 [sshd] 1000 97479 > 97469 0 44 0 10828 2468 wait Ds ?? 311046:58.00 [bash] > > ------------------------------------------------------------------------ > vmstat -s > > 5927091 cpu context switches > 2037250 device interrupts > 1337655 software interrupts > 49077340 traps > 173266014 system calls > 19 kernel threads created > 332276 fork() calls > 123727 vfork() calls > 0 rfork() calls > 0 swap pager pageins > 0 swap pager pages paged in > 0 swap pager pageouts > 0 swap pager pages paged out > 15900 vnode pager pageins > 66917 vnode pager pages paged in > 376 vnode pager pageouts > 376 vnode pager pages paged out > 0 page daemon wakeups > 0 pages examined by the page daemon > 581 pages reactivated > 8460226 copy-on-write faults > 2068 copy-on-write optimized faults > 29553775 zero fill pages zeroed > 1343392 zero fill pages prezeroed > 11 intransit blocking page faults > 46831577 total VM faults taken > 0 pages affected by kernel thread creation > 317038645 pages affected by fork() > 112597829 pages affected by vfork() > 0 pages affected by rfork() > 0 pages cached > 42931623 pages freed > 0 pages freed by daemon > 0 pages freed by exiting processes > 9615 pages active > 101549 pages inactive > 27 pages in VM cache > 36303 pages wired down > 357114 pages free > 4096 bytes per page > 25766502 total name lookups > cache hits (88% pos + 8% neg) system 0% per-directory > deletions 0%, falsehits 0%, toolong 0% > > ------------------------------------------------------------------------ > vmstat -m > > Type InUse MemUse HighUse Requests Size(s) > sigio 1 1K - 1 32 > filedesc 91 64K - 456335 > 16,32,64,128,256,512,1024,2048,4096 kenv 77 7K - 81 > 16,32,64,128,4096 > kqueue 2 5K - 1275 128,256,1024,4096 > proc-args 42 3K - 310324 16,32,64,128,256 > drm_maps 1 1K - 1 64 > ithread 102 9K - 103 16,64,128 > KTRACE 100 13K - 100 128 > drm_driver 4 5K - 8 16,64,256,4096 > linker 86 81K - 148 16,32,64,128,512,1024,4096 > lockf 23 2K - 1163 32,64 > drm_sarea 1 1K - 1 16 > temp 149 211K - 691955 > 16,32,64,128,256,512,1024,2048,4096 devbuf 3134 4146K - 3309 > 16,32,64,128,256,512,1024,2048,4096 drm_dma 1 1K - 1 > 16 > module 216 14K - 217 64,128 > kbdmux 7 18K - 7 16,256,1024,2048 > mtx_pool 2 8K - 2 4096 > osd 2 1K - 2 16,32 > subproc 147 266K - 456112 256,4096 > proc 2 8K - 2 4096 > session 33 3K - 372 64 > pgrp 39 3K - 586 64 > cred 66 7K - 2074138 64,128 > uidinfo 7 2K - 87 64,1024 > plimit 19 5K - 7121 256 > CAM periph 2 1K - 5 16,32,128 > sysctltmp 0 0K - 19899 16,32,64,128 > sysctloid 3061 93K - 3196 16,32,64 > sysctl 0 0K - 102808 16,32,64 > umtx 280 27K - 280 64,128 > p1003.1b 1 1K - 1 16 > SWAP 2 277K - 2 64 > ddb_capture 1 48K - 1 > bus-sc 65 107K - 1521 16,32,64,128,256,512,1024,2048 > bus 762 38K - 4231 16,32,64,128,256,512,1024 > devstat 4 9K - 4 16,4096 > eventhandler 76 4K - 77 32,64,128 > kobj 162 324K - 179 2048 > Per-cpu 1 1K - 1 16 > agp 1 1K - 1 16 > rman 206 13K - 574 16,32,64 > CAM XPT 5 2K - 12 16,32,64,1024 > sbuf 0 0K - 343 > 16,32,64,128,256,512,1024,2048,4096 CAM dev queue 1 1K - > 1 128 > CAM queue 3 1K - 7 16 > stack 0 0K - 2 128 > taskqueue 9 1K - 9 16,64 > Unitno 14 1K - 782 16,64 > iov 0 0K - 25538 16,64,128,256 > select 67 5K - 67 64 > ioctlops 0 0K - 169970 16,32,64,128,256,512,1024 > msg 4 25K - 4 1024,4096 > sem 4 101K - 4 1024,4096 > shm 4 15K - 68 1024 > tty 26 13K - 141 512,2048 > pts 3 1K - 116 128 > mbuf_tag 0 0K - 1 32 > shmfd 1 4K - 1 4096 > ppbusdev 1 1K - 1 128 > pcb 23 7K - 1717 16,512,1024,2048 > soname 6 1K - 9156 16,32,128 > acl 0 0K - 20564 4096 > biobuf 71 142K - 9314 2048 > vfscache 1 512K - 1 > cl_savebuf 0 0K - 8192 32,64 > vfs_hash 1 256K - 1 > vnodes 3 1K - 11 32,128 > vnodemarker 0 0K - 1749 512 > mount 94 3K - 210 16,32,64,128,256 > BPF 9 65K - 10 16,64,256 > ether_multi 7 1K - 8 16,32,64 > ifaddr 40 9K - 40 16,32,256,2048 > ifnet 6 6K - 6 64,1024 > entropy 1024 64K - 1024 64 > clone 4 16K - 5 4096 > arpcom 2 1K - 2 16 > lltable 8 2K - 8 128,256 > ata_generic 2 2K - 2 1024 > UART 12 6K - 12 16,256,1024 > USBdev 39 9K - 39 32,128,256,1024,2048 > USB 66 77K - 74 16,32,64,128,1024,2048,4096 > ad_driver 1 1K - 1 32 > routetbl 11 2K - 148 16,32,64,128,256 > igmp 5 1K - 5 128 > acd_driver 1 2K - 1 2048 > CAM SIM 1 1K - 1 128 > in_multi 2 1K - 2 128 > hostcache 1 16K - 1 > syncache 1 72K - 1 > savedino 0 0K - 49275 256 > freework 1 1K - 163160 64 > newdirblk 0 0K - 9617 32 > dirrem 1 1K - 141359 64 > mkdir 0 0K - 18624 64 > diradd 1 1K - 142994 64 > freefile 3 1K - 127270 32 > freeblks 1 1K - 121940 64 > freefrag 0 0K - 59952 64 > indirdep 1 1K - 1613 64 > newblk 3 65K - 324053 128 > bmsafemap 2 5K - 1909 128,4096 > inodedep 15 260K - 219956 256 > pagedep 2 65K - 19292 128 > ufs_dirhash 228 44K - 1425 16,32,64,128,256,512 > ufs_mount 12 69K - 21 256,2048,4096 > UMAHash 1 1K - 3 256,512,1024 > DEVFS1 137 35K - 251 256 > vm_pgdata 2 65K - 2 64 > DEVFS3 162 21K - 276 128 > atkbddev 1 1K - 1 32 > memdesc 1 4K - 1 4096 > nexusdev 4 1K - 4 16 > DEVFS 27 1K - 28 16,64 > linux 14 1K - 14 32,64 > DEVFSP 2 1K - 2 32 > pfs_nodes 169 22K - 169 128 > drm_ctxbitmap 1 4K - 1 4096 > GEOM 69 15K - 167 16,64,128,512,1024,2048 > isadev 8 1K - 8 64 > drm_agplists 1 1K - 1 64 > io_apic 2 2K - 2 1024 > cdev 9 2K - 9 128 > acpica 1863 97K - 71981 16,32,64,128,256,512,1024 > acpitask 1 1K - 1 1024 > pci_link 16 2K - 16 64,128 > acpisem 15 2K - 15 64,128 > PUC 4 1K - 4 32,256 > apmdev 1 1K - 1 64 > acpidev 57 2K - 57 32 > acpipwr 1 1K - 1 32 > fuse_messaging 5 2K - 8 128,256,512,1024 > fuse_filehandles 1 1K - 44 64 > fuse_vnode 29 8K - 29 256 > > ------------------------------------------------------------------------ > vmstat -z > > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > > UMA Kegs: 128, 0, 89, 1, 89, 0, 0 > UMA Zones: 152, 0, 89, 7, 89, 0, 0 > UMA Slabs: 284, 0, 1402, 12, 1899, 0, 0 > UMA RCntSlabs: 544, 0, 204, 6, 204, 0, 0 > UMA Hash: 128, 0, 2, 28, 3, 0, 0 > 16 Bucket: 76, 0, 36, 14, 36, 0, 0 > 32 Bucket: 140, 0, 59, 25, 59, 0, 0 > 64 Bucket: 268, 0, 58, 12, 58, 0, 0 > 128 Bucket: 524, 0, 2005, 4, 2005,2324, 0 > VM OBJECT: 136, 0, 28684, 12931, 5719386, 0, 0 > MAP: 140, 0, 7, 49, 7, 0, 0 > KMAP ENTRY: 72, 57505, 30, 129, 16796, 0, 0 > MAP ENTRY: 72, 0, 1046, 438,10907676, 0, 0 > DP fakepg: 72, 0, 0, 0, 0, 0, 0 > SG fakepg: 72, 0, 0, 0, 0, 0, 0 > mt_zone: 76, 0, 209, 41, 209, 0, 0 > 16: 16, 0, 2676, 369, 218984, 0, 0 > 32: 32, 0, 2329, 11796, 591034, 0, 0 > 64: 64, 0, 4567, 43223, 1961616, 0, 0 > 128: 128, 0, 1945, 7865, 1511081, 0, 0 > 256: 256, 0, 729, 20556, 769786, 0, 0 > 512: 512, 0, 163, 53, 295755, 0, 0 > 1024: 1024, 0, 54, 122, 15622, 0, 0 > 2048: 2048, 0, 271, 1671, 9689, 0, 0 > 4096: 4096, 0, 115, 36, 486502, 0, 0 > Files: 56, 0, 130, 272, 3534124, 0, 0 > TURNSTILE: 72, 0, 141, 39, 141, 0, 0 > umtx pi: 52, 0, 0, 0, 0, 0, 0 > PROC: 680, 0, 60, 24, 456022, 0, 0 > THREAD: 704, 0, 124, 16, 282, 0, 0 > SLEEPQUEUE: 44, 0, 141, 95, 141, 0, 0 > VMSPACE: 240, 0, 42, 38, 456003, 0, 0 > cpuset: 40, 0, 2, 182, 2, 0, 0 > mbuf_packet: 256, 0, 256, 140, 71609, 0, 0 > mbuf: 256, 0, 2, 394, 140999, 0, 0 > mbuf_cluster: 2048, 25600, 384, 6, 384, 0, 0 > mbuf_jumbo_page: 4096, 12800, 0, 9, 75, 0, 0 > mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 > g_bio: 140, 0, 0, 3164, 929046, 0, 0 > ttyinq: 152, 0, 480, 66, 8565, 0, 0 > ttyoutq: 256, 0, 251, 34, 4444, 0, 0 > ata_request: 208, 0, 1, 797, 235403, 0, 0 > ata_composite: 180, 0, 0, 0, 0, 0, 0 > VNODE: 272, 0, 34124, 12104, 196226, 0, 0 > VNODEPOLL: 60, 0, 1, 125, 1, 0, 0 > NAMEI: 1024, 0, 0, 12, 8349730, 0, 0 > S VFS Cache: 72, 0, 35128, 11300, 414636, 0, 0 > L VFS Cache: 292, 0, 331, 59, 1277, 0, 0 > DIRHASH: 1024, 0, 368, 192, 1551, 0, 0 > pipe: 392, 0, 4, 26, 204010, 0, 0 > ksiginfo: 80, 0, 74, 982, 733, 0, 0 > itimer: 220, 0, 1, 35, 4, 0, 0 > KNOTE: 72, 0, 6, 100, 11843, 0, 0 > socket: 412, 25605, 42, 57, 2341, 0, 0 > ipq: 32, 904, 0, 0, 0, 0, 0 > udp_inpcb: 220, 25614, 9, 81, 1781, 0, 0 > udpcb: 8, 25781, 9, 194, 1781, 0, 0 > tcp_inpcb: 220, 25614, 13, 41, 230, 0, 0 > tcpcb: 632, 25602, 12, 12, 230, 0, 0 > tcptw: 52, 5184, 1, 143, 82, 0, 0 > syncache: 112, 15365, 0, 70, 129, 0, 0 > hostcache: 76, 15400, 9, 91, 18, 0, 0 > tcpreass: 20, 1690, 0, 169, 9552, 0, 0 > sackhole: 20, 0, 0, 169, 71, 0, 0 > ripcb: 220, 25614, 0, 36, 21, 0, 0 > unpcb: 172, 25622, 20, 26, 305, 0, 0 > rtentry: 108, 0, 4, 68, 4, 0, 0 > pfsrctrpl: 124, 0, 0, 0, 0, 0, 0 > pfrulepl: 828, 0, 0, 0, 0, 0, 0 > pfstatepl: 284, 10010, 0, 0, 0, 0, 0 > pfaltqpl: 224, 0, 0, 0, 0, 0, 0 > pfpooladdrpl: 68, 0, 0, 0, 0, 0, 0 > pfrktable: 1240, 0, 0, 0, 0, 0, 0 > pfrkentry: 156, 0, 0, 0, 0, 0, 0 > pfrkentry2: 156, 0, 0, 0, 0, 0, 0 > pffrent: 16, 5075, 0, 0, 0, 0, 0 > pffrag: 48, 0, 0, 0, 0, 0, 0 > pffrcache: 48, 10062, 0, 0, 0, 0, 0 > pffrcent: 12, 50141, 0, 0, 0, 0, 0 > pfstatescrub: 28, 0, 0, 0, 0, 0, 0 > pfiaddrpl: 100, 0, 0, 0, 0, 0, 0 > pfospfen: 108, 0, 0, 0, 0, 0, 0 > pfosfp: 28, 0, 0, 0, 0, 0, 0 > selfd: 28, 0, 112, 142,60027973, 0, 0 > SWAPMETA: 276, 121576, 0, 0, 0, 0, 0 > Mountpoints: 648, 0, 6, 6, 9, 0, 0 > FFS inode: 116, 0, 34049, 12151, 195941, 0, 0 > FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 > FFS2 dinode: 256, 0, 34049, 12136, 195941, 0, 0 > > > ------------------------------------------------------------------------ > vmstat -i > > interrupt total rate > irq1: atkbd0 2 0 > irq0: attimer0 834491 2418 > irq3: uart1 33065 95 > irq4: uart0 154540 447 > irq14: ata0 232411 673 > irq15: ata1 25 0 > irq16: uhci0 21 0 > irq19: uhci1 16 0 > irq20: puc0 uart2+ 636041 1843 > irq23: ehci0 18283 52 > irq24: re0 128350 372 > cpu0:timer 6570306 19044 > Total 8607551 24949 > > ------------------------------------------------------------------------ > pstat -T > > 130/12328 files > 0M/1996M swap space > > ------------------------------------------------------------------------ > pstat -s > > Device 512-blocks Used Avail Capacity > /dev/ad0s1b 4088976 0 4088976 0% > > ------------------------------------------------------------------------ > iostat > > iostat: kvm_read(_tk_nin): invalid address (0x0) > iostat: disabling TTY statistics > iostat: kvm_getcptime: invalid address (0x0) > iostat: disabling CPU time statistics > ad0 > KB/t tps MB/s > 13.86 673 9.11 > > ------------------------------------------------------------------------ > ipcs -a > > Message Queues: > T ID KEY MODE OWNER GROUP CREATOR CGROUP > CBYTES QNUM QBYTES > LSPID LRPID STIME RTIME CTIME > > Shared Memory: > T ID KEY MODE OWNER GROUP CREATOR CGROUP > NATTCH SEGSZ CPID LPID ATIME DTIME > CTIME m 65536 5432001 --rw------- pgsql pgsql pgsql > pgsql 2 32571392 29103 29103 14:19:22 > 16:00:29 14:19:22 > > Semaphores: > T ID KEY MODE OWNER GROUP CREATOR CGROUP > NSEMS OTIME CTIME s 65536 5432001 --rw------- pgsql > pgsql pgsql pgsql 17 14:19:22 14:19:22 s 65537 > 5432002 --rw------- pgsql pgsql pgsql pgsql 17 > 14:19:22 14:19:22 s 65538 5432003 --rw------- pgsql pgsql > pgsql pgsql 17 14:19:22 14:19:22 > > > ------------------------------------------------------------------------ > ipcs -T > > msginfo: > msgmax: 16384 (max characters in a message) > msgmni: 40 (# of message queues) > msgmnb: 2048 (max characters in a message queue) > msgtql: 40 (max # of messages in system) > msgssz: 8 (size of a message segment) > msgseg: 2048 (# of message segments in system) > > shminfo: > shmmax: 536870912 (max shared memory segment size) > shmmin: 1 (min shared memory segment size) > shmmni: 192 (max number of shared memory identifiers) > shmseg: 128 (max shared memory segments per process) > shmall: 131072 (max amount of shared memory in pages) > > seminfo: > semmap: 30 (# of entries in semaphore map) > semmni: 50 (# of semaphore identifiers) > semmns: 340 (# of semaphores in system) > semmnu: 150 (# of undo structures in system) > semmsl: 340 (max # of semaphores per id) > semopm: 100 (max # of operations per semop call) > semume: 50 (max # of undo entries per process) > semusz: 616 (size in bytes of undo structure) > semvmx: 32767 (semaphore maximum value) > semaem: 16384 (adjust on exit max value) > > > ------------------------------------------------------------------------ > nfsstat > > nfsstat: kvm_nlist: can't get names > > ------------------------------------------------------------------------ > netstat -s > > tcp: > 74465 packets sent > 50412 data packets (5860981 bytes) > 85 data packets (52300 bytes) retransmitted > 4 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 19347 ack-only packets (276 delayed) > 0 URG only packets > 0 window probe packets > 4340 window update packets > 281 control packets > 62397 packets received > 27848 acks (for 5858054 bytes) > 568 duplicate acks > 0 acks for unsent data > 25262 packets (25484049 bytes) received in-sequence > 55 completely duplicate packets (54515 bytes) > 1 old duplicate packet > 1 packet with some dup. data (416 bytes duped) > 9552 out-of-order packets (9355410 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 108 window update packets > 17 packets received after close > 637 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 24 discarded due to memory problems > 79 connection requests > 129 connection accepts > 0 bad connection attempts > 0 listen queue overflows > 60 ignored RSTs in the windows > 207 connections established (including accepts) > 217 connections closed (including 21 drops) > 186 connections updated cached RTT on close > 186 connections updated cached RTT variance on close > 1 connection updated cached ssthresh on close > 1 embryonic connection dropped > 27814 segments updated rtt (of 19294 attempts) > 25 retransmit timeouts > 0 connections dropped by rexmit timeout > 0 persist timeouts > 0 connections dropped by persist timeout > 0 Connections (fin_wait_2) dropped because of timeout > 0 keepalive timeouts > 0 keepalive probes sent > 0 connections dropped by keepalive > 1 correct ACK header prediction > 23157 correct data packet header predictions > 129 syncache entries added > 1 retransmitted > 2 dupsyn > 0 dropped > 129 completed > 0 bucket overflow > 0 cache overflow > 0 reset > 0 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > 129 cookies sent > 0 cookies received > 43 SACK recovery episodes > 58 segment rexmits in SACK recovery episodes > 29868 byte rexmits in SACK recovery episodes > 467 SACK options (SACK blocks) received > 7893 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > 0 packets with ECN CE bit set > 0 packets with ECN ECT(0) bit set > 0 packets with ECN ECT(1) bit set > 0 successful ECN handshakes > 0 times ECN reduced the congestion window > udp: > 3240 datagrams received > 0 with incomplete header > 0 with bad data length field > 0 with bad checksum > 0 with no checksum > 56 dropped due to no socket > 101 broadcast/multicast datagrams undelivered > 0 dropped due to full socket buffers > 0 not for hashed pcb > 3083 delivered > 3576 datagrams output > 0 times multicast source filter matched > ip: > 65718 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 packets reassembled ok > 65658 packets for this host > 60 packets for unknown/unsupported protocol > 0 packets forwarded (0 packets fast forwarded) > 0 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 78171 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > icmp: > 56 calls to icmp_error > 0 errors not generated in response to an icmp message > Output histogram: > destination unreachable: 56 > 0 messages with bad code fields > 0 messages less than the minimum length > 0 messages with bad checksum > 0 messages with bad length > 0 multicast echo requests ignored > 0 multicast timestamp requests ignored > Input histogram: > echo reply: 21 > destination unreachable: 60 > 0 message responses generated > 0 invalid return addresses > 0 no return routes > igmp: > 0 messages received > 0 messages received with too few bytes > 0 messages received with wrong TTL > 0 messages received with bad checksum > 0 V1/V2 membership queries received > 0 V3 membership queries received > 0 membership queries received with invalid field(s) > 0 general queries received > 0 group queries received > 0 group-source queries received > 0 group-source queries dropped > 0 membership reports received > 0 membership reports received with invalid field(s) > 0 membership reports received for groups to which we belong > 0 V3 reports received without Router Alert > 0 membership reports sent > carp: > 0 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for wrong TTL > 0 packets shorter than header > 0 discarded for bad checksums > 0 discarded packets with a bad version > 0 discarded because packet too short > 0 discarded for bad authentication > 0 discarded for bad vhid > 0 discarded because of a bad address list > 0 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > pfsync: > 0 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for bad ttl > 0 packets shorter than header > 0 packets discarded for bad version > 0 packets discarded for bad HMAC > 0 packets discarded for bad action > 0 packets discarded for short packet > 0 states discarded for bad values > 0 stale states > 0 failed state lookup/inserts > 0 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 0 send error > arp: > 258 ARP requests sent > 181 ARP replies sent > 2046 ARP requests received > 113 ARP replies received > 2159 ARP packets received > 255 total packets dropped due to no ARP entry > 0 ARP entrys timed out > 0 Duplicate IPs seen > > ------------------------------------------------------------------------ > netstat -m > > 258/534/792 mbufs in use (current/cache/total) > 244/146/390/25600 mbuf clusters in use (current/cache/total/max) > 256/140 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/19200 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/12800 16k jumbo clusters in use (current/cache/total/max) > 552K/461K/1014K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > ------------------------------------------------------------------------ > netstat -id > > Name Mtu Network Address Ipkts Ierrs Idrop Opkts > Oerrs Coll Drop re0 1500 00:30:4f:52:39:70 64608 > 0 0 75086 0 0 0 re0 1500 41.154.0.8/29 41.154.0.9 > 63726 - - 74902 - - - re1* 1500 > 00:01:29:2d:41:49 0 0 0 0 0 0 0 pfsyn > 1460 0 0 0 0 0 > 0 0 lo0 16384 3269 0 0 > 3269 0 0 0 lo0 16384 your-net localhost > 1891 - - 3269 - - - pflog 33200 > 0 0 0 0 0 0 0 > > ------------------------------------------------------------------------ > netstat -anr > > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 41.154.0.14 UGS 0 74808 re0 > 41.154.0.8/29 link#1 U 0 94 re0 > 41.154.0.9 link#1 UHS 0 1378 lo0 > 127.0.0.1 link#4 UH 0 1891 lo0 > > ------------------------------------------------------------------------ > netstat -anA > > Active Internet connections (including servers) > Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) > c782e1a0 tcp4 0 0 127.0.0.1.22341 127.0.0.1.5432 > TIME_WAIT c78bb000 tcp4 0 48 41.154.0.9.22 > 196.7.162.28.42945 ESTABLISHED c78bbc58 tcp4 0 0 41.154.0.9.22 > 196.7.162.28.59568 ESTABLISHED c77d1768 tcp4 0 0 *.22 > *.* LISTEN c7809278 tcp4 0 0 > 127.0.0.1.587 *.* LISTEN c78094f0 tcp4 0 0 > 127.0.0.1.25 *.* LISTEN c77d1000 tcp4 0 0 > 41.154.0.9.587 *.* LISTEN c77d0768 tcp4 0 0 > 41.154.0.9.25 *.* LISTEN c77d0000 tcp4 0 0 > *.5432 *.* LISTEN c77d0278 tcp4 0 0 > *.515 *.* LISTEN c77d04f0 tcp4 0 0 > *.111 *.* LISTEN c77d09e0 tcp4 0 0 > 127.0.0.1.953 *.* LISTEN c77d0c58 tcp4 0 0 > 41.154.0.9.53 *.* LISTEN c5000a50 udp4 0 0 > 41.154.0.9.60130 192.0.2.1.53 > c50007bc udp4 0 0 127.0.0.1.123 *.* > c77d60dc udp4 0 0 41.154.0.9.123 *.* > c4fff1b8 udp4 0 0 *.123 *.* > c50006e0 udp4 0 0 127.0.0.1.32314 127.0.0.1.32314 > c5000528 udp4 0 0 *.862 *.* > c4fffb2c udp4 0 0 *.111 *.* > c4fff294 udp4 0 0 41.154.0.9.53 *.* > c4fff370 udp4 0 0 *.514 *.* > Active UNIX domain sockets > Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > c75f0ac0 stream 0 0 0 c75f0b6c 0 0 > c75f0b6c stream 0 0 0 c75f0ac0 0 0 > c75f0764 stream 0 0 0 c75f06b8 0 0 > c75f06b8 stream 0 0 0 c75f0764 0 0 > c75f0d70 stream 0 0 0 c75f0ec8 0 0 > c75f0ec8 stream 0 0 0 c75f0d70 0 0 > c75f0968 stream 0 0 c721abb0 0 0 0 > /tmp/.s.PGSQL.5432 c75f060c stream 0 0 c5480110 0 > 0 0 /var/run/printer c75f0408 stream 0 0 c5480dd0 > 0 0 0 /var/run/rpcbind.sock c75f02b0 stream 0 0 > 0 c75f035c 0 0 > c75f035c stream 0 0 0 c75f02b0 0 0 > c75f0c18 stream 0 0 c5435880 0 0 0 > /var/run/devd.pipe c75f1000 dgram 0 0 0 c75f0000 > 0 c75f0204 > c75f0204 dgram 0 0 0 c75f0000 0 c75f0560 > c75f0a14 dgram 0 0 0 c75f00ac 0 0 > c75f0560 dgram 0 0 0 c75f0000 0 c75f04b4 > c75f04b4 dgram 0 0 0 c75f0000 0 c75f0158 > c75f0158 dgram 0 0 0 c75f0000 0 0 > c75f0000 dgram 0 0 c5489660 0 c75f1000 0 > /var/run/logpriv c75f00ac dgram 0 0 c5489550 0 c75f0a14 > 0 /var/run/log > > ------------------------------------------------------------------------ > netstat -aL > > Current listen queue sizes (qlen/incqlen/maxqlen) > Proto Listen Local Address > tcp4 0/0/128 *.ssh > tcp4 0/0/20 localhost.submission > tcp4 0/0/20 localhost.smtp > tcp4 0/0/20 41.154.0.9.submission > tcp4 0/0/20 41.154.0.9.smtp > tcp4 0/0/80 *.postgresql > tcp4 0/0/5 *.printer > tcp4 0/0/128 *.sunrpc > tcp4 0/0/128 localhost.rndc > tcp4 0/0/3 41.154.0.9.domain > unix 0/0/80 /tmp/.s.PGSQL.5432 > unix 0/0/5 /var/run/printer > unix 0/0/128 /var/run/rpcbind.sock > unix 0/0/4 /var/run/devd.pipe > > ------------------------------------------------------------------------ > fstat > > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W > ianf sh 56578 root / 2 drwxr-xr-x 1024 r > ianf sh 56578 wd /usr 11846887 drwxr-xr-x 6144 r > ianf sh 56578 text / 17809 -r-xr-xr-x 120784 r > ianf sh 56578 0 /dev 152 crw--w---- pts/3 rw > ianf sh 56578 1 /dev 152 crw--w---- pts/3 rw > ianf sh 56578 2 /dev 152 crw--w---- pts/3 rw > ianf sh 56578 10 /usr 11894944 -rwxr-xr-x 243 r > ianf sh 56578 11 /dev 152 crw--w---- pts/3 rw > root owfs 56378 root / 2 drwxr-xr-x 1024 r > root owfs 56378 wd / 2 drwxr-xr-x 1024 r > root owfs 56378 text /usr 24494430 -rwxr-xr-x 41342 r > root owfs 56378 0 /dev 15 crw-rw-rw- null rw > root owfs 56378 1 /dev 15 crw-rw-rw- null rw > root owfs 56378 2 /dev 15 crw-rw-rw- null rw > root owfs 56378 3 /dev 120 crw------- ttyU1 rw > root owfs 56378 4 /dev 109 crw------- ttyU0 rw > root owfs 56378 5 /dev 153 crw-rw---- fuse0 rw > ianf perl 45103 root / 2 drwxr-xr-x 1024 r > ianf perl 45103 wd /usr 11846887 drwxr-xr-x 6144 r > ianf perl 45103 text /usr 24494623 -rwxr-xr-x 4712 r > ianf perl 45103 0 /dev 152 crw--w---- pts/3 rw > ianf perl 45103 1 /dev 152 crw--w---- pts/3 rw > ianf perl 45103 2 /dev 152 crw--w---- pts/3 rw > ianf perl 45103 3 /dev 76 crw-rw---- cuau1 rw > ianf bash 97479 root / 2 drwxr-xr-x 1024 r > ianf bash 97479 wd /usr 11846887 drwxr-xr-x 6144 r > ianf bash 97479 text /usr 24496001 -rwxr-xr-x 632468 r > ianf bash 97479 0 /dev 152 crw--w---- pts/3 rw > ianf bash 97479 1 /dev 152 crw--w---- pts/3 rw > ianf bash 97479 2 /dev 152 crw--w---- pts/3 rw > ianf bash 97479 255 /dev 152 crw--w---- pts/3 rw > ianf sshd 97469 root / 2 drwxr-xr-x 1024 r > ianf sshd 97469 wd / 2 drwxr-xr-x 1024 r > ianf sshd 97469 text /usr 42158090 -r-xr-xr-x 232420 r > ianf sshd 97469 0 /dev 15 crw-rw-rw- null rw > ianf sshd 97469 1 /dev 15 crw-rw-rw- null rw > ianf sshd 97469 2 /dev 15 crw-rw-rw- null rw > ianf sshd 97469 3* internet stream tcp c78bb000 > ianf sshd 97469 4* local stream c75f0b6c <-> c75f0ac0 > ianf sshd 97469 5* pipe c500d498 <-> c500d550 0 rw > ianf sshd 97469 6* pipe c500d550 <-> c500d498 0 rw > ianf sshd 97469 7* pseudo-terminal master pts/3 rw > ianf sshd 97469 9* pseudo-terminal master pts/3 rw > ianf sshd 97469 10* pseudo-terminal master pts/3 rw > root sshd 97423 root / 2 drwxr-xr-x 1024 r > root sshd 97423 wd / 2 drwxr-xr-x 1024 r > root sshd 97423 text /usr 42158090 -r-xr-xr-x 232420 r > root sshd 97423 0 /dev 15 crw-rw-rw- null r > root sshd 97423 1 /dev 15 crw-rw-rw- null rw > root sshd 97423 2 /dev 15 crw-rw-rw- null rw > root sshd 97423 3* internet stream tcp c78bb000 > root sshd 97423 4* pseudo-terminal master pts/3 rw > root sshd 97423 5* local stream c75f0ac0 <-> c75f0b6c > root screen 75229 root / 2 drwxr-xr-x 1024 r > root screen 75229 wd /usr 11846887 drwxr-xr-x 6144 r > root screen 75229 text /usr 24495939 -rwsr-xr-x 301192 r > root screen 75229 0 /dev 149 crw--w---- pts/2 rw > root screen 75229 1 /dev 149 crw--w---- pts/2 rw > root screen 75229 2 /dev 149 crw--w---- pts/2 rw > root bash 75228 root / 2 drwxr-xr-x 1024 r > root bash 75228 wd /usr 11846887 drwxr-xr-x 6144 r > root bash 75228 text /usr 24496001 -rwxr-xr-x 632468 r > root bash 75228 0 /dev 149 crw--w---- pts/2 rw > root bash 75228 1 /dev 149 crw--w---- pts/2 rw > root bash 75228 2 /dev 149 crw--w---- pts/2 rw > root bash 75228 255 /dev 149 crw--w---- pts/2 rw > root su 75227 root / 2 drwxr-xr-x 1024 r > root su 75227 wd /usr 11846887 drwxr-xr-x 6144 r > root su 75227 text /usr 38296097 -r-sr-xr-x 14676 r > root su 75227 0 /dev 149 crw--w---- pts/2 rw > root su 75227 1 /dev 149 crw--w---- pts/2 rw > root su 75227 2 /dev 149 crw--w---- pts/2 rw > ianf bash 75224 root / 2 drwxr-xr-x 1024 r > ianf bash 75224 wd /usr 11846887 drwxr-xr-x 6144 r > ianf bash 75224 text /usr 24496001 -rwxr-xr-x 632468 r > ianf bash 75224 0 /dev 149 crw--w---- pts/2 rw > ianf bash 75224 1 /dev 149 crw--w---- pts/2 rw > ianf bash 75224 2 /dev 149 crw--w---- pts/2 rw > ianf bash 75224 255 /dev 149 crw--w---- pts/2 rw > ianf sshd 75223 root / 2 drwxr-xr-x 1024 r > ianf sshd 75223 wd / 2 drwxr-xr-x 1024 r > ianf sshd 75223 text /usr 42158090 -r-xr-xr-x 232420 r > ianf sshd 75223 0 /dev 15 crw-rw-rw- null rw > ianf sshd 75223 1 /dev 15 crw-rw-rw- null rw > ianf sshd 75223 2 /dev 15 crw-rw-rw- null rw > ianf sshd 75223 3* internet stream tcp c78bbc58 > ianf sshd 75223 4* local stream c75f0ec8 <-> c75f0d70 > ianf sshd 75223 5* pipe c500c000 <-> c500c0b8 0 rw > ianf sshd 75223 6* pipe c500c0b8 <-> c500c000 0 rw > ianf sshd 75223 7* pseudo-terminal master pts/2 rw > ianf sshd 75223 9* pseudo-terminal master pts/2 rw > ianf sshd 75223 10* pseudo-terminal master pts/2 rw > root sshd 75221 root / 2 drwxr-xr-x 1024 r > root sshd 75221 wd / 2 drwxr-xr-x 1024 r > root sshd 75221 text /usr 42158090 -r-xr-xr-x 232420 r > root sshd 75221 0 /dev 15 crw-rw-rw- null r > root sshd 75221 1 /dev 15 crw-rw-rw- null rw > root sshd 75221 2 /dev 15 crw-rw-rw- null rw > root sshd 75221 3* internet stream tcp c78bbc58 > root sshd 75221 4* pseudo-terminal master pts/2 rw > root sshd 75221 5* local stream c75f0d70 <-> c75f0ec8 > root bash 57990 root / 2 drwxr-xr-x 1024 r > root bash 57990 wd /var 234887 drwxr-xr-x 1024 r > root bash 57990 text /usr 24496001 -rwxr-xr-x 632468 r > root bash 57990 0 /dev 151 crw--w---- pts/1 rw > root bash 57990 1 /dev 151 crw--w---- pts/1 rw > root bash 57990 2 /dev 151 crw--w---- pts/1 rw > root bash 57990 255 /dev 151 crw--w---- pts/1 rw > root screen 57989 root / 2 drwxr-xr-x 1024 r > root screen 57989 wd /usr 11846887 drwxr-xr-x 6144 r > root screen 57989 text /usr 24495939 -rwsr-xr-x 301192 r > root screen 57989 0 /dev 15 crw-rw-rw- null r > root screen 57989 1 /dev 15 crw-rw-rw- null w > root screen 57989 2 /dev 15 crw-rw-rw- null w > root screen 57989 3 /tmp 95 prwx------ 0 r > root screen 57989 4 /dev 149 crw--w---- pts/2 rw > root screen 57989 5 /var 70466 -rw-r--r-- 591 r > root screen 57989 6* pseudo-terminal master pts/1 rw > root ntpd 44418 root / 2 drwxr-xr-x 1024 r > root ntpd 44418 wd / 2 drwxr-xr-x 1024 r > root ntpd 44418 text /usr 42158375 -r-xr-xr-x 349228 r > root ntpd 44418 0 /dev 15 crw-rw-rw- null rw > root ntpd 44418 1 /dev 15 crw-rw-rw- null rw > root ntpd 44418 2 /dev 15 crw-rw-rw- null rw > root ntpd 44418 3* local dgram c75f1000 <-> c75f0000 > root ntpd 44418 4 /var 164440 -rw-r--r-- 57025 w > root ntpd 44418 5 /var 164422 -rw-r--r-- 1741190 w > root ntpd 44418 6 /dev 36 crw-rw---- cuau2 rw > root ntpd 44418 7 /var 211400 -rw-r--r-- 3584 rw > root ntpd 44418 8 /dev 42 crw-rw---- cuau3 rw > root ntpd 44418 9 /var 211401 -rw-r--r-- 3584 rw > root ntpd 44418 10 /var 164441 -rw-r--r-- 20164 w > root ntpd 44418 20* internet dgram udp c4fff1b8 > root ntpd 44418 21* internet dgram udp c77d60dc > root ntpd 44418 22* internet dgram udp c50007bc > root ntpd 44418 23* route raw 0 c77e680c > root sh 39521 root / 2 drwxr-xr-x 1024 r > root sh 39521 wd / 16461 drwxr-xr-x 512 r > root sh 39521 text / 17809 -r-xr-xr-x 120784 r > root sh 39521 0 /dev 67 crw------- ttyu0 rw > root sh 39521 1 /dev 67 crw------- ttyu0 rw > root sh 39521 2 /dev 67 crw------- ttyu0 rw > root sh 39521 10 /dev 67 crw------- ttyu0 rw > root login 29347 root / 2 drwxr-xr-x 1024 r > root login 29347 wd / 16461 drwxr-xr-x 512 r > root login 29347 text /usr 38295942 -r-sr-xr-x 21924 r > root login 29347 0 /dev 67 crw------- ttyu0 rw > root login 29347 1 /dev 67 crw------- ttyu0 rw > root login 29347 2 /dev 67 crw------- ttyu0 rw > root login 29347 3* local dgram c75f0204 <-> c75f0000 > root getty 29346 root / 2 drwxr-xr-x 1024 r > root getty 29346 wd / 2 drwxr-xr-x 1024 r > root getty 29346 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29346 0 /dev 53 crw------- ttyv7 rw > root getty 29346 1 /dev 53 crw------- ttyv7 rw > root getty 29346 2 /dev 53 crw------- ttyv7 rw > root getty 29345 root / 2 drwxr-xr-x 1024 r > root getty 29345 wd / 2 drwxr-xr-x 1024 r > root getty 29345 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29345 0 /dev 52 crw------- ttyv6 rw > root getty 29345 1 /dev 52 crw------- ttyv6 rw > root getty 29345 2 /dev 52 crw------- ttyv6 rw > root getty 29344 root / 2 drwxr-xr-x 1024 r > root getty 29344 wd / 2 drwxr-xr-x 1024 r > root getty 29344 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29344 0 /dev 51 crw------- ttyv5 rw > root getty 29344 1 /dev 51 crw------- ttyv5 rw > root getty 29344 2 /dev 51 crw------- ttyv5 rw > root getty 29343 root / 2 drwxr-xr-x 1024 r > root getty 29343 wd / 2 drwxr-xr-x 1024 r > root getty 29343 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29343 0 /dev 50 crw------- ttyv4 rw > root getty 29343 1 /dev 50 crw------- ttyv4 rw > root getty 29343 2 /dev 50 crw------- ttyv4 rw > root getty 29342 root / 2 drwxr-xr-x 1024 r > root getty 29342 wd / 2 drwxr-xr-x 1024 r > root getty 29342 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29342 0 /dev 49 crw------- ttyv3 rw > root getty 29342 1 /dev 49 crw------- ttyv3 rw > root getty 29342 2 /dev 49 crw------- ttyv3 rw > root getty 29341 root / 2 drwxr-xr-x 1024 r > root getty 29341 wd / 2 drwxr-xr-x 1024 r > root getty 29341 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29341 0 /dev 48 crw------- ttyv2 rw > root getty 29341 1 /dev 48 crw------- ttyv2 rw > root getty 29341 2 /dev 48 crw------- ttyv2 rw > root getty 29340 root / 2 drwxr-xr-x 1024 r > root getty 29340 wd / 2 drwxr-xr-x 1024 r > root getty 29340 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29340 0 /dev 47 crw------- ttyv1 rw > root getty 29340 1 /dev 47 crw------- ttyv1 rw > root getty 29340 2 /dev 47 crw------- ttyv1 rw > root getty 29339 root / 2 drwxr-xr-x 1024 r > root getty 29339 wd / 2 drwxr-xr-x 1024 r > root getty 29339 text /usr 20584686 -r-xr-xr-x 21760 r > root getty 29339 0 /dev 46 crw------- ttyv0 rw > root getty 29339 1 /dev 46 crw------- ttyv0 rw > root getty 29339 2 /dev 46 crw------- ttyv0 rw > root inetd 29305 root / 2 drwxr-xr-x 1024 r > root inetd 29305 wd / 2 drwxr-xr-x 1024 r > root inetd 29305 text /usr 42158316 -r-xr-xr-x 42736 r > root inetd 29305 0 /dev 15 crw-rw-rw- null rw > root inetd 29305 1 /dev 15 crw-rw-rw- null rw > root inetd 29305 2 /dev 15 crw-rw-rw- null rw > root inetd 29305 3 /var 70522 -rw------- 5 w > root inetd 29305 4* pipe c500d000 <-> c500d0b8 0 rw > root inetd 29305 5* pipe c500d0b8 <-> c500d000 0 rw > root cron 29273 root / 2 drwxr-xr-x 1024 r > root cron 29273 wd /var 211495 drwxr-x--- 512 r > root cron 29273 text /usr 42158176 -r-xr-xr-x 34464 r > root cron 29273 0 /dev 15 crw-rw-rw- null rw > root cron 29273 1 /dev 15 crw-rw-rw- null rw > root cron 29273 2 /dev 15 crw-rw-rw- null rw > root cron 29273 3 /var 70521 -rw------- 5 w > root sshd 29262 root / 2 drwxr-xr-x 1024 r > root sshd 29262 wd / 2 drwxr-xr-x 1024 r > root sshd 29262 text /usr 42158090 -r-xr-xr-x 232420 r > root sshd 29262 0 /dev 15 crw-rw-rw- null rw > root sshd 29262 1 /dev 15 crw-rw-rw- null rw > root sshd 29262 2 /dev 15 crw-rw-rw- null rw > root sshd 29262 3* internet stream tcp c77d1768 > mailnull exim-4.72-0 29201 root / 2 drwxr-xr-x 1024 r > mailnull exim-4.72-0 29201 wd /var 93953 drwxr-x--- 512 r > mailnull exim-4.72-0 29201 text /usr 24541512 -rwsr-xr-x 877756 r > mailnull exim-4.72-0 29201 0 /dev 15 crw-rw-rw- null rw > mailnull exim-4.72-0 29201 1 /dev 15 crw-rw-rw- null rw > mailnull exim-4.72-0 29201 2 /dev 15 crw-rw-rw- null rw > mailnull exim-4.72-0 29201 3* internet stream tcp c77d0768 > mailnull exim-4.72-0 29201 4* internet stream tcp c77d1000 > mailnull exim-4.72-0 29201 5* internet stream tcp c78094f0 > mailnull exim-4.72-0 29201 6* internet stream tcp c7809278 > mailnull exim-4.72-0 29201 9 /var 187908 -rw-r----- 903663 w > pgsql postgres 29106 root / 2 drwxr-xr-x 1024 r > pgsql postgres 29106 wd /usr 24944078 drwx------ 512 r > pgsql postgres 29106 text /usr 24495550 -rwxr-xr-x 2968772 r > pgsql postgres 29106 0 /dev 15 crw-rw-rw- null rw > pgsql postgres 29106 1 /dev 15 crw-rw-rw- null rw > pgsql postgres 29106 2 /dev 15 crw-rw-rw- null rw > pgsql postgres 29106 5* local dgram c75f0a14 <-> c75f00ac > pgsql postgres 29106 6* internet dgram udp c50006e0 > pgsql postgres 29105 root / 2 drwxr-xr-x 1024 r > pgsql postgres 29105 wd /usr 24944078 drwx------ 512 r > pgsql postgres 29105 text /usr 24495550 -rwxr-xr-x 2968772 r > pgsql postgres 29105 0 /dev 15 crw-rw-rw- null rw > pgsql postgres 29105 1 /dev 15 crw-rw-rw- null rw > pgsql postgres 29105 2 /dev 15 crw-rw-rw- null rw > pgsql postgres 29105 5* local dgram c75f0a14 <-> c75f00ac > pgsql postgres 29105 6* internet dgram udp c50006e0 > pgsql postgres 29105 7 /usr 24988964 -rw------- 16777216 rw > pgsql postgres 29103 root / 2 drwxr-xr-x 1024 r > pgsql postgres 29103 wd /usr 24944078 drwx------ 512 r > pgsql postgres 29103 text /usr 24495550 -rwxr-xr-x 2968772 r > pgsql postgres 29103 0 /dev 15 crw-rw-rw- null rw > pgsql postgres 29103 1 /dev 15 crw-rw-rw- null rw > pgsql postgres 29103 2 /dev 15 crw-rw-rw- null rw > pgsql postgres 29103 3* internet stream tcp c77d0000 > pgsql postgres 29103 4* local stream c75f0968 > pgsql postgres 29103 5* local dgram c75f0a14 <-> c75f00ac > pgsql postgres 29103 6* internet dgram udp c50006e0 > root lpd 28988 root / 2 drwxr-xr-x 1024 r > root lpd 28988 wd / 2 drwxr-xr-x 1024 r > root lpd 28988 text /usr 42158332 -r-xr-xr-x 76384 r > root lpd 28988 0 /dev 15 crw-rw-rw- null rw > root lpd 28988 1 /dev 15 crw-rw-rw- null rw > root lpd 28988 2 /dev 15 crw-rw-rw- null rw > root lpd 28988 3* local dgram c75f0560 <-> c75f0000 > root lpd 28988 4 /var 93997 -rw-rw-r-- 6 w > root lpd 28988 5* local stream c75f060c > root lpd 28988 6* internet stream tcp c77d0278 > root rpcbind 28818 root / 2 drwxr-xr-x 1024 r > root rpcbind 28818 wd / 2 drwxr-xr-x 1024 r > root rpcbind 28818 text /usr 42158494 -r-xr-xr-x 39588 r > root rpcbind 28818 0 /dev 15 crw-rw-rw- null rw > root rpcbind 28818 1 /dev 15 crw-rw-rw- null rw > root rpcbind 28818 2 /dev 15 crw-rw-rw- null rw > root rpcbind 28818 3 /var 70509 -r--r--r-- 0 r > root rpcbind 28818 5* local stream c75f0408 > root rpcbind 28818 6* local dgram c75f04b4 <-> c75f0000 > root rpcbind 28818 7* internet dgram udp c4fffb2c > root rpcbind 28818 8* internet dgram udp c5000528 > root rpcbind 28818 9* internet stream tcp c77d04f0 > bind named 28794 root / 2 drwxr-xr-x 1024 r > bind named 28794 wd / 32958 drwxr-xr-x 512 r > bind named 28794 text /usr 42158313 -r-xr-xr-x 1957456 r > bind named 28794 0 /dev 15 crw-rw-rw- null rw > bind named 28794 1 /dev 15 crw-rw-rw- null rw > bind named 28794 2 /dev 15 crw-rw-rw- null rw > bind named 28794 3* local dgram c75f0158 <-> c75f0000 > bind named 28794 4 /dev 15 crw-rw-rw- null rw > bind named 28794 5* pipe c500c188 <-> c500c240 0 rw > bind named 28794 7* pipe c500c240 <-> c500c188 0 rw > bind named 28794 9 /dev 25 crw-rw-rw- random r > bind named 28794 20* internet stream tcp c77d0c58 > bind named 28794 21* internet stream tcp c77d09e0 > bind named 28794 512* internet dgram udp c4fff294 > bind named 28794 514* internet dgram udp c5000a50 > root syslogd 28779 root / 2 drwxr-xr-x 1024 r > root syslogd 28779 wd / 2 drwxr-xr-x 1024 r > root syslogd 28779 text /usr 42158509 -r-xr-xr-x 35984 r > root syslogd 28779 0 /dev 15 crw-rw-rw- null rw > root syslogd 28779 1 /dev 15 crw-rw-rw- null rw > root syslogd 28779 2 /dev 15 crw-rw-rw- null rw > root syslogd 28779 3 /var 70494 -rw------- 5 w > root syslogd 28779 4* local dgram c75f00ac > root syslogd 28779 5* local dgram c75f0000 > root syslogd 28779 6* internet dgram udp c4fff370 > root syslogd 28779 7 /dev 14 crw------- klog r > root syslogd 28779 9 - - bad - > root syslogd 28779 10 /var 164534 -rw-r--r-- 3799383 w > root syslogd 28779 11 /var 164577 -rw------- 60 w > root syslogd 28779 12 /var 164497 -rw------- 9340748 w > root syslogd 28779 13 /var 164530 -rw-r----- 778934 w > root syslogd 28779 14 /var 164459 -rw-r--r-- 51244 w > root syslogd 28779 15 /var 164463 -rw------- 14969 w > root syslogd 28779 16 /var 164436 -rw------- 18198 w > root syslogd 28779 17 /var 164506 -rw------- 41941 w > root syslogd 28779 18 /var 164563 -rw-r----- 60 w > _pflogd pflogd 28574 root /var 12 dr-xr-xr-x 512 r > _pflogd pflogd 28574 wd /var 12 dr-xr-xr-x 512 r > _pflogd pflogd 28574 jail /var 12 dr-xr-xr-x 512 r > _pflogd pflogd 28574 text / 1463 -r-xr-xr-x 18880 r > _pflogd pflogd 28574 0 /dev 15 crw-rw-rw- null rw > _pflogd pflogd 28574 1 /dev 15 crw-rw-rw- null rw > _pflogd pflogd 28574 2 /dev 15 crw-rw-rw- null rw > _pflogd pflogd 28574 3 /dev 11 crw------- bpf rw > _pflogd pflogd 28574 4 /var 164557 -rw------- 24 rw > _pflogd pflogd 28574 5* local stream c75f02b0 <-> c75f035c > root pflogd 28572 root / 2 drwxr-xr-x 1024 r > root pflogd 28572 wd / 2 drwxr-xr-x 1024 r > root pflogd 28572 text / 1463 -r-xr-xr-x 18880 r > root pflogd 28572 0 /dev 15 crw-rw-rw- null rw > root pflogd 28572 1 /dev 15 crw-rw-rw- null rw > root pflogd 28572 2 /dev 15 crw-rw-rw- null rw > root pflogd 28572 3 /dev 11 crw------- bpf rw > root pflogd 28572 4* local stream c75f035c <-> c75f02b0 > root devd 28553 root / 2 drwxr-xr-x 1024 r > root devd 28553 wd / 2 drwxr-xr-x 1024 r > root devd 28553 text / 1402 -r-xr-xr-x 404976 r > root devd 28553 0 /dev 15 crw-rw-rw- null rw > root devd 28553 1 /dev 15 crw-rw-rw- null rw > root devd 28553 2 /dev 15 crw-rw-rw- null rw > root devd 28553 3 / 33227 drwxr-xr-x 512 r > root devd 28553 4 /dev 4 crw------- devctl r > root devd 28553 5* local stream c75f0c18 > root devd 28553 6 /var 70476 -rw------- 5 w > root moused 28536 root / 2 drwxr-xr-x 1024 r > root moused 28536 wd / 2 drwxr-xr-x 1024 r > root moused 28536 text /usr 42158367 -r-xr-xr-x 36220 r > root moused 28536 0 /dev 15 crw-rw-rw- null rw > root moused 28536 1 /dev 15 crw-rw-rw- null rw > root moused 28536 2 /dev 15 crw-rw-rw- null rw > root moused 28536 3 /dev 138 crw-r--r-- ums0 rw > root moused 28536 4 /dev 62 crw------- consolectl rw > root moused 28536 5 /var 70471 -rw------- 5 w > root adjkerntz 27845 root / 2 drwxr-xr-x 1024 r > root adjkerntz 27845 wd / 2 drwxr-xr-x 1024 r > root adjkerntz 27845 text / 11 -r-xr-xr-x 7448 r > root adjkerntz 27845 0 /dev 15 crw-rw-rw- null rw > root adjkerntz 27845 1 /dev 15 crw-rw-rw- null rw > root adjkerntz 27845 2 /dev 15 crw-rw-rw- null rw > root init 1 root / 2 drwxr-xr-x 1024 r > root init 1 wd / 2 drwxr-xr-x 1024 r > root init 1 text / 61 -r-xr-xr-x 664972 r > > ------------------------------------------------------------------------ > dmesg > > Setting hostuuid: fe134458-976b-11dc-8f0f-006008101031. > Setting hostid: 0x43bda48f. > Entropy harvesting: > interrupts > ethernet > point_to_point > kickstart > . > Fast boot: skipping disk checks. > Mounting local file systems: > . > Setting hostname: brane.freislich.nom.za > . > Starting Network: lo0 re0 re1 pfsync0 pflog0. > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > re0: flags=8843 metric 0 mtu 1500 > options=389b OL_MCAST,WOL_MAGIC> ether 00:30:4f:52:39:70 > inet 41.154.0.9 netmask 0xfffffff8 broadcast 41.154.0.15 > media: Ethernet autoselect (none) > status: no carrier > re1: flags=8802 metric 0 mtu 1500 > options=389b OL_MCAST,WOL_MAGIC> ether 00:01:29:2d:41:49 > media: Ethernet autoselect (100baseTX ) > status: no carrier > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > pflog0: flags=0<> metric 0 mtu 33200 > Starting devd. > Starting Network: re1. > re1: flags=8802 metric 0 mtu 1500 > options=389b OL_MCAST,WOL_MAGIC> ether 00:01:29:2d:41:49 > media: Ethernet autoselect (100baseTX ) > status: no carrier > Starting Network: pfsync0. > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > Starting Network: pflog0. > pflog0: flags=0<> metric 0 mtu 33200 > Configuring keyboard: > keymap > keyrate > . > Starting ums0 moused > . > Starting pflog. > Aug 20 14:19:12 pflogd[28572]: [priv]: msg PRIV_OPEN_LOG received > add net default: gateway 41.154.0.14 > Generating host.conf. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout > Creating and/or trimming log files > . > Starting syslogd. > No core dumps found. > Additional ABI support: > linux > . > Starting named. > Aug 20 14:19:13 brane named[28794]: the working directory is not writable > Setting date via ntp. > 20 Aug 14:19:13 > ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 > 20 Aug 14:19:14 > ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 > 20 Aug 14:19:15 > ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 > 20 Aug 14:19:16 > ntpdate[28802]: sendto(196.7.18.242): Unknown error: 0 > re0: link state changed to UP > 20 Aug 14:19:17 > ntpdate[28802]: no server suitable for synchronization found > Starting rpcbind. > Aug 20 14:19:17 brane rpcbind: cannot create socket for udp6 > Clearing /tmp (X related). > Starting lpd. > Updating motd: > . > Starting fusefs. > KLD fuse.ko: depends on kernel - not available or version mismatch > kldload: > can't load /usr/local/modules/fuse.ko > > File exists > Starting owfs. > fuse: failed to open fuse device: No such file or directory > Starting ntpd. > /etc/rc: WARNING: run_rc_command: cannot run /usr/local/bin/spamd > Starting default moused > moused: > unable to open /dev/psm0: No such file or directory > > . > /etc/rc: WARNING: run_rc_command: cannot run /usr/local/sbin/clamd > /etc/rc: WARNING: run_rc_command: cannot run /usr/local/bin/freshclam > Starting exim. > /etc/rc: WARNING: run_rc_command: cannot run /usr/local/sbin/httpd > Configuring syscons: > keymap > keyrate > blanktime > allscreens > . > Starting sshd. > Starting cron. > Local package initialization: > popd > /usr/local/etc/rc.d/050.popd.sh: /usr/local/libexec/popd: not found > popd-ssl > /usr/local/etc/rc.d/050.popd.sh: /usr/local/libexec/popd: not found > . > Starting inetd. > Starting background file system checks in 60 seconds. > > Fri Aug 20 14:19:25 SAST 2010 > Aug 20 14:20:44 brane su: ianf to root on /dev/pts/0 > Aug 20 14:24:26 brane login: ROOT LOGIN (root) ON ttyu0 > Aug 20 14:27:06 brane su: ianf to root on /dev/pts/0 > Aug 20 15:05:42 brane su: BAD SU ianf to root on /dev/pts/2 > Aug 20 15:05:48 brane su: ianf to root on /dev/pts/2 > Aug 20 15:10:14 brane su: ianf to root on /dev/pts/3 > Aug 20 15:10:36 brane named[28794]: client 41.161.16.217#52348: zone > transfer 'freislich.nom.za/AXFR/IN' denied Aug 20 15:18:19 brane su: ianf > to root on /dev/pts/3 > fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xe75d3b50 > frame pointer = 0x28:0xe75d3c14 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 56578 (sh) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at > kdb_backtrace+0x29 panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf > trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 > trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b > trap(e75d3b10) at trap+0x423 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- > uart_z8530_class(c784ab00,ffffff9c,284052c4,0,402,...) at 0 > kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 > open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 > syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at > syscallenter+0x343 syscall(e75d3d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, > ebp = 0xbfbfea28 --- Uptime: 1h49m31s > Physical memory: 2007 MB > Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 > > ------------------------------------------------------------------------ > kernel config > > config: File /boot/kernel/kernel doesn't contain configuration file. Either > unsupported, or not compiled with INCLUDE_CONFIG_FILE > > ------------------------------------------------------------------------ > ddb capture buffer Hi, Do you have all the drivers you need in the kernel? ./uart/uart.h:extern struct uart_class uart_z8530_class __attribute__((weak)); ./uart/uart_bus_scc.c: sc->sc_class = &uart_z8530_class; ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class; ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class; ./uart/uart_cpu_sparc64.c: class = &uart_z8530_class; ./uart/uart_dev_z8530.c:struct uart_class uart_z8530_class = { ./uart/uart_subr.c: &uart_z8530_class, --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 16:53:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9405B10656A8 for ; Fri, 20 Aug 2010 16:53:24 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id D661E8FC17 for ; Fri, 20 Aug 2010 16:53:23 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OmUqI-0002ZO-Ch; Fri, 20 Aug 2010 18:53:22 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmUqF-0000TQ-Vy; Fri, 20 Aug 2010 18:53:19 +0200 Message-Id: To: Hans Petter Selasky From: Ian FREISLICH In-Reply-To: <201008201823.36022.hselasky@c2i.net> References: <201008201823.36022.hselasky@c2i.net> X-Attribution: BOFH Date: Fri, 20 Aug 2010 18:53:19 +0200 Cc: freebsd-current@freebsd.org Subject: Re: fusefs-kmod broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:53:24 -0000 Hans Petter Selasky wrote: > Do you have all the drivers you need in the kernel? > > ./uart/uart.h:extern struct uart_class uart_z8530_class __attribute__((weak)) ; > ./uart/uart_bus_scc.c: sc->sc_class = &uart_z8530_class; > ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class; > ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class; > ./uart/uart_cpu_sparc64.c: class = &uart_z8530_class; > ./uart/uart_dev_z8530.c:struct uart_class uart_z8530_class = { > ./uart/uart_subr.c: &uart_z8530_class, What drivers do you sugest? These are what's configured. device ucom device uplcom device uart # 8250, 16[45]50 based serial ports device puc The 2 DS2480 (1-wire bus masters) are on 2 PL2303 usb serial ports. Reading the devices works fine: [brane] /1-wire # ls 10.0ADC53010800 10.AB2D4C010800 26.1D82B5000000 bus.0 structure 10.174637010800 10.BD4437010800 26.2882B5000000 bus.1 system 10.19D24C010800 10.E32C4C010800 29.832903000000 settings uncached 10.4A6237010800 1D.33F00D000000 29.A52A03000000 simultaneous 10.725A4C010800 1D.6A560B000000 alarm statistics [brane] /1-wire # cat 10.0ADC53010800/temperature 22.1875 It's writing to the 29.A52A03000000 or 29.832903000000 PIO registers that results in the panic. [brane] /1-wire # ls 29.A52A03000000 LCD_H PIO.ALL latch.4 r_address sensed.7 LCD_M PIO.BYTE latch.5 r_id sensed.ALL PIO.0 address latch.6 r_locator sensed.BYTE PIO.1 crc8 latch.7 sensed.0 set_alarm PIO.2 family latch.ALL sensed.1 strobe PIO.3 id latch.BYTE sensed.2 type PIO.4 latch.0 locator sensed.3 PIO.5 latch.1 por sensed.4 PIO.6 latch.2 power sensed.5 PIO.7 latch.3 present sensed.6 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 16:55:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B73810656A5; Fri, 20 Aug 2010 16:55:09 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB278FC1B; Fri, 20 Aug 2010 16:55:08 +0000 (UTC) Received: by qyk8 with SMTP id 8so698899qyk.13 for ; Fri, 20 Aug 2010 09:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lRVzHtqevEcPUp+nkmk+nM8jfWj+LXRqLEsbICJYthk=; b=Y7TVd/4Zpf4nw2x5Q7xVwdy8n9DXgh0Ay1/8Xjhbk1ej5IcKo88QEkWKzQ6uQeCqgP JLb8E87PHBo2CeAYpT48gCpXaLuUS+lZY/WFcZpqjT8axbjir5T18OsbqIlgKTCiceQm kzWKd6ilwWOfZqvX+2Y39PoHTQkhFGhuajhCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bxS6merDtfAsSxsbULSV+WgQjlAWK3sVL44UAp+TyfotwGzZyazRh7Ck+nDGkDF9Gb jVWKGQMP6geetBkWtN9CUnnD0xHzKYPpE4IeE32eo6hBosHoSUR3RdLYptW6bDfs74Vl aCnw5pEr5RIMtJz5Cgp5nUkWRPzwe21NgLwWw= MIME-Version: 1.0 Received: by 10.224.36.209 with SMTP id u17mr1108901qad.328.1282323308209; Fri, 20 Aug 2010 09:55:08 -0700 (PDT) Received: by 10.229.26.81 with HTTP; Fri, 20 Aug 2010 09:55:08 -0700 (PDT) In-Reply-To: <201008190934.28365.jhb@freebsd.org> References: <201008181607.52798.jhb@freebsd.org> <201008190934.28365.jhb@freebsd.org> Date: Fri, 20 Aug 2010 20:55:08 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: multipart/mixed; boundary=0015175caf7c45eade048e44290f Cc: Kostik Belousov , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:55:09 -0000 --0015175caf7c45eade048e44290f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 19 August 2010 17:34, John Baldwin wrote: > On Thursday, August 19, 2010 5:29:25 am pluknet wrote: >> On 19 August 2010 00:07, John Baldwin wrote: >> > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: >> >> On 18 August 2010 23:11, pluknet wrote: >> >> > On 18 August 2010 17:46, Kostik Belousov wrot= e: >> >> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: >> >> >>> On 18 August 2010 12:07, pluknet wrote: >> >> >>> > On 17 August 2010 20:04, Kostik Belousov = wrote: >> >> >>> > >> >> >>> >> >> >> >>> >> Also please take a note of the John' suggestion to use the tas= kqueue. >> >> >>> > >> >> >>> > I decided to go this road. Thank you both. >> >> >>> > Now I do nfs buildkernel survive and prepare some benchmark res= ults. >> >> >>> > >> >> >>> >> >> >>> So, I modified the patch to defer proc_create() with taskqueue(9)= . >> >> >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=3Dyes` perf. >> > evaluation. >> >> >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both >> >> >>> nfs-mounted over 1Gbit LAN. >> >> >>> >> >> >>> clean old >> >> >>> 1137.985u 239.411s 7:42.15 298.0% =A0 =A0 =A0 6538+2133k 87+43388= io 226pf+0w >> >> >>> >> >> >>> clean new >> >> >>> 1134.755u 240.032s 7:41.25 298.0% =A0 =A0 =A0 6553+2133k 87+43367= io 224pf+0w >> >> >>> >> >> >>> Patch needs polishing, though it generally works. >> >> >>> Not sure if shep_chan (or whatever name it will get) needs lockin= g. >> >> >> As I said yesterday, if several requests to create nfsiod coming o= ne >> >> >> after another, you would loose all but the last. >> >> >> >> >> >> You should put the requests into the list, probably protected by >> >> >> nfs_iod_mtx. >> >> >> >> >> > >> >> > How about this patch? Still several things to ask. >> >> > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_i= od_mtx >> > held. >> >> > 2) Probably busy/done gymnastics is a wrong mess. Your help is >> > appreciated. >> >> > 3) if (1) is fine, is it right to use fail: logic (i.e. set >> >> > NFSIOD_NOT_AVAILABLE) >> >> > on memory shortage? Not tested. >> >> > >> >> > There are debug printf() left intentionally to see how 3 contexts r= un >> > under load >> >> > to each other. I attached these messages as well if that makes sens= e. >> >> > >> >> >> >> Ah, yes. Sorry, forgot about that. >> > >> > Your task handler needs to run in a loop until the list of requests is= empty. >> > If multiple threads call taskqueue_enqueue() before your task is sched= uled, >> > they will be consolidated down to a single call of your task handler. >> >> Thanks for your suggestions. >> >> So I converted nfs_nfsiodnew_tq() into loop, and as such >> I changed a cleanup SLIST_FOREACH() as well to free a bulk of >> (potentially consolidated) completed requests in one pass. >> kproc_create() is still out of the SLIST_FOREACH() to avoid calling it >> with nfs_iod_mtx held. >> >> > >> > - =A0 =A0 =A0 int error, i; >> > - =A0 =A0 =A0 int newiod; >> > + =A0 =A0 =A0 int i, newiod, error; >> > >> > You should sort these alphabetically if you are going to change this. = =A0I would >> > probably just leave it as-is. >> >> Err.. that's resulted after a set of changes. Thanks for noting that. >> >> > >> > Also, I'm not sure how this works as you don't actually wait for the t= ask to >> > complete. =A0If the taskqueue_enqueue() doesn't preempt, then you may = read >> > ni_error as zero before the kproc has actually been created and return= success >> > even though an nfsiod hasn't been created. >> > >> >> I put taskqueue_drain() right after taskqueue_enqueue() to be in sync wi= th >> task handler. That was part to think about, as I didn't find such a use = pattern. >> It seems though that tasks are launched now strictly one-by-one, without >> visible parallelism (as far as debug printf()s don't overlap anymore). > > Ah, if it is safe to sleep then I have a couple of suggestions: > Cool, credits go to John :). I just adopted all of your changes (attached). > - Use M_WAITOK to malloc() so you don't have to worry about the failure c= ase > =A0(I see Rick already suggested this). After all that reduces to the following replacement in nfs_nfsiodnew(). So, no regression should be there in theory. mtx_unlock(&nfs_iod_mtx); - kproc_create(...) + malloc(...) mtx_lock(&nfs_iod_mtx); It survived after this simple test running for an hour, which forces creation of many iods with r/w from 300 threads: nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & while [ true ]; do sysctl vfs.nfs.iodmax=3D2; sysctl vfs.nfs.iodmax=3D60; sleep 20; done randomio is from ports/149838. P.S. it's funny to see in top 0 root 10 44 0 0K 144K deadlk 2 23:16 28.86% kernel Someone might think the kernel is in deadlock. --=20 wbr, pluknet --0015175caf7c45eade048e44290f Content-Type: application/octet-stream; name="nfsiod_tq_lock.3.diff" Content-Disposition: attachment; filename="nfsiod_tq_lock.3.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gd3a4fy00 SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX3N1YnMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmZzY2xp ZW50L25mc19zdWJzLmMJKHJldmlzaW9uIDIxMTI3OSkKKysrIHN5cy9uZnNjbGllbnQvbmZzX3N1 YnMuYwkod29ya2luZyBjb3B5KQpAQCAtNTksNiArNTksNyBAQAogI2luY2x1ZGUgPHN5cy9zeXNl bnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzY2FsbC5oPgogI2luY2x1ZGUgPHN5cy9zeXNwcm90by5o PgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5j bHVkZSA8dm0vdm1fb2JqZWN0Lmg+CkBAIC0xMTcsNiArMTE4LDcgQEAKIAogc3RydWN0IG5mc19i dWZxCW5mc19idWZxOwogc3RhdGljIHN0cnVjdCBtdHggbmZzX3hpZF9tdHg7CitzdHJ1Y3QgdGFz awluZnNfbmZzaW9kbmV3X3Rhc2s7CiAKIC8qCiAgKiBhbmQgdGhlIHJldmVyc2UgbWFwcGluZyBm cm9tIGdlbmVyaWMgdG8gVmVyc2lvbiAyIHByb2NlZHVyZSBudW1iZXJzCkBAIC0zNTQsNiArMzU2 LDcgQEAKIAkgKi8KIAltdHhfaW5pdCgmbmZzX2lvZF9tdHgsICJORlMgaW9kIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKIAltdHhfaW5pdCgmbmZzX3hpZF9tdHgsICJORlMgeGlkIGxvY2siLCBOVUxM LCBNVFhfREVGKTsKKwlUQVNLX0lOSVQoJm5mc19uZnNpb2RuZXdfdGFzaywgMCwgbmZzX25mc2lv ZG5ld190cSwgTlVMTCk7CiAKIAluZnNfcGJ1Zl9mcmVlY250ID0gbnN3YnVmIC8gMiArIDE7CiAK SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzX25mc2lvZC5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZnNj bGllbnQvbmZzX25mc2lvZC5jCShyZXZpc2lvbiAyMTEyNzkpCisrKyBzeXMvbmZzY2xpZW50L25m c19uZnNpb2QuYwkod29ya2luZyBjb3B5KQpAQCAtNTksNiArNTksNyBAQAogI2luY2x1ZGUgPHN5 cy9mY250bC5oPgogI2luY2x1ZGUgPHN5cy9sb2NrZi5oPgogI2luY2x1ZGUgPHN5cy9tdXRleC5o PgorI2luY2x1ZGUgPHN5cy90YXNrcXVldWUuaD4KIAogI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4K ICNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgpAQCAtNzUsNiArNzYsMTYgQEAKIAogc3RhdGljIHZv aWQJbmZzc3ZjX2lvZCh2b2lkICopOwogCitzdHJ1Y3QgbmZzaW9kX3N0ciB7CisJU1RBSUxRX0VO VFJZKG5mc2lvZF9zdHIpIG5pX2xpbmtzOworCWludCAqbmlfaW5zdDsKKwlpbnQgbmlfaW9kOwor CWludCBuaV9lcnJvcjsKKwlpbnQgbmlfZG9uZTsKK307CitzdGF0aWMgU1RBSUxRX0hFQUQoLCBu ZnNpb2Rfc3RyKSBuZnNpb2RoZWFkID0KKyAgICBTVEFJTFFfSEVBRF9JTklUSUFMSVpFUihuZnNp b2RoZWFkKTsKKwogc3RhdGljIGludCBuZnNfYXN5bmNkYWVtb25bTkZTX01BWEFTWU5DREFFTU9O XTsKIAogU1lTQ1RMX0RFQ0woX3Zmc19uZnMpOwpAQCAtMTU5LDExICsxNzAsMzAgQEAKICAgICBz aXplb2YgKG5mc19pb2RtYXgpLCBzeXNjdGxfaW9kbWF4LCAiSVUiLAogICAgICJNYXggbnVtYmVy IG9mIG5mc2lvZCBrdGhyZWFkcyIpOwogCit2b2lkCituZnNfbmZzaW9kbmV3X3RxKF9fdW51c2Vk IHZvaWQgKmFyZywgaW50IHBlbmRpbmcpCit7CisJc3RydWN0IG5mc2lvZF9zdHIgKm5pcDsKKwor CW10eF9sb2NrKCZuZnNfaW9kX210eCk7CisJd2hpbGUgKChuaXAgPSBTVEFJTFFfRklSU1QoJm5m c2lvZGhlYWQpKSAhPSBOVUxMKSB7CisJCVNUQUlMUV9SRU1PVkVfSEVBRCgmbmZzaW9kaGVhZCwg bmlfbGlua3MpOworCQltdHhfdW5sb2NrKCZuZnNfaW9kX210eCk7CisJCW5pcC0+bmlfZXJyb3Ig PSBrcHJvY19jcmVhdGUobmZzc3ZjX2lvZCwgbmlwLT5uaV9pbnN0LCBOVUxMLAorCQkgICAgUkZI SUdIUElELCAwLCAibmZzaW9kICVkIiwgbmlwLT5uaV9pb2QpOworCQluaXAtPm5pX2RvbmUgPSAx OworCQltdHhfbG9jaygmbmZzX2lvZF9tdHgpOworCQl3YWtldXAobmlwKTsKKwl9CisJbXR4X3Vu bG9jaygmbmZzX2lvZF9tdHgpOworfQorCiBpbnQKIG5mc19uZnNpb2RuZXcoaW50IHNldF9pb2R3 YW50KQogewogCWludCBlcnJvciwgaTsKIAlpbnQgbmV3aW9kOworCXN0cnVjdCBuZnNpb2Rfc3Ry ICpuaXA7CiAKIAlpZiAobmZzX251bWFzeW5jID49IG5mc19pb2RtYXgpCiAJCXJldHVybiAoLTEp OwpAQCAtMTc5LDkgKzIwOSwxNiBAQAogCWlmIChzZXRfaW9kd2FudCA+IDApCiAJCW5mc19pb2R3 YW50W2ldID0gTkZTSU9EX0NSRUFURURfRk9SX05GU19BU1lOQ0lPOwogCW10eF91bmxvY2soJm5m c19pb2RfbXR4KTsKLQllcnJvciA9IGtwcm9jX2NyZWF0ZShuZnNzdmNfaW9kLCBuZnNfYXN5bmNk YWVtb24gKyBpLCBOVUxMLCBSRkhJR0hQSUQsCi0JICAgIDAsICJuZnNpb2QgJWQiLCBuZXdpb2Qp OworCW5pcCA9IG1hbGxvYyhzaXplb2YoKm5pcCksIE1fVEVNUCwgTV9XQUlUT0sgfCBNX1pFUk8p OworCW5pcC0+bmlfaW5zdCA9IG5mc19hc3luY2RhZW1vbiArIGk7CisJbmlwLT5uaV9pb2QgPSBu ZXdpb2Q7CiAJbXR4X2xvY2soJm5mc19pb2RfbXR4KTsKKwlTVEFJTFFfSU5TRVJUX1RBSUwoJm5m c2lvZGhlYWQsIG5pcCwgbmlfbGlua3MpOworCXRhc2txdWV1ZV9lbnF1ZXVlKHRhc2txdWV1ZV90 aHJlYWQsICZuZnNfbmZzaW9kbmV3X3Rhc2spOworCXdoaWxlICghbmlwLT5uaV9kb25lKQorCQlt dHhfc2xlZXAobmlwLCAmbmZzX2lvZF9tdHgsIDAsICJuaXd0IiwgMCk7CisJZXJyb3IgPSBuaXAt Pm5pX2Vycm9yOworCWZyZWUobmlwLCBNX1RFTVApOwogCWlmIChlcnJvcikgewogCQlpZiAoc2V0 X2lvZHdhbnQgPiAwKQogCQkJbmZzX2lvZHdhbnRbaV0gPSBORlNJT0RfTk9UX0FWQUlMQUJMRTsK SW5kZXg6IHN5cy9uZnNjbGllbnQvbmZzLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25mc2NsaWVudC9u ZnMuaAkocmV2aXNpb24gMjExMjc5KQorKysgc3lzL25mc2NsaWVudC9uZnMuaAkod29ya2luZyBj b3B5KQpAQCAtMTI1LDYgKzEyNSw3IEBACiAKIGV4dGVybiBzdHJ1Y3QgbmZzc3RhdHMgbmZzc3Rh dHM7CiBleHRlcm4gc3RydWN0IG10eCBuZnNfaW9kX210eDsKK2V4dGVybiBzdHJ1Y3QgdGFzayBu ZnNfbmZzaW9kbmV3X3Rhc2s7CiAKIGV4dGVybiBpbnQgbmZzX251bWFzeW5jOwogZXh0ZXJuIHVu c2lnbmVkIGludCBuZnNfaW9kbWF4OwpAQCAtMjUzLDYgKzI1NCw3IEBACiAJICAgIHN0cnVjdCB1 Y3JlZCAqY3JlZCwgc3RydWN0IHRocmVhZCAqdGQpOwogaW50CW5mc19yZWFkZGlycnBjKHN0cnVj dCB2bm9kZSAqLCBzdHJ1Y3QgdWlvICosIHN0cnVjdCB1Y3JlZCAqKTsKIGludAluZnNfbmZzaW9k bmV3KGludCk7Cit2b2lkCW5mc19uZnNpb2RuZXdfdHEoX191bnVzZWQgdm9pZCAqLCBpbnQpOwog aW50CW5mc19hc3luY2lvKHN0cnVjdCBuZnNtb3VudCAqLCBzdHJ1Y3QgYnVmICosIHN0cnVjdCB1 Y3JlZCAqLCBzdHJ1Y3QgdGhyZWFkICopOwogaW50CW5mc19kb2lvKHN0cnVjdCB2bm9kZSAqLCBz dHJ1Y3QgYnVmICosIHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3QgdGhyZWFkICopOwogdm9pZAluZnNf ZG9pb19kaXJlY3R3cml0ZSAoc3RydWN0IGJ1ZiAqKTsK --0015175caf7c45eade048e44290f-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 17:03:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 079C710656A3; Fri, 20 Aug 2010 17:03:30 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 996C58FC12; Fri, 20 Aug 2010 17:03:29 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id B87BA2A28CF3; Fri, 20 Aug 2010 19:03:27 +0200 (CEST) Date: Fri, 20 Aug 2010 19:03:27 +0200 From: Ed Schouten To: Daichi GOTO Message-ID: <20100820170327.GL2978@hoeg.nl> References: <4C6B9F51.1060009@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cW0eHRJ76X8TDo3d" Content-Disposition: inline In-Reply-To: <4C6B9F51.1060009@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, ozawa@ongs.co.jp Subject: Whiteout support for tmpfs [Was: unionfs a little improvement] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:03:30 -0000 --cW0eHRJ76X8TDo3d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Even though the proposed fix for unionfs would still be nice to have in SVN, I just wrote a patch for tmpfs to add support for whiteouts: http://80386.nl/pub/tmpfs-whiteout.txt Basically I've implemented it by allowing directory entries to refer to NULL inodes, to indicate the entry is a whiteout. I think the patch should work pretty well, but what I dislike about it, is that when it removes a file and replaces it by a whiteout, it deallocates the entire directory entry, followed by the allocation of a new directory entry for the whiteout. This could be done more efficiently, but the problem is that it turns the code into a mess. Any comments? --=20 Ed Schouten WWW: http://80386.nl/ --cW0eHRJ76X8TDo3d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxutV8ACgkQ52SDGA2eCwWV2wCdFgiJwRp3LqMCyav+AJfLHg6b /cIAn2MtKM/AEmxHH7mW7WpdU8dKPMdT =UF2+ -----END PGP SIGNATURE----- --cW0eHRJ76X8TDo3d-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:19:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0732106567A; Fri, 20 Aug 2010 19:19:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 11D488FC08; Fri, 20 Aug 2010 19:19:57 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7KJJrpr079223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 22:19:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7KJJrGc093395; Fri, 20 Aug 2010 22:19:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7KJJrMD093394; Fri, 20 Aug 2010 22:19:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 Aug 2010 22:19:53 +0300 From: Kostik Belousov To: pluknet Message-ID: <20100820191953.GN2396@deviant.kiev.zoral.com.ua> References: <201008181607.52798.jhb@freebsd.org> <201008190934.28365.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6kwAx1lhQCGpXeLP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:19:58 -0000 --6kwAx1lhQCGpXeLP Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 20, 2010 at 08:55:08PM +0400, pluknet wrote: > On 19 August 2010 17:34, John Baldwin wrote: > > On Thursday, August 19, 2010 5:29:25 am pluknet wrote: > >> On 19 August 2010 00:07, John Baldwin wrote: > >> > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: > >> >> On 18 August 2010 23:11, pluknet wrote: > >> >> > On 18 August 2010 17:46, Kostik Belousov wr= ote: > >> >> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: > >> >> >>> On 18 August 2010 12:07, pluknet wrote: > >> >> >>> > On 17 August 2010 20:04, Kostik Belousov wrote: > >> >> >>> > > >> >> >>> >> > >> >> >>> >> Also please take a note of the John' suggestion to use the t= askqueue. > >> >> >>> > > >> >> >>> > I decided to go this road. Thank you both. > >> >> >>> > Now I do nfs buildkernel survive and prepare some benchmark r= esults. > >> >> >>> > > >> >> >>> > >> >> >>> So, I modified the patch to defer proc_create() with taskqueue(= 9). > >> >> >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=3Dyes` perf. > >> > evaluation. > >> >> >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj bo= th > >> >> >>> nfs-mounted over 1Gbit LAN. > >> >> >>> > >> >> >>> clean old > >> >> >>> 1137.985u 239.411s 7:42.15 298.0% =9A =9A =9A 6538+2133k 87+433= 88io 226pf+0w > >> >> >>> > >> >> >>> clean new > >> >> >>> 1134.755u 240.032s 7:41.25 298.0% =9A =9A =9A 6553+2133k 87+433= 67io 224pf+0w > >> >> >>> > >> >> >>> Patch needs polishing, though it generally works. > >> >> >>> Not sure if shep_chan (or whatever name it will get) needs lock= ing. > >> >> >> As I said yesterday, if several requests to create nfsiod coming= one > >> >> >> after another, you would loose all but the last. > >> >> >> > >> >> >> You should put the requests into the list, probably protected by > >> >> >> nfs_iod_mtx. > >> >> >> > >> >> > > >> >> > How about this patch? Still several things to ask. > >> >> > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs= _iod_mtx > >> > held. > >> >> > 2) Probably busy/done gymnastics is a wrong mess. Your help is > >> > appreciated. > >> >> > 3) if (1) is fine, is it right to use fail: logic (i.e. set > >> >> > NFSIOD_NOT_AVAILABLE) > >> >> > on memory shortage? Not tested. > >> >> > > >> >> > There are debug printf() left intentionally to see how 3 contexts= run > >> > under load > >> >> > to each other. I attached these messages as well if that makes se= nse. > >> >> > > >> >> > >> >> Ah, yes. Sorry, forgot about that. > >> > > >> > Your task handler needs to run in a loop until the list of requests = is empty. > >> > If multiple threads call taskqueue_enqueue() before your task is sch= eduled, > >> > they will be consolidated down to a single call of your task handler. > >> > >> Thanks for your suggestions. > >> > >> So I converted nfs_nfsiodnew_tq() into loop, and as such > >> I changed a cleanup SLIST_FOREACH() as well to free a bulk of > >> (potentially consolidated) completed requests in one pass. > >> kproc_create() is still out of the SLIST_FOREACH() to avoid calling it > >> with nfs_iod_mtx held. > >> > >> > > >> > - =9A =9A =9A int error, i; > >> > - =9A =9A =9A int newiod; > >> > + =9A =9A =9A int i, newiod, error; > >> > > >> > You should sort these alphabetically if you are going to change this= . =9AI would > >> > probably just leave it as-is. > >> > >> Err.. that's resulted after a set of changes. Thanks for noting that. > >> > >> > > >> > Also, I'm not sure how this works as you don't actually wait for the= task to > >> > complete. =9AIf the taskqueue_enqueue() doesn't preempt, then you ma= y read > >> > ni_error as zero before the kproc has actually been created and retu= rn success > >> > even though an nfsiod hasn't been created. > >> > > >> > >> I put taskqueue_drain() right after taskqueue_enqueue() to be in sync = with > >> task handler. That was part to think about, as I didn't find such a us= e pattern. > >> It seems though that tasks are launched now strictly one-by-one, witho= ut > >> visible parallelism (as far as debug printf()s don't overlap anymore). > > > > Ah, if it is safe to sleep then I have a couple of suggestions: > > >=20 > Cool, credits go to John :). > I just adopted all of your changes (attached). >=20 > > - Use M_WAITOK to malloc() so you don't have to worry about the failure= case > > =9A(I see Rick already suggested this). >=20 > After all that reduces to the following replacement in nfs_nfsiodnew(). > So, no regression should be there in theory. >=20 > mtx_unlock(&nfs_iod_mtx); > - kproc_create(...) > + malloc(...) > mtx_lock(&nfs_iod_mtx); >=20 > It survived after this simple test running for an hour, which > forces creation of many iods with r/w from 300 threads: >=20 > nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) >=20 > ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & > ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & > ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & > while [ true ]; do sysctl vfs.nfs.iodmax=3D2; sysctl vfs.nfs.iodmax=3D60; > sleep 20; done >=20 > randomio is from ports/149838. >=20 >=20 > P.S. > it's funny to see in top > 0 root 10 44 0 0K 144K deadlk 2 23:16 28.86% kernel > Someone might think the kernel is in deadlock. It seems nobody replied to the mdf@ objection against wait of the new proc startup being equivalent to the LOR. I think that the wait is safe, because the task is executed in the context of the different process then the enqueue request. This might be worth noting in the comment or commit message. You should drain the taskq and prevent creation of new nfsiods before waiting for existing nfsiods to exit on module unload. I find it somewhat weird that nip is removed from the list in the task handler, but freed in the enqueue thread. You could provide pointers to the local variables to exchange done/exit codes. I do not insist on this part. --6kwAx1lhQCGpXeLP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxu1VgACgkQC3+MBN1Mb4iKEACg5/0bvwUd2PFkn5tSeFR6BaMw JPoAnR9kQdlIrE8uONgUC7uLOVt3CE0U =39jH -----END PGP SIGNATURE----- --6kwAx1lhQCGpXeLP-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:20:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 462541065670; Fri, 20 Aug 2010 19:20:35 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 055298FC1A; Fri, 20 Aug 2010 19:20:33 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id EE7551FFC38; Fri, 20 Aug 2010 19:20:32 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C7BE78456E; Fri, 20 Aug 2010 21:20:32 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Whitehorn References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> Date: Fri, 20 Aug 2010 21:20:32 +0200 In-Reply-To: <4C6E825C.5060509@freebsd.org> (Nathan Whitehorn's message of "Fri, 20 Aug 2010 08:25:48 -0500") Message-ID: <86fwy9f5vj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:20:35 -0000 Nathan Whitehorn writes: > Next up: tinderbox needs to build GENERIC64, not GENERIC, on > powerpc64. make buildkernel is programmed to do the right thing is you > don't pass a KERNCONF, but tinderbox apparently passes GENERIC > explicitly. This one's in your court! There is no way to fix this with the current tinderbox code. MHO is that the entire powerpc64 thing is very poorly thought out. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:27:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01D9D10656AA for ; Fri, 20 Aug 2010 19:27:46 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AF6F88FC1E for ; Fri, 20 Aug 2010 19:27:45 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id CED451FFC34; Fri, 20 Aug 2010 19:27:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A4A888456E; Fri, 20 Aug 2010 21:27:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alan Cox References: <4C6505A4.9060203@FreeBSD.org> <20100813085235.GA16268@freebsd.org> <4C66C010.3040308@FreeBSD.org> <4C673F02.8000805@FreeBSD.org> <20100815013438.GA8958@troutmask.apl.washington.edu> <4C67492C.5020206@FreeBSD.org> <8639ufd78w.fsf@ds4.des.no> <4C6844D8.5070602@andric.com> <86sk2faqdl.fsf@ds4.des.no> <4C6AAA88.5080606@andric.com> <4C6AF13A.1080606@andric.com> <4C6D3BBB.7030104@andric.com> <4C6D5302.4030602@cs.rice.edu> Date: Fri, 20 Aug 2010 21:27:44 +0200 In-Reply-To: <4C6D5302.4030602@cs.rice.edu> (Alan Cox's message of "Thu, 19 Aug 2010 10:51:30 -0500") Message-ID: <8639u9f5jj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, Dimitry Andric , current@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:27:46 -0000 Alan Cox writes: > Here is what actually puzzles me about these results. With > traditional I/O, even after the optimizations to bsdgrep, the system > time for gnugrep is still less than half that of the optimized > bsdgrep. I haven't looked at the changes, but I would have thought > the system time for gnugrep and bsdgrep would be almost the same. Two reasons: 1) BSD grep does tons of unnecessary memory-to-memory copy operations in grep_fgetln(). 2) GNU grep has its own highly optimized regex code. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:33:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D571065694; Fri, 20 Aug 2010 19:33:10 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 45B2C8FC0A; Fri, 20 Aug 2010 19:33:10 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3480C1FFC38; Fri, 20 Aug 2010 19:33:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E929A84571; Fri, 20 Aug 2010 21:33:08 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "C. P. Ghost" References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Date: Fri, 20 Aug 2010 21:33:08 +0200 In-Reply-To: (C. P. Ghost's message of "Thu, 19 Aug 2010 18:00:54 +0200") Message-ID: <86vd75dqq3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Ivan Voras , Andrew Reilly , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:33:10 -0000 "C. P. Ghost" writes: > After all LISP-like syntax is *still* more common and prevalent > than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps > that use it as a small language. So we can expect more users > to be at least partially familiar with it. And there *are* lightweight > MIT- or BSD-licensed scheme interpreters out there too: Considering that the majority of people who might be interested in using this know *neither* Lisp *nor* Lua, my vote is for Lua, because people who are familiar with neither will be more open to learning Lua, which resembles other languages they already know, than Lisp, which doesn't. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:35:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87DB01065696; Fri, 20 Aug 2010 19:35:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 44BFD8FC18; Fri, 20 Aug 2010 19:35:06 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 8D7081FFC38; Fri, 20 Aug 2010 19:35:05 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 687FB8456E; Fri, 20 Aug 2010 21:35:05 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gabor PALI References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> Date: Fri, 20 Aug 2010 21:35:05 +0200 In-Reply-To: (Gabor PALI's message of "Thu, 19 Aug 2010 18:48:57 +0200") Message-ID: <86r5htdqmu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:35:06 -0000 Gabor PALI writes: > Sorry for chiming in, just a quick idea. If you find the "get a > high-level language that compiled to C" idea good, I don't think it's a good idea, and I don't understand why this thread seems stuck in that rut. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:35:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B95106566B for ; Fri, 20 Aug 2010 19:35:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A527B8FC19 for ; Fri, 20 Aug 2010 19:35:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 31D0446B97; Fri, 20 Aug 2010 15:35:50 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 320398A03C; Fri, 20 Aug 2010 15:35:49 -0400 (EDT) From: John Baldwin To: Kostik Belousov Date: Fri, 20 Aug 2010 15:35:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100820191953.GN2396@deviant.kiev.zoral.com.ua> In-Reply-To: <20100820191953.GN2396@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008201535.48560.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 20 Aug 2010 15:35:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: pluknet , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:35:51 -0000 On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote: > On Fri, Aug 20, 2010 at 08:55:08PM +0400, pluknet wrote: > > On 19 August 2010 17:34, John Baldwin wrote: > > > On Thursday, August 19, 2010 5:29:25 am pluknet wrote: > > >> On 19 August 2010 00:07, John Baldwin wrote: > > >> > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: > > >> >> On 18 August 2010 23:11, pluknet wrote: > > >> >> > On 18 August 2010 17:46, Kostik Belousov wrote: > > >> >> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: > > >> >> >>> On 18 August 2010 12:07, pluknet wrote: > > >> >> >>> > On 17 August 2010 20:04, Kostik Belousov wrote: > > >> >> >>> > > > >> >> >>> >> > > >> >> >>> >> Also please take a note of the John' suggestion to use the taskqueue. > > >> >> >>> > > > >> >> >>> > I decided to go this road. Thank you both. > > >> >> >>> > Now I do nfs buildkernel survive and prepare some benchmark results. > > >> >> >>> > > > >> >> >>> > > >> >> >>> So, I modified the patch to defer proc_create() with taskqueue(9). > > >> >> >>> Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. > > >> > evaluation. > > >> >> >>> Done on 4-way CPU on clean /usr/obj with /usr/src & /usr/obj both > > >> >> >>> nfs-mounted over 1Gbit LAN. > > >> >> >>> > > >> >> >>> clean old > > >> >> >>> 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w > > >> >> >>> > > >> >> >>> clean new > > >> >> >>> 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w > > >> >> >>> > > >> >> >>> Patch needs polishing, though it generally works. > > >> >> >>> Not sure if shep_chan (or whatever name it will get) needs locking. > > >> >> >> As I said yesterday, if several requests to create nfsiod coming one > > >> >> >> after another, you would loose all but the last. > > >> >> >> > > >> >> >> You should put the requests into the list, probably protected by > > >> >> >> nfs_iod_mtx. > > >> >> >> > > >> >> > > > >> >> > How about this patch? Still several things to ask. > > >> >> > 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx > > >> > held. > > >> >> > 2) Probably busy/done gymnastics is a wrong mess. Your help is > > >> > appreciated. > > >> >> > 3) if (1) is fine, is it right to use fail: logic (i.e. set > > >> >> > NFSIOD_NOT_AVAILABLE) > > >> >> > on memory shortage? Not tested. > > >> >> > > > >> >> > There are debug printf() left intentionally to see how 3 contexts run > > >> > under load > > >> >> > to each other. I attached these messages as well if that makes sense. > > >> >> > > > >> >> > > >> >> Ah, yes. Sorry, forgot about that. > > >> > > > >> > Your task handler needs to run in a loop until the list of requests is empty. > > >> > If multiple threads call taskqueue_enqueue() before your task is scheduled, > > >> > they will be consolidated down to a single call of your task handler. > > >> > > >> Thanks for your suggestions. > > >> > > >> So I converted nfs_nfsiodnew_tq() into loop, and as such > > >> I changed a cleanup SLIST_FOREACH() as well to free a bulk of > > >> (potentially consolidated) completed requests in one pass. > > >> kproc_create() is still out of the SLIST_FOREACH() to avoid calling it > > >> with nfs_iod_mtx held. > > >> > > >> > > > >> > - int error, i; > > >> > - int newiod; > > >> > + int i, newiod, error; > > >> > > > >> > You should sort these alphabetically if you are going to change this. I would > > >> > probably just leave it as-is. > > >> > > >> Err.. that's resulted after a set of changes. Thanks for noting that. > > >> > > >> > > > >> > Also, I'm not sure how this works as you don't actually wait for the task to > > >> > complete. If the taskqueue_enqueue() doesn't preempt, then you may read > > >> > ni_error as zero before the kproc has actually been created and return success > > >> > even though an nfsiod hasn't been created. > > >> > > > >> > > >> I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with > > >> task handler. That was part to think about, as I didn't find such a use pattern. > > >> It seems though that tasks are launched now strictly one-by-one, without > > >> visible parallelism (as far as debug printf()s don't overlap anymore). > > > > > > Ah, if it is safe to sleep then I have a couple of suggestions: > > > > > > > Cool, credits go to John :). > > I just adopted all of your changes (attached). > > > > > - Use M_WAITOK to malloc() so you don't have to worry about the failure case > > > (I see Rick already suggested this). > > > > After all that reduces to the following replacement in nfs_nfsiodnew(). > > So, no regression should be there in theory. > > > > mtx_unlock(&nfs_iod_mtx); > > - kproc_create(...) > > + malloc(...) > > mtx_lock(&nfs_iod_mtx); > > > > It survived after this simple test running for an hour, which > > forces creation of many iods with r/w from 300 threads: > > > > nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) > > > > ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & > > ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & > > ./randomio /usr/obj/file 100 0.5 0 4096 60 100 & > > while [ true ]; do sysctl vfs.nfs.iodmax=2; sysctl vfs.nfs.iodmax=60; > > sleep 20; done > > > > randomio is from ports/149838. > > > > > > P.S. > > it's funny to see in top > > 0 root 10 44 0 0K 144K deadlk 2 23:16 28.86% kernel > > Someone might think the kernel is in deadlock. > > It seems nobody replied to the mdf@ objection against wait of the > new proc startup being equivalent to the LOR. I think that the wait > is safe, because the task is executed in the context of > the different process then the enqueue request. > This might be worth noting in the comment or commit message. I do wonder if we could get away with not waiting at all and always return -1? You could have the task handler actually finish the toggle of the tristate in the array. Potentially you could even dispense with the linked list of malloc'd structures and just walk the array creating processes for any entries in the "in-progress" state in the task handler. You might also want to avoid submitting entries for new threads if there is already a pending one? If that is the case it could be further simplified by having the task always create a single kthread when scheduled and just scheduling the task anytime a request needs one. > You should drain the taskq and prevent creation of new nfsiods before > waiting for existing nfsiods to exit on module unload. Agreed that unload needs to be handled. > I find it somewhat weird that nip is removed from the list in the > task handler, but freed in the enqueue thread. You could provide > pointers to the local variables to exchange done/exit codes. > I do not insist on this part. Well, this is because the ownership of the thread transitions back from the task to the process that requested the thread be created. However, I wonder if given my suggestions above you could have a model where a request that couldn't immediately find a free thread is always queued elsewhere after requesting a new thread to be started, and the new thread just grabs a request from the head of that other queue when it starts up. If that sort of approach would work I think it would end up simpler overall. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:38:56 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5171A1065673; Fri, 20 Aug 2010 19:38:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 148B78FC13; Fri, 20 Aug 2010 19:38:55 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 248311FFC34; Fri, 20 Aug 2010 19:38:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id EA4528456E; Fri, 20 Aug 2010 21:38:54 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: bf1783@gmail.com References: Date: Fri, 20 Aug 2010 21:38:54 +0200 In-Reply-To: (b. f.'s message of "Thu, 19 Aug 2010 21:42:01 +0000") Message-ID: <86mxshdqgh.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, gabor@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:38:56 -0000 "b. f." writes: > At r211506, 'grep -wq' does not seem to work properly (in the very > least, it is not the same as with GNU grep), "Does not seem to work properly" is not a very useful statement. The least you could do is provide an example. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:40:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5601065694 for ; Fri, 20 Aug 2010 19:40:22 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B67D8FC08 for ; Fri, 20 Aug 2010 19:40:21 +0000 (UTC) Received: by qyk4 with SMTP id 4so3910548qyk.13 for ; Fri, 20 Aug 2010 12:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=w0mhE+IWH7qqjivSZi3/m201TOQb9fjEN0bDz9dvEVc=; b=PDg9clJF1b1vOhuNrjHToO/h4QKSIYeuRHb3YKcWvEy5uIm+3eu9lPBDHMcNJE1X0P 5M8SBln7O8mhxzQUhXB6VHAi6UQ2puBKKtHLBhBtcffE63ZadFFsnpxmQbBA4GS1iwQD 04RoztX5BLrW2TaWW5wWSrnlxzBrEbI3IyzUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=kcTqPTPcfu3xQxMjVNxEzspjOfuSSzZ03x7ZQfmpB+qFtaqwFLPbHmF4DmmuhXO+jH 3FjEFx4ze9f48UJwkRg8oiguuHtQcU/apnWdB6hfo0rZym63lGXLXct0Lmuw7HCcjTaF qpGwp1F3Syv4S6mEgEE8bwKlXDAAKzd1aW7Xg= MIME-Version: 1.0 Received: by 10.229.181.16 with SMTP id bw16mr1431851qcb.183.1282333221447; Fri, 20 Aug 2010 12:40:21 -0700 (PDT) Sender: pali.gabor@googlemail.com Received: by 10.229.183.198 with HTTP; Fri, 20 Aug 2010 12:40:21 -0700 (PDT) In-Reply-To: <86r5htdqmu.fsf@ds4.des.no> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <86r5htdqmu.fsf@ds4.des.no> Date: Fri, 20 Aug 2010 21:40:21 +0200 X-Google-Sender-Auth: VE_fQdEspuk0y7W0jnf2tt0n8aA Message-ID: From: Gabor PALI To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:40:22 -0000 2010/8/20 Dag-Erling Sm=F8rgrav : > Gabor PALI writes: >> Sorry for chiming in, just a quick idea. =A0If you find the "get a >> high-level language that compiled to C" idea good, > > I don't think it's a good idea Could you be more specific on your concerns? I am just curious. > I don't understand why this thread seems stuck in that rut. Perhaps because people want to write more reliable code faster? :g From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 19:42:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4228A106564A; Fri, 20 Aug 2010 19:42:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 90D548FC08; Fri, 20 Aug 2010 19:42:30 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o7KJgRDJ080760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 22:42:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o7KJgRtJ093572; Fri, 20 Aug 2010 22:42:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o7KJgRaT093571; Fri, 20 Aug 2010 22:42:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 20 Aug 2010 22:42:27 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20100820194227.GO2396@deviant.kiev.zoral.com.ua> References: <20100820191953.GN2396@deviant.kiev.zoral.com.ua> <201008201535.48560.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J58k4iUnqtw3lv0j" Content-Disposition: inline In-Reply-To: <201008201535.48560.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: pluknet , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 19:42:32 -0000 --J58k4iUnqtw3lv0j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 20, 2010 at 03:35:48PM -0400, John Baldwin wrote: > On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote: > > It seems nobody replied to the mdf@ objection against wait of the > > new proc startup being equivalent to the LOR. I think that the wait > > is safe, because the task is executed in the context of > > the different process then the enqueue request. > > This might be worth noting in the comment or commit message. >=20 > I do wonder if we could get away with not waiting at all and always retur= n -1? > You could have the task handler actually finish the toggle of the tristat= e in > the array. Potentially you could even dispense with the linked list of > malloc'd structures and just walk the array creating processes for any en= tries > in the "in-progress" state in the task handler. You might also want to a= void > submitting entries for new threads if there is already a pending one? If= that > is the case it could be further simplified by having the task always crea= te a > single kthread when scheduled and just scheduling the task anytime a requ= est > needs one. I think this is not that easy. Please take a look at nfs_asyncio(). There is a lot of logic what to do in case an nfsiod thread was found or not etc. --J58k4iUnqtw3lv0j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxu2qIACgkQC3+MBN1Mb4hzEgCgpzwzjn+luvtYc0FHy/CXTtnV KaEAoJRoPIv9a8wdCm5YuuTRxXrX4Vrz =XFvO -----END PGP SIGNATURE----- --J58k4iUnqtw3lv0j-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 20:08:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC13F106567A for ; Fri, 20 Aug 2010 20:08:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 898108FC18 for ; Fri, 20 Aug 2010 20:08:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2DEC746B65; Fri, 20 Aug 2010 16:08:59 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 833CD8A04E; Fri, 20 Aug 2010 16:08:58 -0400 (EDT) From: John Baldwin To: Kostik Belousov Date: Fri, 20 Aug 2010 16:08:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201008201535.48560.jhb@freebsd.org> <20100820194227.GO2396@deviant.kiev.zoral.com.ua> In-Reply-To: <20100820194227.GO2396@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008201608.12421.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 20 Aug 2010 16:08:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: pluknet , FreeBSD Current Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:08:59 -0000 On Friday, August 20, 2010 3:42:27 pm Kostik Belousov wrote: > On Fri, Aug 20, 2010 at 03:35:48PM -0400, John Baldwin wrote: > > On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote: > > > It seems nobody replied to the mdf@ objection against wait of the > > > new proc startup being equivalent to the LOR. I think that the wait > > > is safe, because the task is executed in the context of > > > the different process then the enqueue request. > > > This might be worth noting in the comment or commit message. > > > > I do wonder if we could get away with not waiting at all and always return -1? > > You could have the task handler actually finish the toggle of the tristate in > > the array. Potentially you could even dispense with the linked list of > > malloc'd structures and just walk the array creating processes for any entries > > in the "in-progress" state in the task handler. You might also want to avoid > > submitting entries for new threads if there is already a pending one? If that > > is the case it could be further simplified by having the task always create a > > single kthread when scheduled and just scheduling the task anytime a request > > needs one. > I think this is not that easy. Please take a look at nfs_asyncio(). > There is a lot of logic what to do in case an nfsiod thread was found > or not etc. Gah, the real problem is that unless the new kproc starts up super fast we would invariably return EIO causing the I/O to be performed synchronously more often. Given that, I think pluknet's patch is fine once it is updated for the module unload case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 20:03:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0332A1065698 for ; Fri, 20 Aug 2010 20:03:13 +0000 (UTC) (envelope-from freebsd-lists@christianserving.org) Received: from zion.christianserving.org (zion.christianserving.org [66.128.242.154]) by mx1.freebsd.org (Postfix) with ESMTP id C8CFD8FC0A for ; Fri, 20 Aug 2010 20:03:12 +0000 (UTC) Received: from localhost (localhost.christianserving.org [127.0.0.1]) by zion.christianserving.org (Postfix) with ESMTP id 6C4D322C198 for ; Fri, 20 Aug 2010 14:46:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at christianserving.org X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-9999 required=6 tests=[ALL_TRUSTED=-1.8, AWL=0.401, BAYES_00=-2.599] autolearn=ham Received: from mm-riggsj.peace.daveramsey.com (mail.daveramsey.com [67.216.167.148]) by zion.christianserving.org (Postfix) with ESMTPSA for ; Fri, 20 Aug 2010 14:46:40 -0500 (CDT) From: Jim Riggs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 14:46:39 -0500 Message-Id: <9674C06D-DC2D-40C3-B523-E397C9ADC37B@christianserving.org> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 20 Aug 2010 20:15:59 +0000 Subject: CD/DVD ejecting after sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:03:13 -0000 References: http://www.mail-archive.com/svn-src-all@freebsd.org/msg24380.html http://forums.freebsd.org/showthread.php?t=3D17126 This commit automatically ejects the CD when sysinstall exits which = almost had dire consequences for me this week. As described in the = forum post, I keep a LiveFS CD in all of my servers so that I can = remotely diagnose and fix issues. I have done this for several years = now, and it has saved my tail many times. However, I got a surprise when I tried it today with the new 8.1 LiveFS = CDs I had just burned. After attempting to fix a problem from the = LiveFS and rebooting back to the HD, the problem still existed. No = problem. I just tried to boot back to the CD only to find that it was = gone. Luckily, this was on a box in-house, so I was quickly able to see = what was wrong. Now that I have the commit, I can roll my own patched sysinstall and = CDs, but the question is: Should we be ejecting the media without any = prompt? Obviously, for my use case, I liked the old behavior of just = reminding the user to eject the media when rebooting. I understand that = may not be optimal for some users. Can we present a dialog asking the = user if they want the media to be ejected? That still leaves me at risk = of selecting the wrong answer, I suppose. I would rather not have to = roll my own LiveFS CDs every time, though. Thoughts from anyone else? (Please copy me on responses.) - Jim From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 20:19:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994ED10656A7 for ; Fri, 20 Aug 2010 20:19:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 21A958FC13 for ; Fri, 20 Aug 2010 20:19:21 +0000 (UTC) Received: (qmail 17698 invoked by uid 399); 20 Aug 2010 20:19:20 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Aug 2010 20:19:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C6EE347.4000301@FreeBSD.org> Date: Fri, 20 Aug 2010 13:19:19 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <86r5htdqmu.fsf@ds4.des.no> In-Reply-To: <86r5htdqmu.fsf@ds4.des.no> X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Gabor PALI , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:19:22 -0000 On 8/20/2010 12:35 PM, Dag-Erling Smørgrav wrote: > Gabor PALI writes: >> Sorry for chiming in, just a quick idea. If you find the "get a >> high-level language that compiled to C" idea good, > > I don't think it's a good idea, and I don't understand why this thread > seems stuck in that rut. If your only tool is a hammer, all your problems look like nails. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 20:35:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276C710656AC; Fri, 20 Aug 2010 20:35:22 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 042B68FC17; Fri, 20 Aug 2010 20:35:21 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id A48235B91; Fri, 20 Aug 2010 13:35:19 -0700 (PDT) To: "C. P. Ghost" In-reply-to: Your message of "Thu, 19 Aug 2010 20:35:59 +0200." References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100819172227.1AAE25B89@mail.bitblocks.com> Date: Fri, 20 Aug 2010 13:35:19 -0700 From: Bakul Shah Message-Id: <20100820203519.A48235B91@mail.bitblocks.com> Cc: Doug Barton , Ivan Voras , Andrew Reilly , freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:35:22 -0000 On Thu, 19 Aug 2010 20:35:59 +0200 "C. P. Ghost" wrote: > > But seriously, the point isn't so much which specific interpreter > we use (if we go down this road), it's about libraries: most > sysadmin tasks require some basic networking and I/O, > and a FFI to seamlessly call out C functions from .so libs. > > And, of course, instead of writing 1,001 sysadmin scripts > with endless code duplication and reinventing of the wheel, > common sysadmin tasks should also be made into reusable > functions, grouped into modules. Exactly what I had in mind. > > And we don't have to argue about which language. I would > > suggest setting up a wiki page to list all the system scripts > > people want to write and get cracking in your favorite > > language! May the best effort win :-) At the very least we > > will get some useful tools out of this effort. =A0I will > > certainly help out with Scheme. > > Funny idea. I only hope we won't end up with a typical > post-dot-com young developer distribution, a la: > > 60% PHP (yuck!) > 25% Java (and XML-everywhere) > 15% ${OTHERS} > > ;-) If that is what people want then so be it :-) But I think only "little" languages like forth, lua, sh, rc, es & scheme have small footprint interpreters that start up fast and are reasonably efficient. Anyway, system programming in Scheme is what interests me and something I already tinker with on and off. If anyone is interested (in helping or just playing with it), let me know privately (but *not* on this mailing list). From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 20:39:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D355A1065693 for ; Fri, 20 Aug 2010 20:39:19 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4168FC12 for ; Fri, 20 Aug 2010 20:39:19 +0000 (UTC) Received: by qwg5 with SMTP id 5so3801262qwg.13 for ; Fri, 20 Aug 2010 13:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=+tsWBqg7hlHkMUsL/kk1sZj6dl+52DIUYIeu40rLPBI=; b=lwu+ayThLwwzpdWNKk54gCp19ufzk1rL+dN0Uet70CGfKnzhs18nKyVNJM5hN0VwxV lMcjDz1RwZBeTjelqH/EAJltwDNf3/AgPtlCEzv9E17wPlYq3534RZxxPPZDAPU9xHmj IxOM4iOuIUNJzkX7tj+5HTiexJsJ7SGBw5wtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=ws2FOFBwOPbLRSN6MDkdng407orcwPFyUPbyzhTOLli1ygnFct802As02MZcuHTJKg 5AqVKwa0Z+j+dwq82WO0jtiLsQyoCLyc7pWu0vLpgf2Ae/VjrP9JwMxucYuEjAZqMH8N RKEbN3VbDpAoBjzWkPpv2zcShTjLWylhXuxN0= MIME-Version: 1.0 Received: by 10.224.79.151 with SMTP id p23mr1335898qak.312.1282336758506; Fri, 20 Aug 2010 13:39:18 -0700 (PDT) Sender: pali.gabor@googlemail.com Received: by 10.229.183.198 with HTTP; Fri, 20 Aug 2010 13:39:18 -0700 (PDT) In-Reply-To: <20100820203519.A48235B91@mail.bitblocks.com> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <20100819172227.1AAE25B89@mail.bitblocks.com> <20100820203519.A48235B91@mail.bitblocks.com> Date: Fri, 20 Aug 2010 22:39:18 +0200 X-Google-Sender-Auth: QVSxjFuCkRgAyZHgRpo5H7uxf38 Message-ID: From: Gabor PALI To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:39:19 -0000 On Fri, Aug 20, 2010 at 10:35 PM, Bakul Shah wrote: > Anyway, system programming in Scheme is what interests me and > something I already tinker with on and off. If anyone is > interested (in helping or just playing with it), let me know > privately (but *not* on this mailing list). Not Scheme but still FP, and it is about "little languages" (called domain-specific languages these days) that you may find interesting: http://donsbot.wordpress.com/2010/08/17/practical-haskell/ :g From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 20:51:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C13A10656A6 for ; Fri, 20 Aug 2010 20:51:24 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 911998FC1A for ; Fri, 20 Aug 2010 20:51:23 +0000 (UTC) Received: by eyx24 with SMTP id 24so2401196eyx.13 for ; Fri, 20 Aug 2010 13:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:cc:content-type :content-transfer-encoding; bh=w5mZFhv9HCa4KIaKTctcFJRYwV3vgdOhC2ystdWHi+c=; b=DRua4CiVc6p6WHBglaFuEPfRXubfF7un8Bu9ql4fAOAQ1Mki1BrfwsL7NUPgPlMIzM ra3AXIPEx40Yfx7ArpDAc4o8Cn+VklIS9aXDJBk//Czoy7282A0TTCt8LgXxFKIyajXw 05r090jtaWiOLPiKlJW3px+joR781T0lmWqqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding; b=rj/VbGptXUf7rsFVgOrA3XBCK0YIlsd+ifBO5IOqHSive5ShC8AJVr9nmSg2EVKsuR C25C8HIYvoQ84jKLrBJKsjc3aZn2GRPXUyved2TkbCY3t/mGZyl/yI3SjoEBTqvk06Vg c8vToyi9aTuS976fvjsDhLn6XxBkwW6khrkws= MIME-Version: 1.0 Received: by 10.216.236.226 with SMTP id w76mr1783787weq.7.1282337482215; Fri, 20 Aug 2010 13:51:22 -0700 (PDT) Received: by 10.216.86.10 with HTTP; Fri, 20 Aug 2010 13:51:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Aug 2010 15:51:22 -0500 Message-ID: From: Chris Ruiz Cc: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: recent ath changes related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 20:51:24 -0000 On Fri, Aug 20, 2010 at 1:56 AM, Bernhard Schmidt wrote: > On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt = wrote: >> On Fri, Aug 20, 2010 at 01:04, Chris Ruiz wrote: >>> I run a PCI Atheros card in hostap mode on CURRENT. >>> >>> ath0@pci0:6:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x5a001385 chip= =3D0x0013168c >>> rev=3D0x01 hdr=3D0x00 >>> =A0 =A0vendor =A0 =A0 =3D 'Atheros Communications Inc.' >>> =A0 =A0device =A0 =A0 =3D '802.11a/b/g Wireless Adapter (AR2312)' >>> =A0 =A0class =A0 =A0 =A0=3D network >>> =A0 =A0subclass =A0 =3D ethernet >>> >>> Everything works fine with r211193 but with newer kernels I receive >>> the same panic related to the ath0 tasq. >> >> >> I guess this also happens with post-r211314 kernels? > > Seems like I missed you wrap a few ieee80211_ratectl_node_init() > calls. Please try attached patch, it should fix it. Thanks! My system no longer panics at the login prompt. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 21:06:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BD0C1065697 for ; Fri, 20 Aug 2010 21:06:03 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD988FC0C for ; Fri, 20 Aug 2010 21:06:03 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id A416A5B91; Fri, 20 Aug 2010 14:06:02 -0700 (PDT) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-reply-to: Your message of "Fri, 20 Aug 2010 21:33:08 +0200." <86vd75dqq3.fsf@ds4.des.no> References: <4C6505A4.9060203@FreeBSD.org> <4C650B75.3020800@FreeBSD.org> <4C651192.9020403@FreeBSD.org> <4C673898.2080609@FreeBSD.org> <20100818134341.GA88861@johnny.reilly.home> <86vd75dqq3.fsf@ds4.des.no> Comments: In-reply-to =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= message dated "Fri, 20 Aug 2010 21:33:08 +0200." Date: Fri, 20 Aug 2010 14:06:02 -0700 From: Bakul Shah Message-Id: <20100820210602.A416A5B91@mail.bitblocks.com> Cc: freebsd-current@freebsd.org Subject: Re: Interpreted language(s) in the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:06:03 -0000 On Fri, 20 Aug 2010 21:33:08 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > "C. P. Ghost" writes: > > After all LISP-like syntax is *still* more common and prevalent > > than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps > > that use it as a small language. So we can expect more users > > to be at least partially familiar with it. And there *are* lightweight > > MIT- or BSD-licensed scheme interpreters out there too: > > Considering that the majority of people who might be interested in using > this know *neither* Lisp *nor* Lua, my vote is for Lua, because people > who are familiar with neither will be more open to learning Lua, which > resembles other languages they already know, than Lisp, which doesn't. [Couldn't resist responding but my last message on this tangent] If you are "open to learning" a C like language, one can provide a C like frontend syntax to most of Scheme & to a degreee similar to lua. Like C/Lua etc. Scheme is also a block structured language. Apart from syntax, the key differences are: - everything is an expression. - variables are not typed (anything can be assigned to a var) - functions can be anonymous, nested and returned from other functions - symbols & lists are built-in unlike in C - no built-in structs, unions or ptrs - a very powerful macro facility - support for continuations ksm for instance implements a C like syntax. See http://square.umin.ac.jp/hchang/ksm/ref/ksm_13.html [Yes, I am aware of Dylan and what happened to it but still think this can be a useful effort] From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 21:07:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD77A1065674; Fri, 20 Aug 2010 21:07:58 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 33CF48FC24; Fri, 20 Aug 2010 21:07:57 +0000 (UTC) Received: by eyx24 with SMTP id 24so2411483eyx.13 for ; Fri, 20 Aug 2010 14:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=QPvrOUVDggN5tD/W2dmTsQzjqVNfufNIOtXOhZtcjTk=; b=AWURJJ7hKtv41pMelcdFEllHYCgmJgFwduv25IhKgMIliNnyKAsMbPaQ+2Zxf2UafU a+sTq8drKfXeU1YArsYoy3xm4H0QQ7LBojM9iPluTyiaI/YBKwCH9VAzx92qKXJkTe6u 8S/jSAUibm0ZjgMmPPBnFuMYIZSXAhlrABuWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=guGHNZKvN3SWa38tlJ6Kxks02pO2UzbRGyQfGd99fSJNRb6W1FgouBmxaqRh3NZxV/ XSicz2c+XjjZ2UfJuluJNDWlg91UfQaweyCWrKXJYB2tiJuLATN3weoyzC9Rz82OEBC7 D78XBggtNTnJIPaDrWA0d7fLr90F2jJEv54rU= MIME-Version: 1.0 Received: by 10.216.155.206 with SMTP id j56mr1759821wek.67.1282338476323; Fri, 20 Aug 2010 14:07:56 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Fri, 20 Aug 2010 14:07:56 -0700 (PDT) In-Reply-To: <86mxshdqgh.fsf@ds4.des.no> References: <86mxshdqgh.fsf@ds4.des.no> Date: Fri, 20 Aug 2010 21:07:56 +0000 Message-ID: From: "b. f." To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, gabor@freebsd.org Subject: Re: Official request: Please make GNU grep the default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:07:58 -0000 On 8/20/10, Dag-Erling Sm=F8rgrav wrote: > "b. f." writes: >> At r211506, 'grep -wq' does not seem to work properly (in the very >> least, it is not the same as with GNU grep), > > "Does not seem to work properly" is not a very useful statement. The > least you could do is provide an example. I did provide an example, later in the same sentence that you quoted. Using a current ports tree, go to a port with 'lisp' in CATEGORIES, and run any ports target that requires 'check-categories', e.g.: make -C /usr/ports/math/maxima check-categories maxima-5.22.1: Makefile error: category lisp not in list of valid categorie= s. *** Error code 1 Stop in /mnt/disk2/usr/ports/math/maxima. >From bsd.port.mk: 2941 VALID_CATEGORIES+=3D accessibility afterstep arabic archivers astro audio \ 2942 benchmarks biology cad chinese comms converters databases \ 2943 deskutils devel docs dns editors elisp emulators finance french ftp \ 2944 games geography german gnome gnustep graphics hamradio haskell hebrew hungarian \ 2945 ipv6 irc japanese java kde kld korean lang linux lisp \ 2946 mail math mbone misc multimedia net net-im net-mgmt net-p2p news \ 2947 palm parallel pear perl5 plan9 polish portuguese ports-mgmt= \ 2948 print python ruby rubygems russian \ 2949 scheme science security shells spanish sysutils \ 2950 tcl textproc tk \ 2951 ukrainian vietnamese windowmaker www \ 2952 x11 x11-clocks x11-drivers x11-fm x11-fonts x11-servers x11-themes \ 2953 x11-toolkits x11-wm xfce zope 2954 2955 check-categories: 2956 .for cat in ${CATEGORIES} 2957 @if ${ECHO_CMD} ${VALID_CATEGORIES} | ${GREP} -wq ${cat}; t= hen \ 2958 ${TRUE}; \ 2959 else \ 2960 ${ECHO_MSG} "${PKGNAME}: Makefile error: category ${cat} not in list of valid categories. 2960 "; \ 2961 ${FALSE}; \ 2962 fi 2963 .endfor A closer look at VALID_CATEGORIES, using vis -oltw: VALID_CATEGORIES+=3D\040accessibility\040afterstep\040arabic\040archivers\0= 40astro\040audio\040\\\$ \011benchmarks\040biology\040cad\040chinese\040comms\040converters\040datab= ases\040\\\$ \011deskutils\040devel\040docs\040dns\040editors\040elisp\040emulators\040f= inance\040french\040ftp\040\\\$ \011games\040geography\040german\040gnome\040gnustep\040graphics\040hamradi= o\040haskell\040hebrew\040hungarian\040\\\$ \011ipv6\040irc\040japanese\040java\040kde\040kld\040korean\040lang\040linu= x\040lisp\040\\\$ \011mail\040math\040mbone\040misc\040multimedia\040net\040net-im\040net-mgm= t\040net-p2p\040news\040\\\$ \011palm\040parallel\040pear\040perl5\040plan9\040polish\040portuguese\040p= orts-mgmt\040\\\$ \011print\040python\040ruby\040rubygems\040russian\040\\\$ \011scheme\040science\040security\040shells\040spanish\040sysutils\040\\\$ \011tcl\040textproc\040tk\040\\\$ \011ukrainian\040vietnamese\040windowmaker\040www\040\\\$ \011x11\040x11-clocks\040x11-drivers\040x11-fm\040x11-fonts\040x11-servers\= 040x11-themes\040\\\$ \011x11-toolkits\040x11-wm\040xfce\040zope\$ The lisp category is the only category that causes a problem with the new bsdgrep, and I didn't take the time to analyze why ( which is why I was not more specific in my original message). 'lisp' is preceded by 'elisp', which would normally be a match for the 'lisp' in a port Makefile, were it not for the -w flag. 'x11' succeeds, but it precedes all of the x11-* categories. I suspect that there is an error in the logic of either the -w or the -q flag implementation in bsdgrep, which causes problems when the two options are used together. The target succeeds as expected with GNU grep. b. From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 21:21:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 721421065694 for ; Fri, 20 Aug 2010 21:21:14 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1568FC1C for ; Fri, 20 Aug 2010 21:21:14 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 5BCE111B966; Fri, 20 Aug 2010 16:21:13 -0500 (CDT) Received: from 10.0.10.3 (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by lavabit.com with ESMTP id VPI314LVFWM4; Fri, 20 Aug 2010 16:21:13 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <9674C06D-DC2D-40C3-B523-E397C9ADC37B@christianserving.org> Date: Fri, 20 Aug 2010 22:21:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <641B7F47-CD12-415D-A808-861F4E85F60C@FreeBSD.org> References: <9674C06D-DC2D-40C3-B523-E397C9ADC37B@christianserving.org> To: Jim Riggs X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: CD/DVD ejecting after sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 21:21:14 -0000 On 20 Aug 2010, at 20:46, Jim Riggs wrote: > References: >=20 > http://www.mail-archive.com/svn-src-all@freebsd.org/msg24380.html > http://forums.freebsd.org/showthread.php?t=3D17126 >=20 >=20 > This commit automatically ejects the CD when sysinstall exits which = almost had dire consequences for me this week. As described in the = forum post, I keep a LiveFS CD in all of my servers so that I can = remotely diagnose and fix issues. I have done this for several years = now, and it has saved my tail many times. >=20 > However, I got a surprise when I tried it today with the new 8.1 = LiveFS CDs I had just burned. After attempting to fix a problem from = the LiveFS and rebooting back to the HD, the problem still existed. No = problem. I just tried to boot back to the CD only to find that it was = gone. Luckily, this was on a box in-house, so I was quickly able to see = what was wrong. >=20 > Now that I have the commit, I can roll my own patched sysinstall and = CDs, but the question is: Should we be ejecting the media without any = prompt? Obviously, for my use case, I liked the old behavior of just = reminding the user to eject the media when rebooting. I understand that = may not be optimal for some users. Can we present a dialog asking the = user if they want the media to be ejected? That still leaves me at risk = of selecting the wrong answer, I suppose. I would rather not have to = roll my own LiveFS CDs every time, though. >=20 > Thoughts from anyone else? (Please copy me on responses.) You are correct. We should not be ejecting the CD without a prompt. If = the commit is reverted, it should be explicitly noted in the code so = that we don't do this mistake again. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 22:08:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 029761065696 for ; Fri, 20 Aug 2010 22:08:32 +0000 (UTC) (envelope-from ipfreak@yahoo.com) Received: from web52302.mail.re2.yahoo.com (web52302.mail.re2.yahoo.com [206.190.48.145]) by mx1.freebsd.org (Postfix) with SMTP id 7A4E48FC0A for ; Fri, 20 Aug 2010 22:08:31 +0000 (UTC) Received: (qmail 61653 invoked by uid 60001); 20 Aug 2010 22:08:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1282342110; bh=+phq78FiTL9na6cXLEfpdd0MagOzN8az/x02O8b9P1A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=k1YA/arjxMDxsai12mFMHRZWWeuPmrJb5962gn5/hQlQnya9Dn8MK6hE7lYtYrVqgNxAK/KgPs0qFuMYpJ9r0bobF3AvYDL1BEhdSucc7fGogcd4Qs3C/8R+TJGYBkZjqhONnld3q6nsfISJA8XQewSzNhvz9XyJ6GIndKDeSMY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=g6ynQ4bf19aJjk2qe3suyGLyJ3yOg92PpsDn0sozHRqfBFGFGi4mJjXD0/fEK8MaVZx6G1WrofYM9TiWGKeiBVq3xIfZJTZ5LFF0slfJaX0mjdYnaVfNhZBO/JAA8Q0bPNTAcMs6icajmHH77rpl7ZGBPjdOUzXZZCNUPrMHwps=; Message-ID: <781712.60498.qm@web52302.mail.re2.yahoo.com> X-YMail-OSG: _nlouQAVM1nVHmzzz2xsFwEsvRwQUPS.7b4d48AGN90RFJV UBATCe2QZhdApRkm_TDzLOizAI5vdNk9TG12iT4bHsJMbERfVFcvnukfWmcd h83DlzL154iX.5P1GkP_T0Bbuu8KIkGmpFpRqzfovRO7llYHKltc9lsbudMk _ELKtG9TYEl8o0hhiGVfBdRYaQUvhTfDn_4ClvlD2NCDU62zQhu1U4_0dkNl g8JR7WVt._dtb586AeHNIeGZ3BUFU_PHCUC_XS.a9m_z8Gx69u8gN5B3rpub aNRUZVhMzSemUbik1nVuqELEU7tG_LEOZHbRxrA-- Received: from [209.22.88.90] by web52302.mail.re2.yahoo.com via HTTP; Fri, 20 Aug 2010 15:08:30 PDT X-Mailer: YahooMailClassic/11.3.2 YahooMailWebService/0.8.105.279950 Date: Fri, 20 Aug 2010 15:08:30 -0700 (PDT) From: gahn To: free bsd , freebsd general questions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: meory file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 22:08:32 -0000 Hi, All: I am running 8.1. under /dev, I don't see /dev/md0, so i am trying to add following lines in kernel file and got error messages: options MFS #Memory Filesystem /usr/src/sys/i386/conf/bn39_1: unknown option "MFS" *** Error code 1 Stop in /usr/src. *** Error code 1 any gurus here know what is happeny here? From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 22:36:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39C11065672; Fri, 20 Aug 2010 22:36:45 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 95AD28FC0C; Fri, 20 Aug 2010 22:36:45 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o7KMajqq058213; Fri, 20 Aug 2010 15:36:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o7KMajQ5058212; Fri, 20 Aug 2010 15:36:45 -0700 (PDT) (envelope-from sgk) Date: Fri, 20 Aug 2010 15:36:45 -0700 From: Steve Kargl To: gahn Message-ID: <20100820223645.GA58189@troutmask.apl.washington.edu> References: <781712.60498.qm@web52302.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <781712.60498.qm@web52302.mail.re2.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: free bsd , freebsd general questions Subject: Re: meory file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 22:36:45 -0000 On Fri, Aug 20, 2010 at 03:08:30PM -0700, gahn wrote: > Hi, All: > > I am running 8.1. under /dev, I don't see /dev/md0, so i am trying to add following lines in kernel file and got error messages: > > options MFS #Memory Filesystem > > /usr/src/sys/i386/conf/bn39_1: unknown option "MFS" > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > any gurus here know what is happeny here? > There isn't a MFS option. Try 'man mdconfig'. PS: Your message should have been sent for freebsd-questions@freebsd.org. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 22:56:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D1A10656AB; Fri, 20 Aug 2010 22:56:23 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id C7A5E8FC19; Fri, 20 Aug 2010 22:56:22 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L7H00L003PYFM00@smtpauth2.wiscmail.wisc.edu>; Fri, 20 Aug 2010 17:56:22 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.72.125]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L7H00DMN3PWST20@smtpauth2.wiscmail.wisc.edu>; Fri, 20 Aug 2010 17:56:21 -0500 (CDT) Date: Fri, 20 Aug 2010 17:56:19 -0500 From: Nathan Whitehorn In-reply-to: <86fwy9f5vj.fsf@ds4.des.no> To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Message-id: <4C6F0813.9030007@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.72.125 X-Spam-PmxInfo: Server=avs-12, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.8.20.224815, SenderIP=76.210.72.125 References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> <86fwy9f5vj.fsf@ds4.des.no> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100729 Thunderbird/3.0.6 Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 22:56:23 -0000 On 08/20/10 14:20, Dag-Erling Smørgrav wrote: > Nathan Whitehorn writes: > >> Next up: tinderbox needs to build GENERIC64, not GENERIC, on >> powerpc64. make buildkernel is programmed to do the right thing is you >> don't pass a KERNCONF, but tinderbox apparently passes GENERIC >> explicitly. This one's in your court! >> > There is no way to fix this with the current tinderbox code. > > MHO is that the entire powerpc64 thing is very poorly thought out. > I'm the first to admit that many of the config tricks involved in this port, and GENERIC64, are ugly hacks, largely because config(8) was not designed with such things in mind. But the alternatives were much worse: - A sys/powerpc64 that duplicated most of sys/powerpc, which would have been a maintenance nightmare (see sun4v). - A sys/powerpc64 that was mostly symlinks and stub includes, which is inelegant at best, and could cause kinds of fascinating problems for user programs including things in machine/. - Bunches of new make variables like TARGET_BIG_ENDIAN and TARGET_64BIT and such like mips and arm have, which is way more awful, as well as precluding tinderbox and make universe coverage in a reasonable way. powerpc64 is the first architecture trying out this new multi-architecture MACHINE approach, which Warner designed to kill off things like TARGET_BIG_ENDIAN, so there are going to be some interesting rough patches along the way, and I really appreciate your patience in sorting them out. To address the immediate problem, I think the best solution is to use the -m option to config to reject kernel configs for different architectures, the way the tinderbox scripts currently skip kernel configs that they are asked to build that don't exist. If you think this is a reasonable approach, I'm happy to code up a patch to tinderbox to do this over the weekend. You can feel free to disconnect powerpc64 from tinderbox in the interim. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 23:12:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB98610656A6 for ; Fri, 20 Aug 2010 23:12:04 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 720318FC08 for ; Fri, 20 Aug 2010 23:12:04 +0000 (UTC) Received: by iwn36 with SMTP id 36so3933875iwn.13 for ; Fri, 20 Aug 2010 16:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.17.11 with SMTP id q11mr1200164iba.63.1282345923518; Fri, 20 Aug 2010 16:12:03 -0700 (PDT) Received: by 10.231.176.140 with HTTP; Fri, 20 Aug 2010 16:12:03 -0700 (PDT) In-Reply-To: <20100820223645.GA58189@troutmask.apl.washington.edu> References: <781712.60498.qm@web52302.mail.re2.yahoo.com> <20100820223645.GA58189@troutmask.apl.washington.edu> Date: Sat, 21 Aug 2010 01:12:03 +0200 Message-ID: From: Olivier Smedts To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: gahn , free bsd , freebsd general questions Subject: Re: meory file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 23:12:04 -0000 2010/8/21 Steve Kargl : > On Fri, Aug 20, 2010 at 03:08:30PM -0700, gahn wrote: >> Hi, All: >> >> I am running 8.1. under /dev, I don't see /dev/md0, so i am trying to ad= d following lines in kernel file and got error messages: >> >> options =A0 =A0 =A0 =A0 MFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #Memory File= system >> >> /usr/src/sys/i386/conf/bn39_1: unknown option "MFS" >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> any gurus here know what is happeny here? >> > > There isn't a MFS option. =A0Try 'man mdconfig'. Also, have a look at tmpfs ! > > PS: Your message should have been sent for freebsd-questions@freebsd.org. > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 00:03:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A15C1065675 for ; Sat, 21 Aug 2010 00:03:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id BE60A8FC18 for ; Sat, 21 Aug 2010 00:03:41 +0000 (UTC) Received: (qmail 12272 invoked by uid 399); 21 Aug 2010 00:03:40 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Aug 2010 00:03:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 20 Aug 2010 17:03:38 -0700 (PDT) From: Doug Barton To: freebsd-current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andriy Gapon Subject: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 00:03:42 -0000 Here are the results of a vmstat -i, the old dtrace script, and Andriy's new one. interrupt total rate irq1: atkbd0 10420 1 irq9: acpi0 111 0 irq14: ata0 176564 26 irq17: wpi0 105948 15 irq20: hpet0 uhci0+ 858975 128 irq22: uhci2 18972 2 cpu0:timer 6655466 997 irq256: hdac0 11 0 cpu1:timer 6656559 997 Total 14483026 2170 CPU ID FUNCTION:NAME 1 2 :END kernel`loadav value ------------- Distribution ------------- count 16384 | 0 32768 |@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2 65536 |@@@@@@@@@@@@@ 1 131072 | 0 0xc0b6bf30 value ------------- Distribution ------------- count 65536 | 0 131072 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 262144 | 0 kernel`ieee80211_node_timeout value ------------- Distribution ------------- count 131072 | 0 262144 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 524288 | 0 kernel`ipport_tick value ------------- Distribution ------------- count 256 | 0 512 |@@@@@ 2 1024 |@@@ 1 2048 | 0 4096 | 0 8192 | 0 16384 |@@@@@@@@@@@ 4 32768 |@@@@@ 2 65536 |@@@@@@@@@@@@@@@@ 6 131072 | 0 0xc0b6a9d0 value ------------- Distribution ------------- count 256 | 0 512 |@@@ 1 1024 |@@@ 1 2048 | 0 4096 |@@@ 1 8192 | 0 16384 |@@@@@@@@@@@ 4 32768 |@@@@@@@@@@@ 4 65536 |@@@@@@@@ 3 131072 |@@@ 1 262144 | 0 kernel`kbdmux_kbd_intr_timo value ------------- Distribution ------------- count 512 | 0 1024 |@@@@@ 2 2048 |@@@ 1 4096 | 0 8192 | 0 16384 |@@@@@@@@ 3 32768 |@@@@@@@@ 3 65536 |@@@@@@@@@@@@@@@@ 6 131072 | 0 kernel`nd6_timer value ------------- Distribution ------------- count 1024 | 0 2048 |@@@ 1 4096 | 0 8192 | 0 16384 |@@@@@ 2 32768 |@@@@@@@@ 3 65536 |@@@@@@@@@@@@@ 5 131072 |@@@@@@@@@@@ 4 262144 | 0 kernel`uma_timeout value ------------- Distribution ------------- count 524288 | 0 1048576 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 2097152 | 0 kernel`usb_power_wdog value ------------- Distribution ------------- count 2048 | 0 4096 |@@@ 1 8192 | 0 16384 | 0 32768 |@@@ 1 65536 |@@@@@@@@@@@@@@@ 6 131072 |@@@@@@@@@@@@@ 5 262144 |@@@@@@@@ 3 524288 | 0 kernel`uhci_root_intr value ------------- Distribution ------------- count 1024 | 0 2048 |@@ 3 4096 | 0 8192 | 0 16384 |@@@ 4 32768 |@@@@@@@@@@@@@@@ 22 65536 |@@@@@@@@@@@@@@@@@@@@ 30 131072 |@ 1 262144 | 0 kernel`lim_cb value ------------- Distribution ------------- count 512 | 0 1024 |@@@@ 4 2048 |@ 1 4096 |@ 1 8192 | 0 16384 |@@@@ 4 32768 |@@@@@@@@@ 10 65536 |@@@@@@@@@@@@ 13 131072 |@@@@@@@@ 9 262144 |@@@ 3 524288 | 0 0xc7c975d0 value ------------- Distribution ------------- count 16384 | 0 32768 |@@@ 1 65536 |@@@@@@@@@@@ 4 131072 |@@@ 1 262144 |@@@@@@@@@ 3 524288 |@@@@@@@@@@@@@@ 5 1048576 | 0 kernel`realtimer_expire value ------------- Distribution ------------- count 16384 | 0 32768 |@@@@@ 2 65536 |@@@ 1 131072 |@@@@@@@@@@@@@ 5 262144 |@@@@@ 2 524288 |@@@@@@@@@@@@@ 5 1048576 | 0 kernel`pffasttimo value ------------- Distribution ------------- count 256 | 0 512 |@ 1 1024 |@@ 4 2048 |@ 2 4096 | 0 8192 | 0 16384 |@@@@@ 9 32768 |@@@@@@@@@@ 18 65536 |@@@@@@@@@@@@@@@ 28 131072 |@@@@@@ 12 262144 |@ 1 524288 | 0 kernel`atkbd_timeout value ------------- Distribution ------------- count 1024 | 0 2048 |@@ 9 4096 | 1 8192 | 0 16384 |@@@@ 14 32768 |@@@@@@@@@@@@@@ 53 65536 |@@@@@@@@@@@@@@ 54 131072 |@@@@ 16 262144 |@ 2 524288 | 0 kernel`logtimeout value ------------- Distribution ------------- count 256 | 0 512 |@@@ 5 1024 |@ 1 2048 |@@ 3 4096 |@ 2 8192 | 0 16384 |@@@@@@@@@@@@ 22 32768 |@@@@@@@@ 15 65536 |@@@@@@@@@@@@@@ 26 131072 | 0 262144 | 0 524288 | 0 1048576 | 0 2097152 | 0 4194304 | 0 8388608 | 0 16777216 |@ 1 33554432 | 0 kernel`scrn_timer value ------------- Distribution ------------- count 256 | 0 512 |@ 9 1024 |@@@ 26 2048 | 4 4096 | 4 8192 | 0 16384 |@@@@@@@@ 76 32768 |@@@@@@@@@@ 89 65536 |@@@@@@@@@@@@@ 118 131072 |@@@@ 35 262144 |@ 7 524288 | 2 1048576 | 0 kernel`pfslowtimo value ------------- Distribution ------------- count 2048 | 0 4096 |@ 1 8192 | 0 16384 |@ 1 32768 |@@@@ 3 65536 |@@@@@@@@@@@@ 9 131072 |@@@@@@@@@@@@ 9 262144 |@@@@@@@ 5 524288 | 0 1048576 | 0 2097152 |@ 1 4194304 | 0 8388608 | 0 16777216 | 0 33554432 |@ 1 67108864 | 0 kernel`sleepq_timeout value ------------- Distribution ------------- count 256 | 0 512 |@ 7 1024 |@@@ 39 2048 |@ 16 4096 |@ 10 8192 | 0 16384 |@@@@@ 61 32768 |@@@@@@@@ 90 65536 |@@@@@@@@@@ 114 131072 |@@@@@@@@@@@@ 138 262144 | 1 524288 | 1 1048576 | 0 2097152 | 0 4194304 | 0 8388608 | 0 16777216 | 0 33554432 | 1 67108864 | 0 0xc7ca2f40 value ------------- Distribution ------------- count 256 | 0 512 |@@ 81 1024 |@@@ 124 2048 | 10 4096 |@ 43 8192 | 0 16384 |@@@@@@@ 278 32768 |@@@@@@@@@@ 420 65536 |@@@@@@@@@@@@@@@ 604 131072 |@ 61 262144 | 11 524288 | 3 1048576 | 0 kernel`tcp_isn_tick value ------------- Distribution ------------- count 128 | 0 256 | 7 512 |@@@ 112 1024 |@@@ 99 2048 |@@ 85 4096 | 16 8192 | 0 16384 |@@@@@@@@ 286 32768 |@@@@@@@@ 305 65536 |@@@@@@@@@@@@@@@ 540 131072 | 13 262144 | 4 524288 | 3 1048576 | 0 2097152 | 0 4194304 | 0 8388608 | 0 16777216 | 3 33554432 | 0 kernel`ieee80211_node_timeout 1 kernel`uma_timeout 1 0xc0b6bf30 1 kernel`loadav 3 0xc7c975d0 14 kernel`kbdmux_kbd_intr_timo 15 kernel`realtimer_expire 15 kernel`ipport_tick 15 kernel`nd6_timer 15 0xc0b6a9d0 15 kernel`usb_power_wdog 16 kernel`pfslowtimo 30 kernel`lim_cb 45 kernel`uhci_root_intr 60 kernel`logtimeout 75 kernel`pffasttimo 75 kernel`atkbd_timeout 149 kernel`scrn_timer 370 kernel`sleepq_timeout 478 kernel`tcp_isn_tick 1473 0xc7ca2f40 1635 CPU ID FUNCTION:NAME 1 2 :END ***** CPU 0: kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`fork_exit+0xb8 kernel`0xc086a094 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`smp_rendezvous_cpus+0x174 0xc7caf7ff 0xc7cac249 kernel`devfs_ioctl_f+0x10b kernel`kern_ioctl+0x1dd kernel`ioctl+0x12f kernel`syscallenter+0x280 kernel`syscall+0x34 kernel`0xc086a081 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`ioapic_enable_source+0x7c kernel`ithread_loop+0x143 kernel`fork_exit+0xb8 kernel`0xc086a094 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`ithread_loop+0x1ff kernel`fork_exit+0xb8 kernel`0xc086a094 11 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`cpu_idle_acpi+0x1b kernel`cpu_idle+0x1b kernel`sched_idletd+0x3c kernel`fork_exit+0xb8 kernel`0xc086a094 87 ***** CPU 1: kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`_mtx_unlock_spin_flags+0x10d kernel`ithread_loop+0x1ff kernel`fork_exit+0xb8 kernel`0xc086a094 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`ffs_sync+0x2b2 kernel`sync_fsync+0x18f kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`_mtx_unlock_spin_flags+0x10d kernel`sched_idletd+0xa5 kernel`fork_exit+0xb8 kernel`0xc086a094 0 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`cpu_idle_acpi+0x1b kernel`cpu_idle+0x1b kernel`sched_idletd+0x3c kernel`fork_exit+0xb8 kernel`0xc086a094 97 ***** Top Processes: 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`__mnt_vnode_next+0x2f kernel`ffs_sync+0x2b2 kernel`sync_fsync+0x18f kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 36475 100100 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 0 10 100003 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`fork_exit+0xb8 kernel`0xc086a094 0 11 100006 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`callout_reset_on+0x1ca 0xc7ca3076 kernel`softclock+0x284 kernel`intr_event_execute_handlers+0x125 kernel`ithread_loop+0x9f kernel`fork_exit+0xb8 kernel`0xc086a094 0 11 100007 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`_mtx_unlock_spin_flags+0x10d kernel`sleepq_timeout+0xe4 kernel`softclock+0x284 kernel`intr_event_execute_handlers+0x125 kernel`ithread_loop+0x9f kernel`fork_exit+0xb8 kernel`0xc086a094 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`ffs_sync+0x1db kernel`sync_fsync+0x18f kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`vfs_msync+0x205 kernel`sync_fsync+0x17b kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`sync_fsync+0x17b kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 11 100006 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`softclock+0x1bf kernel`intr_event_execute_handlers+0x125 kernel`ithread_loop+0x9f kernel`fork_exit+0xb8 kernel`0xc086a094 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`ffs_sync+0x173 kernel`sync_fsync+0x18f kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`vfs_msync+0x217 kernel`sync_fsync+0x17b kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`vfs_msync+0x77 kernel`sync_fsync+0x17b kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 36475 100100 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`smp_rendezvous_cpus+0x174 0xc7caf7ff 0xc7cac249 kernel`devfs_ioctl_f+0x10b kernel`kern_ioctl+0x1dd kernel`ioctl+0x12f kernel`syscallenter+0x280 kernel`syscall+0x34 kernel`0xc086a081 0 36475 100100 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f 0 17 100064 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`ffs_sync+0x2b2 kernel`sync_fsync+0x18f kernel`VOP_FSYNC_APV+0xda kernel`sync_vnode+0x168 kernel`sched_sync+0x273 kernel`fork_exit+0xb8 kernel`0xc086a094 0 10 100002 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`_mtx_unlock_spin_flags+0x10d kernel`sched_idletd+0xa5 kernel`fork_exit+0xb8 kernel`0xc086a094 0 11 100026 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`ioapic_enable_source+0x7c kernel`ithread_loop+0x143 kernel`fork_exit+0xb8 kernel`0xc086a094 0 11 100006 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`_mtx_unlock_spin_flags+0x10d kernel`ithread_loop+0x1ff kernel`fork_exit+0xb8 kernel`0xc086a094 11 10 100003 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`timer2cb+0xb9 kernel`hpet_intr_single+0xed kernel`hpet_intr+0x72 kernel`intr_event_handle+0x76 kernel`intr_execute_handlers+0x49 kernel`lapic_handle_intr+0x4c kernel`0xc086a3e5 kernel`cpu_idle_acpi+0x1b kernel`cpu_idle+0x1b kernel`sched_idletd+0x3c kernel`fork_exit+0xb8 kernel`0xc086a094 87 10 100002 kernel`timer2clock+0x4d kernel`statclockhandler+0x33 kernel`statclockintr+0x73 kernel`ipi_bitmap_handler+0x54 kernel`0xc086a76f kernel`cpu_idle_acpi+0x1b kernel`cpu_idle+0x1b kernel`sched_idletd+0x3c kernel`fork_exit+0xb8 kernel`0xc086a094 97 -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 03:00:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472461065695; Sat, 21 Aug 2010 03:00:30 +0000 (UTC) (envelope-from mike@ducky.net) Received: from ducky.net (ducky.net [71.216.22.205]) by mx1.freebsd.org (Postfix) with ESMTP id F0DA18FC1A; Sat, 21 Aug 2010 03:00:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ducky.net (8.14.3/8.14.3) with ESMTP id o7L2VRvI031700; Fri, 20 Aug 2010 19:31:27 -0700 (PDT) (envelope-from mike@ducky.net) Message-Id: <201008210231.o7L2VRvI031700@ducky.net> To: gabor@freebsd.org Date: Fri, 20 Aug 2010 19:31:27 -0700 From: Mike Haertel X-Mailman-Approved-At: Sat, 21 Aug 2010 03:57:13 +0000 Cc: freebsd-current@freebsd.org Subject: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:00:30 -0000 Hi Gabor, I am the original author of GNU grep. I am also a FreeBSD user, although I live on -stable (and older) and rarely pay attention to -current. However, while searching the -current mailing list for an unrelated reason, I stumbled across some flamage regarding BSD grep vs GNU grep performance. You may have noticed that discussion too... Anyway, just FYI, here's a quick summary of where GNU grep gets its speed. Hopefully you can carry these ideas over to BSD grep. #1 trick: GNU grep is fast because it AVOIDS LOOKING AT EVERY INPUT BYTE. #2 trick: GNU grep is fast because it EXECUTES VERY FEW INSTRUCTIONS FOR EACH BYTE that it *does* look at. GNU grep uses the well-known Boyer-Moore algorithm, which looks first for the final letter of the target string, and uses a lookup table to tell it how far ahead it can skip in the input whenever it finds a non-matching character. GNU grep also unrolls the inner loop of Boyer-Moore, and sets up the Boyer-Moore delta table entries in such a way that it doesn't need to do the loop exit test at every unrolled step. The result of this is that, in the limit, GNU grep averages fewer than 3 x86 instructions executed for each input byte it actually looks at (and it skips many bytes entirely). See "Fast String Searching", by Andrew Hume and Daniel Sunday, in the November 1991 issue of Software Practice & Experience, for a good discussion of Boyer-Moore implementation tricks. It's available as a free PDF online. Once you have fast search, you'll find you also need fast input. GNU grep uses raw Unix input system calls and avoids copying data after reading it. Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking for newlines would slow grep down by a factor of several times, because to find the newlines it would have to look at every byte! So instead of using line-oriented input, GNU grep reads raw data into a large buffer, searches the buffer using Boyer-Moore, and only when it finds a match does it go and look for the bounding newlines. (Certain command line options like -n disable this optimization.) Finally, when I was last the maintainer of GNU grep (15+ years ago...), GNU grep also tried very hard to set things up so that the *kernel* could ALSO avoid handling every byte of the input, by using mmap() instead of read() for file input. At the time, using read() caused most Unix versions to do extra copying. Since GNU grep passed out of my hands, it appears that use of mmap became non-default, but you can still get it via --mmap. And at least in cases where the data is already file system buffer caches, mmap is still faster: $ time sh -c 'find . -type f -print | xargs grep -l 123456789abcdef' real 0m1.530s user 0m0.230s sys 0m1.357s $ time sh -c 'find . -type f -print | xargs grep --mmap -l 123456789abcdef' real 0m1.201s user 0m0.330s sys 0m0.929s [workload was a 648 megabyte MH mail folder containing 41000 messages] So even nowadays, using --mmap can be worth a >20% speedup. Summary: - Use Boyer-Moore (and unroll its inner loop a few times). - Roll your own unbuffered input using raw system calls. Avoid copying the input bytes before searching them. (Do, however, use buffered *output*. The normal grep scenario is that the amount of output is small compared to the amount of input, so the overhead of output buffer copying is small, while savings due to avoiding many small unbuffered writes can be large.) - Don't look for newlines in the input until after you've found a match. - Try to set things up (page-aligned buffers, page-sized read chunks, optionally use mmap) so the kernel can ALSO avoid copying the bytes. The key to making programs fast is to make them do practically nothing. ;-) Regards, Mike From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 04:03:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81E71106566B; Sat, 21 Aug 2010 04:03:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 536CD8FC18; Sat, 21 Aug 2010 04:03:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7L43Ake088957; Sat, 21 Aug 2010 00:03:10 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7L43A5L088956; Sat, 21 Aug 2010 04:03:10 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 21 Aug 2010 04:03:10 GMT Message-Id: <201008210403.o7L43A5L088956@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 04:03:11 -0000 TB --- 2010-08-21 01:46:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-21 01:46:10 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-21 01:46:10 - cleaning the object tree TB --- 2010-08-21 01:47:03 - cvsupping the source tree TB --- 2010-08-21 01:47:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-21 01:47:34 - building world TB --- 2010-08-21 01:47:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 01:47:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 01:47:34 - TARGET=powerpc TB --- 2010-08-21 01:47:34 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 01:47:34 - TZ=UTC TB --- 2010-08-21 01:47:34 - __MAKE_CONF=/dev/null TB --- 2010-08-21 01:47:34 - cd /src TB --- 2010-08-21 01:47:34 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 21 01:47:35 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Aug 21 03:31:56 UTC 2010 TB --- 2010-08-21 03:31:56 - generating LINT kernel config TB --- 2010-08-21 03:31:56 - cd /src/sys/powerpc/conf TB --- 2010-08-21 03:31:56 - /usr/bin/make -B LINT TB --- 2010-08-21 03:31:56 - building LINT kernel TB --- 2010-08-21 03:31:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 03:31:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 03:31:56 - TARGET=powerpc TB --- 2010-08-21 03:31:56 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 03:31:56 - TZ=UTC TB --- 2010-08-21 03:31:56 - __MAKE_CONF=/dev/null TB --- 2010-08-21 03:31:56 - cd /src TB --- 2010-08-21 03:31:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 21 03:31:56 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Aug 21 03:57:39 UTC 2010 TB --- 2010-08-21 03:57:39 - building GENERIC kernel TB --- 2010-08-21 03:57:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 03:57:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 03:57:39 - TARGET=powerpc TB --- 2010-08-21 03:57:39 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 03:57:39 - TZ=UTC TB --- 2010-08-21 03:57:39 - __MAKE_CONF=/dev/null TB --- 2010-08-21 03:57:39 - cd /src TB --- 2010-08-21 03:57:39 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Aug 21 03:57:39 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-21 04:03:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-21 04:03:10 - ERROR: failed to build GENERIC kernel TB --- 2010-08-21 04:03:10 - 5652.94 user 1594.18 system 8220.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 05:56:28 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8280A106567A for ; Sat, 21 Aug 2010 05:56:28 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 184908FC15 for ; Sat, 21 Aug 2010 05:56:27 +0000 (UTC) Received: (qmail 1332 invoked by uid 399); 21 Aug 2010 05:56:27 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Aug 2010 05:56:27 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 20 Aug 2010 22:56:24 -0700 (PDT) From: Doug Barton To: freebsd-current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: malus.x@gmail.com Subject: npviewer.bin and nspluginwrapper errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 05:56:28 -0000 These are various error messages collected from running X and/or firefox from the command line: *** NSPlugin Viewer *** WARNING: unhandled variable 18 () in NPN_GetValue() I get lots and lots of these, even when things are working well. npviewer.bin: ../src/npw-rpc.c:1190: do_send_NPObject: Assertion `npobj_id != 0' failed. *** NSPlugin Wrapper *** ERROR: NPN_ReleaseObject() get args: Connection closed *** NSPlugin Wrapper *** ERROR: NPP_Destroy() wait for reply: Connection closed *** NSPlugin Wrapper *** ERROR: NPObject 0x2fac2100 is no longer valid! When I get these "no longer valid" errors is usually about the time that intr starts to run away. *** NSPlugin Wrapper *** WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwra pper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: asse rtion failed: (rpc_method_invoke_possible(plugin->connection)) *** NSPlugin Wrapper *** ERROR: NPClass::HasProperty() wait for reply: Connection closed *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: assertion failed: (rpc_method_invoke_possible(plugin->connection)) *** NSPlugin Wrapper *** ERROR: NPObject 0x2f6235d0 is no longer valid! *** NSPlugin Wrapper *** WARNING:(/usr/local/tmp/usr/local/ports/www/nspluginwrapper/work/nspluginwrapper-1.2.2/src/npw-wrapper.c:1855):invoke_NPP_Destroy: assertion failed: (rpc_method_invoke_possible(plugin->connection)) -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 06:50:24 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE07A106567A; Sat, 21 Aug 2010 06:50:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0628F8FC13; Sat, 21 Aug 2010 06:50:23 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA11713; Sat, 21 Aug 2010 09:50:21 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OmhuH-00061S-2W; Sat, 21 Aug 2010 09:50:21 +0300 Message-ID: <4C6F772A.5020703@icyb.net.ua> Date: Sat, 21 Aug 2010 09:50:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 06:50:24 -0000 on 21/08/2010 03:03 Doug Barton said the following: > Here are the results of a vmstat -i, the old dtrace script, and Andriy's > new one. I think that for such amount of data it is better to use links (perhaps a service like pastebin) rather than inlining it. BTW, it seems that there are no followups/comments on results of the old dtrace script, so I am not sure if there is any point in continuing to post it. It is useless personally for me. Back to the data. Could you please report results of procstat -k 10 procstat -k 11 ? Thanks. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 07:10:13 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0442810656A6; Sat, 21 Aug 2010 07:10:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 221408FC08; Sat, 21 Aug 2010 07:10:11 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA11891; Sat, 21 Aug 2010 10:10:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OmiDS-00062p-Ct; Sat, 21 Aug 2010 10:10:10 +0300 Message-ID: <4C6F7BD1.4030009@icyb.net.ua> Date: Sat, 21 Aug 2010 10:10:09 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: <4C6F772A.5020703@icyb.net.ua> In-Reply-To: <4C6F772A.5020703@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 07:10:13 -0000 on 21/08/2010 09:50 Andriy Gapon said the following: > on 21/08/2010 03:03 Doug Barton said the following: >> Here are the results of a vmstat -i, the old dtrace script, and Andriy's >> new one. > > I think that for such amount of data it is better to use links (perhaps a > service like pastebin) rather than inlining it. > BTW, it seems that there are no followups/comments on results of the old dtrace > script, so I am not sure if there is any point in continuing to post it. > It is useless personally for me. > > Back to the data. > Could you please report results of > procstat -k 10 > procstat -k 11 > ? Some additional stuff. Could you please remind what the "old dtrace script" is? :-) Output of sysctl dev.cpu (normal and when the problem hits) Another dtrace script: profile:::profile-1001 { @stacks[curthread->td_oncpu, pid, tid, stack()] = count(); } END { trunc(@stacks, 20); printa(@stacks); } -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 07:33:47 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA991065697 for ; Sat, 21 Aug 2010 07:33:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id CF4DF8FC0C for ; Sat, 21 Aug 2010 07:33:46 +0000 (UTC) Received: (qmail 7594 invoked by uid 399); 21 Aug 2010 07:33:45 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Aug 2010 07:33:45 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sat, 21 Aug 2010 00:33:43 -0700 (PDT) From: Doug Barton To: Andriy Gapon In-Reply-To: <4C6F7BD1.4030009@icyb.net.ua> Message-ID: References: <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 07:33:47 -0000 On Sat, 21 Aug 2010, Andriy Gapon wrote: >> I think that for such amount of data it is better to use links (perhaps a >> service like pastebin) rather than inlining it. No problem: http://people.freebsd.org/~dougb/intr-out.txt >> BTW, it seems that there are no followups/comments on results of the old dtrace >> script, so I am not sure if there is any point in continuing to post it. >> It is useless personally for me. Ok. >> Back to the data. >> Could you please report results of >> procstat -k 10 >> procstat -k 11 > > Could you please remind what the "old dtrace script" is? :-) http://people.freebsd.org/~dougb/dtrace-script.txt > Output of sysctl dev.cpu (normal and when the problem hits) > > Another dtrace script: > profile:::profile-1001 > { > @stacks[curthread->td_oncpu, pid, tid, stack()] = count(); > } > END > { > trunc(@stacks, 20); > printa(@stacks); > } All of the above is in that intr-out.txt file. The last 2 (sysctl and the 2nd dtrace script) are actually while the intr cpu% was going down (i.e., the system was recovering) but I'll run it again next time if you like. Thanks! Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 09:35:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A181410656A9; Sat, 21 Aug 2010 09:35:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BCE1F8FC16; Sat, 21 Aug 2010 09:35:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA13629; Sat, 21 Aug 2010 12:35:18 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OmkTt-0006C0-Uw; Sat, 21 Aug 2010 12:35:17 +0300 Message-ID: <4C6F9DD4.3050205@icyb.net.ua> Date: Sat, 21 Aug 2010 12:35:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 09:35:20 -0000 on 21/08/2010 10:33 Doug Barton said the following: > On Sat, 21 Aug 2010, Andriy Gapon wrote: > >>> I think that for such amount of data it is better to use links >>> (perhaps a >>> service like pastebin) rather than inlining it. > > No problem: > http://people.freebsd.org/~dougb/intr-out.txt Thanks a lot! Can you try, for the sake of experiment, to reproduce the problem with hw.acpi.cpu.cx_lowest=C1 ? I feel like you might be having a problem with clocks... BTW, if you run procstat -k 11 a few times during the condition, does TID 100006 typically have or not have "lock_mtx softclock" substring in its stack? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 10:21:33 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF7D9106566B; Sat, 21 Aug 2010 10:21:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6794C8FC08; Sat, 21 Aug 2010 10:21:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA14094; Sat, 21 Aug 2010 13:21:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OmlCc-0006F2-LD; Sat, 21 Aug 2010 13:21:30 +0300 Message-ID: <4C6FA8A9.3040606@icyb.net.ua> Date: Sat, 21 Aug 2010 13:21:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> <4C6F9DD4.3050205@icyb.net.ua> In-Reply-To: <4C6F9DD4.3050205@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 10:21:33 -0000 on 21/08/2010 12:35 Andriy Gapon said the following: > I feel like you might be having a problem with clocks... FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 and I see this sentence: "All of the clocks in the processor core are stopped in the C3 state". I see that you have C3 state enabled and it's regularly entered: dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us Also I see that LAPIC timer is used as timer1 (hardclock) on your system: kern.eventtimer.timer1: LAPIC I believe that this might be the explanation of what you see, but I am not sure. One indication that this might be the case is high degree of aliasing between hardclock and statclock interrupts as per my interpretation of the dtrace information. You can test by either avoiding C3 state (via cx_lowest) or configuring some other timer as kern.eventtimer.timer1 P.S. I think that timer selection code and/or Cx configuration code could/should be smarter about things like that. After all ET_FLAGS_C3STOP is set for your LAPIC timer. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 11:08:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 481E7106564A for ; Sat, 21 Aug 2010 11:08:00 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB8B08FC17 for ; Sat, 21 Aug 2010 11:07:59 +0000 (UTC) Received: by qwg5 with SMTP id 5so4299496qwg.13 for ; Sat, 21 Aug 2010 04:07:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.213.212 with SMTP id gx20mr1983508qcb.60.1282388879142; Sat, 21 Aug 2010 04:07:59 -0700 (PDT) Received: by 10.229.25.130 with HTTP; Sat, 21 Aug 2010 04:07:59 -0700 (PDT) X-Originating-IP: [88.65.54.5] In-Reply-To: References: Date: Sat, 21 Aug 2010 13:07:59 +0200 Message-ID: From: Bernhard Schmidt To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Current Subject: Re: recent ath changes related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 11:08:00 -0000 On Fri, Aug 20, 2010 at 22:51, Chris Ruiz wrote: > On Fri, Aug 20, 2010 at 1:56 AM, Bernhard Schmidt > wrote: >> On Fri, Aug 20, 2010 at 08:31, Bernhard Schmidt = wrote: >>> On Fri, Aug 20, 2010 at 01:04, Chris Ruiz wrote= : >>>> I run a PCI Atheros card in hostap mode on CURRENT. >>>> >>>> ath0@pci0:6:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x5a001385 chi= p=3D0x0013168c >>>> rev=3D0x01 hdr=3D0x00 >>>> =A0 =A0vendor =A0 =A0 =3D 'Atheros Communications Inc.' >>>> =A0 =A0device =A0 =A0 =3D '802.11a/b/g Wireless Adapter (AR2312)' >>>> =A0 =A0class =A0 =A0 =A0=3D network >>>> =A0 =A0subclass =A0 =3D ethernet >>>> >>>> Everything works fine with r211193 but with newer kernels I receive >>>> the same panic related to the ath0 tasq. >>> >>> >>> I guess this also happens with post-r211314 kernels? >> >> Seems like I missed you wrap a few ieee80211_ratectl_node_init() s,you,to, of course. >> calls. Please try attached patch, it should fix it. > > Thanks! =A0My system no longer panics at the login prompt. Committed, thanks. --=20 Bernhard From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 11:15:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E0451065670 for ; Sat, 21 Aug 2010 11:15:09 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D37D8FC15 for ; Sat, 21 Aug 2010 11:15:08 +0000 (UTC) Received: by fxm4 with SMTP id 4so2585829fxm.13 for ; Sat, 21 Aug 2010 04:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/AlGhXz9gU0QTPuV6oC1ExSeEZIIvDmvRaY7p9pdwnU=; b=bJNJBB8KGKIysmCN4Ksn1LgwNQwv7U5ZbJi1hTxBdsJqfHeKAEodHaLfQiiPeBJc5q svdbHY38gCVUxnx4sRtpUbXrF2EXCUQWePP8j6Yv2OuGj+JLc9+2m6HPqVdsIivRNcUz /mDi0Tj4fBCwxh/AvExSALwBAJMnGgjp/avvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sidHcCYLGk5rFJxem2c9WiS1ydugRWrKgVIblnk8aS2TF1G0vym8JFRzIRY4vSYqZh XPQXWGsjmDI1ZoZGhh11sGfFwaeVv0MLPMRZFbBRQfUXJFZ+7cYk9PbLrgx0GmG7tDws ZMSFncsiYjmCvh937gGjBTcEG9tRhoSKB5SJY= MIME-Version: 1.0 Received: by 10.223.122.198 with SMTP id m6mr2044031far.87.1282387479306; Sat, 21 Aug 2010 03:44:39 -0700 (PDT) Received: by 10.223.114.138 with HTTP; Sat, 21 Aug 2010 03:44:39 -0700 (PDT) Date: Sat, 21 Aug 2010 19:44:39 +0900 Message-ID: From: Hideki Yamamoto To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: vimage problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 11:15:09 -0000 Hi, I tried vimage and jail today. I have encountered the problem. In the vimage in Jail, I can not reach the internet server. It seems that routing table is incorrect. I do not know the real reason. This is the procedure I did. At first, I created the jail environment. # jail -c vnet host.hostname=vnet1.example.net path=/ persist # jexec 1 ifconfig lo0 inet 127.0.0.1/8 # jexec 1 ifconfig lo0 inet6 ::1 prefixlen 128 # ifconfig em0 vnet 1 # jexec 1 ifconfig em0 em0: flags=8842 metric 0 mtu 1500 options=219b ether 00:1c:c0:60:e7:2d media: Ethernet autoselect (100baseTX ) status: active In jail 1, IPv4 and IPv6 address seemed to be assigned by dhclient and rtsol. # jexec 1 dhclient em0 DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.4 -- renewal in 43200 seconds. # jexec 1 rtsol -F em0 # jexec 1 ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:1c:c0:60:e7:2d inet6 fe80::21c:c0ff:fe60:e72d%em0 prefixlen 64 scopeid 0x2 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2001:c90:48d:7139:21c:c0ff:fe60:e72d prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect (100baseTX ) status: active At this moment, the routing table is as follows. It seems no problem. # jexec 1 netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 0 em0 127.0.0.1 link#1 UH 0 0 lo0 192.168.1.0/24 link#2 U 0 5 em0 192.168.1.4 link#2 UHS 0 0 lo0 # But I cannot reach a server in the Internet. # jexec 1 ping an-internet-host And I cannot detach em0 correctly. # ifconfig em0 -vnet 1 # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:1c:c0:60:e7:2d media: Ethernet autoselect (100baseTX ) status: active After detaching, IPv4 can be assigned by dhclient but IPv6 cannot. # dhclient em0 DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.4 -- renewal in 43200 seconds. # rtsol -F em0 get_llflag() failed, anyway I'll try sendmsg on em0: Can't assign requested address sendmsg on em0: Can't assign requested address sendmsg on em0: Can't assign requested address # And IPv4 address assigned by dhclient cannot be used to connect a server in the Internet. Dose anyone knows any resolution or something? My kernel is as follows. # uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Aug 21 08:23:45 JST 2010 root@:/usr/obj/usr/src/sys/vimage i386 Best regards, Hideki Yamamoto From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 11:35:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7206106566B for ; Sat, 21 Aug 2010 11:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5DD8FC19 for ; Sat, 21 Aug 2010 11:35:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5D58641C747; Sat, 21 Aug 2010 13:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id hfu8dLlkeQJa; Sat, 21 Aug 2010 13:35:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 04B5E41C74D; Sat, 21 Aug 2010 13:35:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5D07E4448F3; Sat, 21 Aug 2010 11:32:56 +0000 (UTC) Date: Sat, 21 Aug 2010 11:32:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Hideki Yamamoto In-Reply-To: Message-ID: <20100821112922.D48418@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: vimage problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 11:35:07 -0000 On Sat, 21 Aug 2010, Hideki Yamamoto wrote: > Dose anyone knows any resolution or something? 1) jexec 1 ifconfig em0 inet6 -ifdisabled to enabled v6 for the interface. 2) have you tried ping -n a.c.b.d using addresses to get the resolver out of the picture. Can you tcpdump and see outgoing packets on em0? /bz PS: freebsd-virtualization@ is more approriate for VIMAGE questions. -- Bjoern A. Zeeb This signature is about you not me. From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 11:46:36 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223D610656AD; Sat, 21 Aug 2010 11:46:36 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out3.libero.it (cp-out3.libero.it [212.52.84.103]) by mx1.freebsd.org (Postfix) with ESMTP id DB61F8FC0A; Sat, 21 Aug 2010 11:46:35 +0000 (UTC) Received: from wmail61 (172.31.0.58) by cp-out3.libero.it (8.5.107) id 4C6C33290013476E; Sat, 21 Aug 2010 13:35:16 +0200 Message-ID: <7971935.1866461282390516480.JavaMail.defaultUser@defaultHost> Date: Sat, 21 Aug 2010 13:35:16 +0200 (CEST) From: Barbara To: , David Wolfskill MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 80.181.217.196 Cc: Michael Butler , current@freebsd.org Subject: R: Re: making dependencies breaks between r210462 and r210495? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 11:46:36 -0000 >On Mon, 26 Jul 2010, David Wolfskill wrote: > >> I don't know if this is likely to bite enough folks htat updating >> UPDATING is warranted. > >The window was small, so probably not. > > >Doug > Last time I've update the src tree (with csup) and successfully rebuilt world+kernel was on July 25th, so just one day before this problem was reported. I've updated the src tree yesterday and now I'm getting the same exact error. Barbara From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 11:52:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B4721065698; Sat, 21 Aug 2010 11:52:42 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id 496AF8FC15; Sat, 21 Aug 2010 11:52:42 +0000 (UTC) Received: from unknown (client-86-31-88-103.midd.adsl.virginmedia.com [86.31.88.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 8F6575F11; Sat, 21 Aug 2010 11:36:10 +0000 (UTC) Date: Sat, 21 Aug 2010 12:36:26 +0100 From: Bruce Cran To: Doug Barton Message-ID: <20100821123626.000025cc@unknown> In-Reply-To: References: <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 11:52:42 -0000 On Sat, 21 Aug 2010 00:33:43 -0700 (PDT) Doug Barton wrote: > On Sat, 21 Aug 2010, Andriy Gapon wrote: > > >> I think that for such amount of data it is better to use links > >> (perhaps a service like pastebin) rather than inlining it. > > No problem: > http://people.freebsd.org/~dougb/intr-out.txt I reported something similar a few years ago that appeared to be related to ACPI that occurred when I changed the CPU frequency: http://www.mavetju.org/mail/view_message.php?list=freebsd-acpi&id=2522390 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 11:53:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC441065696; Sat, 21 Aug 2010 11:53:40 +0000 (UTC) (envelope-from prvs=18493e2b7e=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE8F8FC1B; Sat, 21 Aug 2010 11:53:40 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 21 Aug 2010 12:42:57 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 21 Aug 2010 12:42:57 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50011105508.msg; Sat, 21 Aug 2010 12:42:56 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=18493e2b7e=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: , "Mike Haertel" References: <201008210231.o7L2VRvI031700@ducky.net> Date: Sat, 21 Aug 2010 12:42:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: freebsd-current@freebsd.org Subject: Re: why GNU grep is fast X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 11:53:41 -0000 That's a good read for other things as Mike, thanks for taking the time to pass on this knowledge :) ----- Original Message ----- From: "Mike Haertel" To: > Anyway, just FYI, here's a quick summary of where GNU grep gets > its speed. Hopefully you can carry these ideas over to BSD grep. > > #1 trick: GNU grep is fast because it AVOIDS LOOKING AT > EVERY INPUT BYTE. > > #2 trick: GNU grep is fast because it EXECUTES VERY FEW > INSTRUCTIONS FOR EACH BYTE that it *does* look at. ... ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 13:18:22 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDAE210656A4 for ; Sat, 21 Aug 2010 13:18:22 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 866AC8FC1F for ; Sat, 21 Aug 2010 13:18:22 +0000 (UTC) Received: by wwi18 with SMTP id 18so1382642wwi.31 for ; Sat, 21 Aug 2010 06:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=DxjiBAntRF2mpJ22AEmqY+SNKd6pa79KUg/m21/Hx1o=; b=tii7iH/EXbS3vS9Lwzkc+8bQhlVjJglh9TpIqoyv6HHfUbbVelSbp7A5LIeYYIEZZd GB9iZK7iY1B/mXL3aGPdj+A2iUM5o567X8yUKBDUjjEd2PBsQyZMyswN4McZR2IZhL9j s2TMhewdMVm20/sAXnNLoB1la4uLBI9HBL0Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=ohQu3up3GpMr3nsKBwC3jgCgTJqfaqzMJT7fzgIh4yQxNZhSxRIT0szbC6TrM5eUfV /JcObX0Ek/K1oYMHuO2QYjr3DJ22xaR1Pkc359Pp/3IUiYiScWcR8BcHd97Mb7H9iy7W YdXH/SJYdPoS4ANgO84ONq/eYAFG7/H8qzs90= MIME-Version: 1.0 Received: by 10.216.178.130 with SMTP id f2mr2436325wem.101.1282396701437; Sat, 21 Aug 2010 06:18:21 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Sat, 21 Aug 2010 06:18:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Aug 2010 13:18:21 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Fwd: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 13:18:23 -0000 Andriy Gapon wrote: >on 21/08/2010 12:35 Andriy Gapon said the following: >> I feel like you might be having a problem with clocks... > >FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 >and I see this sentence: "All of the clocks in the processor core are >stopped in the C3 state". > >I see that you have C3 state enabled and it's regularly entered: >dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us I don't think this accounts for all of his problems, unless his machine has an unusual configuration. Alexander and I recommended that he try different clocks, and just recently, for example, he wrote that he had used: loader.conf hint.apic.0.clock="0" hint.atrtc.0.clock="0" hint.attimer.0.clock="0" hint.hpet.0.legacy_route="1" machdep.disable_rtc_set="1" kern.eventtimer.timer2="HPET" kern.eventtimer.timer1="NONE" (Or, if available, HPET1, ...) kern.eventtimer.singlemul="1" sysctl.conf: kern.timecounter.hardware=HPET and reported that it did not help. The HPET doesn't usually suffer from the problem that you are describing, right? b. From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 14:00:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07D3F106564A for ; Sat, 21 Aug 2010 14:00:03 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 79F958FC1E for ; Sat, 21 Aug 2010 14:00:02 +0000 (UTC) Received: by wwi18 with SMTP id 18so1421494wwi.31 for ; Sat, 21 Aug 2010 07:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=BsZW+huqhwUkYEv0K48lCrTXEmmsZh0zKu8Hcl/h69c=; b=CE9jml217KK+ACb7QfuSlEBUzWvfZYiF4f/jI60SxeD0Fk3lnI5vd9q3WON1VCL6Fj besrn4IW/hi24hCyKWe8r6MiY9n2dHZm35j1TQ/MSGHDM8w6NwPGDjBd6F8l7YFrx3ee ce1MLybpe7B6EV6w417CxIb0vk45mm6e9NZp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=vYsAgHtpBpPowh8576rGsbdOQBiT3mz3OYgZtU1THn6U/aGO45FLZUZAnQRPD5vHJw pLOrURZ/DN3fsqwsBHaKwR13rOC1f0HFUbHGVIVRMnbJSdGyzMU6mKjfGxdX/U1sthsi eLc2pUhfCLaL5zqsxtQhqOo/qwISQ6JFCqd+8= MIME-Version: 1.0 Received: by 10.227.133.18 with SMTP id d18mr2572321wbt.33.1282399201392; Sat, 21 Aug 2010 07:00:01 -0700 (PDT) Received: by 10.216.183.212 with HTTP; Sat, 21 Aug 2010 07:00:01 -0700 (PDT) In-Reply-To: <4C6FD562.1030700@icyb.net.ua> References: <4C6FD562.1030700@icyb.net.ua> Date: Sat, 21 Aug 2010 14:00:01 +0000 Message-ID: From: "b. f." To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 14:00:03 -0000 On 8/21/10, Andriy Gapon wrote: > on 21/08/2010 16:04 b. f. said the following: >> Andriy Gapon wrote: >>> on 21/08/2010 12:35 Andriy Gapon said the following: > Well, let's try to not muddy the waters prematurely. It's not premature to say that his machine has some peculiar clock-related features, that should be kept in mind while testing. This came up earlier: http://lists.freebsd.org/pipermail/freebsd-current/2010-June/018179.html and is partly why I recommended some of the settings below. > >> Alexander and I recommended >> that he try different clocks, and just recently, for example, he wrote >> that he had used: >> >> loader.conf >> hint.apic.0.clock="0" >> hint.atrtc.0.clock="0" >> hint.attimer.0.clock="0" >> hint.hpet.0.legacy_route="1" > > Well, I don't see much point in doing the above in this situation. We suspected clock problems as well, and were trying to isolate the problem taking other clocks completely out of consideration. Probably the legacy_route could have been discarded, but in that case the second eventtimer would have to be emulated with NONE. > >> machdep.disable_rtc_set="1" >> kern.eventtimer.timer2="HPET" >> kern.eventtimer.timer1="NONE" (Or, if available, HPET1, ...) > > So, what was actually used here? > I don't think that NONE is a good idea. Doug will have to answer that -- he wasn't specific in his reply. >> kern.eventtimer.singlemul="1" >> >> sysctl.conf: >> kern.timecounter.hardware=HPET >> >> and reported that it did not help. The HPET doesn't usually suffer >> from the problem that you are describing, right? > > Right. > Still I would prefer that Doug would do the cleaner experiment(s) that I > suggested. And if the problem persists then elimination of LAPIC timer > would > make the picture clearer (for me). Sure, let's see if restraining the C-states yields any results. > > P.S. > I still think that KTR+schedgraph would be the best tool here. Attilio recommended that originally, then (reportedly) changed his mind and said to try dtrace. I brought it up again earlier, and Doug said that he would make some experiments. b. From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 15:28:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B3C10656A5 for ; Sat, 21 Aug 2010 15:28:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DAB938FC0C for ; Sat, 21 Aug 2010 15:28:45 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA17441; Sat, 21 Aug 2010 18:28:43 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ompzu-0006cr-TK; Sat, 21 Aug 2010 18:28:43 +0300 Message-ID: <4C6FF0A9.9020809@icyb.net.ua> Date: Sat, 21 Aug 2010 18:28:41 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 15:28:46 -0000 on 21/08/2010 16:04 b. f. said the following: > Andriy Gapon wrote: >> on 21/08/2010 12:35 Andriy Gapon said the following: >>> I feel like you might be having a problem with clocks... >> FWIW, I am reading this document http://edc.intel.com/Link.aspx?id=1484 >> and I see this sentence: "All of the clocks in the processor core are >> stopped in the C3 state". >> >> I see that you have C3 state enabled and it's regularly entered: >> dev.cpu.0.cx_usage: 0.00% 5.51% 94.48% last 305us > > I don't think this accounts for all of his problems, unless his > machine has an unusual configuration. Well, let's try to not muddy the waters prematurely. > Alexander and I recommended > that he try different clocks, and just recently, for example, he wrote > that he had used: > > loader.conf > hint.apic.0.clock="0" > hint.atrtc.0.clock="0" > hint.attimer.0.clock="0" > hint.hpet.0.legacy_route="1" Well, I don't see much point in doing the above in this situation. > machdep.disable_rtc_set="1" > kern.eventtimer.timer2="HPET" > kern.eventtimer.timer1="NONE" (Or, if available, HPET1, ...) So, what was actually used here? I don't think that NONE is a good idea. > kern.eventtimer.singlemul="1" > > sysctl.conf: > kern.timecounter.hardware=HPET > > and reported that it did not help. The HPET doesn't usually suffer > from the problem that you are describing, right? Right. Still I would prefer that Doug would do the cleaner experiment(s) that I suggested. And if the problem persists then elimination of LAPIC timer would make the picture clearer (for me). P.S. I still think that KTR+schedgraph would be the best tool here. -- From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 16:20:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAC4710656A7; Sat, 21 Aug 2010 16:20:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B99668FC18; Sat, 21 Aug 2010 16:20:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17948; Sat, 21 Aug 2010 19:20:19 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Omqnq-0006gY-VA; Sat, 21 Aug 2010 19:20:19 +0300 Message-ID: <4C6FFCC2.6030307@icyb.net.ua> Date: Sat, 21 Aug 2010 19:20:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Anton Shterenlikht References: <20100728161715.GA91906@mech-cluster241.men.bris.ac.uk> <4C505BE8.1050308@icyb.net.ua> <20100728164449.GA92092@mech-cluster241.men.bris.ac.uk> <4C505FFC.6000601@icyb.net.ua> <20100728171324.GB92206@mech-cluster241.men.bris.ac.uk> <4C50663B.7030203@icyb.net.ua> <20100730115753.GA9578@mech-cluster241.men.bris.ac.uk> <4C52C00E.3050400@icyb.net.ua> <20100730130237.GA9853@mech-cluster241.men.bris.ac.uk> <4C52D440.1070908@icyb.net.ua> <20100730143648.GA10259@mech-cluster241.men.bris.ac.uk> In-Reply-To: <20100730143648.GA10259@mech-cluster241.men.bris.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lstewart@freebsd.org, Gavin Atkinson , freebsd-current@freebsd.org Subject: Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 16:20:25 -0000 on 30/07/2010 17:36 Anton Shterenlikht said the following: > On Fri, Jul 30, 2010 at 04:31:44PM +0300, Andriy Gapon wrote: >> Just a one thing to try - can you please add hdac_reset(sc, 1) call in >> hdac_attach() right before hdac_get_capabilities() call? >> The idea is to reset the controller before trying to get its capabilities. > > OSS became 1, no other change: > > % dmesg | fgrep -i hda > hdac0: irq 16 at device 20.2 on pci0 > hdac0: HDA Driver Revision: 20100226_0142 > hdac0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xb7fb0000 > hdac0: [MPSAFE] > hdac0: [ITHREAD] > hdac0: hdac_get_capabilities: Invalid corb size (0) > hdac0: Resetting corb size to 256 > hdac0: hdac_get_capabilities: Invalid rirb size (0) > hdac0: Resetting rirb size to 256 > hdac0: Caps: OSS 1, ISS 0, BSS 0, NSDO 1, CORB 256, RIRB 256 > hdac0: Just a notice that I don't have any further ideas, sorry. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 17:49:51 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A091065674 for ; Sat, 21 Aug 2010 17:49:51 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D0BAE8FC08 for ; Sat, 21 Aug 2010 17:49:50 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id AEA0A6106 for ; Sat, 21 Aug 2010 13:49:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1282412989; bh=aMGOzREpJiFhcaxhVjIEUotyarKdHWGw2ciSD4P1mv8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=W41ZsANZsfzGQ+hS5hPrNawBErYXiuCuy2FEhv5zMPrEFBV6cZlNESCM69mVCK4sy Rt82WeWObBvREZA2HgokzE+uCQEAyRQ0HCHecP3HKaNxM4DO00LR3jlRCXPpXvX DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type; b=CtneEita9JSUM7vNJIpWpE8d7NrH5EcNz2hDylV8QWoM/k48yo/u7M9IvpmU1L/ke 03FKJ+6gHS5o3YEM+aucHh2KJClphZzaSpg99p6W6GZ4Gd5Kh6UXEY4f1X4ZjPv Message-ID: <4C7011B9.4020902@protected-networks.net> Date: Sat, 21 Aug 2010 13:49:45 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------070801000609050702020602" Cc: Subject: softupdate with journal panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 17:49:51 -0000 This is a multi-part message in MIME format. --------------070801000609050702020602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit While updating sysutils/coreutils port on -current as of this morning (SVN r211550), I noted a panic during the directory rename config test. I disabled the journal and the test succeeded without a panic. Abbreviated core.txt is attached, imb --------------070801000609050702020602 Content-Type: text/plain; name="core.txt.4" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="core.txt.4" toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 Sat Aug 21 13:27:54 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #22 r211550M: Sat Aug 21 07:49:50 EDT 2010 root@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x18 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08da5c5 stack pointer = 0x28:0xe8d65870 frame pointer = 0x28:0xe8d65878 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 49855 (conftest) trap number = 12 panic: page fault cpuid = 1 Uptime: 4h35m14s Physical memory: 3049 MB Dumping 305 MB: 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc066b627 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc066ba18 in panic (fmt=0x104
) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc098a5cf in trap_fatal (frame=0xe8d65830, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:941 #4 0xc098a939 in trap_pfault (frame=0xe8d65830, usermode=0, eva=24) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:854 #5 0xc098adc7 in trap (frame=0xe8d65830) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:529 #6 0xc097363c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:166 #7 0xc08da5c5 in free_jremref (jremref=0x0) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:3569 #8 0xc08e4ef3 in cancel_diradd (dap=0xce4d1e40, dirrem=0xcba243c0, jremref=0x0, dotremref=0xc9c0d440, dotdotremref=0x0) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:6774 #9 0xc08e514f in newdirrem (bp=0xda12ecec, dp=0xc9c0d440, ip=0xcd20a32c, isrmdir=1, prevdirremp=0xe8d65914) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:7197 #10 0xc08e560b in softdep_setup_directory_change (bp=0xda12ecec, dp=0xcd354a6c, ip=0xcd20a32c, newinum=10389760, isrmdir=1) at /usr/home/imb/svn/head/sys/ufs/ffs/ffs_softdep.c:7263 #11 0xc08f8c76 in ufs_dirrewrite (dp=0xcd354a6c, oip=0xcd20a32c, newinum=10389760, newtype=4, isrmdir=1) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:1304 #12 0xc0904757 in ufs_rename (ap=0xe8d65be8) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_vnops.c:1429 #13 0xc09a7287 in VOP_RENAME_APV (vop=0xc0ab7720, a=0xe8d65be8) at vnode_if.c:1474 #14 0xc070daeb in kern_renameat (td=0xc7117b00, oldfd=-100, old=0x8048511
, newfd=-100, new=0x8048505
, pathseg=UIO_USERSPACE) at vnode_if.h:636 #15 0xc070db51 in kern_rename (td=0xc7117b00, from=0x8048511
, to=0x8048505
, pathseg=UIO_USERSPACE) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:3574 #16 0xc070db7c in rename (td=0xc7117b00, uap=0xe8d65cec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:3551 #17 0xc06a93c7 in syscallenter (td=0xc7117b00, sa=0xe8d65ce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #18 0xc098a99c in syscall (frame=0xe8d65d28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1056 #19 0xc09736a1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:264 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) --------------070801000609050702020602-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 19:25:19 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F97610656A5 for ; Sat, 21 Aug 2010 19:25:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B36438FC1A for ; Sat, 21 Aug 2010 19:25:18 +0000 (UTC) Received: (qmail 29081 invoked by uid 399); 21 Aug 2010 19:25:17 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Aug 2010 19:25:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C70281D.9030907@FreeBSD.org> Date: Sat, 21 Aug 2010 12:25:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100807 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andriy Gapon References: <4C6F772A.5020703@icyb.net.ua> <4C6F7BD1.4030009@icyb.net.ua> <4C6F9DD4.3050205@icyb.net.ua> In-Reply-To: <4C6F9DD4.3050205@icyb.net.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Latest intr problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 19:25:19 -0000 On 08/21/2010 02:35, Andriy Gapon wrote: > BTW, if you run procstat -k 11 a few times during the condition, does TID 100006 > typically have or not have "lock_mtx softclock" substring in its stack? Not. I ran 'procstat -k 11 | grep 100006' about 20 times, and all but one looked like this: 11 100006 intr swi4: clock mi_switch ithread_loop fork_exit fork_trampoline The one that didn't looked like this: 11 100006 intr swi4: clock mi_switch turnstile_wait _mtx_lock_sleep _mtx_lock_flags lock_mtx softclock intr_event_execute_handlers ithread_loop fork_exit fork_trampoline It just ran away again with the only change being cx_lowest=C1. I'll try changing the event timer next. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 20:41:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BE97106564A; Sat, 21 Aug 2010 20:41:45 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id D5D608FC15; Sat, 21 Aug 2010 20:41:44 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Omusp-0003Us-FJ; Sat, 21 Aug 2010 21:41:43 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Omuso-0000y5-Pt; Sat, 21 Aug 2010 21:41:42 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o7LKfgIp086799; Sat, 21 Aug 2010 21:41:42 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o7LKfgqO086798; Sat, 21 Aug 2010 21:41:42 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Sat, 21 Aug 2010 21:41:42 +0100 From: Anton Shterenlikht To: Andriy Gapon Message-ID: <20100821204142.GE82621@mech-cluster241.men.bris.ac.uk> References: <20100728164449.GA92092@mech-cluster241.men.bris.ac.uk> <4C505FFC.6000601@icyb.net.ua> <20100728171324.GB92206@mech-cluster241.men.bris.ac.uk> <4C50663B.7030203@icyb.net.ua> <20100730115753.GA9578@mech-cluster241.men.bris.ac.uk> <4C52C00E.3050400@icyb.net.ua> <20100730130237.GA9853@mech-cluster241.men.bris.ac.uk> <4C52D440.1070908@icyb.net.ua> <20100730143648.GA10259@mech-cluster241.men.bris.ac.uk> <4C6FFCC2.6030307@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6FFCC2.6030307@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: lstewart@freebsd.org, Gavin Atkinson , Anton Shterenlikht , freebsd-current@freebsd.org Subject: Re: amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 20:41:45 -0000 On Sat, Aug 21, 2010 at 07:20:18PM +0300, Andriy Gapon wrote: > on 30/07/2010 17:36 Anton Shterenlikht said the following: > > On Fri, Jul 30, 2010 at 04:31:44PM +0300, Andriy Gapon wrote: > >> Just a one thing to try - can you please add hdac_reset(sc, 1) call in > >> hdac_attach() right before hdac_get_capabilities() call? > >> The idea is to reset the controller before trying to get its capabilities. > > > > OSS became 1, no other change: > > > > % dmesg | fgrep -i hda > > hdac0: irq 16 at device 20.2 on pci0 > > hdac0: HDA Driver Revision: 20100226_0142 > > hdac0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0xb7fb0000 > > hdac0: [MPSAFE] > > hdac0: [ITHREAD] > > hdac0: hdac_get_capabilities: Invalid corb size (0) > > hdac0: Resetting corb size to 256 > > hdac0: hdac_get_capabilities: Invalid rirb size (0) > > hdac0: Resetting rirb size to 256 > > hdac0: Caps: OSS 1, ISS 0, BSS 0, NSDO 1, CORB 256, RIRB 256 > > hdac0: > > Just a notice that I don't have any further ideas, sorry. ok, many thanks I might be back if I get a different message in future. manton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 21:05:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DE0010656A3; Sat, 21 Aug 2010 21:05:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 319038FC17; Sat, 21 Aug 2010 21:05:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o7LL5Y9x094741; Sat, 21 Aug 2010 17:05:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o7LL5YrX094740; Sat, 21 Aug 2010 21:05:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 21 Aug 2010 21:05:34 GMT Message-Id: <201008212105.o7LL5YrX094740@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 21:05:35 -0000 TB --- 2010-08-21 18:50:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-21 18:50:21 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-21 18:50:21 - cleaning the object tree TB --- 2010-08-21 18:51:11 - cvsupping the source tree TB --- 2010-08-21 18:51:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-21 18:51:43 - building world TB --- 2010-08-21 18:51:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 18:51:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 18:51:43 - TARGET=powerpc TB --- 2010-08-21 18:51:43 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 18:51:43 - TZ=UTC TB --- 2010-08-21 18:51:43 - __MAKE_CONF=/dev/null TB --- 2010-08-21 18:51:43 - cd /src TB --- 2010-08-21 18:51:43 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 21 18:51:44 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Aug 21 20:34:59 UTC 2010 TB --- 2010-08-21 20:34:59 - generating LINT kernel config TB --- 2010-08-21 20:34:59 - cd /src/sys/powerpc/conf TB --- 2010-08-21 20:34:59 - /usr/bin/make -B LINT TB --- 2010-08-21 20:34:59 - building LINT kernel TB --- 2010-08-21 20:34:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 20:34:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 20:34:59 - TARGET=powerpc TB --- 2010-08-21 20:34:59 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 20:34:59 - TZ=UTC TB --- 2010-08-21 20:34:59 - __MAKE_CONF=/dev/null TB --- 2010-08-21 20:34:59 - cd /src TB --- 2010-08-21 20:34:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 21 20:35:00 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Aug 21 21:00:12 UTC 2010 TB --- 2010-08-21 21:00:12 - building GENERIC kernel TB --- 2010-08-21 21:00:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-21 21:00:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-21 21:00:12 - TARGET=powerpc TB --- 2010-08-21 21:00:12 - TARGET_ARCH=powerpc64 TB --- 2010-08-21 21:00:12 - TZ=UTC TB --- 2010-08-21 21:00:12 - __MAKE_CONF=/dev/null TB --- 2010-08-21 21:00:12 - cd /src TB --- 2010-08-21 21:00:12 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Aug 21 21:00:13 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-21 21:05:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-21 21:05:34 - ERROR: failed to build GENERIC kernel TB --- 2010-08-21 21:05:34 - 5648.34 user 1537.88 system 8112.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 21:54:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DE610656A5; Sat, 21 Aug 2010 21:54:11 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 450D58FC16; Sat, 21 Aug 2010 21:54:10 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 96AA11FFC34; Sat, 21 Aug 2010 21:54:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 498BD8454D; Sat, 21 Aug 2010 23:54:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Whitehorn References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> <86fwy9f5vj.fsf@ds4.des.no> <4C6F0813.9030007@freebsd.org> Date: Sat, 21 Aug 2010 23:54:08 +0200 In-Reply-To: <4C6F0813.9030007@freebsd.org> (Nathan Whitehorn's message of "Fri, 20 Aug 2010 17:56:19 -0500") Message-ID: <86aaofpr7j.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 21:54:11 -0000 Nathan Whitehorn writes: > I'm the first to admit that many of the config tricks involved in this > port, and GENERIC64, are ugly hacks, largely because config(8) was not > designed with such things in mind. It's not just "config tricks and ugly hacks", it also violates the assumption that target names are unique. > To address the immediate problem, I think the best solution is to use > the -m option to config to reject kernel configs for different > architectures, I'm not sure I understand what you mean (or rather, how it would help the tinderbox). What *would* help would be an easy way to determine, *before* trying to build it, whether a specific kernel config is appropriate for a specific target. Can you think of an easier way to do this than to scan the config for the "machine" line? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 22:01:57 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4D32106567A; Sat, 21 Aug 2010 22:01:57 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id A58E38FC0A; Sat, 21 Aug 2010 22:01:57 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 87734582C9; Sat, 21 Aug 2010 17:01:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 9PtLQtbwBQDu; Sat, 21 Aug 2010 17:01:56 -0500 (CDT) Received: from wanderer.tachypleus.net (adsl-76-208-70-144.dsl.mdsnwi.sbcglobal.net [76.208.70.144]) by mail.icecube.wisc.edu (Postfix) with ESMTP id CEB79582C5; Sat, 21 Aug 2010 17:01:55 -0500 (CDT) Message-ID: <4C704CD2.9040604@freebsd.org> Date: Sat, 21 Aug 2010 17:01:54 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.11) Gecko/20100727 Thunderbird/3.0.6 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> <86fwy9f5vj.fsf@ds4.des.no> <4C6F0813.9030007@freebsd.org> <86aaofpr7j.fsf@ds4.des.no> In-Reply-To: <86aaofpr7j.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 22:01:58 -0000 On 08/21/10 16:54, Dag-Erling Smørgrav wrote: > Nathan Whitehorn writes: > >> I'm the first to admit that many of the config tricks involved in this >> port, and GENERIC64, are ugly hacks, largely because config(8) was not >> designed with such things in mind. >> > It's not just "config tricks and ugly hacks", it also violates the > assumption that target names are unique. > This was discussed on arch several months ago. Breaking that assumption seems much better, in the long term, than any of the alternatives in order to accomodate mips[64][el|eb], arm[eb], powerpc[64], and any other similar situations we may run into in the future. Sharing an include/machine directory, which is a side effect, also means that things like cc -m32 work out of the box. >> To address the immediate problem, I think the best solution is to use >> the -m option to config to reject kernel configs for different >> architectures, >> > I'm not sure I understand what you mean (or rather, how it would help > the tinderbox). What *would* help would be an easy way to determine, > *before* trying to build it, whether a specific kernel config is > appropriate for a specific target. Can you think of an easier way to do > this than to scan the config for the "machine" line? > That's exactly what I proposed. You use config, before trying the build, to look up the machine specification for the config file. I sent you a 5 line patch to tinderbox.pl that does this by private email. Other alternatives would be having sys/$MACHINE/conf.$MACHINE_ARCH directories or something, but that invites far more breakage. -Nathan