From owner-freebsd-current@FreeBSD.ORG Sat Jul 17 22:43: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 C5EAF1065673 for ; Sat, 17 Jul 2010 22:43:58 +0000 (UTC) (envelope-from fabiokaminski@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 823548FC19 for ; Sat, 17 Jul 2010 22:43:58 +0000 (UTC) Received: by qyk7 with SMTP id 7so1625083qyk.13 for ; Sat, 17 Jul 2010 15:43:57 -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=AnilCsgFn91YsauhX2GJ8BIxHCQXcaaVco2kcLjKT6I=; b=g+7n7vD+phV61pm8JPicuLB0WjdWB5hNUV4UxDErIGL2UtEkD+BcWZUe0S+sDdwHKu NA5mu7hEWMhwpbXeGNAC71KvzpM8w17S2hn9eYAdrrPA3fL1Kk/oM50uwyqWwlWyCbWR t5sy/Yq/l/YxWLVV2Hfpp6WgtiiNfC/ytkPPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Wj7T2/DC/hG3Z5ktAEhdx3jA+qXGE2kxGK5BuJ774kAu1F1/7zoBl/DDvDdMu88X7E hTO2P3PFdC5Hp/tQ4CwhuvFxUOnjX5YvpyFtESLLWx939s3xpA0Wwtb/rx9h0d0OFa6N Vdzr6RFahK75PPJ7yfuRHfNJmUP1TK3CzGQbE= MIME-Version: 1.0 Received: by 10.224.80.2 with SMTP id r2mr2314341qak.380.1279405023792; Sat, 17 Jul 2010 15:17:03 -0700 (PDT) Received: by 10.229.228.199 with HTTP; Sat, 17 Jul 2010 15:17:03 -0700 (PDT) Date: Sat, 17 Jul 2010 19:17:03 -0300 Message-ID: From: Fabio Kaminski To: freebsd-current@freebsd.org X-Mailman-Approved-At: Sun, 18 Jul 2010 00:25:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: sensitive emt64 performance degradation over amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Jul 2010 22:43:59 -0000 Hello list, im running two freebsd dists , each one in a diferent notebook.. i have a freebsd 8.1 rc2 running in amd64 with 2 cores 2MB mem.. (my old hp), and a freebsd 9-current running on a intel i3 (2 cores + 2 logical cores) with 4 MB ram.. and im was noting that the amd notebook was performing really fast compared to the i3.. even with for each core of i3 the clock been superior to the amd that i got here... i was looking to the kernel build and disable all the debug options from the 9 / kernel before the SMP option.. to see if it was the performance penalty cause... but that doesnt help to much... i didnt find any cpu flag to build the kernel specific to the intel arquitecture and leave the HAMMER option alone, knowing that emt64 and amd64 pretty the same thing... what could be happening... the biggest number of cores? .. or its a common thing... freebsd perform better on amd hardware... (note that i cant be too precise , since i didnt go any further with more tests... its more a subjective feel (boot time, general use.. etc)) Thanks, Fabio Kaminski From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 08:14: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 A25BC1065673 for ; Sun, 18 Jul 2010 08:14: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 E1C348FC18 for ; Sun, 18 Jul 2010 08:14:46 +0000 (UTC) Received: (qmail 23471 invoked by uid 399); 18 Jul 2010 08:14:44 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jul 2010 08:14:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 18 Jul 2010 01:14:41 -0700 (PDT) From: Doug Barton To: Kostik Belousov In-Reply-To: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.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, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 08:14:47 -0000 On Sat, 17 Jul 2010, Kostik Belousov wrote: > Run top in the mode where all system threads are shown separately > (e.g. top -HS seems to do it), then watch what thread eats the processor. And the winner is! 11 root -32 - 0K 168K WAIT 0 0:28 18.02% {swi4: clock} 11 root 21 -64 - 0K 168K WAIT 0 1:17 18.90% intr The first is with -H, the second without. 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 Jul 18 10:19: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 30972106567C; Sun, 18 Jul 2010 10:19:36 +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 8E44D8FC15; Sun, 18 Jul 2010 10:19:34 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o6IAJW9k080898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Jul 2010 12:19:33 +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.3/8.14.3) with ESMTP id o6IAJLxp028944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 12:19:21 +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 o6IAJLqr023194; Sun, 18 Jul 2010 12:19:21 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o6IAJLBp023193; Sun, 18 Jul 2010 12:19:21 +0200 (CEST) (envelope-from ticso) Date: Sun, 18 Jul 2010 12:19:21 +0200 From: Bernd Walter To: Kostik Belousov Message-ID: <20100718101920.GC17125@cicely7.cicely.de> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> 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=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Doug Barton , Rui Paulo , freebsd-current@freebsd.org Subject: Re: Why is intr taking up so much cpu? 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: Sun, 18 Jul 2010 10:19:36 -0000 On Sat, Jul 17, 2010 at 10:21:28PM +0300, Kostik Belousov wrote: > On Sat, Jul 17, 2010 at 12:10:26PM -0700, Doug Barton wrote: > > On Sat, 17 Jul 2010, Rui Paulo wrote: > > > > >This doesn't indicate any problem. I suggest you try to figure out what > > >interrupt is causing this by adding printfs or disabling drivers one by > > >one. > > > > I've no idea where to even begin on something like that. Given that > > there are other -current users who are also having problems > > (particularly with the nvidia drivers) I'm wondering if some sort of > > systemic debugging isn't in order here? > > > > Note that intr time most likely come from the interrupt threads chewing > the CPU, not from the real interrupt handlers doing something, and definitely > not due to the high interrupt rate, as your vmstat -i output already shown. I've noticed a few webpages to trigger lot of X11 related network traffic just by watching them even without any seeable content change, but CPU load on browser and especialy X process went high, but of course symptoms might be different with different drivers - I use mga myself. I never analysed it properly beacuse I'm using a quite old Xorg version, but I see the increase of traffic on the domain socket. I also noticed that recent firefox and seamonkey are doing lots of NFS traffic, so I was forced to switch ~/.mozilla to a local disk, where iostat still stays idle. But my OS is also not very recent, so I also never debugged this problem. > Run top in the mode where all system threads are shown separately > (e.g. top -HS seems to do it), then watch what thread eats the processor. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 10:30: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 3382F1065673; Sun, 18 Jul 2010 10:30:09 +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 9753D8FC0C; Sun, 18 Jul 2010 10:30:07 +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 o6IAU48c016649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 13:30:04 +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 o6IAU3Tq009437; Sun, 18 Jul 2010 13:30:03 +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 o6IAU3bZ009436; Sun, 18 Jul 2010 13:30:03 +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: Sun, 18 Jul 2010 13:30:03 +0300 From: Kostik Belousov To: Doug Barton Message-ID: <20100718103003.GO2381@deviant.kiev.zoral.com.ua> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="owpTafYe/1tj88Rh" 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.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, 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@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 10:30:09 -0000 --owpTafYe/1tj88Rh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote: > On Sat, 17 Jul 2010, Kostik Belousov wrote: >=20 > >Run top in the mode where all system threads are shown separately > >(e.g. top -HS seems to do it), then watch what thread eats the processor. >=20 > And the winner is! >=20 > 11 root -32 - 0K 168K WAIT 0 0:28 18.02% {swi4:=20 > clock} > 11 root 21 -64 - 0K 168K WAIT 0 1:17 18.90% intr >=20 > The first is with -H, the second without. Most likely it is some callout handling. Just in case, do you have console screensaver active ? --owpTafYe/1tj88Rh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxC16sACgkQC3+MBN1Mb4jgzACeMg9veXo29z7tRQrjx+HXR5I1 FjcAoIR0uBJhJkUY/v7KqpCcor3z0nzQ =1Y1d -----END PGP SIGNATURE----- --owpTafYe/1tj88Rh-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 10:51:02 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 61E411065677 for ; Sun, 18 Jul 2010 10:51:02 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 250A88FC18 for ; Sun, 18 Jul 2010 10:51:02 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id D0EFF6C81C; Sun, 18 Jul 2010 10:51:00 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20100717143003.GB62874@lordsith.net> Date: Sun, 18 Jul 2010 12:50:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80BD364B-4961-440B-B8B0-EA4301CF0634@lassitu.de> References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> <86DB038E-D49B-4793-B966-6B5D29FA3B84@lassitu.de> <20100717143003.GB62874@lordsith.net> To: Marco van Lienen X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@FreeBSD.org Subject: Re: RAIDZ capacity (was ZFS version 15 committed to head) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 10:51:02 -0000 Am 17.07.2010 um 16:30 schrieb Marco van Lienen: > I also posted the example of creating a test raidz pool based on 3 = 65Mb files. > On osol there is more available space being reported by 'zfs list' on = that test raidz pool > When I created a similar test raidz pool also based on 3 65Mb files, = 'zfs list' on my FreeBSD boxes (9.0-CURRENT amd64 and 8.0-RELEASE-p2 = i386) is showing much less available space. > So regardless whether we use whole disks or simply files for testing = purposes, 'zfs list' on the osol system is reporting more available = space. I suggest to read up on ZFS a bit more. With OpenSolaris 09.06, with three 20 GB virtual disks, I'm getting = this: root@opensolaris:~# zpool create tank raidz c8t1d0 c8t2d0 c8t3d0 root@opensolaris:~# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 59.5G 881K 59.5G 0% ONLINE - root@opensolaris:~# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 91.2K 39.0G 25.3K /tank Which is exactly the same behavior as with FreeBSD. And of course you = only get to store 40 GB worth of files on this filesystem. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 12: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 175A41065691 for ; Sun, 18 Jul 2010 12:20:25 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9998FC1D for ; Sun, 18 Jul 2010 12:20:24 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6ICKNPV012970; Sun, 18 Jul 2010 14:20:23 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6ICKN5d012969; Sun, 18 Jul 2010 14:20:23 +0200 (CEST) (envelope-from marius) Date: Sun, 18 Jul 2010 14:20:22 +0200 From: Marius Strobl To: =?unknown-8bit?Q?St=E5le?= Kristoffersen Message-ID: <20100718122022.GW4706@alchemy.franken.de> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100716103125.GA73878@putsch.kolbu.ws> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 12:20:25 -0000 On Fri, Jul 16, 2010 at 12:31:26PM +0200, Stle Kristoffersen wrote: > On 2010-07-15 at 19:52, Ståle Kristoffersen wrote: > > On 2010-07-15 at 18:00, Marius Strobl wrote: > > > On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > > > > Upgraded to from stable to current yesterday and very quickly received a > > > > panic. It did however not dump it's core, so I was unable to debug it. > > > > Today it did panic again, and I took a picture: (Sorry about the bad > > > > quality) > > > > > > > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > > > > > > > And from the backtrace: > > > > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > > > > > > > Both times I hade the mpt0: request timed out just before the panic. > > > > > > > > I'm not sure why it's not dumping it's core (It was working under stable, > > > > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) > > > > > > What revision were you using? > > > > Not sure exactly what revision I was using, is there an easy way to figure > > that out? I ran cvsupdate around 13:00 CEST yesterday. > > > > > Does using current as of r209598 make a difference? > > > > Downgrading now... > > And it crashed again, with current from r209598... > Ok, this at least means that your problem isn't caused by the recent changes to mpt(4) as the pre-r209599 version only differed from the 8-STABLE one in a cosmetic change at that time. Marius From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 12:22: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 A9EF8106567D for ; Sun, 18 Jul 2010 12:22:32 +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 648518FC1C for ; Sun, 18 Jul 2010 12:22:32 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2F0A8.dip.t-dialin.net [217.226.240.168]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 92E6784405D; Sun, 18 Jul 2010 14:22:27 +0200 (CEST) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 293A8159C; Sun, 18 Jul 2010 14:22:24 +0200 (CEST) Date: Sun, 18 Jul 2010 14:22:21 +0200 From: Alexander Leidinger To: freebsd-current@freebsd.org Message-ID: <20100718142221.00007932@unknown> In-Reply-To: <20100717105134.GB13626@lordsith.net> References: <4C3C7202.7090103@FreeBSD.org> <20100717101459.GA13626@lordsith.net> <9E4FCF4C-7A69-426E-9F39-B5487D4CB07C@lassitu.de> <20100717105134.GB13626@lordsith.net> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 92E6784405D.A628C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.846, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_YF 0.08, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1280060549.43732@JUzdzfdPESyM7pFXQCazXg X-EBL-Spam-Status: No Cc: Marco van Lienen Subject: Re: [HEADSUP] ZFS version 15 committed to head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 12:22:32 -0000 On Sat, 17 Jul 2010 12:51:34 +0200 Marco van Lienen wrote: > On Sat, Jul 17, 2010 at 12:25:56PM +0200, you (Stefan Bethke) sent > the following to the -current list: > > Am 17.07.2010 um 12:14 schrieb Marco van Lienen: > > > > > # zpool list pool1 > > > NAME SIZE USED AVAIL CAP HEALTH ALTROOT > > > pool1 5.44T 147K 5.44T 0% ONLINE - > > ... > > > zfs list however only shows: > > > # zfs list pool1 > > > NAME USED AVAIL REFER MOUNTPOINT > > > pool1 91.9K 3.56T 28.0K /pool1 > > > > > > I just lost the space of an entire hdd! > > > > zpool always shows the raw capacity (without redundancy), zfs the > > actual available capacity. > > I have read many things about those differences, but why then does > zfs on opensolaris report more available space whereas FreeBSD does > not? That would imply that my friend running osol build 117 couldn't > fill up his raidz pool past the 3.56T. If you compare the yfs list output of OSol and FreeBSD and they differ where they shouldn't, you should have a look if compression and/or deduplication (were available) is activated. Bye, Alexander. From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 13:02: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 EF1C0106567D; Sun, 18 Jul 2010 13:02:29 +0000 (UTC) (envelope-from gavin@ury.york.ac.uk) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 73B6B8FC1C; Sun, 18 Jul 2010 13:02:29 +0000 (UTC) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id o6ID2O1A012886; Sun, 18 Jul 2010 14:02:24 +0100 (BST) Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1OaTVg-0001HE-J1; Sun, 18 Jul 2010 14:02:24 +0100 Date: Sun, 18 Jul 2010 14:02:24 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: freebsd-current@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@ury.york.ac.uk Cc: jeff@FreeBSD.org Subject: Re: Filesystem wedge, SUJ-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, 18 Jul 2010 13:02:30 -0000 On Sat, 17 Jul 2010, Gavin Atkinson wrote: > Semi-regularly (every two-three days) I'm seeing what appears to be some > sort of filesystem wedge. I usually see it initially with web browsers, > but it's possible that's only because it's what produces most disk > activity on this machine. I've seen it with both Opera and Firefox. > > What happens is that the process will just wedge. A "procstat -kk" on it > shows the following stack backtrace: > > 9012 100243 firefox-bin initial thread mi_switch+0x21d > sleepq_switch+0x123 sleepq_wait+0x4d _sleep+0x357 getdirtybuf+0x21e > flush_deplist+0x6f softdep_sync_metadata+0x153 ffs_syncvnode+0x213 > ffs_fsync+0x43 fsync+0x148 syscallenter+0x1b5 syscall+0x4c > Xfast_syscall+0xe2 A bit more detail: it does look like whatever is supposed to periodically flush the journal just stops doing it's job. Presumably this is also the root cause of the "softdep: Out of journal space!" messages I have been seeing in the past, which I had assumed may have been fixed by r209717. (I'm running r209723 at the moment) While processes are starting to hang, "sh ffs" from ddb shows: db> sh ffs mp 0xffffff0002c45be0 / devvp 0xffffff0002c51000 fs 0xffffff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xffffff0002d705f0 /tmp devvp 0xffffff0002d48780 fs 0xffffff0002c64800 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xffffff0002c458e8 /usr devvp 0xffffff0002d485a0 fs 0xffffff0002c66000 su_wl 0 su_wl_in 0 su_deps 17345 su_req 0 mp 0xffffff0002c455f0 /var devvp 0xffffff0002d483c0 fs 0xffffff0002c66800 su_wl 0 su_wl_in 0 su_deps 55 su_req 0 Leaving it another couple of hours, I then see: db> sh ffs mp 0xffffff0002c45be0 / devvp 0xffffff0002c51000 fs 0xffffff0002c67000 su_wl 0 su_wl_in 0 su_deps 0 su_req 0 mp 0xffffff0002d705f0 /tmp devvp 0xffffff0002d48780 fs 0xffffff0002c64800 su_wl 0 su_wl_in 0 su_deps 36 su_req 0 mp 0xffffff0002c458e8 /usr devvp 0xffffff0002d485a0 fs 0xffffff0002c66000 su_wl 0 su_wl_in 0 su_deps 31899 su_req 0 mp 0xffffff0002c455f0 /var devvp 0xffffff0002d483c0 fs 0xffffff0002c66800 su_wl 0 su_wl_in 0 su_deps 95 su_req 0 so, su_deps is increasing significantly. During reboot, vnlru failed to stop within 60 seconds, and gave up on syncing 125 vnodes and 140 buffers (no idea if these are related). On reboot, SU+J fsck shows for /usr: ** SU+J Recovering /dev/ad4s1f ** Reading 33554432 byte journal from inode 150. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 405991 journal records in 18194944 bytes for 71.40% utilization ** Freed 3872 inodes (0 dirs) 48157 blocks, and 8744 frags. So it seems clear that somehow the journal is filling up, and never being written. Any other suggestions as to where I should go from here? Thanks, Gaivn From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 14:34: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 CD506106564A for ; Sun, 18 Jul 2010 14:34:53 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 52B3E8FC08 for ; Sun, 18 Jul 2010 14:34:53 +0000 (UTC) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1OaUx9-0002em-QD; Sun, 18 Jul 2010 16:34:51 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OaUx9-0003bG-9H; Sun, 18 Jul 2010 16:34:51 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OaUx8-0005rM-OI; Sun, 18 Jul 2010 16:34:50 +0200 Date: Sun, 18 Jul 2010 16:34:50 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: =?iso-8859-1?Q?St=E5le?= Kristoffersen Message-ID: <20100718143450.GA29150@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100716103125.GA73878@putsch.kolbu.ws> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 08548F51E483148FA44EB6B7C839CDD4464D3756 X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1729 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: freebsd-current@freebsd.org, Marius Strobl Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 14:34:53 -0000 On 2010-07-16 at 12:31, Ståle Kristoffersen wrote: > On 2010-07-15 at 19:52, Ståle Kristoffersen wrote: > > On 2010-07-15 at 18:00, Marius Strobl wrote: > > > On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: > > > > Upgraded to from stable to current yesterday and very quickly received a > > > > panic. It did however not dump it's core, so I was unable to debug it. > > > > Today it did panic again, and I took a picture: (Sorry about the bad > > > > quality) > > > > > > > > http://folk.uio.no/stalk/mpt/IMG_1403.JPG > > > > > > > > And from the backtrace: > > > > http://folk.uio.no/stalk/mpt/IMG_1404.JPG > > > > > > > > Both times I hade the mpt0: request timed out just before the panic. > > > > > > > > I'm not sure why it's not dumping it's core (It was working under stable, > > > > and I have dumpdev="AUTO" and dumpdir="/var/crash" in rc.conf) > > > > > > What revision were you using? > > > > Not sure exactly what revision I was using, is there an easy way to figure > > that out? I ran cvsupdate around 13:00 CEST yesterday. > > > > > Does using current as of r209598 make a difference? > > > > Downgrading now... > > And it crashed again, with current from r209598... It still keeps on crashing :/ I grabbed the output of show alllocks: http://folk.uio.no/stalk/mpt/IMAG0047.jpg To me it looks like maybe there is a race condition or something that makes TAILQ_REMOVE-call in mpt_scsi_tmf_reply_handler() work on an element that has been removed, but this is an un-educated guess ;) I do not understand enough of the driver to follow the flow of the requests around the driver. -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 17:35: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 88011106566B; Sun, 18 Jul 2010 17:35:49 +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 4785B8FC0C; Sun, 18 Jul 2010 17:35:46 +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 o6IHZjST062863; Sun, 18 Jul 2010 13:35:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6IHZjiE062862; Sun, 18 Jul 2010 17:35:45 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 18 Jul 2010 17:35:45 GMT Message-Id: <201007181735.o6IHZjiE062862@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/sparc64 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: Sun, 18 Jul 2010 17:35:49 -0000 TB --- 2010-07-18 16:59:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 16:59:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-07-18 16:59:15 - cleaning the object tree TB --- 2010-07-18 16:59:27 - cvsupping the source tree TB --- 2010-07-18 16:59:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-07-18 17:35:45 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 17:35:45 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 17:35:45 - 0.58 user 7.79 system 2190.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 17:43: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 104491065677; Sun, 18 Jul 2010 17:43:51 +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 C5D358FC19; Sun, 18 Jul 2010 17:43:50 +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 o6IHhou2062881; Sun, 18 Jul 2010 13:43:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6IHhoPp062880; Sun, 18 Jul 2010 17:43:50 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 18 Jul 2010 17:43:50 GMT Message-Id: <201007181743.o6IHhoPp062880@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: Sun, 18 Jul 2010 17:43:51 -0000 TB --- 2010-07-18 17:03:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 17:03:19 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-07-18 17:03:19 - cleaning the object tree TB --- 2010-07-18 17:03:30 - cvsupping the source tree TB --- 2010-07-18 17:03:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-07-18 17:43:50 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 17:43:50 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 17:43:50 - 0.52 user 6.58 system 2430.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 19:06: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 10885106566B; Sun, 18 Jul 2010 19:06:54 +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 C3C278FC1F; Sun, 18 Jul 2010 19:06:53 +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 o6IJ6qMM063167; Sun, 18 Jul 2010 15:06:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o6IJ6qBI063166; Sun, 18 Jul 2010 19:06:52 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 18 Jul 2010 19:06:52 GMT Message-Id: <201007181906.o6IJ6qBI063166@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/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: Sun, 18 Jul 2010 19:06:54 -0000 TB --- 2010-07-18 16:56:36 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-18 16:56:36 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-07-18 16:56:36 - cleaning the object tree TB --- 2010-07-18 16:56:52 - cvsupping the source tree TB --- 2010-07-18 16:56:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-07-18 19:06:52 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-07-18 19:06:52 - ERROR: unable to cvsup the source tree TB --- 2010-07-18 19:06:52 - 0.85 user 8.25 system 7816.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 19:21:02 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 BC3281065673 for ; Sun, 18 Jul 2010 19:21:02 +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 5C2508FC14 for ; Sun, 18 Jul 2010 19:21:02 +0000 (UTC) Received: (qmail 8442 invoked by uid 399); 18 Jul 2010 19:21:01 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jul 2010 19:21:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C43541C.3060101@FreeBSD.org> Date: Sun, 18 Jul 2010 12:21:00 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100718 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kostik Belousov References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100718103003.GO2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 19:21:02 -0000 On 07/18/10 03:30, Kostik Belousov wrote: > On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote: >> On Sat, 17 Jul 2010, Kostik Belousov wrote: >> >>> Run top in the mode where all system threads are shown separately >>> (e.g. top -HS seems to do it), then watch what thread eats the processor. >> >> And the winner is! >> >> 11 root -32 - 0K 168K WAIT 0 0:28 18.02% {swi4: >> clock} >> 11 root 21 -64 - 0K 168K WAIT 0 1:17 18.90% intr >> >> The first is with -H, the second without. > > Most likely it is some callout handling. Just in case, do you have > console screensaver active ? I assume you mean "saver=yes" in rc.conf, and the answer is no, I am not using that. Usually I run xscreensaver, but at the time this happened I was not. I do have DPMS enabled in my X config though. Any suggestions on how to dig deeper on this? Are there any settings I can twiddle to try and mitigate it? Doug -- ... 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 Sun Jul 18 19:21: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 045CB106564A for ; Sun, 18 Jul 2010 19:21:42 +0000 (UTC) (envelope-from fabiokaminski@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 B3EAB8FC1E for ; Sun, 18 Jul 2010 19:21:41 +0000 (UTC) Received: by qyk7 with SMTP id 7so2086114qyk.13 for ; Sun, 18 Jul 2010 12:21:41 -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=2x28uP5d3Tw7f4JWtqXQX93Zk4EjJ7Hgse1T5C2Tmc8=; b=wzkiF4rCuqh/Rrf7xFdR6iCECdRK//sujUkXkzO6RTz8AU1b+RI76f1Ktz3sIUllz+ +aSx+G8R2SUJclTT1l7fYvWn62lKb6tCmtZQUnih2XSk568bOeUhdPIiN4QUQc0zqSrh jJH/sZALw0BaW/qjmXuKRV+Trf6MQHVMQdMZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TvPBMO3JC/74xDiP/DXjrTgRI7mK2di1Z1jHQut0fBrtAM26oCHpF+29XNrmW+ZRPu ss43eoXmtq13Tw8KfMSnFW25iPO8prUVAeUJ4rLwPUzJdA35nwRWfFFXZ+CxAnsTeMd1 rW3RrqrGp1O0Gkll2NSAh7aLq8jngXdOeCQiU= MIME-Version: 1.0 Received: by 10.224.59.145 with SMTP id l17mr3200712qah.287.1279480900848; Sun, 18 Jul 2010 12:21:40 -0700 (PDT) Received: by 10.229.228.199 with HTTP; Sun, 18 Jul 2010 12:21:40 -0700 (PDT) Date: Sun, 18 Jul 2010 16:21:40 -0300 Message-ID: From: Fabio Kaminski To: freebsd-current@freebsd.org X-Mailman-Approved-At: Sun, 18 Jul 2010 19:29:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: emt64 performance degradation over amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 19:21:42 -0000 Hello list, im running two freebsd dists , each one in a diferent notebook.. i have a freebsd 8.1 rc2 running in amd64 with 2 cores 2MB mem.. (my old hp), and a freebsd 9-current running on a intel i3 (2 cores + 2 logical cores) with 4 MB ram.. and im was noting that the amd notebook was performing really fast compared to the i3.. even with for each core of i3 the clock been superior to the amd that i got here... i was looking to the kernel build and disable all the debug options from the 9 / kernel before the SMP option.. to see if it was the performance penalty cause... but that doesnt help to much... i didnt find any cpu flag to build the kernel specific to the intel arquitecture and leave the HAMMER option alone, knowing that emt64 and amd64 pretty the same thing... what could be happening... the biggest number of cores? .. or its a common thing... freebsd perform better on amd hardware... (note that i cant be too precise , since i didnt go any further with more tests... its more a subjective feel (boot time, general use.. etc)) Thanks, Fabio Kaminski From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 19:41: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 00E201065677; Sun, 18 Jul 2010 19:41:18 +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 662A28FC0C; Sun, 18 Jul 2010 19:41:16 +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 o6IJf99o053534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 22:41:09 +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 o6IJf96V029318; Sun, 18 Jul 2010 22:41:09 +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 o6IJf92o029317; Sun, 18 Jul 2010 22:41:09 +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: Sun, 18 Jul 2010 22:41:09 +0300 From: Kostik Belousov To: Doug Barton Message-ID: <20100718194109.GU2381@deviant.kiev.zoral.com.ua> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fh5LqGQwq8YwuKb/" Content-Disposition: inline In-Reply-To: <4C43541C.3060101@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.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@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 19:41:18 -0000 --Fh5LqGQwq8YwuKb/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2010 at 12:21:00PM -0700, Doug Barton wrote: > On 07/18/10 03:30, Kostik Belousov wrote: > > On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote: > >> On Sat, 17 Jul 2010, Kostik Belousov wrote: > >> > >>> Run top in the mode where all system threads are shown separately > >>> (e.g. top -HS seems to do it), then watch what thread eats the proces= sor. > >> > >> And the winner is! > >> > >> 11 root -32 - 0K 168K WAIT 0 0:28 18.02% {swi4:= =20 > >> clock} > >> 11 root 21 -64 - 0K 168K WAIT 0 1:17 18.90% intr > >> > >> The first is with -H, the second without. > > > > Most likely it is some callout handling. Just in case, do you have > > console screensaver active ? >=20 > I assume you mean "saver=3Dyes" in rc.conf, and the answer is no, I am not > using that. Usually I run xscreensaver, but at the time this happened I > was not. I do have DPMS enabled in my X config though. >=20 > Any suggestions on how to dig deeper on this? Are there any settings I > can twiddle to try and mitigate it? When intr time starts accumulating again, try to do "procstat -kk " and correlate the clock thread tid with the backtrace. Might be, it helps to guess what callouts are eating the CPU. --Fh5LqGQwq8YwuKb/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxDWNUACgkQC3+MBN1Mb4heCACfbleQu3vugDcaJP9F7TFUlzSM Gq8AoPGaORB+Ed1MIqxiSSilYND2uH2q =Yglp -----END PGP SIGNATURE----- --Fh5LqGQwq8YwuKb/-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 19:57: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 EF3951065670 for ; Sun, 18 Jul 2010 19:57:52 +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 76FC28FC0A for ; Sun, 18 Jul 2010 19:57:52 +0000 (UTC) Received: (qmail 20447 invoked by uid 399); 18 Jul 2010 19:57:51 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jul 2010 19:57:51 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C435CBE.50500@FreeBSD.org> Date: Sun, 18 Jul 2010 12:57:50 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100718 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kostik Belousov References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100718194109.GU2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 19:57:53 -0000 On 07/18/10 12:41, Kostik Belousov wrote: > When intr time starts accumulating again, try to do > "procstat -kk " and correlate the clock thread tid > with the backtrace. Might be, it helps to guess what callouts are eating > the CPU. Will do, thanks! Doug -- ... 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 Sun Jul 18 20:31: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 280AE1065670 for ; Sun, 18 Jul 2010 20:31:14 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id C07E58FC0A for ; Sun, 18 Jul 2010 20:31:13 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o6IKVCuZ073755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Jul 2010 15:31:13 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o6IKVCUA034249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Jul 2010 15:31:12 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o6IKNcni010225; Sun, 18 Jul 2010 15:23:38 -0500 (CDT) (envelope-from dan) Date: Sun, 18 Jul 2010 15:23:38 -0500 From: Dan Nelson To: Doug Barton Message-ID: <20100718202338.GI5485@dan.emsphone.com> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C435CBE.50500@FreeBSD.org> X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Sun, 18 Jul 2010 15:31:13 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Kostik Belousov , freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 20:31:14 -0000 In the last episode (Jul 18), Doug Barton said: > On 07/18/10 12:41, Kostik Belousov wrote: > > When intr time starts accumulating again, try to do > > "procstat -kk " and correlate the clock thread tid > > with the backtrace. Might be, it helps to guess what callouts are eating > > the CPU. > > Will do, thanks! You can also use dtrace to get a count of callouts and their time spent. Run this for a few seconds then hit ^C: #! /usr/sbin/dtrace -s /* #pragma D option quiet */ callout_execute:::callout_start { this->start = timestamp; } callout_execute:::callout_end { this->end = timestamp; /* printf("%a %d\n",args[0]->c_func, this->end - this->start); */ @times[args[0]->c_func] = quantize(this->end - this->start); /* @times[args[0]->c_func] = lquantize(this->end - this->start,0,300000,10000); */ @counts[args[0]->c_func] = count(); } END { printa("%a %@u\n",@times); printa("%a %@u\n",@counts); } -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 21:01: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 3BF941065672 for ; Sun, 18 Jul 2010 21:01:44 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id EE7628FC0C for ; Sun, 18 Jul 2010 21:01:43 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o6IL1h0i076753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Jul 2010 16:01:43 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o6IL1gLR007899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Jul 2010 16:01:43 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o6IKra7t083330; Sun, 18 Jul 2010 15:53:37 -0500 (CDT) (envelope-from dan) Date: Sun, 18 Jul 2010 15:53:36 -0500 From: Dan Nelson To: Doug Barton Message-ID: <20100718205336.GJ5485@dan.emsphone.com> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100718202338.GI5485@dan.emsphone.com> X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Sun, 18 Jul 2010 16:01:43 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Kostik Belousov , freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 21:01:44 -0000 In the last episode (Jul 18), Dan Nelson said: > In the last episode (Jul 18), Doug Barton said: > > On 07/18/10 12:41, Kostik Belousov wrote: > > > When intr time starts accumulating again, try to do > > > "procstat -kk " and correlate the clock thread tid > > > with the backtrace. Might be, it helps to guess what callouts are eating > > > the CPU. > > > > Will do, thanks! > > You can also use dtrace to get a count of callouts and their time spent. > Run this for a few seconds then hit ^C: That may actually be too verbose (you'll get a histogram per callout). Try the ones at http://wiki.freebsd.org/DTrace/Examples instead. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 21:18: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 A511E1065674; Sun, 18 Jul 2010 21:18:14 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1393E8FC18; Sun, 18 Jul 2010 21:18:13 +0000 (UTC) Received: from [95.132.104.252] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oab0D-0009g4-P5; Mon, 19 Jul 2010 00:02:28 +0300 Received: from levsha by laptop.levsha.me with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oaazi-000PeW-Pl; Mon, 19 Jul 2010 00:01:54 +0300 Date: Mon, 19 Jul 2010 00:01:54 +0300 From: Mykola Dzham To: freebsd-current@FreeBSD.org Message-ID: <20100718210154.GA94088@laptop.levsha.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 95.132.104.252 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false Cc: imp@freebsd.org Subject: Can't make distribution TARGET_ARCH=... after r209510 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 21:18:14 -0000 Hi! Attemt to make jail with different target arch on tinderbox (i386 jail on amd64 host) exits with error: ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/dis= tribution.tmp Last lines from log: cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distributi= on install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src= /etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/et= c/mail install: freebsd.cf: No such file or directory *** Error code 71 Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. *** Error code 1 Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. Full build and distribution logs avaliable on=20 http://levsha.me/tmp/20100718/world.txt (20M) http://levsha.me/tmp/20100718/distribution.txt (7.4K) Reverting r209510 fixes this problem --=20 LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 21:41: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 A5D161065672 for ; Sun, 18 Jul 2010 21:41:50 +0000 (UTC) (envelope-from emss.mail@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 F0B078FC08 for ; Sun, 18 Jul 2010 21:41:49 +0000 (UTC) Received: by wyf22 with SMTP id 22so4551643wyf.13 for ; Sun, 18 Jul 2010 14:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received :x-virus-scanned:received:received:to:cc:subject:from:in-reply-to :references:x-operating-system:date:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=YvAdCP4aYSU1RgWcrK4ODkO81UV1slN/jpMbjLCWdHM=; b=NNbnuHBKYd111W+rjOH23TWb7WWl/CDCSKLjHZz9/NQV4k1K2+doO2DTmHnMppLaNM ysit+MQ+wtHbrmUo4MrUXSGtQniFr+238iWR9lgPQUh2LUDsKgIkmj7f4zfR8PYnroMB 3B0fMoxF5SyUsIRyYer2Ln6dzr5seSRMJRTHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:x-virus-scanned:to:cc:subject:from:in-reply-to:references :x-operating-system:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; b=rHyQpPz6KeJVj9LSPvxMn7SFF7kfBs0LNtZqMhYQfXcAuxGaoVg6SxGKUx4tbsDLqn wDYeFTYvV26ZIPQYArwV/lwFN9WT7dl2YO1kdnEahjWnnSvDZyRNsR1qyfGrXNg1ZYc8 mRvJR+ZLfumlqy8TXIXiuqmksmzDdvCHmjOpY= Received: by 10.216.178.199 with SMTP id f49mr2940910wem.110.1279489308551; Sun, 18 Jul 2010 14:41:48 -0700 (PDT) Received: from srvbsdfenssv.interne.associated-bears.org (LCaen-151-92-21-48.w217-128.abo.wanadoo.fr [217.128.200.48]) by mx.google.com with ESMTPS id p82sm1914142weq.3.2010.07.18.14.41.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Jul 2010 14:41:46 -0700 (PDT) Sender: Eric Masson Received: from srvbsdfenssv.interne.associated-bears.org (localhost [127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (Postfix) with ESMTP id 0D29C1D0F8; Sun, 18 Jul 2010 23:41:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at interne.associated-bears.org Received: from srvbsdfenssv.interne.associated-bears.org ([127.0.0.1]) by srvbsdfenssv.interne.associated-bears.org (srvbsdfenssv.interne.associated-bears.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zmYn4KFna-H; Sun, 18 Jul 2010 23:41:42 +0200 (CEST) Received: by srvbsdfenssv.interne.associated-bears.org (Postfix, from userid 1001) id 3B7781D0F1; Sun, 18 Jul 2010 23:41:42 +0200 (CEST) To: Ivan Voras From: Eric Masson In-Reply-To: (Ivan Voras's message of "Thu, 08 Jul 2010 17:17:42 +0200") References: <4C31C71C.2010606@FreeBSD.org> <4C34A593.7060101@dataix.net> <4C34C567.2030408@FreeBSD.org> <86ocejjfoj.fsf@srvbsdfenssv.interne.associated-bears.org> <4C3509A2.3050700@continum.net> X-Operating-System: FreeBSD 8.1-RELEASE amd64 Date: Sun, 18 Jul 2010 23:41:42 +0200 Message-ID: <86tynweacp.fsf@srvbsdfenssv.interne.associated-bears.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 21:41:50 -0000 Ivan Voras writes: Hello Ivan, > I'm not a Solaris guy but from > http://hub.opensolaris.org/bin/view/Project+comstar/ it looks like > COMSTAR does something similar to what FreeBSD's GEOM does now. Ok. It seems to me that COMSTAR provides one functionality that GEOM misses, a generic SCSI target with plugins for different transports. It seems this overlaps with CAM. Having the same level of functionality as OSol regarding iSCSI exports of ZVols would be really nice. I plan to deploy a storage server @home and OSol seems pretty desirable in this area (native iSCSI for ZVols & smb for ZFS filesystems, all imho nicely integrated). Regards Eric Masson -- J'ai pas tout compris... Tu fais ta répartie et tu te proposes au GNU en même temps ? C'est vrai que ça mérite le GNU, mais peut-être pas pour ce que tu crois... -+- BQL in GNU : Gnutez moi, gnutez moi, gnutez moiiiii ça... -+- From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 21:43: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 116D31065670 for ; Sun, 18 Jul 2010 21:43:16 +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 C985B8FC08 for ; Sun, 18 Jul 2010 21:43:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6ILe8FW024781; Sun, 18 Jul 2010 15:40:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 18 Jul 2010 15:40:34 -0600 (MDT) Message-Id: <20100718.154034.197197260755844978.imp@bsdimp.com> To: i@levsha.me From: "M. Warner Losh" In-Reply-To: <20100718210154.GA94088@laptop.levsha.me> References: <20100718210154.GA94088@laptop.levsha.me> 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: freebsd-current@FreeBSD.org Subject: Re: Can't make distribution TARGET_ARCH=... after r209510 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 21:43:16 -0000 In message: <20100718210154.GA94088@laptop.levsha.me> Mykola Dzham writes: : Hi! : Attemt to make jail with different target arch on tinderbox (i386 jail : on amd64 host) exits with error: : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : Last lines from log: : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : install: freebsd.cf: No such file or directory : *** Error code 71 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : *** Error code 1 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : Full build and distribution logs avaliable on : http://levsha.me/tmp/20100718/world.txt (20M) : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : Reverting r209510 fixes this problem Try setting both TARGET and TARGET_ARCH. TARGET_ARCH was depricated in favor of TARGET in FreeBSD 8.0. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jul 18 23:15: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 F27411065670 for ; Sun, 18 Jul 2010 23:15:49 +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 B6C768FC0A for ; Sun, 18 Jul 2010 23:15:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6INFi4j026616; Sun, 18 Jul 2010 17:15:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 18 Jul 2010 17:16:10 -0600 (MDT) Message-Id: <20100718.171610.338707487962422543.imp@bsdimp.com> To: i@levsha.me From: "M. Warner Losh" In-Reply-To: <20100718210154.GA94088@laptop.levsha.me> References: <20100718210154.GA94088@laptop.levsha.me> 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: freebsd-current@FreeBSD.org Subject: Re: Can't make distribution TARGET_ARCH=... after r209510 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Jul 2010 23:15:50 -0000 In message: <20100718210154.GA94088@laptop.levsha.me> Mykola Dzham writes: : Hi! : Attemt to make jail with different target arch on tinderbox (i386 jail : on amd64 host) exits with error: : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : Last lines from log: : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : install: freebsd.cf: No such file or directory : *** Error code 71 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : *** Error code 1 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : Full build and distribution logs avaliable on : http://levsha.me/tmp/20100718/world.txt (20M) : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : Reverting r209510 fixes this problem It works for me. on an amd64 box: setenv TARGET=i386 make buildworld make installworld DESTDIR=/tmp/mumble make distribution DESTDIR=/tmp/mumble Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 03:09: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 6357E106570C for ; Mon, 19 Jul 2010 03:09:45 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D0A368FC0A for ; Mon, 19 Jul 2010 03:09:42 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o6J2rGch004954 for ; Sun, 18 Jul 2010 19:53:16 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o6J2rGk9004953 for current@freebsd.org; Sun, 18 Jul 2010 19:53:16 -0700 (PDT) (envelope-from david) Date: Sun, 18 Jul 2010 19:53:16 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20100719025316.GC2314@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OROCMA9jn6tkzFBc" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: iwi(4): firmware error OR panic: iwi firmware not idle, state ASSOCIATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 03:09:45 -0000 --OROCMA9jn6tkzFBc Content-Type: multipart/mixed; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My laptop has a miniPCI iwi(4) NIC which (basically) works under stable/7 and stable/8, but after I came back from visiting folks last weekend, I found that under 9.0-CURRENT, attempts to make use of it usually yield a stream of iwi0: firmware error messages until I take the interface down ("ifconfig iwi0 down"). And in the case where that doesn't happen, I get a panic; I've attached the core.txt file from one of those I got this morning at r210190. (The uname output reflects r210190M, as I had inserted some printf()s into src/sys/net/if.c to try to resolve a different issue.) I welcome clues; I normally update the CURRENT slice on the laptop daily, using a local mirror of the SVN repository that I sync on a daily basis in the wee small hours of the morning. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="core.txt.25" Content-Transfer-Encoding: quoted-printable localhost dumped core - see /var/crash/vmcore.25 Sun Jul 18 06:10:29 PDT 2010 FreeBSD localhost 9.0-CURRENT FreeBSD 9.0-CURRENT #60 r210190M: Sat Jul 17 = 16:10:49 PDT 2010 root@localhost:/usr/obj/usr/src/sys/CANARY i386 panic: iwi firmware not idle, state ASSOCIATING 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 condition= s. 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: panic: iwi firmware not idle, state ASSOCIATING cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c0cca5e8,c52bcb68,c0890089,c0d0289d,0,...) at 0xc04da= b26 =3D db_trace_self_wrapper+0x26 kdb_backtrace(c0d0289d,0,c11bec2a,c52bcb74,0,...) at 0xc08c2bc9 =3D kdb_bac= ktrace+0x29 panic(c11bec2a,c11bec4d,c11beb2a,ae6,c7c57014,...) at 0xc0890089 =3D panic+= 0x119 iwi_auth_and_assoc(c7885c0c,0,c11beb2a,3c5,8,...) at 0xc11be36c =3D iwi_aut= h_and_assoc+0x77c iwi_newstate(c8be9000,2,c0,652,c52bcc98,...) at 0xc11be679 =3D iwi_newstate= +0x179 ieee80211_newstate_cb(c8be9000,1,c0ccbeba,51,c7c52a98,...) at 0xc098f2b9 = =3D ieee80211_newstate_cb+0x179 taskqueue_run(c7c52a80,c7c52a98,0,c0ce8924,0,...) at 0xc08cf2b3 =3D taskque= ue_run+0x103 taskqueue_thread_loop(c7c57074,c52bcd28,c0cc22eb,343,c0e24800,...) at 0xc08= cf408 =3D taskqueue_thread_loop+0x68 fork_exit(c08cf3a0,c7c57074,c52bcd28) at 0xc08658a8 =3D fork_exit+0xb8 fork_trampoline() at 0xc0bd15f4 =3D fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc52bcd60, ebp =3D 0 --- KDB: enter: panic Uptime: 3m19s Physical memory: 2031 MB Dumping 138 MB: 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/ker= nel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/if_an.ko...Reading symbols from /boot/ker= nel/if_an.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_an.ko Reading symbols from /boot/kernel/if_iwi.ko...Reading symbols from /boot/ke= rnel/if_iwi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwi.ko Reading symbols from /boot/kernel/if_wi.ko...Reading symbols from /boot/ker= nel/if_wi.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_wi.ko Reading symbols from /boot/kernel/iwi_bss.ko...Reading symbols from /boot/k= ernel/iwi_bss.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwi_bss.ko Reading symbols from /boot/kernel/iwi_ibss.ko...Reading symbols from /boot/= kernel/iwi_ibss.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwi_ibss.ko Reading symbols from /boot/kernel/iwi_monitor.ko...Reading symbols from /bo= ot/kernel/iwi_monitor.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwi_monitor.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/ke= rnel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kerne= l/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/ker= nel/tmpfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/tmpfs.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 0xc088fdee in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 16 #2 0xc08900c2 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc11be36c in iwi_auth_and_assoc (sc=3D0xc7885c00, vap=3D0xc8be9000) at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2797 #4 0xc11be679 in iwi_newstate (vap=3D0xc8be9000, nstate=3DIEEE80211_S_AUTH= ,=20 arg=3D192) at /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1001 #5 0xc098f2b9 in ieee80211_newstate_cb (xvap=3D0xc8be9000, npending=3D1) at /usr/src/sys/net80211/ieee80211_proto.c:1652 #6 0xc08cf2b3 in taskqueue_run (queue=3D0xc7c52a80) at /usr/src/sys/kern/subr_taskqueue.c:239 #7 0xc08cf408 in taskqueue_thread_loop (arg=3D0xc7c57074) at /usr/src/sys/kern/subr_taskqueue.c:360 #8 0xc08658a8 in fork_exit (callout=3D0xc08cf3a0 ,= =20 arg=3D0xc7c57074, frame=3D0xc52bcd28) at /usr/src/sys/kern/kern_fork.c:= 843 #9 0xc0bd15f4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 273 (kgdb)=20 ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMA= ND 0 0 0 0 -68 0 0 0 - DLs ?? -15292046:-37.5= 5 [kernel] 0 1 0 0 44 0 8032 536 wait DLs ?? 6061910:48.00 [= init] 0 2 0 0 -8 0 0 0 - DL ?? 29878669:02.00 = [g_event] 0 3 0 0 -8 0 0 0 - DL ?? 8607622:44.00 [= g_up] 0 4 0 0 -8 0 0 0 - DL ?? 10976667:54.00 = [g_down] 0 5 0 0 -16 0 0 0 c798bbbc DL ?? 0:00.00 [cb= b0 eve 0 6 0 0 -16 0 0 0 c78aabbc DL ?? 0:00.00 [cb= b1 eve 0 7 0 0 -16 0 0 0 - DL ?? 0:00.00 [fw0_= prob 0 8 0 0 -16 0 0 0 - DL ?? 59986:18.00 [fd= c0] 0 9 0 0 -60 0 0 0 waitin DL ?? 4088:48.00 [sct= p_ite 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audi= t] 0 11 0 0 171 0 0 0 - RL ?? -23036710:-55.5= 5 [idle] 0 12 0 0 -60 0 0 0 - RL ?? -4764568:-41.55= [intr] 0 13 0 0 -16 0 0 0 - DL ?? 1121449:10.00 [= yarrow] 0 14 0 0 -64 0 0 0 - DL ?? 110610:42.00 [u= sb] 0 15 0 0 -16 0 0 0 tzpoll DL ?? 7389811:52.00 [= acpi_the 0 16 0 0 51 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_= thrd 0 17 0 0 76 0 0 0 psleep DL ?? 20868:58.00 [pa= gedaem 0 18 0 0 76 0 0 0 psleep DL ?? 151:28.00 [vmda= emon 0 19 0 0 76 0 0 0 pgzero DL ?? 189:00.00 [page= zero 0 20 0 0 76 0 0 0 psleep DL ?? 85226:12.00 [bu= fdaemo 0 21 0 0 44 0 0 0 syncer DL ?? 1972420:16.00 [= syncer] 0 22 0 0 76 0 0 0 vlruwt DL ?? 67254:42.00 [vn= lru] 0 23 0 0 76 0 0 0 sdflus DL ?? 78747:26.00 [so= ftdepf 0 24 0 0 -16 0 0 0 flowcl DL ?? 1156362:04.00 [= flowclea 0 1756 1 0 44 0 8032 700 select Ds ?? 78785:08.00 [de= vd] 0 2045 1 0 44 0 9608 1416 select Ds ?? 5506470:18.00 [= syslogd] 0 2071 1 0 44 0 9640 1528 select Ds ?? 263175:50.00 [r= pcbind] 0 2223 1 0 76 0 9524 1424 select Ds ?? 215852:12.00 [l= pd] 0 2261 1 0 44 0 9608 1156 select Ds ?? 6049417:24.00 [= powerd] 0 2373 1 0 76 0 9712 1324 select Ds ?? 44258:00.00 [mo= used] 0 2409 1 0 44 0 14860 6276 select D ?? 5784976:30.00 [= snmpd] 0 2468 1 0 44 0 16692 7956 select Ds ?? 7079579:20.00 [= httpd] 80 2497 2468 0 76 0 16692 8008 accept D ?? 158342:58.00 [h= ttpd] 80 2498 2468 0 76 0 16692 8008 accept D ?? 143164:56.00 [h= ttpd] 80 2499 2468 0 76 0 16692 8008 accept D ?? 150051:52.00 [h= ttpd] 80 2500 2468 0 76 0 16692 8008 accept D ?? 149116:12.00 [h= ttpd] 80 2501 2468 0 76 0 16692 8008 accept D ?? 143495:00.00 [h= ttpd] 0 2502 1 0 76 0 12960 3924 select Ds ?? 133029:52.00 [s= shd] 0 2510 1 0 44 0 11316 3600 select Ds ?? 392881:28.00 [s= endmail 25 2514 1 0 76 0 11316 3620 pause Ds ?? 132681:44.00 [s= endmail 0 2521 1 0 44 0 9636 1492 nanslp Ds ?? 350887:14.00 [c= ron] 0 2587 1 0 76 0 9612 1232 ttyin Ds+ ?? 220039:52.00 [g= etty] 0 2588 1 0 45 0 10040 2028 wait Ds ?? 6058208:48.00 [= login] 0 2589 1 0 76 0 9612 1232 ttyin Ds+ ?? 188277:52.00 [g= etty] 0 2590 1 0 76 0 9612 1232 ttyin Ds+ ?? 197190:52.00 [g= etty] 0 2591 1 0 76 0 9612 1232 ttyin Ds+ ?? 189844:52.00 [g= etty] 0 2592 1 0 76 0 9612 1232 ttyin Ds+ ?? 196517:36.00 [g= etty] 0 2593 1 0 76 0 9612 1232 ttyin Ds+ ?? 195583:48.00 [g= etty] 0 2594 1 0 76 0 9612 1232 ttyin Ds+ ?? 195246:12.00 [g= etty] 0 2595 1 0 76 0 9888 1700 wait D ?? 468476:32.00 [s= h] 0 2596 1 0 76 0 9612 1232 ttyin Ds+ ?? 203503:48.00 [g= etty] 0 2603 2595 0 49 0 11692 2452 pause D ?? 1119112:40.00 [= xdm] 0 2605 2603 0 44 0 90676 81656 select Ds ?? -16871804:-17.5= 5 [Xorg] 0 2607 2603 0 50 0 14308 5936 select Ds ?? 6647878:58.00 [= xdm] 0 2613 1 0 44 0 11996 3520 select D ?? 7810229:24.00 [= xconsole 1001 2614 2588 0 44 0 10884 3224 pause D ?? 6536242:56.00 [= csh] 0 2650 1 0 44 0 9952 2192 select Ds ?? 2018287:52.00 [= screen] 1001 2652 2650 0 66 0 10884 3260 pause Ds ?? 5725366:46.00 [= csh] 0 2685 2652 0 44 0 9608 1116 select D+ ?? 4396467:38.00 [= script] 0 2686 2685 0 76 0 10884 3280 pause Ds ?? 5645827:54.00 [= csh] 0 2723 2686 0 44 0 8032 684 select D+ ?? 1591223:30.00 [= make] 1001 2880 2614 0 44 0 9952 1996 pause D+ ?? 827608:12.00 [s= creen] 0 2881 2880 0 44 0 9952 2200 select Ds ?? 1000428:38.00 [= screen] 1001 2883 2881 0 76 0 10884 3260 pause Ds ?? 2975247:40.00 [= csh] 0 2924 2883 0 55 0 10036 1852 wait D ?? 1600934:12.00 [= su] 0 2931 2723 0 62 0 9888 1560 wait D+ ?? 185833:36.00 [s= h] 0 2933 2931 0 44 0 8032 1012 select D+ ?? 2522712:36.00 [= make] 0 2938 2924 0 44 0 10884 3540 pause D ?? 6788161:40.00 [= csh] 0 3003 2933 0 76 0 9888 1556 wait D+ ?? 174845:32.00 [s= h] 0 3004 3003 0 44 0 8032 1016 select D+ ?? 2018270:56.00 [= make] 0 3008 3004 0 76 0 9888 1560 wait D+ ?? 227842:04.00 [s= h] 0 3201 2938 0 76 0 9888 1784 wait D+ ?? 1211635:32.00 [= sh] 0 3212 3201 0 76 0 11360 3072 wait D+ ?? 1661967:20.00 [= perl] 0 3238 3212 0 57 0 11376 3152 wait D+ ?? 0:00.00 [perl] 0 3272 3008 0 76 0 8032 1640 select D+ ?? 0:00.00 [make] 0 3274 3272 0 76 0 9888 1556 wait D+ ?? 0:00.00 [sh] 0 3276 3274 0 76 0 9536 1260 wait D+ ?? 0:00.00 [c++] 0 3279 3276 0 76 0 18332 11804 - R+ ?? 0:00.00 [cc1p= lus] 0 3280 3276 0 76 0 8032 1092 piperd D+ ?? 32923:56.00 [as] 0 3281 3272 0 76 0 9888 1556 wait D+ ?? 0:00.00 [sh] 0 3282 3281 0 76 0 9536 1260 wait D+ ?? 0:00.00 [c++] 0 3283 3282 0 96 0 20388 13708 - R+ ?? 0:00.00 [cc1p= lus] 0 3284 3282 0 76 0 8032 1092 piperd D+ ?? 31389:08.00 [as] 0 3285 3238 0 58 0 9704 1272 - R+ ?? 0:00.00 [ifco= nfig ------------------------------------------------------------------------ vmstat -s 747853 cpu context switches 236505 device interrupts 187730 software interrupts 537793 traps 685999 system calls 24 kernel threads created 2902 fork() calls 359 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 1042 vnode pager pageins 8339 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 400 pages reactivated 84442 copy-on-write faults 39 copy-on-write optimized faults 343299 zero fill pages zeroed 4737 zero fill pages prezeroed 146 intransit blocking page faults 485093 total VM faults taken 0 pages affected by kernel thread creation 2768642 pages affected by fork() 327821 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 478490 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 13753 pages active 9034 pages inactive 42 pages in VM cache 20798 pages wired down 466950 pages free 4096 bytes per page 417109 total name lookups cache hits (87% pos + 6% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) proc-args 51 14K - 1078 256,512,1024 ithread 64 22K - 64 256,512 KTRACE 100 25K - 100 256 linker 187 139K - 312 256,1024,2048 lockf 32 8K - 52 256 ad_driver 1 1K - 1 256 ip6ndp 9 3K - 9 256 temp 38 275K - 5939 256,512,1024,2048,4096 devbuf 1540 6306K - 1579 256,512,1024,2048,4096 UART 3 4K - 3 256,1024,2048 module 465 117K - 465 256 acd_driver 1 4K - 1 4096 mtx_pool 2 16K - 2 =20 ata_cam 1 2K - 13 256,1024,2048 osd 2 1K - 2 256 subproc 170 723K - 3371 512 proc 2 24K - 2 =20 session 30 8K - 36 256 pgrp 37 10K - 59 256 cred 60 23K - 16458 256,512 uidinfo 5 5K - 17 256,4096 plimit 23 12K - 279 512 sysctltmp 0 0K - 836 256 sysctloid 3547 887K - 3637 256 sysctl 0 0K - 1930 256 umtx 250 63K - 250 256 p1003.1b 1 1K - 1 256 SWAP 2 825K - 2 256 CAM periph 4 1K - 22 256 bus-sc 69 162K - 2508 256,512,1024,2048,4096 bus 1147 287K - 5196 256,512,2048,4096 devstat 14 86K - 14 256 eventhandler 85 22K - 85 256 acpidev 76 19K - 76 256 kobj 321 1284K - 381 4096 Per-cpu 1 1K - 1 256 rman 194 49K - 630 256 sbuf 0 0K - 1180 256,512,1024,2048,4096 USBdev 8 6K - 8 256,2048 USB 14 7K - 14 256,2048 scsi_cd 0 0K - 3 256 stack 0 0K - 2 256 taskqueue 17 5K - 17 256 Unitno 14 4K - 362 256 pci_link 8 2K - 8 256 Witness 1 112K - 1 =20 iov 0 0K - 2867 256,512 select 39 10K - 39 256 ioctlops 1 1K - 4590 256,512,1024,2048 msg 4 46K - 4 2048 sem 4 114K - 4 2048 shm 1 16K - 1 =20 tty 24 48K - 26 2048,4096 pts 4 1K - 4 256 accf 2 1K - 2 256 mbuf_tag 0 0K - 1258 256 ksem 1 12K - 1 =20 shmfd 1 12K - 1 =20 acpi_perf 1 1K - 1 256 pcb 26 125K - 57 256,2048,4096 soname 10 3K - 230 256 biobuf 1 8K - 1 =20 vfscache 1 520K - 1 =20 cl_savebuf 0 0K - 23 256 vfs_hash 1 264K - 1 =20 vnodes 5 2K - 5 256,512 vnodemarker 0 0K - 121 1024 mount 106 31K - 151 256,1024 BPF 8 2K - 18 256,512,1024 ether_multi 17 5K - 18 256 ifaddr 191 72K - 191 256,512,1024 ifnet 9 17K - 9 256,2048 clone 6 72K - 6 =20 arpcom 4 1K - 4 256 fw_com 1 1K - 1 256 lltable 18 9K - 18 512 ddb_capture 1 56K - 1 =20 acpica 1385 352K - 106336 256,512,1024,2048 fw_xfer 0 0K - 1 256 firewire 11 42K - 14 256,1024,4096 acpitask 1 2K - 1 2048 DEVFS1 117 59K - 135 512 DEVFS3 137 37K - 155 256,512 routetbl 214 8798K - 607 256,512,1024 vnet_data_free 1 1K - 1 256 vnet_data 1 36K - 1 =20 vnet 1 1K - 1 256 80211vap 1 8K - 1 =20 80211crypto 1 1K - 1 256 80211com 1 12K - 1 =20 80211nodeie 3 1K - 767 256 80211node 1 12K - 754 =20 80211scan 4 10K - 8 1024,4096 igmp 8 2K - 8 256 DEVFS 14 4K - 15 256 DEVFSP 0 0K - 2 256 in_multi 1 1K - 1 512 dummynet 3 3K - 3 1024 IpFw/IpAcct 13 4K - 93 256 sctp_iter 0 0K - 1 512 sctp_ifn 1 1K - 1 256 sctp_ifa 3 1K - 3 256 sctp_vrf 1 1K - 1 256 sctp_a_it 0 0K - 1 256 hostcache 1 24K - 1 =20 syncache 1 80K - 1 =20 ip6_moptions 2 1K - 2 256,512 in6_multi 13 5K - 13 256,512 in6_mfilter 1 1K - 1 1024 pfs_nodes 21 6K - 21 256 pfs_vncache 6 2K - 32 256 mld 8 2K - 8 256 NFS FHA 1 4K - 1 4096 rpc 2 9K - 2 512 audit_evclass 172 43K - 211 256 newblk 1 72K - 1 =20 bmsafemap 1 12K - 1 =20 inodedep 1 264K - 1 =20 pagedep 1 72K - 1 =20 ufs_dirhash 126 65K - 126 256,512,1024 ufs_mount 12 70K - 12 512 ppbusdev 3 1K - 3 256 UMAHash 1 2K - 2 1024,2048 entropy 1024 256K - 1024 256 GEOM 221 124K - 1272 256,1024,2048 agp 2 65K - 2 256 CAM XPT 34 42K - 112 256,1024,2048,4096 vm_pgdata 2 73K - 2 256 atkbddev 2 1K - 2 256 ac97 2 2K - 2 256,1024 acpisem 15 4K - 15 256 sbp 104 26K - 104 256 apmdev 1 1K - 2 256 isadev 6 2K - 6 256 CAM dev queue 3 1K - 3 256 memdesc 1 8K - 9 256 nexusdev 3 1K - 3 256 feeder 12 3K - 14 256 CAM queue 11 3K - 74 256 CAM SIM 3 1K - 3 256 ata_generic 2 4K - 2 2048 cdev 11 3K - 11 256 tty console 1 16K - 1 =20 kbdmux 6 27K - 6 256,512,2048,4096 mixer 1 8K - 1 =20 sigio 1 1K - 2 256 filedesc 85 43K - 3286 512 kenv 89 30K - 97 256 kqueue 10 23K - 12 512,4096 linux 14 4K - 14 256 drm_ctxbitmap 1 12K - 1 =20 drm_agplists 1 1K - 1 256 drm_maps 1 1K - 1 256 drm_driver 4 3K - 8 256,512,2048 drm_sarea 1 1K - 1 256 tmpfs name 15 4K - 177 256 tmpfs mount 1 1K - 1 256 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 128, 0, 92, 28, 92, 0, 0 UMA Zones: 896, 0, 92, 0, 92, 0, 0 UMA Slabs: 284, 0, 1263, 11, 6859, 0, 0 UMA RCntSlabs: 544, 0, 75, 2, 75, 0, 0 UMA Hash: 128, 0, 3, 27, 4, 0, 0 16 Bucket: 76, 0, 29, 21, 57, 0, 0 32 Bucket: 140, 0, 27, 1, 61, 0, 0 64 Bucket: 268, 0, 27, 1, 97, 11, 0 128 Bucket: 524, 0, 25, 3, 1190, 114, 0 VM OBJECT: 136, 0, 3984, 18, 38313, 0, 0 MAP: 140, 0, 8, 20, 8, 0, 0 KMAP ENTRY: 72, 57505, 43, 116, 17636, 0, 0 MAP ENTRY: 72, 0, 2124, 49, 72052, 0, 0 DP fakepg: 72, 0, 16421, 62, 16422, 0, 0 SG fakepg: 72, 0, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 310, 126, 310, 0, 0 16: 16, 0, 0, 0, 0, 0, 0 32: 32, 0, 0, 0, 0, 0, 0 64: 64, 0, 0, 0, 0, 0, 0 128: 128, 0, 0, 0, 0, 0, 0 256: 256, 0, 11255, 85, 140213, 0, 0 512: 512, 0, 611, 21, 13680, 0, 0 1024: 1024, 0, 117, 7, 1773, 0, 0 2048: 2048, 0, 72, 16, 8252, 0, 0 4096: 4096, 0, 353, 131, 2108, 0, 0 Files: 56, 0, 178, 90, 51896, 0, 0 TURNSTILE: 72, 0, 126, 24, 126, 0, 0 umtx pi: 52, 0, 0, 0, 0, 0, 0 MAC labels: 20, 0, 0, 0, 0, 0, 0 PROC: 680, 0, 84, 0, 3285, 0, 0 THREAD: 704, 0, 115, 10, 115, 0, 0 SLEEPQUEUE: 48, 0, 126, 110, 126, 0, 0 VMSPACE: 240, 0, 61, 19, 3263, 0, 0 cpuset: 40, 0, 2, 182, 2, 0, 0 audit_record: 816, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 32, 110, 156, 0, 0 mbuf: 256, 0, 1, 141, 3211, 0, 0 mbuf_cluster: 2048, 25600, 128, 22, 419, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 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, 203, 33, 0, 0 g_bio: 152, 0, 0, 572, 27440, 0, 0 ttyinq: 152, 0, 210, 50, 660, 0, 0 ttyoutq: 256, 0, 112, 8, 336, 0, 0 ata_request: 204, 0, 1, 170, 9120, 0, 0 ata_composite: 180, 0, 0, 0, 0, 0, 0 VNODE: 272, 0, 5838, 14, 6117, 0, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0, 0 S VFS Cache: 72, 0, 6110, 91, 21176, 0, 0 L VFS Cache: 292, 0, 27, 12, 27, 0, 0 NAMEI: 1024, 0, 0, 12, 87585, 0, 0 DIRHASH: 1024, 0, 240, 16, 240, 0, 0 NFSMOUNT: 524, 0, 0, 0, 0, 0, 0 NFSNODE: 456, 0, 0, 0, 0, 0, 0 pipe: 392, 0, 11, 19, 2282, 0, 0 ksiginfo: 80, 0, 70, 986, 96, 0, 0 itimer: 220, 0, 0, 0, 0, 0, 0 KNOTE: 72, 0, 5, 101, 5, 0, 0 socket: 412, 25605, 45, 18, 795, 0, 0 ipq: 32, 904, 0, 0, 0, 0, 0 udp_inpcb: 220, 25614, 9, 27, 598, 0, 0 udpcb: 8, 25781, 9, 194, 598, 0, 0 tcp_inpcb: 220, 25614, 12, 24, 16, 0, 0 tcpcb: 632, 25602, 12, 6, 16, 0, 0 tcptw: 52, 5184, 0, 0, 0, 0, 0 syncache: 112, 15365, 0, 0, 0, 0, 0 hostcache: 76, 15400, 0, 0, 0, 0, 0 tcpreass: 20, 1690, 0, 0, 0, 0, 0 sackhole: 20, 0, 0, 0, 0, 0, 0 sctp_ep: 860, 25600, 0, 0, 0, 0, 0 sctp_asoc: 1484, 40000, 0, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 145, 2, 0, 0 sctp_raddr: 432, 80001, 0, 0, 0, 0, 0 sctp_chunk: 92, 400008, 0, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0, 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0, 0 ripcb: 220, 25614, 0, 36, 48, 0, 0 unpcb: 172, 25622, 24, 45, 124, 0, 0 rtentry: 108, 0, 6, 66, 10, 0, 0 IPFW dynamic rule: 108, 0, 0, 0, 0, 0, 0 divcb: 220, 25614, 0, 0, 0, 0, 0 selfd: 28, 0, 88, 166, 14163, 0, 0 ip4flow: 40, 25668, 0, 0, 0, 0, 0 ip6flow: 64, 25636, 0, 0, 0, 0, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0, 0 Mountpoints: 648, 0, 7, 5, 7, 0, 0 FFS inode: 116, 0, 5749, 59, 5844, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 5749, 11, 5844, 0, 0 TMPFS dirent: 20, 0, 15, 154, 177, 0, 0 TMPFS node: 136, 0, 21, 37, 177, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq0: attimer0 187286 643 irq1: atkbd0 461 1 irq4: uart0 2598 8 irq6: fdc0 1 0 irq7: ppc0 9 0 irq8: atrtc0 24539 84 irq9: pcm0 acpi0 1 0 irq11: cbb0 cbb1++* 14355 49 irq14: ata0 7173 24 Total 236423 812 ------------------------------------------------------------------------ pstat -T 178/12328 files 0M/6143M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ad0s4b 12582656 0 12582656 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 cd0 pass0=20 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s=20 13.39 24 0.31 0.00 0 0.00 0.00 0 0.00=20 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP = CBYTES QNUM QBYTES LSPI= D LRPID STIME RTIME CTIME =20 Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NATTCH SEGSZ CPID LPID ATIME DTIME CTIM= E =20 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NSEMS OTIME CTIME =20 ------------------------------------------------------------------------ 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 Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Re= move 0 0 0 0 0 0 0 = 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Ac= cess 0 0 0 0 0 0 0 = 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Mi= sses 0 0 0 0 0 0 0 = 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Re= move 0 0 0 0 0 0 0 = 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Ac= cess 0 0 0 0 0 0 0 = 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 0 packets sent 0 data packets (0 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 0 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 0 control packets 0 packets received 0 acks (for 0 bytes) 0 duplicate acks 0 acks for unsent data 0 packets (0 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 0 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 0 connections established (including accepts) 4 connections closed (including 0 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 0 segments updated rtt (of 0 attempts) 0 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 0 correct ACK header predictions 0 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 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: 0 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 0 delivered 0 datagrams output 0 times multicast source filter matched ip: 0 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 0 packets for this host 0 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 0 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: 0 calls to icmp_error 0 errors not generated in response to an icmp message 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 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 arp: 0 ARP requests sent 0 ARP replies sent 0 ARP requests received 0 ARP replies received 0 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data 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 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 2 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 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not continuous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: 11 same address icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 33/251/284 mbufs in use (current/cache/total) 18/132/150/25600 mbuf clusters in use (current/cache/total/max) 32/110 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/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) 44K/326K/371K 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 O= errs Coll Drop xl0* 1500 00:08:74:e9:c9:41 0 0 0 0 = 0 0 0=20 fwe0* 1500 42:4f:c0:2c:30:41 0 0 0 0 = 0 0 0=20 fwip0 1500 42:4f:c0:00:07:2c:30:41:0a:02:ff:fe:00:00:00:00 = 0 0 0 0 0 0 0=20 iwi0* 2290 00:0e:35:aa:11:ca 0 0 0 0 = 0 0 0=20 plip0 1500 0 0 0 0 = 0 0 0=20 ipfw0 65536 0 0 0 0 = 0 0 0=20 lo0 16384 0 0 0 0 = 0 0 0=20 lo0 16384 your-net localhost 0 - - 0 = - - -=20 lo0 16384 localhost ::1 0 - - 0 = - - -=20 lo0 16384 fe80:1::1 fe80:1::1 0 - - 0 = - - -=20 wlan1 1500 00:0e:35:aa:11:ca 0 0 0 0 = 0 0 0=20 ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 link#1 UH 0 0 lo0 Internet6: Destination Gateway Flags = Netif Expire ::1 ::1 UH = lo0 fe80::%xl0/64 link#1 U = lo0 fe80::1%xl0 link#1 UHS = lo0 ff01:1::/32 ::1 U = lo0 ff02::%xl0/32 ::1 U = lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c8c4b4f0 tcp4 0 0 *.6000 *.* LISTEN c8c4b768 tcp6 0 0 *.6000 *.* LISTEN c8c4bc58 tcp4 0 0 127.0.0.1.25 *.* LISTEN c8e0d278 tcp4 0 0 *.22 *.* LISTEN c8e0d4f0 tcp6 0 0 *.22 *.* LISTEN c8c4a000 tcp4 0 0 *.* *.* CLOSED c8c4a278 tcp46 0 0 *.80 *.* LISTEN c8c4a4f0 tcp4 0 0 *.199 *.* LISTEN c8c4a768 tcp4 0 0 *.515 *.* LISTEN c8c4a9e0 tcp6 0 0 *.515 *.* LISTEN c8c4ac58 tcp4 0 0 *.111 *.* LISTEN c8c4b000 tcp6 0 0 *.111 *.* LISTEN c8be2000 udp4 0 0 *.* *.* =20 c8be2e9c udp4 0 0 *.161 *.* =20 c8be2ce4 udp6 0 0 *.* *.* =20 c8be2a50 udp4 0 0 *.1014 *.* =20 c8be26e0 udp4 0 0 *.111 *.* =20 c8be27bc udp6 0 0 *.737 *.* =20 c8be2604 udp6 0 0 *.111 *.* =20 c8be244c udp4 0 0 *.514 *.* =20 c8be2294 udp6 0 0 *.514 *.* =20 Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c8bfaa14 stream 0 0 0 c8bfacc4 0 0 c8bfacc4 stream 0 0 0 c8bfaa14 0 0 c8bfa408 stream 0 0 0 c8bfa35c 0 0 c8bfa35c stream 0 0 0 c8bfa408 0 0 c8bfae1c stream 0 0 0 c8bfb000 0 0 c8bfb000 stream 0 0 0 c8bfae1c 0 0 c8bfac18 stream 0 0 0 c8bfad70 0 0 /tmp/.X11= -unix/X0 c8bfad70 stream 0 0 0 c8bfac18 0 0 c8bfab6c stream 0 0 0 c8bfaac0 0 0 /tmp/.X11= -unix/X0 c8bfaac0 stream 0 0 0 c8bfab6c 0 0 c8bfa000 stream 0 0 0 c8bfa0ac 0 0 /tmp/.X11= -unix/X0 c8bfa0ac stream 0 0 0 c8bfa000 0 0 c8bfa158 stream 0 0 c8eab770 0 0 0 /tmp/.X11= -unix/X0 c8bfa968 stream 0 0 0 c8bfa8bc 0 0 /var/run/= devd.pipe c8bfa8bc stream 0 0 0 c8bfa968 0 0 c8bfa764 stream 0 0 c8c50110 0 0 0 /var/run/= printer c8bfa60c stream 0 0 c8c3abb0 0 0 0 /var/run/= rpcbind.sock c8bfa810 stream 0 0 c8bdc110 0 0 0 /var/run/= devd.pipe c8bfaec8 dgram 0 0 0 c8bfa560 0 c8bfa2b0 c8bfa204 dgram 0 0 0 c8bfa4b4 0 0 c8bfa2b0 dgram 0 0 0 c8bfa560 0 c8bfa6b8 c8bfa6b8 dgram 0 0 0 c8bfa560 0 0 c8bfa560 dgram 0 0 c8c39770 0 c8bfaec8 0 /var/run/= logpriv c8bfa4b4 dgram 0 0 c8c39880 0 c8bfa204 0 /var/run/= log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address =20 tcp4 0/0/128 *.x11 =20 tcp6 0/0/128 *.x11 =20 tcp4 0/0/10 localhost.smtp =20 tcp4 0/0/128 *.ssh =20 tcp6 0/0/128 *.ssh =20 tcp46 0/0/128 *.http =20 tcp4 0/0/128 *.smux =20 tcp4 0/0/5 *.printer =20 tcp6 0/0/5 *.printer =20 tcp4 0/0/128 *.sunrpc =20 tcp6 0/0/128 *.sunrpc =20 unix 0/0/128 /tmp/.X11-unix/X0 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 root ifconfig 3285 root / 2 drwxr-xr-x 1024 r root ifconfig 3285 wd / 2 drwxr-xr-x 1024 r root ifconfig 3285 text / 117805 -r-xr-xr-x 128640 r root ifconfig 3285 0 /dev 126 crw--w---- pts/3 rw root ifconfig 3285 1 /dev 126 crw--w---- pts/3 rw root ifconfig 3285 2 /var 141882 -rw-r--r-- 1755 w root ifconfig 3285 3* internet dgram udp c8be2000 root as 3284 root / 2 drwxr-xr-x 1024 r root as 3284 wd /common 5771290 drwxr-xr-x 512 r root as 3284 text /usr 377815 -r-xr-xr-x 855432 r root as 3284 0* pipe c89fe930 <-> c89fe9e8 0 rw root as 3284 1* pipe c89ffcf8 <-> c89ffc40 0 rw root as 3284 2* pipe c89ffcf8 <-> c89ffc40 0 rw root as 3284 3 /common 5771090 -rw-r--r-- 0 rw root cc1plus 3283 root / 2 drwxr-xr-x 1024 r root cc1plus 3283 wd /common 5771290 drwxr-xr-x 512 r root cc1plus 3283 text /usr 164901 -r-xr-xr-x 5947864 r root cc1plus 3283 0 - - ?(tmpfs) - root cc1plus 3283 1* pipe c89fe9e8 <-> c89fe930 0 rw root cc1plus 3283 2* pipe c89ffcf8 <-> c89ffc40 0 rw root c++ 3282 root / 2 drwxr-xr-x 1024 r root c++ 3282 wd /common 5771290 drwxr-xr-x 512 r root c++ 3282 text /usr 377929 -r-xr-xr-x 176432 r root c++ 3282 0 - - ?(tmpfs) - root c++ 3282 1* pipe c89ffcf8 <-> c89ffc40 0 rw root c++ 3282 2* pipe c89ffcf8 <-> c89ffc40 0 rw root sh 3281 root / 2 drwxr-xr-x 1024 r root sh 3281 wd /common 5771290 drwxr-xr-x 512 r root sh 3281 text / 141356 -r-xr-xr-x 121404 r root sh 3281 0 - - ?(tmpfs) - root sh 3281 1* pipe c89ffcf8 <-> c89ffc40 0 rw root sh 3281 2* pipe c89ffcf8 <-> c89ffc40 0 rw root as 3280 root / 2 drwxr-xr-x 1024 r root as 3280 wd /common 5771290 drwxr-xr-x 512 r root as 3280 text /usr 377815 -r-xr-xr-x 855432 r root as 3280 0* pipe c89ff620 <-> c89ff6d8 0 rw root as 3280 1* pipe c89fe240 <-> c89fe188 0 rw root as 3280 2* pipe c89fe240 <-> c89fe188 0 rw root as 3280 3 /common 5771087 -rw-r--r-- 0 rw root cc1plus 3279 root / 2 drwxr-xr-x 1024 r root cc1plus 3279 wd /common 5771290 drwxr-xr-x 512 r root cc1plus 3279 text /usr 164901 -r-xr-xr-x 5947864 r root cc1plus 3279 0 - - ?(tmpfs) - root cc1plus 3279 1* pipe c89ff6d8 <-> c89ff620 0 rw root cc1plus 3279 2* pipe c89fe240 <-> c89fe188 0 rw root cc1plus 3279 3 /usr 47328 -r--r--r-- 25543 r root c++ 3276 root / 2 drwxr-xr-x 1024 r root c++ 3276 wd /common 5771290 drwxr-xr-x 512 r root c++ 3276 text /usr 377929 -r-xr-xr-x 176432 r root c++ 3276 0 - - ?(tmpfs) - root c++ 3276 1* pipe c89fe240 <-> c89fe188 0 rw root c++ 3276 2* pipe c89fe240 <-> c89fe188 0 rw root sh 3274 root / 2 drwxr-xr-x 1024 r root sh 3274 wd /common 5771290 drwxr-xr-x 512 r root sh 3274 text / 141356 -r-xr-xr-x 121404 r root sh 3274 0 - - ?(tmpfs) - root sh 3274 1* pipe c89fe240 <-> c89fe188 0 rw root sh 3274 2* pipe c89fe240 <-> c89fe188 0 rw root make 3272 root / 2 drwxr-xr-x 1024 r root make 3272 wd /common 5771290 drwxr-xr-x 512 r root make 3272 text /common 4733985 -rwxr-xr-x 474088 r root make 3272 0 - - ?(tmpfs) - root make 3272 1* pipe c89fe3c8 <-> c89fe310 0 rw root make 3272 2* pipe c89fe3c8 <-> c89fe310 0 rw root make 3272 3 - - ?(tmpfs) - root make 3272 5* pipe c89ffc40 <-> c89ffcf8 0 rw root make 3272 6* pipe c89ffcf8 <-> c89ffc40 0 rw root make 3272 7* pipe c89fe188 <-> c89fe240 0 rw root make 3272 8* pipe c89fe240 <-> c89fe188 0 rw root perl 3238 root / 2 drwxr-xr-x 1024 r root perl 3238 wd / 2 drwxr-xr-x 1024 r root perl 3238 text /common 2802694 -rwxr-xr-x 4948 r root perl 3238 0 /dev 126 crw--w---- pts/3 rw root perl 3238 1 /dev 126 crw--w---- pts/3 rw root perl 3238 2 /var 141882 -rw-r--r-- 1755 w root perl 3238 3* pipe c89ff930 <-> c89ff9e8 0 rw root perl 3212 root / 2 drwxr-xr-x 1024 r root perl 3212 wd / 2 drwxr-xr-x 1024 r root perl 3212 text /common 2802694 -rwxr-xr-x 4948 r root perl 3212 0 /dev 126 crw--w---- pts/3 rw root perl 3212 1 /dev 126 crw--w---- pts/3 rw root perl 3212 2 /dev 126 crw--w---- pts/3 rw root perl 3212 3* pipe c949a310 <-> c949a3c8 0 rw root sh 3201 root / 2 drwxr-xr-x 1024 r root sh 3201 wd / 2 drwxr-xr-x 1024 r root sh 3201 text / 141356 -r-xr-xr-x 121404 r root sh 3201 0 /dev 126 crw--w---- pts/3 rw root sh 3201 1 /dev 126 crw--w---- pts/3 rw root sh 3201 2 /dev 126 crw--w---- pts/3 rw root sh 3201 10 /common 3205791 -r-xr-xr-x 1807 r root sh 3008 root / 2 drwxr-xr-x 1024 r root sh 3008 wd /usr 155090 drwxr-xr-x 512 r root sh 3008 text / 141356 -r-xr-xr-x 121404 r root sh 3008 0 - - ?(tmpfs) - root sh 3008 1* pipe c89fe3c8 <-> c89fe310 0 rw root sh 3008 2* pipe c89fe3c8 <-> c89fe310 0 rw root make 3004 root / 2 drwxr-xr-x 1024 r root make 3004 wd /common 5394382 drwxr-xr-x 512 r root make 3004 text /common 4733985 -rwxr-xr-x 474088 r root make 3004 0 - - ?(tmpfs) - root make 3004 1* pipe c89fecf8 <-> c89fec40 0 rw root make 3004 2* pipe c89fecf8 <-> c89fec40 0 rw root make 3004 3 - - ?(tmpfs) - root make 3004 5* pipe c89fe310 <-> c89fe3c8 0 rw root make 3004 6* pipe c89fe3c8 <-> c89fe310 0 rw root sh 3003 root / 2 drwxr-xr-x 1024 r root sh 3003 wd /usr 71233 drwxr-xr-x 1024 r root sh 3003 text / 141356 -r-xr-xr-x 121404 r root sh 3003 0 - - ?(tmpfs) - root sh 3003 1* pipe c89fecf8 <-> c89fec40 0 rw root sh 3003 2* pipe c89fecf8 <-> c89fec40 0 rw root csh 2938 root / 2 drwxr-xr-x 1024 r root csh 2938 wd /common 5487617 drwxr-xr-x 4096 r root csh 2938 text / 141345 -r-xr-xr-x 327768 r root csh 2938 15 /dev 126 crw--w---- pts/3 rw root csh 2938 16 /dev 126 crw--w---- pts/3 rw root csh 2938 17 /dev 126 crw--w---- pts/3 rw root csh 2938 18 /dev 126 crw--w---- pts/3 rw root csh 2938 19 /dev 126 crw--w---- pts/3 rw root make 2933 root / 2 drwxr-xr-x 1024 r root make 2933 wd /common 4733955 drwxr-xr-x 512 r root make 2933 text /common 4733985 -rwxr-xr-x 474088 r root make 2933 0 - - ?(tmpfs) - root make 2933 1* pipe c89feb70 <-> c89feab8 0 rw root make 2933 2* pipe c89feb70 <-> c89feab8 0 rw root make 2933 3 - - ?(tmpfs) - root make 2933 5* pipe c89fec40 <-> c89fecf8 0 rw root make 2933 6* pipe c89fecf8 <-> c89fec40 0 rw root sh 2931 root / 2 drwxr-xr-x 1024 r root sh 2931 wd /usr 71233 drwxr-xr-x 1024 r root sh 2931 text / 141356 -r-xr-xr-x 121404 r root sh 2931 0 - - ?(tmpfs) - root sh 2931 1* pipe c89feb70 <-> c89feab8 0 rw root sh 2931 2* pipe c89feb70 <-> c89feab8 0 rw root su 2924 root / 2 drwxr-xr-x 1024 r root su 2924 wd /common 5487617 drwxr-xr-x 4096 r root su 2924 text /usr 378091 -r-sr-xr-x 14576 r root su 2924 0 /dev 126 crw--w---- pts/3 rw root su 2924 1 /dev 126 crw--w---- pts/3 rw root su 2924 2 /dev 126 crw--w---- pts/3 rw david csh 2883 root / 2 drwxr-xr-x 1024 r david csh 2883 wd /common 5487617 drwxr-xr-x 4096 r david csh 2883 text / 141345 -r-xr-xr-x 327768 r david csh 2883 15 /dev 126 crw--w---- pts/3 rw david csh 2883 16 /dev 126 crw--w---- pts/3 rw david csh 2883 17 /dev 126 crw--w---- pts/3 rw david csh 2883 18 /dev 126 crw--w---- pts/3 rw david csh 2883 19 /dev 126 crw--w---- pts/3 rw root screen 2881 root / 2 drwxr-xr-x 1024 r root screen 2881 wd /common 5487617 drwxr-xr-x 4096 r root screen 2881 text /common 2809219 -rwsr-xr-x 303544 r root screen 2881 0 /dev 20 crw-rw-rw- null r root screen 2881 1 /dev 20 crw-rw-rw- null w root screen 2881 2 /dev 20 crw-rw-rw- null w root screen 2881 3 /dev 61 crw------- ttyv1 rw root screen 2881 4 - - ?(tmpfs) - root screen 2881 5 / 165161 -rw-r--r-- 2136 r root screen 2881 6* pseudo-terminal master pts/3 rw david screen 2880 root / 2 drwxr-xr-x 1024 r david screen 2880 wd /common 5487617 drwxr-xr-x 4096 r david screen 2880 text /common 2809219 -rwsr-xr-x 303544 r david screen 2880 0 /dev 61 crw------- ttyv1 rw david screen 2880 1 /dev 61 crw------- ttyv1 rw david screen 2880 2 /dev 61 crw------- ttyv1 rw root make 2723 root / 2 drwxr-xr-x 1024 r root make 2723 wd /common 4733955 drwxr-xr-x 512 r root make 2723 text /usr 378060 -r-xr-xr-x 401464 r root make 2723 0 /dev 125 crw--w---- pts/2 rw root make 2723 1 /dev 125 crw--w---- pts/2 rw root make 2723 2 /dev 125 crw--w---- pts/2 rw root make 2723 3 - - ?(tmpfs) - root make 2723 5* pipe c89feab8 <-> c89feb70 0 rw root make 2723 6* pipe c89feb70 <-> c89feab8 0 rw root csh 2686 root / 2 drwxr-xr-x 1024 r root csh 2686 wd /usr 71233 drwxr-xr-x 1024 r root csh 2686 text / 141345 -r-xr-xr-x 327768 r root csh 2686 15 /dev 125 crw--w---- pts/2 rw root csh 2686 16 /dev 125 crw--w---- pts/2 rw root csh 2686 17 /dev 125 crw--w---- pts/2 rw root csh 2686 18 /dev 125 crw--w---- pts/2 rw root csh 2686 19 /dev 125 crw--w---- pts/2 rw root script 2685 root / 2 drwxr-xr-x 1024 r root script 2685 wd /common 5487617 drwxr-xr-x 4096 r root script 2685 text /usr 378086 -r-xr-xr-x 7732 r root script 2685 0 /dev 117 crw--w---- pts/1 rw root script 2685 1 /dev 117 crw--w---- pts/1 rw root script 2685 2 /dev 117 crw--w---- pts/1 rw root script 2685 3 /common 5487714 -rw-r--r-- 35216 w root script 2685 4* pseudo-terminal master pts/2 rw david csh 2652 root / 2 drwxr-xr-x 1024 r david csh 2652 wd /common 5487617 drwxr-xr-x 4096 r david csh 2652 text / 141345 -r-xr-xr-x 327768 r david csh 2652 15 /dev 117 crw--w---- pts/1 rw david csh 2652 16 /dev 117 crw--w---- pts/1 rw david csh 2652 17 /dev 117 crw--w---- pts/1 rw david csh 2652 18 /dev 117 crw--w---- pts/1 rw david csh 2652 19 /dev 117 crw--w---- pts/1 rw root screen 2650 root / 2 drwxr-xr-x 1024 r root screen 2650 wd /common 5487617 drwxr-xr-x 4096 r root screen 2650 text /common 2809219 -rwsr-xr-x 303544 r root screen 2650 0 /dev 20 crw-rw-rw- null r root screen 2650 1 /dev 20 crw-rw-rw- null w root screen 2650 2 /dev 20 crw-rw-rw- null w root screen 2650 4 - - ?(tmpfs) - root screen 2650 5 / 165161 -rw-r--r-- 2136 r root screen 2650 6* pseudo-terminal master pts/1 rw david csh 2614 root / 2 drwxr-xr-x 1024 r david csh 2614 wd /common 5487617 drwxr-xr-x 4096 r david csh 2614 text / 141345 -r-xr-xr-x 327768 r david csh 2614 15 /dev 61 crw------- ttyv1 rw david csh 2614 16 /dev 61 crw------- ttyv1 rw david csh 2614 17 /dev 61 crw------- ttyv1 rw david csh 2614 18 /dev 61 crw------- ttyv1 rw david csh 2614 19 /dev 61 crw------- ttyv1 rw root xconsole 2613 root / 2 drwxr-xr-x 1024 r root xconsole 2613 wd - - ?(tmpfs) - root xconsole 2613 text /common 2808944 -r-xr-xr-x 12708 r root xconsole 2613 0 /dev 20 crw-rw-rw- null r root xconsole 2613 1 /var 141880 -rw-r--r-- 1787 w root xconsole 2613 2 /var 141880 -rw-r--r-- 1787 w root xconsole 2613 3* local stream c8bfad70 <-> c8bfac18 root xconsole 2613 4* pseudo-terminal master pts/0 rw root xconsole 2613 5 /dev 113 crw--w---- pts/0 rw root xdm 2607 root / 2 drwxr-xr-x 1024 r root xdm 2607 wd - - ?(tmpfs) - root xdm 2607 text /common 2808940 -r-xr-xr-x 85140 r root xdm 2607 0* local stream c8bfa0ac <-> c8bfa000 root xdm 2607 1* local stream c8bfaac0 <-> c8bfab6c root xdm 2607 2 /var 141880 -rw-r--r-- 1787 w root Xorg 2605 root / 2 drwxr-xr-x 1024 r root Xorg 2605 wd - - ?(tmpfs) - root Xorg 2605 text /common 2805744 -r-xr-xr-x 1695792 r root Xorg 2605 0 /var 141543 -rw-r--r-- 26634 w root Xorg 2605 1* internet6 stream tcp c8c4b768 root Xorg 2605 2 /var 141880 -rw-r--r-- 1787 w root Xorg 2605 3* internet stream tcp c8c4b4f0 root Xorg 2605 4* local stream c8bfa158 root Xorg 2605 5 /common 2967936 -r--r--r-- 31246 r root Xorg 2605 6 /dev 10 crw-r----- mem rw root Xorg 2605 7 /dev 68 crw------- ttyv8 rw root Xorg 2605 8 /dev 22 crw-r--r-- pci rw root Xorg 2605 11* local stream c8bfa000 <-> c8bfa0ac root Xorg 2605 12* local stream c8bfab6c <-> c8bfaac0 root Xorg 2605 13* local stream c8bfac18 <-> c8bfad70 root xdm 2603 root / 2 drwxr-xr-x 1024 r root xdm 2603 wd - - ?(tmpfs) - root xdm 2603 text /common 2808940 -r-xr-xr-x 85140 r root xdm 2603 0 /var 143918 -rw-r--r-- 6 rw root xdm 2603 2 /var 141880 -rw-r--r-- 1787 w root getty 2596 root / 2 drwxr-xr-x 1024 r root getty 2596 wd / 2 drwxr-xr-x 1024 r root getty 2596 text /usr 165002 -r-xr-xr-x 22048 r root getty 2596 0 /dev 51 crw------- ttyu0 rw root getty 2596 1 /dev 51 crw------- ttyu0 rw root getty 2596 2 /dev 51 crw------- ttyu0 rw root sh 2595 root / 2 drwxr-xr-x 1024 r root sh 2595 wd - - ?(tmpfs) - root sh 2595 text / 141356 -r-xr-xr-x 121404 r root sh 2595 10 /common 3204467 -r-xr-xr-x 964 r root getty 2594 root / 2 drwxr-xr-x 1024 r root getty 2594 wd / 2 drwxr-xr-x 1024 r root getty 2594 text /usr 165002 -r-xr-xr-x 22048 r root getty 2594 0 /dev 67 crw------- ttyv7 rw root getty 2594 1 /dev 67 crw------- ttyv7 rw root getty 2594 2 /dev 67 crw------- ttyv7 rw root getty 2593 root / 2 drwxr-xr-x 1024 r root getty 2593 wd / 2 drwxr-xr-x 1024 r root getty 2593 text /usr 165002 -r-xr-xr-x 22048 r root getty 2593 0 /dev 66 crw------- ttyv6 rw root getty 2593 1 /dev 66 crw------- ttyv6 rw root getty 2593 2 /dev 66 crw------- ttyv6 rw root getty 2592 root / 2 drwxr-xr-x 1024 r root getty 2592 wd / 2 drwxr-xr-x 1024 r root getty 2592 text /usr 165002 -r-xr-xr-x 22048 r root getty 2592 0 /dev 65 crw------- ttyv5 rw root getty 2592 1 /dev 65 crw------- ttyv5 rw root getty 2592 2 /dev 65 crw------- ttyv5 rw root getty 2591 root / 2 drwxr-xr-x 1024 r root getty 2591 wd / 2 drwxr-xr-x 1024 r root getty 2591 text /usr 165002 -r-xr-xr-x 22048 r root getty 2591 0 /dev 64 crw------- ttyv4 rw root getty 2591 1 /dev 64 crw------- ttyv4 rw root getty 2591 2 /dev 64 crw------- ttyv4 rw root getty 2590 root / 2 drwxr-xr-x 1024 r root getty 2590 wd / 2 drwxr-xr-x 1024 r root getty 2590 text /usr 165002 -r-xr-xr-x 22048 r root getty 2590 0 /dev 63 crw------- ttyv3 rw root getty 2590 1 /dev 63 crw------- ttyv3 rw root getty 2590 2 /dev 63 crw------- ttyv3 rw root getty 2589 root / 2 drwxr-xr-x 1024 r root getty 2589 wd / 2 drwxr-xr-x 1024 r root getty 2589 text /usr 165002 -r-xr-xr-x 22048 r root getty 2589 0 /dev 62 crw------- ttyv2 rw root getty 2589 1 /dev 62 crw------- ttyv2 rw root getty 2589 2 /dev 62 crw------- ttyv2 rw root login 2588 root / 2 drwxr-xr-x 1024 r root login 2588 wd /common 5487617 drwxr-xr-x 4096 r root login 2588 text /usr 378023 -r-sr-xr-x 21884 r root login 2588 0 /dev 61 crw------- ttyv1 rw root login 2588 1 /dev 61 crw------- ttyv1 rw root login 2588 2 /dev 61 crw------- ttyv1 rw root login 2588 3* local dgram c8bfaec8 <-> c8bfa560 root getty 2587 root / 2 drwxr-xr-x 1024 r root getty 2587 wd / 2 drwxr-xr-x 1024 r root getty 2587 text /usr 165002 -r-xr-xr-x 22048 r root getty 2587 0 /dev 60 crw------- ttyv0 rw root getty 2587 1 /dev 60 crw------- ttyv0 rw root getty 2587 2 /dev 60 crw------- ttyv0 rw root cron 2521 root / 2 drwxr-xr-x 1024 r root cron 2521 wd /var 23552 drwxr-x--- 512 r root cron 2521 text /usr 188677 -r-xr-xr-x 34396 r root cron 2521 0 /dev 20 crw-rw-rw- null rw root cron 2521 1 /dev 20 crw-rw-rw- null rw root cron 2521 2 /dev 20 crw-rw-rw- null rw root cron 2521 3 /var 143239 -rw------- 4 w smmsp sendmail 2514 root / 2 drwxr-xr-x 1024 r smmsp sendmail 2514 wd /var 141356 drwxrwx--- 512 r smmsp sendmail 2514 text /usr 165205 -r-xr-sr-x 686196 r smmsp sendmail 2514 0 /dev 20 crw-rw-rw- null r smmsp sendmail 2514 1 /dev 20 crw-rw-rw- null w smmsp sendmail 2514 2 /dev 20 crw-rw-rw- null w smmsp sendmail 2514 3* local dgram c8bfa204 <-> c8bfa4b4 smmsp sendmail 2514 4 /var 143216 -rw------- 50 w root sendmail 2510 root / 2 drwxr-xr-x 1024 r root sendmail 2510 wd /var 141343 drwxr-xr-x 11776 r root sendmail 2510 text /usr 165205 -r-xr-sr-x 686196 r root sendmail 2510 0 /dev 20 crw-rw-rw- null r root sendmail 2510 1 /dev 20 crw-rw-rw- null w root sendmail 2510 2 /dev 20 crw-rw-rw- null w root sendmail 2510 3* local dgram c8bfa2b0 <-> c8bfa560 root sendmail 2510 4* internet stream tcp c8c4bc58 root sendmail 2510 5 /var 142864 -rw------- 79 w root sshd 2502 root / 2 drwxr-xr-x 1024 r root sshd 2502 wd / 2 drwxr-xr-x 1024 r root sshd 2502 text /usr 188669 -r-xr-xr-x 232408 r root sshd 2502 0 /dev 20 crw-rw-rw- null rw root sshd 2502 1 /dev 20 crw-rw-rw- null rw root sshd 2502 2 /dev 20 crw-rw-rw- null rw root sshd 2502 3* internet6 stream tcp c8e0d4f0 root sshd 2502 4* internet stream tcp c8e0d278 www httpd 2501 root / 2 drwxr-xr-x 1024 r www httpd 2501 wd / 2 drwxr-xr-x 1024 r www httpd 2501 text /common 3443480 -rwxr-xr-x 1083729 r www httpd 2501 0 /dev 20 crw-rw-rw- null r www httpd 2501 1 /dev 20 crw-rw-rw- null w www httpd 2501 2 /var 141877 -rw-r--r-- 8338184 w www httpd 2501 3* internet6 stream tcp c8c4a278 www httpd 2501 4* internet stream tcp c8c4a000 www httpd 2501 5* pipe c89fe620 <-> c89fe6d8 0 rw www httpd 2501 6* pipe c89fe6d8 <-> c89fe620 0 rw www httpd 2501 7 /var 141905 -rw-r--r-- 14220044 w www httpd 2501 8 - - ?(tmpfs) - www httpd 2501 9 /var 142285 -rw------- 0 w www httpd 2501 10 /var 142285 -rw------- 0 w www httpd 2501 11 - - ?(tmpfs) - www httpd 2500 root / 2 drwxr-xr-x 1024 r www httpd 2500 wd / 2 drwxr-xr-x 1024 r www httpd 2500 text /common 3443480 -rwxr-xr-x 1083729 r www httpd 2500 0 /dev 20 crw-rw-rw- null r www httpd 2500 1 /dev 20 crw-rw-rw- null w www httpd 2500 2 /var 141877 -rw-r--r-- 8338184 w www httpd 2500 3* internet6 stream tcp c8c4a278 www httpd 2500 4* internet stream tcp c8c4a000 www httpd 2500 5* pipe c89fe620 <-> c89fe6d8 0 rw www httpd 2500 6* pipe c89fe6d8 <-> c89fe620 0 rw www httpd 2500 7 /var 141905 -rw-r--r-- 14220044 w www httpd 2500 8 - - ?(tmpfs) - www httpd 2500 9 /var 142285 -rw------- 0 w www httpd 2500 10 /var 142285 -rw------- 0 w www httpd 2500 11 - - ?(tmpfs) - www httpd 2499 root / 2 drwxr-xr-x 1024 r www httpd 2499 wd / 2 drwxr-xr-x 1024 r www httpd 2499 text /common 3443480 -rwxr-xr-x 1083729 r www httpd 2499 0 /dev 20 crw-rw-rw- null r www httpd 2499 1 /dev 20 crw-rw-rw- null w www httpd 2499 2 /var 141877 -rw-r--r-- 8338184 w www httpd 2499 3* internet6 stream tcp c8c4a278 www httpd 2499 4* internet stream tcp c8c4a000 www httpd 2499 5* pipe c89fe620 <-> c89fe6d8 0 rw www httpd 2499 6* pipe c89fe6d8 <-> c89fe620 0 rw www httpd 2499 7 /var 141905 -rw-r--r-- 14220044 w www httpd 2499 8 - - ?(tmpfs) - www httpd 2499 9 /var 142285 -rw------- 0 w www httpd 2499 10 /var 142285 -rw------- 0 w www httpd 2499 11 - - ?(tmpfs) - www httpd 2498 root / 2 drwxr-xr-x 1024 r www httpd 2498 wd / 2 drwxr-xr-x 1024 r www httpd 2498 text /common 3443480 -rwxr-xr-x 1083729 r www httpd 2498 0 /dev 20 crw-rw-rw- null r www httpd 2498 1 /dev 20 crw-rw-rw- null w www httpd 2498 2 /var 141877 -rw-r--r-- 8338184 w www httpd 2498 3* internet6 stream tcp c8c4a278 www httpd 2498 4* internet stream tcp c8c4a000 www httpd 2498 5* pipe c89fe620 <-> c89fe6d8 0 rw www httpd 2498 6* pipe c89fe6d8 <-> c89fe620 0 rw www httpd 2498 7 /var 141905 -rw-r--r-- 14220044 w www httpd 2498 8 - - ?(tmpfs) - www httpd 2498 9 /var 142285 -rw------- 0 w www httpd 2498 10 /var 142285 -rw------- 0 w www httpd 2498 11 - - ?(tmpfs) - www httpd 2497 root / 2 drwxr-xr-x 1024 r www httpd 2497 wd / 2 drwxr-xr-x 1024 r www httpd 2497 text /common 3443480 -rwxr-xr-x 1083729 r www httpd 2497 0 /dev 20 crw-rw-rw- null r www httpd 2497 1 /dev 20 crw-rw-rw- null w www httpd 2497 2 /var 141877 -rw-r--r-- 8338184 w www httpd 2497 3* internet6 stream tcp c8c4a278 www httpd 2497 4* internet stream tcp c8c4a000 www httpd 2497 5* pipe c89fe620 <-> c89fe6d8 0 rw www httpd 2497 6* pipe c89fe6d8 <-> c89fe620 0 rw www httpd 2497 7 /var 141905 -rw-r--r-- 14220044 w www httpd 2497 8 - - ?(tmpfs) - www httpd 2497 9 /var 142285 -rw------- 0 w www httpd 2497 10 /var 142285 -rw------- 0 w www httpd 2497 11 - - ?(tmpfs) - root httpd 2468 root / 2 drwxr-xr-x 1024 r root httpd 2468 wd / 2 drwxr-xr-x 1024 r root httpd 2468 text /common 3443480 -rwxr-xr-x 1083729 r root httpd 2468 0 /dev 20 crw-rw-rw- null r root httpd 2468 1 /dev 20 crw-rw-rw- null w root httpd 2468 2 /var 141877 -rw-r--r-- 8338184 w root httpd 2468 3* internet6 stream tcp c8c4a278 root httpd 2468 4* internet stream tcp c8c4a000 root httpd 2468 5* pipe c89fe620 <-> c89fe6d8 0 rw root httpd 2468 6* pipe c89fe6d8 <-> c89fe620 0 rw root httpd 2468 7 /var 141905 -rw-r--r-- 14220044 w root httpd 2468 8 - - ?(tmpfs) - root httpd 2468 9 /var 142285 -rw------- 0 w root snmpd 2409 root / 2 drwxr-xr-x 1024 r root snmpd 2409 wd / 2 drwxr-xr-x 1024 r root snmpd 2409 text /common 3442277 -rwxr-xr-x 25460 r root snmpd 2409 0 /dev 20 crw-rw-rw- null rw root snmpd 2409 1 /dev 20 crw-rw-rw- null rw root snmpd 2409 2 /dev 20 crw-rw-rw- null rw root snmpd 2409 3 /var 141881 -rw-r--r-- 5468 w root snmpd 2409 4 /dev 10 crw-r----- mem r root snmpd 2409 5 /dev 11 crw-r----- kmem r root snmpd 2409 6* pipe c89fe000 <-> c89fe0b8 0 rw root snmpd 2409 7* pipe c89fe0b8 <-> c89fe000 0 rw root snmpd 2409 8 /var 141850 -rw-r----- 728 r root snmpd 2409 9* internet dgram udp c8be2e9c root snmpd 2409 10* internet stream tcp c8c4a4f0 root moused 2373 root / 2 drwxr-xr-x 1024 r root moused 2373 wd / 2 drwxr-xr-x 1024 r root moused 2373 text /usr 188755 -r-xr-xr-x 36216 r root moused 2373 0 /dev 20 crw-rw-rw- null rw root moused 2373 1 /dev 20 crw-rw-rw- null rw root moused 2373 2 /dev 20 crw-rw-rw- null rw root moused 2373 3 /dev 49 crw-rw-rw- psm0 rw root moused 2373 4 /dev 76 crw------- consolectl rw root moused 2373 5 /var 141548 -rw------- 4 w root powerd 2261 root / 2 drwxr-xr-x 1024 r root powerd 2261 wd / 2 drwxr-xr-x 1024 r root powerd 2261 text /usr 188781 -r-xr-xr-x 13076 r root powerd 2261 0 /dev 20 crw-rw-rw- null rw root powerd 2261 1 /dev 20 crw-rw-rw- null rw root powerd 2261 2 /dev 20 crw-rw-rw- null rw root powerd 2261 3 /var 141861 -rw------- 4 w root powerd 2261 4* local stream c8bfa8bc <-> c8bfa968 root lpd 2223 root / 2 drwxr-xr-x 1024 r root lpd 2223 wd / 2 drwxr-xr-x 1024 r root lpd 2223 text /usr 188692 -r-xr-xr-x 76360 r root lpd 2223 0 /dev 20 crw-rw-rw- null rw root lpd 2223 1 /dev 20 crw-rw-rw- null rw root lpd 2223 2 /dev 20 crw-rw-rw- null rw root lpd 2223 3* local dgram c8bfa6b8 <-> c8bfa560 root lpd 2223 4 /var 141561 -rw-rw-r-- 5 w root lpd 2223 5* local stream c8bfa764 root lpd 2223 6* internet6 stream tcp c8c4a9e0 root lpd 2223 7* internet stream tcp c8c4a768 root rpcbind 2071 root / 2 drwxr-xr-x 1024 r root rpcbind 2071 wd / 2 drwxr-xr-x 1024 r root rpcbind 2071 text /usr 188822 -r-xr-xr-x 39588 r root rpcbind 2071 0 /dev 20 crw-rw-rw- null rw root rpcbind 2071 1 /dev 20 crw-rw-rw- null rw root rpcbind 2071 2 /dev 20 crw-rw-rw- null rw root rpcbind 2071 3 /var 141802 -r--r--r-- 0 r root rpcbind 2071 4* internet6 dgram udp c8be2ce4 root rpcbind 2071 5* local stream c8bfa60c root rpcbind 2071 6* internet6 dgram udp c8be2604 root rpcbind 2071 7* internet6 dgram udp c8be27bc root rpcbind 2071 8* internet6 stream tcp c8c4b000 root rpcbind 2071 9* internet dgram udp c8be26e0 root rpcbind 2071 10* internet dgram udp c8be2a50 root rpcbind 2071 11* internet stream tcp c8c4ac58 root syslogd 2045 root / 2 drwxr-xr-x 1024 r root syslogd 2045 wd / 2 drwxr-xr-x 1024 r root syslogd 2045 text /usr 188900 -r-xr-xr-x 35976 r root syslogd 2045 0 /dev 20 crw-rw-rw- null rw root syslogd 2045 1 /dev 20 crw-rw-rw- null rw root syslogd 2045 2 /dev 20 crw-rw-rw- null rw root syslogd 2045 3 /var 141789 -rw------- 4 w root syslogd 2045 4* local dgram c8bfa4b4 root syslogd 2045 5* local dgram c8bfa560 root syslogd 2045 6* internet6 dgram udp c8be2294 root syslogd 2045 7* internet dgram udp c8be244c root syslogd 2045 8 /dev 28 crw------- klog r root syslogd 2045 10 - - bad - root syslogd 2045 11 /var 143696 -rw-r--r-- 122651 w root syslogd 2045 12 /var 143217 -rw------- 13540 w root syslogd 2045 13 /var 143350 -rw------- 95171 w root syslogd 2045 14 /var 144179 -rw-r----- 3016 w root syslogd 2045 15 /var 143948 -rw-r--r-- 68531 w root syslogd 2045 16 /var 141878 -rw-r--r-- 4035 w root syslogd 2045 17 /var 144183 -rw------- 35145 w root syslogd 2045 18 /var 141832 -rw------- 30221 w root syslogd 2045 19 /var 141874 -rw-r----- 71387 w root devd 1756 root / 2 drwxr-xr-x 1024 r root devd 1756 wd / 2 drwxr-xr-x 1024 r root devd 1756 text / 117853 -r-xr-xr-x 400644 r root devd 1756 0 /dev 20 crw-rw-rw- null rw root devd 1756 1 /dev 20 crw-rw-rw- null rw root devd 1756 2 /dev 20 crw-rw-rw- null rw root devd 1756 3 / 164883 drwxr-xr-x 512 r root devd 1756 4 /dev 3 crw------- devctl r root devd 1756 5* local stream c8bfa810 root devd 1756 6 /var 141551 -rw------- 4 w root devd 1756 7* local stream c8bfa968 <-> c8bfa8bc root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 117868 -r-xr-xr-x 677472 r root kernel 0 root / 2 drwxr-xr-x 1024 r root kernel 0 wd / 2 drwxr-xr-x 1024 r ------------------------------------------------------------------------ dmesg 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 #60 r210190M: Sat Jul 17 16:10:49 PDT 2010 root@localhost:/usr/obj/usr/src/sys/CANARY i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc5400000 MEMGUARD map limit: 0xc7401000 MEMGUARD map size: 33558528 (Bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc12e8000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc12e814c. Preloaded elf module "/boot/kernel/if_an.ko" at 0xc12e81f8. Preloaded elf module "/boot/kernel/if_iwi.ko" at 0xc12e82a4. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc12e8350. Preloaded elf module "/boot/kernel/iwi_bss.ko" at 0xc12e83fc. Preloaded elf module "/boot/kernel/iwi_ibss.ko" at 0xc12e84a8. Preloaded elf module "/boot/kernel/iwi_monitor.ko" at 0xc12e8558. Preloaded elf module "/boot/kernel/radeon.ko" at 0xc12e8608. Preloaded elf module "/boot/kernel/drm.ko" at 0xc12e86b4. Calibrating TSC clock ... TSC clock: 2392989428 Hz CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.40GHz (2392.99-MHz 686-class CP= U) Origin =3D "GenuineIntel" Id =3D 0xf27 Family =3D f Model =3D 2 Stepp= ing =3D 7 Features=3D0xbfebf9ff Features2=3D0x400 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte = line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte lin= e size real memory =3D 2147483648 (2048 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001426000 - 0x000000007db8cfff, 2088136704 bytes (509799 pages) avail memory =3D 2086281216 (1989 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry =3D 0xffe90 (c00ffe90) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xf0000+0xbfee pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry =3D f0000:e2f4 Rev =3D 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: x86bios: IVT 0x000000-0x0004ff at 0xc0000000 x86bios: SSEG 0x010000-0x01ffff at 0xc51e8000 x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000 x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000 WARNING: VIMAGE (virtualized network stack) is a highly experimental featur= e. ULE: setup cpu 0 wlan: <802.11 Link Layer> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [10= 24] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_ra= te_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 firmware: 'iwi_bss' version 300: 191154 bytes loaded at 0xc11d0000 firmware: 'iwi_ibss' version 300: 185428 bytes loaded at 0xc1201764 firmware: 'iwi_monitor' version 300: 187836 bytes loaded at 0xc1231000 kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: random: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 ACPI: RSDP 0xfde50 00014 (v00 DELL ) ACPI: RSDT 0xfde64 0002C (v01 DELL CPi R 27D40107 ASL 00000061) ACPI: FACP 0xfde90 00074 (v01 DELL CPi R 27D40107 ASL 00000061) ACPI: DSDT 0xfffe4000 0314E (v01 INT430 SYSFexxx 00001001 MSFT 0100000E) ACPI: FACS 0x7ffff800 00040 ACPI: BOOT 0xfdf04 00028 (v01 DELL CPi R 27D40107 ASL 00000061) acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: wakeup code va 0xc51e7000 pa 0x1000 atpic: Programming IRQ9 as level/low pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D1a308086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISAB.FDIS -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.USB1.AD1_ -> bus 0 dev 29 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISAB.PIRQ -> bus 0 dev 31 func 0 acpi0: reservation of 0, 9fc00 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 9 10 11 Validation 0 11 N 0 9 10 11 After Disable 0 255 N 0 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 Validation 0 255 N 0 5 7 After Disable 0 255 N 0 5 7 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 9 10 11 Validation 0 11 N 0 9 10 11 After Disable 0 255 N 0 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 7 9 10 11 Validation 0 11 N 0 5 7 9 10 11 After Disable 0 255 N 0 5 7 9 10 11 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.31.INTA at func 1: 255 ACPI: Found matching pin for 0.31.INTB at func 5: 11 pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid ACPI: Found matching pin for 0.29.INTA at func 0: 11 ACPI: Found matching pin for 0.29.INTC at func 2: 11 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x1a30, revid=3D0x04 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xe8000000, size 26, ena= bled found-> vendor=3D0x8086, dev=3D0x1a31, revid=3D0x04 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x0e (3500 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2482, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0xbf80, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LNKA:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LNKA found-> vendor=3D0x8086, dev=3D0x2487, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0xbf20, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.PCI0.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \\_SB_.PCI0.LNKC found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0x42 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0080, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x248c, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x010f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x248a, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 map[20]: type I/O Port, range 32, base 0xbfa0, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=3D0x8086, dev=3D0x2485, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D5 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled map[14]: type I/O Port, range 32, base 0xdc80, size 6, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LNKB:0) pci_link1: Picked IRQ 9 with weight 0 pcib0: slot 31 INTB routed to irq 9 via \\_SB_.PCI0.LNKB found-> vendor=3D0x8086, dev=3D0x2486, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D6 class=3D07-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[10]: type I/O Port, range 32, base 0xd400, size 8, enabled map[14]: type I/O Port, range 32, base 0xdc00, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LNKB:0) pcib0: slot 31 INTB routed to irq 9 via \\_SB_.PCI0.LNKB agp0: on hostb0 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xe0000000-0xe7ffffff ACPI: Found matching pin for 1.0.INTA at func 0: 11 pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x4c66, revid=3D0x01 domain=3D0, bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x01a7, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 27, ena= bled pcib1: requested memory range 0xe0000000-0xe7ffffff: good map[14]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib1: requested I/O range 0xc000-0xc0ff: in range map[18]: type Memory, range 32, base 0xfcff0000, size 16, enabled pcib1: requested memory range 0xfcff0000-0xfcffffff: good pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKA vgapci0: port 0xc000-0xc0ff mem 0xe0000000-0xe7fff= fff,0xfcff0000-0xfcffffff irq 11 at device 0.0 on pci1 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe8000000 64MB info: [drm] Initialized radeon 1.31.0 20080613 uhci0: port 0xbf80-0xbf9f i= rq 11 at device 29.0 on pci0 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xbf20-0xbf3f i= rq 11 at device 29.2 on pci0 uhci1: [MPSAFE] uhci1: [ITHREAD] usbus1: on uhci1 pcib2: at device 30.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 16 pcib2: I/O decode 0xe000-0xffff pcib2: memory decode 0xf4000000-0xfbffffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. ACPI: Found matching pin for 2.1.INTA at func 0: 255 ACPI: Found matching pin for 2.1.INTA at func 1: 255 ACPI: Found matching pin for 2.1.INTA at func 2: 11 ACPI: Found matching pin for 2.3.INTA at func 0: 11 ACPI: Found matching pin for 2.0.INTA at func 0: 11 pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x10b7, dev=3D0x9200, revid=3D0x78 domain=3D0, bus=3D2, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x0a (2500 ns), maxlat=3D0x0a (2500 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xec80, size 7, enabled pcib2: requested I/O range 0xec80-0xecff: in range map[14]: type Memory, range 32, base 0xf8fffc00, size 7, enabled pcib2: requested memory range 0xf8fffc00-0xf8fffc7f: good pcib2: matched entry for 2.0.INTA (src \\_SB_.PCI0.LNKC:0) pcib2: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKC found-> vendor=3D0x104c, dev=3D0xac42, revid=3D0x00 domain=3D0, bus=3D2, slot=3D1, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x07 (1750 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled found-> vendor=3D0x104c, dev=3D0xac42, revid=3D0x00 domain=3D0, bus=3D2, slot=3D1, func=3D1 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x07 (1750 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled found-> vendor=3D0x104c, dev=3D0x8027, revid=3D0x00 domain=3D0, bus=3D2, slot=3D1, func=3D2 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0116, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 (1000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf8fff000, size 11, enabled pcib2: requested memory range 0xf8fff000-0xf8fff7ff: good map[14]: type Memory, range 32, base 0xf8ff8000, size 14, enabled pcib2: requested memory range 0xf8ff8000-0xf8ffbfff: good pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKD found-> vendor=3D0x8086, dev=3D0x4220, revid=3D0x05 domain=3D0, bus=3D2, slot=3D3, func=3D0 class=3D02-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0016, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x18 (6000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf8ffe000, size 12, enabled pcib2: requested memory range 0xf8ffe000-0xf8ffefff: good pcib2: matched entry for 2.3.INTA (src \\_SB_.PCI0.LNKD:0) pcib2: slot 3 INTA routed to irq 11 via \\_SB_.PCI0.LNKD xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec80-0xecff mem 0xf8fffc00-0= xf8fffc7f irq 11 at device 0.0 on pci2 xl0: using memory mapped I/O Entered ifindex_alloc_locked(*0) ifindex_alloc_locked(*0): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*0): Scanning slots up to 0 ifindex_alloc_locked(*0): Exited loop; idx =3D 1 xl0: media options word: a xl0: found MII/AUTO miibus0: on xl0 ukphy0: PHY 24 on miibus0 ukphy0: OUI 0x00105a, model 0x0000, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:08:74:e9:c9:41 xl0: [MPSAFE] xl0: [ITHREAD] cbb0: at device 1.0 on pci2 pcib2: cbb0 requested memory range 0x0-0xffffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cbb0: Found memory at 80000000 cbb0: Secondary bus is 4 cbb0: Setting primary bus to 2 cbb0: Secondary bus set to 3 subbus 4 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKD cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xac42104c 0x02100007 0x06070000 0x00822008=20 0x10: 0x80000000 0x020000a0 0x20040302 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc=20 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010b=20 0x40: 0x00d51028 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x3024d021 0x00000600 0x000f0000 0x05033002=20 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 cbb1: at device 1.1 on pci2 pcib2: cbb1 requested memory range 0x0-0xffffffff: good cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80001000 cbb1: Found memory at 80001000 cbb1: Secondary bus is 5 cbb1: Setting primary bus to 2 cbb1: Secondary bus set to 5 subbus 6 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKD cbb1: [MPSAFE] cbb1: [FILTER] cbb1: PCI Configuration space: 0x00: 0xac42104c 0x02100007 0x06070000 0x00822008=20 0x10: 0x80001000 0x020000a0 0x20060502 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc=20 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010b=20 0x40: 0x00d51028 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x3024d021 0x00000600 0x000f0000 0x05033002=20 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 fwohci0: mem 0xf8fff000-0xf8fff7ff,0xf8ff8000-0= xf8ffbfff irq 11 at device 1.2 on pci2 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 42:4f:c0:00:07:2c:30:41 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 42:4f:c0:2c:30:41 Entered ifindex_alloc_locked(*49353) ifindex_alloc_locked(*49353): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*49353): Scanning slots up to 1 ifindex_alloc_locked(*49353): Checking idx: 1 ifindex_alloc_locked(*49353): Exited loop; idx =3D 1 fwe0: bpf attached fwe0: Ethernet address: 42:4f:c0:2c:30:41 fwip0: on firewire0 Entered ifindex_alloc_locked(*49474) ifindex_alloc_locked(*49474): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*49474): Scanning slots up to 1 ifindex_alloc_locked(*49474): Checking idx: 1 ifindex_alloc_locked(*49474): Exited loop; idx =3D 1 fwip0: bpf attached fwip0: Firewire address: 42:4f:c0:00:07:2c:30:41 @ 0xfffe00000000, S400, ma= xrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xe0c8c0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER mode iwi0: mem 0xf8ffe000-0xf8ffefff irq 11 at de= vice 3.0 on pci2 Entered ifindex_alloc_locked(*49474) ifindex_alloc_locked(*49474): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*49474): Scanning slots up to 1 ifindex_alloc_locked(*49474): Checking idx: 1 ifindex_alloc_locked(*49474): Exited loop; idx =3D 1 iwi0: [MPSAFE] iwi0: [ITHREAD] iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 ata0: on atapci0 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ata0: stat0=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0: stat0=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0: stat0=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0: stat0=3D0xd0 err=3D0xd0 lsb=3D0xd0 msb=3D0xd0 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x20001 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 ata1: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x0 ata1: [MPSAFE] ata1: [ITHREAD] pcm0: port 0xd800-0xd8ff,0xdc80-0xdcbf irq 9 at devi= ce 31.5 on pci0 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: pcm0: Codec features mic channel, tone, simulated stereo, bass boost, 20 bi= t DAC, 18 bit ADC, 5 bit master volume, SRS 3D Stereo Enhancement pcm0: Primary codec extended features variable rate PCM, variable rate mic,= AMAP pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "bass": pcm0: Mixer "treble": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e pcm0: sndbuf_setmap 1504000, 4000; 0xc5325000 -> 1504000 pcm0: sndbuf_setmap 1508000, 4000; 0xc5329000 -> 1508000 pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: flags 0x6000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00006000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atrtc0: [MPSAFE] atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [MPSAFE] attimer0: [FILTER] Event timer "i8254" frequency 1193182 Hz quality 100 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on= acpi0 fdc0: ic_type 90 part_id 80 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: fast interrupt uart0: console (9600,n,8,1) ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 Entered ifindex_alloc_locked(*0) ifindex_alloc_locked(*0): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*0): Scanning slots up to 1 ifindex_alloc_locked(*0): Checking idx: 1 ifindex_alloc_locked(*0): Exited loop; idx =3D 1 plip0: bpf attached plip0: [MPSAFE] plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0 pcf0 failed to probe on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices acpi_perf0: on cpu0 p4tcc0: on cpu0 Device configuration finished. Reducing kern.maxvnodes 133845 -> 100000 procfs registered Timecounter "TSC" frequency 2392989428 Hz quality 800 Starting kernel event timers: i8254 @ 1000Hz, RTC @ 128Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining Linux ELF exec handler installed firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forward= ing enabled, default to deny, logging disabled Entered ifindex_alloc_locked(*49307) ifindex_alloc_locked(*49307): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*49307): Scanning slots up to 1 ifindex_alloc_locked(*49307): Checking idx: 1 ifindex_alloc_locked(*49307): Exited loop; idx =3D 1 ipfw0: bpf attached DUMMYNET 0xc75bc980 with IPv6 initialized (100409) Entered ifindex_alloc_locked(*51035) ifindex_alloc_locked(*51035): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*51035): Scanning slots up to 1 ifindex_alloc_locked(*51035): Checking idx: 1 ifindex_alloc_locked(*51035): Exited loop; idx =3D 1 lo0: bpf attached load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded hptrr: no controller detected. ata0: Identifying devices: 00020001 ata0: New devices: 00020001 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 Status is 0x30000006 Status is 0x30000006 ugen0.1: at usbus0 uhub0: on usbus0 Expensive timeout(9) function: 0xc08cc8d0(0xc79462c0) 0.110158134 s ugen1.1: at usbus1 uhub1: on usbus1 fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times battery0: battery initialization start battery0: battery initialization done, tried 1 times battery1: battery initialization start battery1: battery initialization done, tried 1 times ata0-slave: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D80 wire ad0: setting UDMA100 ad0: 114473MB at ata0-master UDMA100=20 ad0: 234441648 sectors [232581C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 acd0: setting UDMA33 acd0: CDRW drive at ata0 as slave acd0: 2048KB buffer, UDMA33=20 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata1: Identifying devices: 00000000 ata1: New devices: 00000000 pcm0: measured ac97 link rate at 48013 Hz, will use 48000 Hz acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00=20 (probe7:ata0:0:1:0): SCSI status error (probe7:ata0:0:1:0): INQUIRY. CDB: 12 1 0 0 ff 0=20 (probe7:ata0:0:1:0): CAM status: SCSI Status Error (probe7:ata0:0:1:0): SCSI status: Check Condition (probe7:ata0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in= CDB) (probe7:ata0:0:1:0): Error 22, Unretryable error (probe7:ata0:0:1:0): Down reving Protocol Version from 2 to 0? (probe7:ata0:0:1:0): SCSI status error (probe7:ata0:0:1:0): TEST UNIT READY. CDB: 0 0 0 0 0 0=20 (probe7:ata0:0:1:0): CAM status: SCSI Status Error (probe7:ata0:0:1:0): SCSI status: Check Condition (probe7:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe7:ata0:0:1:0): Error 6, Unretryable error fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout (probe0:sbp0:0:0:0): Error 22, Unretryable error (probe1:sbp0:0:1:0): Error 22, Unretryable error (probe2:sbp0:0:2:0): Error 22, Unretryable error (probe4:sbp0:0:4:0): Error 22, Unretryable error (probe5:sbp0:0:5:0): Error 22, Unretryable error (probe6:sbp0:0:6:0): Error 22, Unretryable error (probe3:sbp0:0:3:0): Error 22, Unretryable error fdc0: input ready timeout pass0 at ata0 bus 0 scbus1 target 1 lun 0 pass0: Removable CD-ROM SCSI-0 device=20 pass0: 33.000MB/s transfers (cd0:ata0:0:1:0): SCSI status error (cd0:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (cd0:ata0:0:1:0): CAM status: SCSI Status Error (cd0:ata0:0:1:0): SCSI status: Check Condition (cd0:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:1:0): Error 6, Unretryable error cd0 at ata0 bus 0 scbus1 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. GEOM: new disk cd0 (cd0:ata0:0:1:0): SCSI status error (cd0:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (cd0:ata0:0:1:0): CAM status: SCSI Status Error (cd0:ata0:0:1:0): SCSI status: Check Condition (cd0:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:1:0): Error 6, Unretryable error (cd0:ata0:0:1:0): SCSI status error (cd0:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0=20 (cd0:ata0:0:1:0): CAM status: SCSI Status Error (cd0:ata0:0:1:0): SCSI status: Check Condition (cd0:ata0:0:1:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:1:0): Error 6, Unretryable error Trying to mount root from ufs:/dev/ad0s4a ct_to_ts([2010-07-18 13:00:37]) =3D 1279458037.000000000 start_init: trying /sbin/init Setting hostuuid: 44454c4c-5300-1037-8044-c4c04f4a3231. Setting hostid: 0x910528f4. Entropy harvesting: interrupts ethernet point_to_point kickstart =2E Starting file system checks: /dev/ad0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4a: clean, 511618 free (1042 frags, 63822 blocks, 0.1% fragmentati= on) /dev/ad0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2a: clean, 546758 free (2550 frags, 68026 blocks, 0.3% fragmentati= on) /dev/ad0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2d: clean, 996751 free (33879 frags, 120359 blocks, 1.9% fragmenta= tion) /dev/ad0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4d: clean, 914242 free (29890 frags, 110544 blocks, 1.7% fragmenta= tion) /dev/ad0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4f: clean, 1420218 free (106018 frags, 164275 blocks, 1.7% fragmen= tation) /dev/ad0s4g: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4g: clean, 13491004 free (186292 frags, 1663089 blocks, 0.7% fragm= entation) /dev/ad0s4h: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4h: clean, 4180440 free (14184 frags, 520782 blocks, 0.1% fragment= ation) /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 512052 free (500 frags, 63944 blocks, 0.1% fragmentatio= n) /dev/ad0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1d: clean, 915274 free (282 frags, 114374 blocks, 0.0% fragmentati= on) /dev/ad0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3a: clean, 519959 free (1751 frags, 64776 blocks, 0.2% fragmentati= on) /dev/ad0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s3d: clean, 968566 free (48950 frags, 114952 blocks, 2.8% fragmenta= tion) /dev/ad0s4e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s4e: clean, 408503 free (2383 frags, 50765 blocks, 0.2% fragmentati= on) Mounting local file systems: WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. =2E Setting hostname: localhost =2E Entered ifindex_alloc_locked(*51390) ifindex_alloc_locked(*51390): Passed IFNET_WLOCK_ASSERT() ifindex_alloc_locked(*51390): Scanning slots up to 1 ifindex_alloc_locked(*51390): Checking idx: 1 ifindex_alloc_locked(*51390): Exited loop; idx =3D 1 wlan1: bpf attached wlan1: bpf attached wlan1: Ethernet address: 00:0e:35:aa:11:ca Starting wpa_supplicant. Starting Network: lo0 xl0 fwe0 fwip0 iwi0 plip0 ipfw0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000=20 inet6 ::1 prefixlen 128=20 inet6 fe80::1%xl0 prefixlen 64 scopeid 0x1=20 nd6 options=3D21 xl0: flags=3D8802 metric 0 mtu 1500 options=3D80009 ether 00:08:74:e9:c9:41 nd6 options=3D29 media: Ethernet autoselect (none) status: no carrier fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 42:4f:c0:2c:30:41 nd6 options=3D29 ch 1 dma -1 fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 42.4f.c0.0.7.2c.30.41.a.2.ff.fe.0.0.0.0 nd6 options=3D29 iwi0: flags=3D8802 metric 0 mtu 2290 ether 00:0e:35:aa:11:ca nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier plip0: flags=3D8810 metric 0 mtu 1500 nd6 options=3D29 ipfw0: flags=3D8801 metric 0 mtu 65536 nd6 options=3D29 Starting devd. Starting Network: xl0. xl0: flags=3D8802 metric 0 mtu 1500 options=3D80009 ether 00:08:74:e9:c9:41 nd6 options=3D29 media: Ethernet autoselect (none) status: no carrier Starting Network: fwe0. fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 42:4f:c0:2c:30:41 nd6 options=3D29 ch 1 dma -1 Starting Network: fwip0. fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 42.4f.c0.0.7.2c.30.41.a.2.ff.fe.0.0.0.0 nd6 options=3D29 ifconfig:=20 create: bad value Starting wpa_supplicant. Starting Network: iwi0. iwi0: flags=3D8803 metric 0 mtu 2290 ether 00:0e:35:aa:11:ca nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated Starting Network: plip0. plip0: flags=3D8810 metric 0 mtu 1500 nd6 options=3D29 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny log ip from any to any ipoptions ssrr,lsrr,rr,ts 00500 deny log ip from any to any frag 00600 allow icmp from any to any icmptypes 0,3,4,8,11,12 00700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 keep-state 00800 deny ip from any to 255.255.255.255 00900 deny ip from 255.255.255.255 to any 01000 allow udp from any 67 to any dst-port 68 in keep-state 01100 deny log ip from any to any Firewall rules loaded. Firewall logging enabled. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat /usr/local/lib/gcc44 /usr/local/lib/gegl-0.1 /usr/local/lib/grap= hviz /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/pth /usr/local/= lib/qt4 a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Clearing /tmp (X related). Creating and/or trimming log files =2E Starting syslogd. No core dumps found. Additional ABI support: linux =2E Starting rpcbind. iwi0: need multicast update callback ipfw: 1100 Deny ICMPv6:143.0 [::] [ff02::16] out via wlan1 Starting lpd. Updating motd: =2E Starting powerd. nic_init invoked with argument faststart; flags: -n 1=20 Starting nic_init. :: localhost done ::ffff:0.0.0.0 localhost done fe80:: localhost done ff02:: localhost done Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny log ip from any to any ipoptions ssrr,lsrr,rr,ts 00500 deny log ip from any to any frag 00600 allow icmp from any to any icmptypes 0,3,4,8,11,12 00700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 keep-state 00800 deny ip from any to 255.255.255.255 00900 deny ip from 255.255.255.255 to any 01000 allow udp from any 67 to any dst-port 68 in keep-state 01100 deny log ip from any to any Jul 18 06:00:53 localhost wpa_supplicant[1511]: Failed to disable WPA in th= e driver. ipfw: 1100 Deny ICMPv6:143.0 [::] [ff02::16] out via wlan1 wlan1: flags=3D8843 metric 0 mtu 15= 00 ether 00:0e:35:aa:11:ca nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 3 (2422 MHz 11g) country US authmode WPA1+WPA2/802.11i privacy OFF txpower 0 bmiss 24 scanvalid 60 protmode CTS wme iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Script /usr/local/etc/rc.d/nic_init interrupted Starting default moused iwi0: firmware error =2E iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Starting snmpd. iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Setting the mixer vol from 25:25 to 25:25. iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Performing sanity check on apache22 configuration: iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error httpd: Could not reliably determine the server's fully qualified domain nam= e, using ::1 for ServerName Syntax OK iwi0: firmware error Starting apache22. iwi0: firmware error iwi0: firmware error httpd: Could not reliably determine the server's fully qualified domain nam= e, using ::1 for ServerName iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Configuring syscons: blanktime =2E Starting sshd. iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Starting cron. iwi0: firmware error Local package initialization: iwi0: firmware error rtc link_elf: symbol callout_reset undefinediwi0: firmware error kldload:=20 can't load /usr/local/modules/rtc.ko :=20 No such file or directory =2E iwi0: firmware error iwi0: firmware error Starting background file system checks in 60 seconds. iwi0: firmware error Sun Jul 18 06:01:13 PDT 2010 iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error lock order reversal: 1st 0xd9502968 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2607iwi0: f= irmware error 2nd 0xc8a32e00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: db_trace_self_wrapper(c0cca5e8,d974f858,c08d7a35,ciwi0: firmware error 08c6ccb,c0ccd7be,...) at 0xc04dab26 =3D db_trace_self_wrapper+0x26 kdb_baiwi0: firmware error cktrace(c08c6ccb,c0ccd7be,c7548370,c754c470,d974f8b4,...) at 0xc08ciwi0: fi= rmware error 2bc9 =3D kdb_backtrace+0x29 _witness_debugger(c0ccd7be,c8a32e00,c0cf45f3,c754ciwi0: firmware error 470,c0cf4278,...) at 0xc08d7a35 =3D _witness_debugger+0x25 witness_checiwi0: firmware error korder(c8a32e00,9,c0cf4278,11b,0,...) at 0xc08d8c59 =3D witness_checkorder+= 0x839iwi0: firmware error _sx_xlock(c8a32e00,0,c0cf4278,11b,d9d6879c,...) at 0xc0897f45 =3D _sx_xlock= +0x85iwi0: firmware error ufsdirhash_acquire(0,e,c8bb0800,d9502908,d9d6879c,...) at 0xc0b13985 =3D uf= siwi0: firmware error dirhash_acquire+0x35 ufsdirhash_remove(c8bcfae0,d9d6879c,79c,d974f944,d974f940iwi0: firmware err= or ,...) at 0xc0b13d04 =3D ufsdirhash_remove+0x14 ufs_dirremove(c8bcecc0,c8ea1570,5iwi0: firmware error 00940c,0,0,...) at 0xc0b16c03 =3D ufs_dirremove+0x133 ufs_rename(d974fbec,0,ciwi0: firmware error 8eabaa0,d974fb98,0,...) at 0xc0b2014a =3D ufs_rename+0x113a VOP_RENAME_Aiwi0: firmware error PV(c0de2c60,d974fbec,c8eab990,1,d974fb70,...) at 0xc0c0c9e5 =3D VOP_RENAME_= APViwi0: firmware error +0xa5 kern_renameat(c8e7f580,ffffff9c,48819040,ffffff9c,48819060,...) at 0xc0iwi0= : firmware error 930147 =3D kern_renameat+0x307 kern_rename(c8e7f580,48819040,48819060,0,diwi0: firmware error 974fc7c,...) at 0xc09302f6 =3D kern_rename+0x36 rename(c8e7f580,d974fcec,9785,iwi0: firmware error c8e7f580,0,...) at 0xc0930329 =3D rename+0x29 syscallenter(c8e7f580,d974fce4,4,iwi0: firmware error c0cc577f,109,...) at 0xc08cfbfa =3D syscallenter+0x25a syscall(d974fd28) at 0xc0biwi0: firmware error e9f8f =3D syscall+0x4f Xint0x80_syscall() at 0xc0bd15e1 =3D Xint0x80_syscall+0x21iwi0: firmware er= ror --- syscall (128, FreeBSD ELF32, rename), eip =3D 0x4857234b, esp =3D 0xbfb= fe83c, ebiwi0: firmware error p =3D 0xbfbfe8c8 --- iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error Jul 18 06:02:18 localhost sudo: david : 1 incorrect password attempt ; T= TY=3Dttyv1 ; PWD=3D/common/home/david ; USER=3Droot ; COMMAND=3D/usr/bin/su= -m iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error iwi0: firmware error panic: iwi firmware not idle, state ASSOCIATING cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c0cca5e8,c52bcb68,c0890089,c0d0289d,0,...) at 0xc04da= b26 =3D db_trace_self_wrapper+0x26 kdb_backtrace(c0d0289d,0,c11bec2a,c52bcb74,0,...) at 0xc08c2bc9 =3D kdb_bac= ktrace+0x29 panic(c11bec2a,c11bec4d,c11beb2a,ae6,c7c57014,...) at 0xc0890089 =3D panic+= 0x119 iwi_auth_and_assoc(c7885c0c,0,c11beb2a,3c5,8,...) at 0xc11be36c =3D iwi_aut= h_and_assoc+0x77c iwi_newstate(c8be9000,2,c0,652,c52bcc98,...) at 0xc11be679 =3D iwi_newstate= +0x179 ieee80211_newstate_cb(c8be9000,1,c0ccbeba,51,c7c52a98,...) at 0xc098f2b9 = =3D ieee80211_newstate_cb+0x179 taskqueue_run(c7c52a80,c7c52a98,0,c0ce8924,0,...) at 0xc08cf2b3 =3D taskque= ue_run+0x103 taskqueue_thread_loop(c7c57074,c52bcd28,c0cc22eb,343,c0e24800,...) at 0xc08= cf408 =3D taskqueue_thread_loop+0x68 fork_exit(c08cf3a0,c7c57074,c52bcd28) at 0xc08658a8 =3D fork_exit+0xb8 fork_trampoline() at 0xc0bd15f4 =3D fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc52bcd60, ebp =3D 0 --- KDB: enter: panic Uptime: 3m19s Physical memory: 2031 MB Dumping 138 MB: 123 107 91 75 59 43 27 11 ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident LAPTOP_30W machine i386 cpu I686_CPU cpu I586_CPU cpu I486_CPU makeoptions DEBUG=3D-g options VIMAGE options ALT_BREAK_TO_DEBUGGER options BREAK_TO_DEBUGGER options DIAGNOSTIC options DEBUG_REDZONE options DEBUG_MEMGUARD options DDB_NUMSYM options KDB_TRACE options ZERO_COPY_SOCKETS options DUMMYNET options ACCEPT_FILTER_HTTP options ACCEPT_FILTER_DATA options LIBALIAS options IPDIVERT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=3D0 options IPFIREWALL_VERBOSE options IPFIREWALL options FDC_DEBUG options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options SMP options WITNESS_SKIPSPIN options WITNESS options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options DDB options KDB options INCLUDE_CONFIG_FILE options FLOWTABLE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=3D128 options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=3D5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSSERVER options NFSCLIENT options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NATIVE options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD options ISAPNP device isa device npx device mem device io device uart_ns8250 device atpic device apic device cpufreq device acpi device eisa device pci device fdc device ata device atadisk device atapicd device atapifd device ahb device ahc device ahd device amd device hptiop device isp device mpt device sym device trm device adv device adw device aha device aic device bt device ncv device nsp device stg device scbus device ch device da device sa device cd device pass device ses device hptrr device mfi device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device pmtimer device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device de device em device igb device ixgb device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device ie device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device ath device ath_hal device ath_rate_sample device ral device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device uath device ural device firewire device sbp device fwe device fwip device dcons device dcons_crom device atapicam device smbus device intpm device ichsmb device smb device iicbus device iicbb device ic device iic device iicsmb device pcf device speaker device sound device snd_ich ------------------------------------------------------------------------ ddb capture buffer --PuGuTyElPB9bOcsM-- --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxDvhsACgkQmprOCmdXAD0yMACfa6PcDj8QpUezKP0DLjVxsekq NVcAn30XBMfPzMMFUshA2UD1f5cmBZJg =tHnJ -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 04:21: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 8DBBB106567A for ; Mon, 19 Jul 2010 04:21:27 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51808.mail.re2.yahoo.com (web51808.mail.re2.yahoo.com [206.190.38.239]) by mx1.freebsd.org (Postfix) with SMTP id E0B308FC15 for ; Mon, 19 Jul 2010 04:21:26 +0000 (UTC) Received: (qmail 51271 invoked by uid 60001); 19 Jul 2010 04:21:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1279513285; bh=6j9k4UHlI9S+hxqsY2J3t8MWo+nmyzK4jTgu/RDgmTI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jYptPIFJWFGhuZg4Px/avyjBTXkCdKUb8+xL2c+siKyBmu4AN+vcTogYfhOIrvKhyE5GDDg3hXT1FMoRYhT9lKqeKnKC+vJs6+VABUn9Zw/MIiR5he6EkcIcObjlb5J/bXyiEyX0GtOwu1UjV9kD46jIH0ePqZEY9m5jZwr/1Kw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n5MJ/ipkFXo+vnOXjUeoVFePC4hZahnPRUdAYJoEsUei5t0NqWLV6DKk0QEt6Tq3N1ur++zIZnd8F1ypnnh1yIXCPrmcgg1EvxIfN/FteI09bluhH9uUXVEhSSfn/x2SD7g6Co1Jtxx0ht0hP6zx5qTzS2dVC0APhbUVRohlhKs=; Message-ID: <964771.49833.qm@web51808.mail.re2.yahoo.com> X-YMail-OSG: TeLcbeoVM1lSLqYZqrgciQYdh6MzK8ZiIkhDj62W5siPmf1 ye6W8CGWHSm5fCAAJPAPuQMgTHtkJXffEHWfC1DHCcp2xjI5VMH2M_Jx.g7R WGTQ6ZFLZ.hNzE7mNevi8p3vNEG5KUeDu4RiNOxSl.sDGInlFU_ARywfnE0s _3ZcoWpIADWFFybYaLD3JVa9zLAJFt4PIoZwyqivyayvpPD4MZxf16PqZoz5 Xrfevz3AMavWI5HsSdOe4xdWsuQOCCOl9eHrIZbLlDjV7MYELOYt52nUwsmy 3Og6oqe4TJmAVgQsoSsFSG5CmY8KeeWZcTUZz5diiqVBh9reijQiEHiaDP2b AGgz2w8w- Received: from [173.183.132.20] by web51808.mail.re2.yahoo.com via HTTP; Sun, 18 Jul 2010 21:21:25 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <201007141511.46190.hselasky@c2i.net> Date: Sun, 18 Jul 2010 21:21:25 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky In-Reply-To: <201007141511.46190.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Leffler , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 04:21:27 -0000 [NB] Obviously, I didn't click "reply ALL" last time, so here are missing part > > > > -if(vap->iv_opmode == IEEE80211_M_HOSTAP){ > > > > > > > > -RUN_LOCK(sc); > > > > +if (vap->iv_opmode == IEEE80211_M_HOSTAP) > > > > > > > > sc->cmdq_key_set = RUN_CMDQ_GO; > > > > > > > > -RUN_UNLOCK(sc); > > > > -} > > > > > > > > > > > > Why are you removing these locks? > > > > It is simple assignment, it must be atomic. > > Not necessarily. If you don't put lock statements around it or use the > volatile keyword, the compiler can re-organize the execution order. I will > have a look at it. > > > > > > Another question: > > > i = RUN_CMDQ_GET(&sc->cmdq_store); > > > DPRINTF("cmdq_store=%d\n", i); > > > > > > sc->cmdq[i].func = run_update_beacon_cb; > > > sc->cmdq[i].arg0 = vap; > > > > > > Why is this code and similar places not enclosed with mutexes? > > > > First, I couldn't use a lock in key_delete() because of LoR. So, I use > > atomic instead. RUN_CMDQ_GET is atomic_fetch_add(). Whatever executes that > > code gets unique place (cmdq[i]) to write, so there shouldn't be any race. > > > > Then out of order execution happened. Specially, when key_set() overtakes > > key_delete(), encryption fails. So, all deferred processes are called back > > via run_cmdq_cb() to maintain the order. Because cmdq functions are first > > written for key_delete() where lock causes LoR. So, lock isn't needed. > > > > run_cmdq_cb() uses lock. But it is for calling callback functions locked. > > So that, functions just call another function locked, like > > ##_callback() > > { > > LOCK(); > > ##_locked(); > > UNLOCK(); > > } > > won't be needed. > > If the run_cmdq_cb() is running at the same time which you are queuing > elements, then I note that you set .func before .arg0. The ##_callback() code > only checks if .func has been set. Actually the "i" increment should be after > that you filled out the data, and then you see that you cannot use atomic. I > think the most simple solution is to add another mutex, sc->sc_cmdq_mtx, which > protects the queue and it's associated data. Also, what do you do if the queue > wraps around? You should have a mechanism to prevent that, because you then > might start executing commands in random order? > Here is a patch (patch against P4 if_run.c rev 14 and if_runvar.h rev 8) -- begin patch -- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index 8c96534..c988ad4 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -90,12 +90,6 @@ SYSCTL_INT(_hw_usb_run, OID_AUTO, debug, CTLFLAG_RW, &run_debug, 0, #define IEEE80211_HAS_ADDR4(wh) \ (((wh)->i_fc[1] & IEEE80211_FC1_DIR_MASK) == IEEE80211_FC1_DIR_DSTODS) -/* - * Because of LOR in run_key_delete(), use atomic instead. - * '& RUN_CMDQ_MASQ' is to loop cmdq[]. - */ -#define RUN_CMDQ_GET(c)(atomic_fetchadd_32((c), 1) & RUN_CMDQ_MASQ) - static const struct usb_device_id run_devs[] = { { USB_VP(USB_VENDOR_ABOCOM,USB_PRODUCT_ABOCOM_RT2770) }, { USB_VP(USB_VENDOR_ABOCOM,USB_PRODUCT_ABOCOM_RT2870) }, @@ -554,6 +548,8 @@ run_attach(device_t self) mtx_init(&sc->sc_mtx, device_get_nameunit(sc->sc_dev), MTX_NETWORK_LOCK, MTX_DEF); +mtx_init(&sc->sc_cmdq_mtx, device_get_nameunit(sc->sc_dev), + MTX_NETWORK_LOCK, MTX_DEF); iface_index = RT2860_IFACE_INDEX; @@ -737,6 +733,7 @@ run_detach(device_t self) } mtx_destroy(&sc->sc_mtx); +mtx_destroy(&sc->sc_cmdq_mtx); return (0); } @@ -830,9 +827,6 @@ run_vap_create(struct ieee80211com *ic, if(sc->rvp_cnt++ == 0) ic->ic_opmode = opmode; -if(opmode == IEEE80211_M_HOSTAP) -sc->cmdq_run = RUN_CMDQ_GO; - DPRINTF("rvp_id=%d bmap=%x rvp_cnt=%d\n", rvp->rvp_id, sc->rvp_bmap, sc->rvp_cnt); @@ -889,27 +883,31 @@ run_cmdq_cb(void *arg, int pending) struct run_softc *sc = arg; uint8_t i; -/* call cmdq[].func locked */ -RUN_LOCK(sc); -for(i = sc->cmdq_exec; sc->cmdq[i].func && pending; - i = sc->cmdq_exec, pending--){ +RUN_CMDQ_LOCK(sc); +for (i = sc->cmdq_exec; sc->cmdq[i].func; i = sc->cmdq_exec) { DPRINTFN(6, "cmdq_exec=%d pending=%d\n", i, pending); -if(sc->cmdq_run == RUN_CMDQ_GO){ +if (sc->cmdq_run == RUN_CMDQ_GO || + (sc->cmdq_key_set == RUN_CMDQ_GO && + sc->cmdq[i].func == run_key_set_cb)) { +RUN_CMDQ_UNLOCK(sc); +RUN_LOCK(sc); /* * If arg0 is NULL, callback func needs more * than one arg. So, pass ptr to cmdq struct. */ -if(sc->cmdq[i].arg0) +if (sc->cmdq[i].arg0) sc->cmdq[i].func(sc->cmdq[i].arg0); else sc->cmdq[i].func(&sc->cmdq[i]); +RUN_UNLOCK(sc); +RUN_CMDQ_LOCK(sc); } sc->cmdq[i].arg0 = NULL; sc->cmdq[i].func = NULL; sc->cmdq_exec++; sc->cmdq_exec &= RUN_CMDQ_MASQ; } -RUN_UNLOCK(sc); +RUN_CMDQ_UNLOCK(sc); } static void @@ -1771,6 +1769,19 @@ run_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg) case IEEE80211_S_INIT: restart_ratectl = 1; +/* + * When hostapd has set a key, don't clear it. + * But, when the device is being brought down, clear it. + */ +if (sc->cmdq_key_set != RUN_CMDQ_GO || + ostate == IEEE80211_S_RUN) { +/* clear shared key table */ +run_set_region_4(sc, + RT2860_SKEY(rvp->rvp_id, 0), 0, 4 * 32); +/* clear shared key mode */ +run_set_region_4(sc, RT2860_SKEY_MODE_0_7, 0, 4); +} + if (ostate != IEEE80211_S_RUN) break; @@ -1922,12 +1933,24 @@ run_wme_update(struct ieee80211com *ic) struct run_softc *sc = ic->ic_ifp->if_softc; /* sometime called wothout lock */ -if(mtx_owned(&ic->ic_comlock.mtx)){ -uint32_t i = RUN_CMDQ_GET(&sc->cmdq_store); +if (mtx_owned(&ic->ic_comlock.mtx)) { +RUN_CMDQ_LOCK(sc); +uint8_t i = sc->cmdq_store; DPRINTF("cmdq_store=%d\n", i); + +if (sc->cmdq[i].func != NULL) { +DPRINTF("cmdq is full\n"); +RUN_CMDQ_UNLOCK(sc); +return (-1); +} + sc->cmdq[i].func = run_wme_update_cb; sc->cmdq[i].arg0 = ic; +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; ieee80211_runtask(ic, &sc->cmdq_task); + +RUN_CMDQ_UNLOCK(sc); return (0); } @@ -2085,28 +2108,38 @@ run_key_set(struct ieee80211vap *vap, struct ieee80211_key *k, { struct ieee80211com *ic = vap->iv_ic; struct run_softc *sc = ic->ic_ifp->if_softc; -uint32_t i; +uint8_t i; -i = RUN_CMDQ_GET(&sc->cmdq_store); +RUN_CMDQ_LOCK(sc); + +i = sc->cmdq_store; DPRINTF("cmdq_store=%d\n", i); + +if (sc->cmdq[i].func != NULL) { +DPRINTF("cmdq is full\n"); +RUN_CMDQ_UNLOCK(sc); +return (0); +} + sc->cmdq[i].func = run_key_set_cb; sc->cmdq[i].arg0 = NULL; sc->cmdq[i].arg1 = vap; sc->cmdq[i].k = k; IEEE80211_ADDR_COPY(sc->cmdq[i].mac, mac); +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; ieee80211_runtask(ic, &sc->cmdq_task); /* * To make sure key will be set when hostapd * calls iv_key_set() before if_init(). */ -if(vap->iv_opmode == IEEE80211_M_HOSTAP){ -RUN_LOCK(sc); +if (vap->iv_opmode == IEEE80211_M_HOSTAP) sc->cmdq_key_set = RUN_CMDQ_GO; -RUN_UNLOCK(sc); -} -return(1); +RUN_CMDQ_UNLOCK(sc); + +return (1); } /* @@ -2154,16 +2187,23 @@ run_key_delete(struct ieee80211vap *vap, struct ieee80211_key *k) struct ieee80211com *ic = vap->iv_ic; struct run_softc *sc = ic->ic_ifp->if_softc; struct ieee80211_key *k0; -uint32_t i; +uint8_t i; /* * When called back, key might be gone. So, make a copy * of some values need to delete keys before deferring. - * But, because of LOR with node lock, cannot use lock here. - * So, use atomic instead. */ -i = RUN_CMDQ_GET(&sc->cmdq_store); +RUN_CMDQ_LOCK(sc); + +i = sc->cmdq_store; DPRINTF("cmdq_store=%d\n", i); + +if (sc->cmdq[i].func != NULL) { +DPRINTF("cmdq is full\n"); +RUN_CMDQ_UNLOCK(sc); +return (0); +} + sc->cmdq[i].func = run_key_delete_cb; sc->cmdq[i].arg0 = NULL; sc->cmdq[i].arg1 = sc; @@ -2172,9 +2212,13 @@ run_key_delete(struct ieee80211vap *vap, struct ieee80211_key *k) k0->wk_keyix = k->wk_keyix; /* matching wcid was written to wk_pad in run_key_set() */ k0->wk_pad = k->wk_pad; +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; ieee80211_runtask(ic, &sc->cmdq_task); -return (1);/* return fake success */ +RUN_CMDQ_UNLOCK(sc); + +return (1); } static void @@ -2362,19 +2406,31 @@ run_newassoc(struct ieee80211_node *ni, int isnew) } /* only interested in true associations */ -if (isnew && ni->ni_associd != 0){ - +if (isnew && ni->ni_associd != 0) { /* - * This function could is called though timeout function. + * This function could be called though timeout function. * Need to defer. */ -uint32_t cnt = RUN_CMDQ_GET(&sc->cmdq_store); +RUN_CMDQ_LOCK(sc); + +uint8_t cnt = sc->cmdq_store; DPRINTF("cmdq_store=%d\n", cnt); + +if (sc->cmdq[cnt].func != NULL) { +DPRINTF("cmdq is full\n"); +RUN_CMDQ_UNLOCK(sc); +return; +} + sc->cmdq[cnt].func = run_newassoc_cb; sc->cmdq[cnt].arg0 = NULL; sc->cmdq[cnt].arg1 = ni; sc->cmdq[cnt].wcid = wcid; +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; ieee80211_runtask(ic, &sc->cmdq_task); + +RUN_CMDQ_UNLOCK(sc); } DPRINTF("new assoc isnew=%d associd=%x addr=%s\n", @@ -2805,11 +2861,20 @@ tr_setup: if (error != USB_ERR_CANCELLED) { if (error == USB_ERR_TIMEOUT) { device_printf(sc->sc_dev, "device timeout\n"); -uint32_t i = RUN_CMDQ_GET(&sc->cmdq_store); + +RUN_CMDQ_LOCK(sc); +uint8_t i = sc->cmdq_store; DPRINTF("cmdq_store=%d\n", i); -sc->cmdq[i].func = run_usb_timeout_cb; -sc->cmdq[i].arg0 = vap; -ieee80211_runtask(ic, &sc->cmdq_task); +if (sc->cmdq[i].func != NULL) +DPRINTF("cmdq is full\n"); +else { +sc->cmdq[i].func = run_usb_timeout_cb; +sc->cmdq[i].arg0 = vap; +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; +ieee80211_runtask(ic, &sc->cmdq_task); +} +RUN_CMDQ_UNLOCK(sc); } /* @@ -3067,11 +3132,24 @@ run_tx(struct run_softc *sc, struct mbuf *m, struct ieee80211_node *ni) * With multiple vaps or if_bridge, if_start() is called * with a non-sleepable lock, tcpinp. So, need to defer. */ -uint32_t i = RUN_CMDQ_GET(&sc->cmdq_store); +RUN_CMDQ_LOCK(sc); +uint8_t i = sc->cmdq_store; DPRINTFN(6, "cmdq_store=%d\n", i); -sc->cmdq[i].func = run_drain_fifo; -sc->cmdq[i].arg0 = sc; -ieee80211_runtask(ic, &sc->cmdq_task); +if (sc->cmdq[i].func != NULL) { +DPRINTF("cmdq is full\n"); +/* + * Keep going. + * no need to stop Tx + * just because reading Tx stats failed + */ +} else { +sc->cmdq[i].func = run_drain_fifo; +sc->cmdq[i].arg0 = sc; +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; +ieee80211_runtask(ic, &sc->cmdq_task); +} +RUN_CMDQ_UNLOCK(sc); } } @@ -3188,7 +3266,7 @@ run_sendprot(struct run_softc *sc, ackrate = ieee80211_ack_rate(ic->ic_rt, rate); isshort = (ic->ic_flags & IEEE80211_F_SHPREAMBLE) != 0; -dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort); +dur = ieee80211_compute_duration(ic->ic_rt, pktlen, rate, isshort) + ieee80211_ack_duration(ic->ic_rt, rate, isshort); wflags = RT2860_TX_FRAG; @@ -3906,14 +3984,27 @@ run_update_beacon(struct ieee80211vap *vap, int item) { struct ieee80211com *ic = vap->iv_ic; struct run_softc *sc = ic->ic_ifp->if_softc; -uint32_t i; +uint8_t i; + +RUN_CMDQ_LOCK(sc); -i = RUN_CMDQ_GET(&sc->cmdq_store); +i = sc->cmdq_store; DPRINTF("cmdq_store=%d\n", i); + +if (sc->cmdq[i].func != NULL) { +DPRINTF("cmdq is full\n"); +RUN_CMDQ_UNLOCK(sc); +return; +} + sc->cmdq[i].func = run_update_beacon_cb; sc->cmdq[i].arg0 = vap; +sc->cmdq_store++; +sc->cmdq_store &= RUN_CMDQ_MASQ; ieee80211_runtask(ic, &sc->cmdq_task); +RUN_CMDQ_UNLOCK(sc); + return; } @@ -4693,14 +4784,6 @@ run_init_locked(struct run_softc *sc) /* clear WCID attribute table */ run_set_region_4(sc, RT2860_WCID_ATTR(0), 0, 8 * 32); -/* hostapd sets a key before init. So, don't clear it. */ -if(sc->cmdq_key_set != RUN_CMDQ_GO){ -/* clear shared key table */ -run_set_region_4(sc, RT2860_SKEY(0, 0), 0, 8 * 32); -/* clear shared key mode */ -run_set_region_4(sc, RT2860_SKEY_MODE_0_7, 0, 4); -} - run_read(sc, RT2860_US_CYC_CNT, &tmp); tmp = (tmp & ~0xff) | 0x1e; run_write(sc, RT2860_US_CYC_CNT, tmp); @@ -4807,7 +4890,7 @@ run_stop(void *arg) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); sc->ratectl_run = RUN_RATECTL_OFF; -sc->cmdq_run = sc->cmdq_key_set; +sc->cmdq_run = RUN_CMDQ_ABORT; RUN_UNLOCK(sc); diff --git a/dev/usb/wlan/if_runvar.h b/dev/usb/wlan/if_runvar.h index 39addbf..a6fddaa 100644 --- a/dev/usb/wlan/if_runvar.h +++ b/dev/usb/wlan/if_runvar.h @@ -202,6 +202,7 @@ struct run_softc { uint8_tsc_bssid[6]; struct mtxsc_mtx; +struct mtxsc_cmdq_mtx; struct run_endpoint_queuesc_epq[RUN_EP_QUEUES]; @@ -210,12 +211,12 @@ struct run_softc { uint8_tratectl_run; #define RUN_RATECTL_OFF0 -/* need to be power of 2, otherwise RUN_CMDQ_GET fails */ +/* need to be power of 2, otherwise run_cmdq_cb() fails */ #define RUN_CMDQ_MAX16 #define RUN_CMDQ_MASQ(RUN_CMDQ_MAX - 1) struct run_cmdqcmdq[RUN_CMDQ_MAX]; struct taskcmdq_task; -uint32_tcmdq_store; +uint8_tcmdq_store; uint8_tcmdq_exec; uint8_tcmdq_run; uint8_tcmdq_key_set; @@ -255,4 +256,7 @@ struct run_softc { #define RUN_UNLOCK(sc)mtx_unlock(&(sc)->sc_mtx) #define RUN_LOCK_ASSERT(sc, t)mtx_assert(&(sc)->sc_mtx, t) +#define RUN_CMDQ_LOCK(sc)mtx_lock(&(sc)->sc_cmdq_mtx) +#define RUN_CMDQ_UNLOCK(sc)mtx_unlock(&(sc)->sc_cmdq_mtx) + #endif/* _IF_RUNVAR_H_ */ -- end patch -- From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 04:49: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 9004F106566C for ; Mon, 19 Jul 2010 04:49:14 +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 4E9568FC12 for ; Mon, 19 Jul 2010 04:49:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o6J4jWx0031591; Sun, 18 Jul 2010 22:45:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 18 Jul 2010 22:45:58 -0600 (MDT) Message-Id: <20100718.224558.590164615694902393.imp@bsdimp.com> To: i@levsha.me From: "M. Warner Losh" In-Reply-To: <20100718.171610.338707487962422543.imp@bsdimp.com> References: <20100718210154.GA94088@laptop.levsha.me> <20100718.171610.338707487962422543.imp@bsdimp.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: freebsd-current@FreeBSD.ORG Subject: Re: Can't make distribution TARGET_ARCH=... after r209510 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 04:49:14 -0000 In message: <20100718.171610.338707487962422543.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <20100718210154.GA94088@laptop.levsha.me> : Mykola Dzham writes: : : Hi! : : Attemt to make jail with different target arch on tinderbox (i386 jail : : on amd64 host) exits with error: : : : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : : : Last lines from log: : : : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : : install: freebsd.cf: No such file or directory : : *** Error code 71 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : : *** Error code 1 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : : : Full build and distribution logs avaliable on : : http://levsha.me/tmp/20100718/world.txt (20M) : : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : : : Reverting r209510 fixes this problem : : It works for me. : : on an amd64 box: : setenv TARGET=i386 : make buildworld : make installworld DESTDIR=/tmp/mumble : make distribution DESTDIR=/tmp/mumble To which I forgot to add: Please send me the exact sequence of commands that fails, as well as the uname of the host. I'd like to try to track this down... Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 05:06: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 9320C1065677 for ; Mon, 19 Jul 2010 05:06:09 +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 31D128FC15 for ; Mon, 19 Jul 2010 05:06:08 +0000 (UTC) Received: (qmail 5983 invoked by uid 399); 19 Jul 2010 05:06:07 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Jul 2010 05:06:07 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C43DD3E.2000306@FreeBSD.org> Date: Sun, 18 Jul 2010 22:06:06 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Kostik Belousov References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100718194109.GU2381@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.1 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------010103000800080501030401" Cc: freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 05:06:09 -0000 This is a multi-part message in MIME format. --------------010103000800080501030401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/18/10 12:41, Kostik Belousov wrote: > On Sun, Jul 18, 2010 at 12:21:00PM -0700, Doug Barton wrote: >> On 07/18/10 03:30, Kostik Belousov wrote: >>> On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote: >>>> On Sat, 17 Jul 2010, Kostik Belousov wrote: >>>> >>>>> Run top in the mode where all system threads are shown separately >>>>> (e.g. top -HS seems to do it), then watch what thread eats the processor. >>>> >>>> And the winner is! >>>> >>>> 11 root -32 - 0K 168K WAIT 0 0:28 18.02% {swi4: >>>> clock} >>>> 11 root 21 -64 - 0K 168K WAIT 0 1:17 18.90% intr >>>> >>>> The first is with -H, the second without. >>> >>> Most likely it is some callout handling. Just in case, do you have >>> console screensaver active ? >> >> I assume you mean "saver=yes" in rc.conf, and the answer is no, I am not >> using that. Usually I run xscreensaver, but at the time this happened I >> was not. I do have DPMS enabled in my X config though. >> >> Any suggestions on how to dig deeper on this? Are there any settings I >> can twiddle to try and mitigate it? > When intr time starts accumulating again, try to do > "procstat -kk " and correlate the clock thread tid > with the backtrace. Might be, it helps to guess what callouts are eating > the CPU. Ok, file attached. -- 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 --------------010103000800080501030401 Content-Type: text/plain; name="procstat-kk.out" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="procstat-kk.out" ICBQSUQgICAgVElEIENPTU0gICAgICAgICAgICAgVEROQU1FICAgICAgICAgICBLU1RBQ0sg ICAgICAgICAgICAgICAgICAgICAgIAogICAxMSAxMDAwMDQgaW50ciAgICAgICAgICAgICBz d2kxOiBuZXRpc3IgMCAgIG1pX3N3aXRjaCsweDIwMCBpdGhyZWFkX2xvb3ArMHgxZGEgZm9y a19leGl0KzB4YjggZm9ya190cmFtcG9saW5lKzB4OCAKICAgMTEgMTAwMDA1IGludHIgICAg ICAgICAgICAgc3dpNDogY2xvY2sgICAgICBtaV9zd2l0Y2grMHgyMDAgaXRocmVhZF9sb29w KzB4MWRhIGZvcmtfZXhpdCsweGI4IGZvcmtfdHJhbXBvbGluZSsweDggCiAgIDExIDEwMDAw NiBpbnRyICAgICAgICAgICAgIHN3aTQ6IGNsb2NrICAgICAgbWlfc3dpdGNoKzB4MjAwIGl0 aHJlYWRfbG9vcCsweDFkYSBmb3JrX2V4aXQrMHhiOCBmb3JrX3RyYW1wb2xpbmUrMHg4IAog ICAxMSAxMDAwMDcgaW50ciAgICAgICAgICAgICBzd2kzOiB2bSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgIDExIDEwMDAxNCBpbnRyICAgICAgICAgICAgIHN3 aTY6IEdpYW50IHRhc2sgbWlfc3dpdGNoKzB4MjAwIGl0aHJlYWRfbG9vcCsweDFkYSBmb3Jr X2V4aXQrMHhiOCBmb3JrX3RyYW1wb2xpbmUrMHg4IAogICAxMSAxMDAwMTUgaW50ciAgICAg ICAgICAgICBzd2k2OiB0YXNrIHF1ZXVlIG1pX3N3aXRjaCsweDIwMCBpdGhyZWFkX2xvb3Ar MHgxZGEgZm9ya19leGl0KzB4YjggZm9ya190cmFtcG9saW5lKzB4OCAKICAgMTEgMTAwMDIw IGludHIgICAgICAgICAgICAgc3dpMjogY2FtYmlvICAgICBtaV9zd2l0Y2grMHgyMDAgaXRo cmVhZF9sb29wKzB4MWRhIGZvcmtfZXhpdCsweGI4IGZvcmtfdHJhbXBvbGluZSsweDggCiAg IDExIDEwMDAyMSBpbnRyICAgICAgICAgICAgIHN3aTU6ICsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgMTEgMTAwMDIyIGludHIgICAgICAgICAgICAgaXJx OTogYWNwaTAgICAgICBtaV9zd2l0Y2grMHgyMDAgaXRocmVhZF9sb29wKzB4MWRhIGZvcmtf ZXhpdCsweGI4IGZvcmtfdHJhbXBvbGluZSsweDggCiAgIDExIDEwMDAyMyBpbnRyICAgICAg ICAgICAgIGlycTE2OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgMTEgMTAwMDI0IGludHIgICAgICAgICAgICAgaXJxMjU2OiBoZGFjMCAgICBtaV9zd2l0 Y2grMHgyMDAgaXRocmVhZF9sb29wKzB4MWRhIGZvcmtfZXhpdCsweGI4IGZvcmtfdHJhbXBv bGluZSsweDggCiAgIDExIDEwMDAyNiBpbnRyICAgICAgICAgICAgIGlycTE3OiB3cGkwICAg ICAgbWlfc3dpdGNoKzB4MjAwIGl0aHJlYWRfbG9vcCsweDFkYSBmb3JrX2V4aXQrMHhiOCBm b3JrX3RyYW1wb2xpbmUrMHg4IAogICAxMSAxMDAwMjcgaW50ciAgICAgICAgICAgICBpcnEy MDogaHBldDAgdWhjIG1pX3N3aXRjaCsweDIwMCBpdGhyZWFkX2xvb3ArMHgxZGEgZm9ya19l eGl0KzB4YjggZm9ya190cmFtcG9saW5lKzB4OCAKICAgMTEgMTAwMDMyIGludHIgICAgICAg ICAgICAgaXJxMjE6IHVoY2kxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAxMSAxMDAwMzcgaW50ciAgICAgICAgICAgICBpcnEyMjogdWhjaTIgICAgIG1pX3N3aXRj aCsweDIwMCBpdGhyZWFkX2xvb3ArMHgxZGEgZm9ya19leGl0KzB4YjggZm9ya190cmFtcG9s aW5lKzB4OCAKICAgMTEgMTAwMDQyIGludHIgICAgICAgICAgICAgaXJxMjM6IHVoY2kzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAxMSAxMDAwNTIgaW50ciAgICAg ICAgICAgICBpcnExNDogYXRhMCAgICAgIG1pX3N3aXRjaCsweDIwMCBpdGhyZWFkX2xvb3Ar MHgxZGEgZm9ya19leGl0KzB4YjggZm9ya190cmFtcG9saW5lKzB4OCAKICAgMTEgMTAwMDUz IGludHIgICAgICAgICAgICAgaXJxMTU6IGF0YTEgICAgICBtaV9zd2l0Y2grMHgyMDAgaXRo cmVhZF9sb29wKzB4MWRhIGZvcmtfZXhpdCsweGI4IGZvcmtfdHJhbXBvbGluZSsweDggCiAg IDExIDEwMDA1NSBpbnRyICAgICAgICAgICAgIGlycTE6IGF0a2JkMCAgICAgbWlfc3dpdGNo KzB4MjAwIGl0aHJlYWRfbG9vcCsweDFkYSBmb3JrX2V4aXQrMHhiOCBmb3JrX3RyYW1wb2xp bmUrMHg4IAogICAxMSAxMDAwNTYgaW50ciAgICAgICAgICAgICBpcnExMjogcHNtMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgIDExIDEwMDA1NyBpbnRyICAgICAg ICAgICAgIHN3aTA6IHVhcnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK --------------010103000800080501030401-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 08:20: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 6543E1065674; Mon, 19 Jul 2010 08:20:30 +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 EDFB68FC1F; Mon, 19 Jul 2010 08:20:29 +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 o6J8KJ7N009307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jul 2010 11:20:19 +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 o6J8KJBh033346; Mon, 19 Jul 2010 11:20:19 +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 o6J8KJf6033345; Mon, 19 Jul 2010 11:20:19 +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, 19 Jul 2010 11:20:19 +0300 From: Kostik Belousov To: Doug Barton Message-ID: <20100719082019.GW2381@deviant.kiev.zoral.com.ua> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C43DD3E.2000306@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R4RAxL8G0iuuxuj8" Content-Disposition: inline In-Reply-To: <4C43DD3E.2000306@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.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@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 08:20:30 -0000 --R4RAxL8G0iuuxuj8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 18, 2010 at 10:06:06PM -0700, Doug Barton wrote: > On 07/18/10 12:41, Kostik Belousov wrote: > > On Sun, Jul 18, 2010 at 12:21:00PM -0700, Doug Barton wrote: > >> On 07/18/10 03:30, Kostik Belousov wrote: > >>> On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote: > >>>> On Sat, 17 Jul 2010, Kostik Belousov wrote: > >>>> > >>>>> Run top in the mode where all system threads are shown separately > >>>>> (e.g. top -HS seems to do it), then watch what thread eats the proc= essor. > >>>> > >>>> And the winner is! > >>>> > >>>> 11 root -32 - 0K 168K WAIT 0 0:28 18.02% {swi= 4:=20 > >>>> clock} > >>>> 11 root 21 -64 - 0K 168K WAIT 0 1:17 18.90% intr > >>>> > >>>> The first is with -H, the second without. > >>> > >>> Most likely it is some callout handling. Just in case, do you have > >>> console screensaver active ? > >> > >> I assume you mean "saver=3Dyes" in rc.conf, and the answer is no, I am= not > >> using that. Usually I run xscreensaver, but at the time this happened I > >> was not. I do have DPMS enabled in my X config though. > >> > >> Any suggestions on how to dig deeper on this? Are there any settings I > >> can twiddle to try and mitigate it? > > When intr time starts accumulating again, try to do > > "procstat -kk " and correlate the clock thread tid > > with the backtrace. Might be, it helps to guess what callouts are eating > > the CPU. >=20 > Ok, file attached. >=20 > --=20 >=20 > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ >=20 > Computers are useless. They can only give you answers. > -- Pablo Picasso >=20 > PID TID COMM TDNAME KSTACK = =20 > 11 100004 intr swi1: netisr 0 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100005 intr swi4: clock mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100006 intr swi4: clock mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100007 intr swi3: vm = =20 > 11 100014 intr swi6: Giant task mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100015 intr swi6: task queue mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100020 intr swi2: cambio mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100021 intr swi5: + = =20 > 11 100022 intr irq9: acpi0 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100023 intr irq16: = =20 > 11 100024 intr irq256: hdac0 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100026 intr irq17: wpi0 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100027 intr irq20: hpet0 uhc mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100032 intr irq21: uhci1 = =20 > 11 100037 intr irq22: uhci2 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100042 intr irq23: uhci3 = =20 > 11 100052 intr irq14: ata0 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100053 intr irq15: ata1 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100055 intr irq1: atkbd0 mi_switch+0x200 ithread_lo= op+0x1da fork_exit+0xb8 fork_trampoline+0x8=20 > 11 100056 intr irq12: psm0 = =20 > 11 100057 intr swi0: uart = =20 You should correlate the backtrace and the id of the cpu-consuming thread (100005 or 100006, or both) and do periodic procstat -k to see which functions are referenced most often. Might be, suggested dtrace solution is easier. --R4RAxL8G0iuuxuj8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxECsIACgkQC3+MBN1Mb4h/TACeKGqNjorEqYYpPyk7JkUJhtOY HXgAni/9rgxiAAuNoNwcT4POiUcfIPTL =r1n+ -----END PGP SIGNATURE----- --R4RAxL8G0iuuxuj8-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 14:30: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 698F51065676 for ; Mon, 19 Jul 2010 14:30:58 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4F68FC1F for ; Mon, 19 Jul 2010 14:30:57 +0000 (UTC) Received: from [95.133.113.139] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OarMs-000NEj-5E; Mon, 19 Jul 2010 17:30:56 +0300 Received: from levsha by laptop.levsha.me with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OarMN-0008UV-7L; Mon, 19 Jul 2010 17:30:23 +0300 Date: Mon, 19 Jul 2010 17:30:23 +0300 From: Mykola Dzham To: "M. Warner Losh" Message-ID: <20100719143023.GA31690@laptop.levsha.me> References: <20100718210154.GA94088@laptop.levsha.me> <20100718.171610.338707487962422543.imp@bsdimp.com> <20100718.224558.590164615694902393.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100718.224558.590164615694902393.imp@bsdimp.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 95.133.113.139 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false X-Spam-Level: -- X-Spam-Report: 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.6 AWL AWL: From: address is in the auto white-list Cc: freebsd-current@FreeBSD.ORG Subject: Re: Can't make distribution TARGET_ARCH=... after r209510 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 14:30:58 -0000 M. Warner Losh wrote: > In message: <20100718.171610.338707487962422543.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <20100718210154.GA94088@laptop.levsha.me> > : Mykola Dzham writes: > : : Hi! > : : Attemt to make jail with different target arch on tinderbox (i386 jail > : : on amd64 host) exits with error: > : : > : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp > : : > : : Last lines from log: > : : > : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution > : : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail > : : install: freebsd.cf: No such file or directory > : : *** Error code 71 > : : > : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. > : : *** Error code 1 > : : > : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. > : : > : : Full build and distribution logs avaliable on > : : http://levsha.me/tmp/20100718/world.txt (20M) > : : http://levsha.me/tmp/20100718/distribution.txt (7.4K) > : : > : : Reverting r209510 fixes this problem > : > : It works for me. > : > : on an amd64 box: > : setenv TARGET=i386 > : make buildworld > : make installworld DESTDIR=/tmp/mumble > : make distribution DESTDIR=/tmp/mumble > > To which I forgot to add: > > Please send me the exact sequence of commands that fails, as well as > the uname of the host. I'd like to try to track this down... Hmm, all work properly with TARGET_ARCH when i build directly: export TARGET_ARCH=i386 make buildworld make installworld DESTDIR=/tmp/i386 make distribution DESTDIR=/tmp/i386 Problem occurs only if i try to make i386 jail in tinderbox $ sudo ./tc tbversion Tinderbox version 3.3.r1 $ svn info /usr/local/tinderbox/jails/9-HEAD.i386/src Path: /usr/local/tinderbox/jails/9-HEAD.i386/src URL: file:///usr/local/arch/base/head Repository Root: file:///usr/local/arch/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 210161 Node Kind: directory Schedule: normal Last Changed Author: imp Last Changed Rev: 210161 Last Changed Date: 2010-07-16 09:35:17 +0300 (ÐÔ, 16 ÌÉÐ 2010) I will try to get commands, used by tinderbox to build world and distribution, and check this commands. Thanks! -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 15:00: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 E66C81065678 for ; Mon, 19 Jul 2010 15:00:49 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id A432D8FC0A for ; Mon, 19 Jul 2010 15:00:49 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 0ACD9151616 for ; Mon, 19 Jul 2010 18:00:46 +0300 (EEST) Date: Mon, 19 Jul 2010 18:00:46 +0300 From: Jaakko Heinonen To: freebsd-current@FreeBSD.org Message-ID: <20100719150046.GA913@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: [CFR] devfs improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 15:00:50 -0000 Hi, I have been working on some devfs improvements and I am now posting the patch for wider review and testing. Especially testing from people using multiple devfs mounts and/or symbolic links would be useful. The patch: http://people.freebsd.org/~jh/patches/devfs.7.diff Notable changes: - Automatically remove empty directories. - Allow user created symbolic links to cover device files and directories if the device file appears after the link creation. - It's now possible to report if the device file already exists or is invalid to make_dev_credf(9) and make_dev_p(9) callers. There is a new flag MAKEDEV_CHECKNAME to indicate that the caller is prepared to handle such error. If the flag is not specified and the device name is invalid, a panic will occur. This code is not yet enabled because there are some driver issues which need to be sorted out before. (See "#ifdef notyet" in make_dev_credv().) In addition the patch should fix these bugs: - kern/114057 - fstat(2) could return stale information through open file descriptors. My main motivation for these changes was erratic handling of duplicate and invalid device names. For example currently you can crash the system through geom_label by inserting a specially crafted CD. Driver bugs causing duplicate device registrations weren't detected either. Most of the ideas implemented in the patch are from Kostik Belousov. Special thanks for him providing help and reviews during the development. Additional patches: A patch for GEOM to convert g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag instead of make_dev(). http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff Enable panicking on invalid device names: http://people.freebsd.org/~jh/patches/make_dev-checkname.diff -- Jaakko From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 17:06: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 145E91065672 for ; Mon, 19 Jul 2010 17:06:57 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id B9AD38FC1E for ; Mon, 19 Jul 2010 17:06:56 +0000 (UTC) Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Oatnr-0001VJ-4i; Mon, 19 Jul 2010 19:06:55 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Oatnq-0008KJ-OD; Mon, 19 Jul 2010 19:06:55 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oatnq-000Cb1-6i; Mon, 19 Jul 2010 19:06:54 +0200 Date: Mon, 19 Jul 2010 19:06:54 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Marius Strobl Message-ID: <20100719170654.GA19889@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100718122022.GW4706@alchemy.franken.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EE2D4CC965BCEDB5131DDC325444A9A24A736EEF X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1749 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: freebsd-current@freebsd.org, =?iso-8859-1?Q?St=E5le?= Kristoffersen Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 17:06:57 -0000 On 2010-07-18 at 14:20, Marius Strobl wrote: > > > Downgrading now... > > > > And it crashed again, with current from r209598... > > > > Ok, this at least means that your problem isn't caused by the recent > changes to mpt(4) as the pre-r209599 version only differed from the > 8-STABLE one in a cosmetic change at that time. I have another data-point, I cvsup'ed to the latest current again, and rebuilt without INVARIANT and WITNESS, and now it seems to survive the timeouts. -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 19:20: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 E9B7A106566B; Mon, 19 Jul 2010 19:20:03 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4CC8FC13; Mon, 19 Jul 2010 19:20:02 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=6KUfmzbym87FxoMGRWTr46e60yW4QTEOPMCHQyBOt0U= c=1 sm=1 a=HRj3ij7MtkgA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=Yv11-1_rfktiYAfpp74A:9 a=eEo5yydBpXFsrSRyyCK1k87hZm8A:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 118491; Mon, 19 Jul 2010 21:20:01 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 19 Jul 2010 21:17:04 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201007141511.46190.hselasky@c2i.net> <964771.49833.qm@web51808.mail.re2.yahoo.com> In-Reply-To: <964771.49833.qm@web51808.mail.re2.yahoo.com> 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-1" Content-Transfer-Encoding: 7bit Message-Id: <201007192117.05034.hselasky@c2i.net> Cc: Sam Leffler , PseudoCylon , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 19:20:04 -0000 Hi AK, I've committed your patches to USB P4. I've made some additional patches. Can you check and verify everything? http://p4web.freebsd.org/@@181189?ac=10 Also please compile a kernel with WITNESS enabled to catch any LOR's, hence we introduced another mutex. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 19:26: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 16FE81065675; Mon, 19 Jul 2010 19:26:30 +0000 (UTC) (envelope-from shteryana@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 3EBE48FC14; Mon, 19 Jul 2010 19:26:28 +0000 (UTC) Received: by fxm13 with SMTP id 13so2633863fxm.13 for ; Mon, 19 Jul 2010 12:26: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:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=jC7qF01OKQIeqY9e84EGO//fnZeChV/fNhWH2t4tiRo=; b=eho9dDxGBlHS8FrSWkLqyRjWJzzB/ZNQ8WowdN5NyeCDOtN+tauHqFfp1mwezDyIrj pFnZOQDikWIxaAVpgF2x1aoBylF0PaBHqvSJjbukvhPnOlAfIs/7YBU7RoVl++PQuxbv TvTlCo095K69exMloez0vJq/uPnBE7uAAmDlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=jnYzLRqbO4Su3nqYxLXWsIvBwV+SKL3o4zdX3TMdwftJ7hmU1rQyvDkkwubW1Ek7up Aly4wauM60VDI0rsJXdxKgRk9mijgfYbar8CwnKuEtIBlstcSVTxEXgFqFEf7PL6eoy6 lbt+0ZrxTqQGNSWJ47qt4cOLNWyZx33vvAniY= MIME-Version: 1.0 Received: by 10.223.104.148 with SMTP id p20mr4272156fao.11.1279567587972; Mon, 19 Jul 2010 12:26:27 -0700 (PDT) Sender: shteryana@gmail.com Received: by 10.223.113.10 with HTTP; Mon, 19 Jul 2010 12:26:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Jul 2010 22:26:27 +0300 X-Google-Sender-Auth: -ox1kBeG0n3l5n9nfAxPr3JCgeM Message-ID: From: Shteryana Shopova To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@FreeBSD.org" , freebsd-current@freebsd.org Subject: Re: Call for testers: wireless module for bsnmpd(1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@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: Mon, 19 Jul 2010 19:26:30 -0000 Hi all, Thanks for the feedback and comments. I've uploaded an updated tarball at http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100719-01.tar . On Sun, Jul 11, 2010 at 8:23 PM, Gabor PALI wrote: > > A few comments: > > - I think there should be bsnmpd(1) instead of bsnmpd(8) in the NAME > section of snmp_wlan(3). Fixed in the latest sources. > - It creates an "/usr/lib/snmp_wlan.so." file which seems a bit strange > for me. Yes, indeed - this weird naming happens when an bsnmp module is built outside the source tree and SHLIB_MAJOR is not defined - the file names a module based on snmp_${MOD}.so.${SHLIB_MAJOR} - this should be resolved once the module is made part of the source tree. > - It produces the following on my machine: > > snmpd[3871]: SNMP wlan loaded wlan_wlan_acl module > snmpd[3871]: send: Connection refused > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument > This is because ioctl(wname, IEEE80211_IOC_MACCMD, ...) returns EINVAL when no MAC ACL policy has been configured in the interface - should be resolved in the latest sources. > On Wed, Jul 14, 2010 at 5:40 AM, Adrian Chadd wrote: > Howdy! > > Compiling this on MIPS gives this error: > > Warning: Object directory not changed from original /usr/home/adrian/w/snmp_wlan > cc -fpic -DPIC -O -pipe -EB -msoft-float -G0 -mno-dsp -mabicalls > -DSNMPTREE_TYPES -g -I. -std=gnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c wlan_sys.c -o wlan_sys.So > cc1: warnings being treated as errors > wlan_sys.c: In function 'wlan_get_scan_results': > wlan_sys.c:2221: warning: cast increases required alignment of target type > wlan_sys.c: In function 'wlan_get_peerinfo': > wlan_sys.c:2713: warning: cast increases required alignment of target type > *** Error code 1 > In the latest sources, I replaced the cast with memcopy's which shold fix the errors, but I haven't tested it since I don't have a MIPS platform to test. It'll be good to know the errors have been actually fixed. > On Wed, Jul 14, 2010 at 6:16 AM, Adrian Chadd wrote: > I've already emailed you about the alignment warnings. > > The returned error value is an SNMPv2 error (SNMP_ERR_INCONS_VALUE) > which causes v1 requests to error out. Is it at all possible to return > something valid if a v1 request is made? The SNMP_ERR_INCONS_VALUE is only returned in responce to SET requests when the value requested for SET is not valid - in such case if the packet is SNMPv1 packet the SNMP agent should itself replace any SNMPv2 error code with a corresponding SNMPv1 code (e.g SNMP_ERR_BADVALUE should be returned instead of SNMP_ERR_INCONS_VALUE); could you please specify your agent config and what exact client command and aparameters are you issueing to produce the problem. > > snmpwalk'ing to inspect what -is- returned fails, even when querying in v2 mode: > > BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nRIFS."wlan0" = INTEGER: false(2) > BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nShortGI."wlan0" = INTEGER: false(2) > BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" = INTEGER: disabled(1) > Error in packet. > Reason: (genError) A general failure occured > Failed object: BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode."wlan0" > > The daemon logs errors when features aren't supported by the > underlying driver (eg querying TDMA stats on a non-TDMA interface.) > This may hide any actual underlying issues. This shouldn't be the case - the module reads each wlan parent capabilities and a relevant setting is only attempted in the kernel, only if the parent/wlan iterface capabilities indicate it is supported. I'm trying to test it on my system, but I don't see a problem. Again, could you please specify your kernel config, hardware wireless card, FreeBSD vsersion and the commands that you're running to create the problem. > > It isn't immediately clear which parameters are related to station and > which are related to hostap. Eg, wlanIfaceBeaconMissedThreshold. Is > that the station threshold or the AP threshold? Would it be worthwhile > creating separate branches for different stat types (station, ap, TDMA > AP, dot11n stuff, etc, etc?) rather than whacking it all together in > one tree? > The description of each object (and specifically under the wlanIfaceConfigTable table) in the BEGEMOT-WIRELESS-MIB.txt specifies whether the relevant object is meaningfull for interfaces in station or ap mode. I've thought about splitting the configuration in separate tables, but then there seven modes, not only station and host ap, and many objects are relevant for interfaces operating in any mode, so I decided to keep them in a common table. > I've not seen binary string indexing values on tables before. Eg: > > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'...$..'.61 = > STRING: 0:11:24:c7:e4:3d > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAddress."wlan0".'..#2'.'.219 = > STRING: 0:23:32:27:fc:db > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'...$..'.61 = > INTEGER: 2 > BEGEMOT-WIRELESS-MIB::wlanIfacePeerAssociationId."wlan0".'..#2'.'.219 > = INTEGER: 1 > > Is that going to be portable to different utilities? Some of the code > I've seen (and written!) expect numeric table indexes rather than what > I see above. > No, it's not uncommon to have binary strings as indexes, as it is also not uncommon to have several indexes for an entry - for example dot1dTpFdbTable (BRIDGE-MIB, RFC 4188) is indexed by the entry's MAC address, mgmdHostSrcListTable (MGMD-STD-MIB, RFC 5519) is indexed by address type (IPv4 or IPv6), a multicast group address, a interface index and a host ip address (again either IPv4 or IPv6). Many other examples may be given in standartized MIBs and no software should rely on having SNMP tables indexed by a single integer index. cheers, Shteryana From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 21:20: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 576031065679 for ; Mon, 19 Jul 2010 21:20:51 +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 90C8D8FC1C for ; Mon, 19 Jul 2010 21:20:47 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 63154A67B73; Tue, 20 Jul 2010 05:20:43 +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 JKXUhm6TxFe8; Tue, 20 Jul 2010 05:20:34 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 589D7A584C5; Tue, 20 Jul 2010 05:20:33 +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=Q2wBxVC/KGcJMEUGFBnlx+tgxpUMXuCn2/L3kJ0aSILHKPyKLAGW96H1BWeSfHI2i 9fEGt8XaZeD6i8AIK6tbw== Message-ID: <4C44C19C.4080302@delphij.net> Date: Mon, 19 Jul 2010 14:20:28 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: Michael Gusek References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> In-Reply-To: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problem with ZFS version 15 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: Mon, 19 Jul 2010 21:20:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 2010/07/17 06:40, Michael Gusek wrote: > Hi, > > i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reboot i upgrade my pool successfully to version 15. Now, after a new reboot the bootloader can't boot from version 15, it supports only 13. Well, i build a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says "gpart: No such geom: ad0". How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. If you have previous saved gpart information (e.g. start/end) then you can safely destroy and re-create the GPT partitions without destroying the data. Note that you may need to backup and dd the first and last sector of your hard drive before proceeding. Cheers, Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRMGcAAoJEATO+BI/yjfBbVUIAMIKRxUKMRpEdDJkPKqE3hZJ sjCUm8XveedJHVz2SupvpsQizo/hKDkgksfzeqeRd8JA1g4jerORLCNYilpcwMfc 2AiyjgvpKbsYmT27WcG4Grnl3eE4jFF+7Wm8B8WtuzE7L+YMo+QcEYiSPzL8P8hJ 1+RwLas/4nVkaDWWBW9osanLYT1v62zIN0ik1bnZypY3kYuprfJN3G7ZCKVX7ffD 4AZr7bvO57mcQOXON9gkmOMfewt89lNJiMYf5yQiGX+BL/i3pYUGSj2kt1Yc0su5 y5NyC42wiUNVEn15pVsIS5AUJVHs574pZBH2+DX5DfvDZMgxCkcUxgKq08QVnjE= =qQgN -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 21:37: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 4CD6B106577F for ; Mon, 19 Jul 2010 21:37:15 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0335B8FC13 for ; Mon, 19 Jul 2010 21:37:14 +0000 (UTC) Received: by gxk24 with SMTP id 24so3016482gxk.13 for ; Mon, 19 Jul 2010 14:37: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lKyzBX6mcOxuvLH1GL6d3vQPwQaQQ04xgeTwpC9LS6w=; b=CO4CZpU3E5tF8v68InZ6tAO4M67tUGRi5eyYxBx3e3TItzSNGFFspJgkanCUnNeijd g7Lcg2YcTo5PO/yjdkWdXqqMenDV6z6+T1T42QrijVyWniafJwkDDYv/l9fByfFQ0aLL ZsSNKTGq32qhnEm6yNnfut3jPNHLEhm8lrDB8= 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=qkfDGkKpEuKMrPP9BkJQ6iXRcjh/mmlgaHaBkw6u4MY/734bGulH/SVPPjmhaN+Cln HeQv9XMOQKI1PJUIVlBoowHgjkpSRaWDexxYQm7FwchpbUb+5LS2RUSNqGw/rUAnEGFF yMYWRMJndLcCbB8EWEwOTmnxlLxIlCp/40gzE= MIME-Version: 1.0 Received: by 10.224.28.213 with SMTP id n21mr2149894qac.53.1279575433872; Mon, 19 Jul 2010 14:37:13 -0700 (PDT) Received: by 10.229.35.205 with HTTP; Mon, 19 Jul 2010 14:37:13 -0700 (PDT) In-Reply-To: <4C44C19C.4080302@delphij.net> References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> <4C44C19C.4080302@delphij.net> Date: Mon, 19 Jul 2010 16:37:13 -0500 Message-ID: From: "Sam Fourman Jr." To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Michael Gusek Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Jul 2010 21:37:15 -0000 > If you have previous saved gpart information (e.g. start/end) then you > can safely destroy and re-create the GPT partitions without destroying > the data. > > Note that you may need to backup and dd the first and last sector of > your hard drive before proceeding. > Could someone post a example of how to correctly backup a gpart partition information -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 22:25: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 891131065674 for ; Mon, 19 Jul 2010 22:25:16 +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 C10108FC1A for ; Mon, 19 Jul 2010 22:25:15 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id A6806A67CC1; Tue, 20 Jul 2010 06:25:14 +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 ZpgMZYho26gn; Tue, 20 Jul 2010 06:25:04 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id EEBB8A67ADB; Tue, 20 Jul 2010 06:25:02 +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=mHfocVNzApDkT21rvv2KB8L49NjgPPcIYsTec6F1WW1lSo2IN+x/F1Wme3VDeSFlb /gGO+V3BCXlmQLPxSWGsw== Message-ID: <4C44D0BA.5080705@delphij.net> Date: Mon, 19 Jul 2010 15:24:58 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> <4C44C19C.4080302@delphij.net> 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: freebsd-current@freebsd.org, d@delphij.net, Michael Gusek Subject: Re: Problem with ZFS version 15 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: Mon, 19 Jul 2010 22:25:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/07/19 14:37, Sam Fourman Jr. wrote: >> If you have previous saved gpart information (e.g. start/end) then you >> can safely destroy and re-create the GPT partitions without destroying >> the data. >> >> Note that you may need to backup and dd the first and last sector of >> your hard drive before proceeding. >> > > Could someone post a example of how to correctly backup a gpart > partition information For now it would be to backup the first 34 and last 33 sectors of a given disk. Another way would be to copy what gpart show says and restore it manually. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRNC6AAoJEATO+BI/yjfBEjcIAIj3e/n7DUBfXhaUKEOSrP2q fvJlAKiQoDyRpzuovT/9/c9jCUxOOgpW43S7EVQ244uzgVEGB2Su5jXOjX6dU+rZ ba0JwH60ANMB6RAsJFSk1cT6xMmQ4TMfSYCwwlx9p6Fbv2ejdd5gKE+zvbc20fwN HIojqdF9xIW2XT3gjvAngn69c/0EtHoJVG1gydlO3H3te6iDVM6CY5yHV71WJrEk cFDD6x65VYmC2GWYYbeokf2ud8nry1QjzxzBJRd9T0eHXPWweJBC7lOsIOSW5QYa 1VsyhFE8s1xPwtYTAYFUw3IhBzJdLt36n+YAEQEbrX20/G5+Qn2oo/bw0kIYrFg= =SsvG -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 00:37:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6B0AA106567A; Tue, 20 Jul 2010 00:37:42 +0000 (UTC) Date: Tue, 20 Jul 2010 00:37:42 +0000 From: Alexander Best To: Xin Li Message-ID: <20100720003742.GA95384@freebsd.org> References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> <4C44C19C.4080302@delphij.net> <4C44D0BA.5080705@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C44D0BA.5080705@delphij.net> User-Agent: Mutt/1.4.2.1i Cc: "Sam Fourman Jr." , freebsd-current@freebsd.org, Michael Gusek Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 00:37:42 -0000 how about adding a periodic script to /etc/periodic/daily to backup the information? the idea was raised a long time ago already, but was abandoned [1]. cheers. alex [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/86388 On Mon, Jul 19, 2010 at 03:24:58PM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/07/19 14:37, Sam Fourman Jr. wrote: > >> If you have previous saved gpart information (e.g. start/end) then you > >> can safely destroy and re-create the GPT partitions without destroying > >> the data. > >> > >> Note that you may need to backup and dd the first and last sector of > >> your hard drive before proceeding. > >> > > > > Could someone post a example of how to correctly backup a gpart > > partition information > > For now it would be to backup the first 34 and last 33 sectors of a > given disk. Another way would be to copy what gpart show says and > restore it manually. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.15 (FreeBSD) > > iQEcBAEBCAAGBQJMRNC6AAoJEATO+BI/yjfBEjcIAIj3e/n7DUBfXhaUKEOSrP2q > fvJlAKiQoDyRpzuovT/9/c9jCUxOOgpW43S7EVQ244uzgVEGB2Su5jXOjX6dU+rZ > ba0JwH60ANMB6RAsJFSk1cT6xMmQ4TMfSYCwwlx9p6Fbv2ejdd5gKE+zvbc20fwN > HIojqdF9xIW2XT3gjvAngn69c/0EtHoJVG1gydlO3H3te6iDVM6CY5yHV71WJrEk > cFDD6x65VYmC2GWYYbeokf2ud8nry1QjzxzBJRd9T0eHXPWweJBC7lOsIOSW5QYa > 1VsyhFE8s1xPwtYTAYFUw3IhBzJdLt36n+YAEQEbrX20/G5+Qn2oo/bw0kIYrFg= > =SsvG > -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 01:03: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 6E9CC1065677 for ; Tue, 20 Jul 2010 01:03:25 +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 122E48FC1B for ; Tue, 20 Jul 2010 01:03:24 +0000 (UTC) Received: (qmail 20955 invoked by uid 399); 20 Jul 2010 01:03:24 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2010 01:03:24 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Mon, 19 Jul 2010 18:03:21 -0700 (PDT) From: Doug Barton To: Dan Nelson In-Reply-To: <20100718202338.GI5485@dan.emsphone.com> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> 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: Kostik Belousov , freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 01:03:25 -0000 I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and rebooted. I decided to try your script before things went sideways so I'd have an idea of what to expect, and it didn't work: dtrace: failed to initialize dtrace: DTrace device not available on system Is there something else I need to do to enable it? Doug On Sun, 18 Jul 2010, Dan Nelson wrote: > You can also use dtrace to get a count of callouts and their time spent. > Run this for a few seconds then hit ^C: > > #! /usr/sbin/dtrace -s > /* #pragma D option quiet */ > > callout_execute:::callout_start > { > this->start = timestamp; > } > > callout_execute:::callout_end > { > this->end = timestamp; > /* printf("%a %d\n",args[0]->c_func, this->end - this->start); */ > @times[args[0]->c_func] = quantize(this->end - this->start); > /* @times[args[0]->c_func] = lquantize(this->end - this->start,0,300000,10000); */ > @counts[args[0]->c_func] = count(); > } > > END > { > printa("%a %@u\n",@times); > printa("%a %@u\n",@counts); > } From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 01:19: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 6D050106566B for ; Tue, 20 Jul 2010 01:19:46 +0000 (UTC) (envelope-from yr.retarded@gmail.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 3D02D8FC0C for ; Tue, 20 Jul 2010 01:19:46 +0000 (UTC) Received: by pzk7 with SMTP id 7so1860619pzk.13 for ; Mon, 19 Jul 2010 18:19:45 -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; bh=7oWbhTDgur0Dd5EJsuATnqUsMu91sjUNMKvj3lVouTE=; b=HEq26+VkVLQEceI1C/Sk+iP4V3dZMSqKRNF9fajpucUzMlSfTnggCZSRd0k5XwUgbi l9O2N0qDh3HI0twCPpMgoHSvMTdSaDwIxdgK/jW/P0l8ATkzpWU65uAKIkxJvHWA9LTw 62qSJKoSMYv00KYIQvRBY9Ajicl+hQQIFS9qQ= 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; b=WfloLKiFKPWM5hTiCRncHbBu9KcblQHiDsa91PUGcXpb+sKxDo9YwDxl5nsRCQuyse JfPvA9JSEhDbkykITN4snocDIbmwej2fHauiBeLmbwH1ShwJs3ytqAe2PJArkqKzlb7d 2KXAdtliiuX9jRKe/q7Mx6SdtFkuLUHxaYrQ8= MIME-Version: 1.0 Received: by 10.142.171.9 with SMTP id t9mr8258129wfe.318.1279588785390; Mon, 19 Jul 2010 18:19:45 -0700 (PDT) Received: by 10.142.246.9 with HTTP; Mon, 19 Jul 2010 18:19:45 -0700 (PDT) In-Reply-To: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> Date: Mon, 19 Jul 2010 20:19:45 -0500 Message-ID: From: Chris Ruiz Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 01:19:46 -0000 On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton wrote: > I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and > rebooted. I decided to try your script before things went sideways so I'd > have an idea of what to expect, and it didn't work: > > dtrace: failed to initialize dtrace: DTrace device not available on system > > Is there something else I need to do to enable it? You need to build the kernel with CTF. Try adding "makeoptions WITH_CTF=yes" to your config and rebuilding your kernel. There's a blurb in src/UPDATING about other ways to accomplish the same thing. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 01:31: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 1BD861065673; Tue, 20 Jul 2010 01:31:13 +0000 (UTC) (envelope-from sfourman@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 B1A978FC17; Tue, 20 Jul 2010 01:31:12 +0000 (UTC) Received: by qyk7 with SMTP id 7so2943707qyk.13 for ; Mon, 19 Jul 2010 18:31: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; bh=6ri5M656TugtAtdCejlYbYxwNTC/pX0baB3+Rvetkuw=; b=AT3VJhsD0VKVG7Vr8r2ChaazmdxwWFHDqsJnrNpVJo363KPBKMkS9yscvWdAw0Onv6 90AbrVE1Or0BDqQRdlVL+7KKgBX1rjg1ZtnAWdwGZaqUb7uKEaj5vJkid5ZO4wwQ8zSm YvIb5o6hDpoLojspkP48wPwhkFNxiPUk2bVCo= 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=TrMS/b9vjldbi2U10QbbbpvW9q7xp4lt1xWmQUNlT0lNHe5swx3+k05nz3MhLM3ppX B44StLbP2YUuOjwFyYsKuXVi4StTeFPDFs/mnJjx9nSYLwKdEjat95pjUl9kYVrHbAFR PTNe8d9vA0UGWFzDhT9dP3djtWpS/Q41BSgqI= MIME-Version: 1.0 Received: by 10.224.78.68 with SMTP id j4mr4977408qak.231.1279589471756; Mon, 19 Jul 2010 18:31:11 -0700 (PDT) Received: by 10.229.35.205 with HTTP; Mon, 19 Jul 2010 18:31:11 -0700 (PDT) In-Reply-To: <20100720003742.GA95384@freebsd.org> References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> <4C44C19C.4080302@delphij.net> <4C44D0BA.5080705@delphij.net> <20100720003742.GA95384@freebsd.org> Date: Mon, 19 Jul 2010 20:31:11 -0500 Message-ID: From: "Sam Fourman Jr." To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Xin Li , Michael Gusek Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 01:31:13 -0000 On Mon, Jul 19, 2010 at 7:37 PM, Alexander Best wrote: > how about adding a periodic script to /etc/periodic/daily to backup the information? > > the idea was raised a long time ago already, but was abandoned [1]. > > cheers. > alex > I think that is a good idea, if you have a script to do that I would test it -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 01:38:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 762291065672; Tue, 20 Jul 2010 01:38:29 +0000 (UTC) Date: Tue, 20 Jul 2010 01:38:29 +0000 From: Alexander Best To: "Sam Fourman Jr." Message-ID: <20100720013829.GA7099@freebsd.org> References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> <4C44C19C.4080302@delphij.net> <4C44D0BA.5080705@delphij.net> <20100720003742.GA95384@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.1i Cc: freebsd-current@freebsd.org, Xin Li , Michael Gusek Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 01:38:29 -0000 On Mon, Jul 19, 2010 at 08:31:11PM -0500, Sam Fourman Jr. wrote: > On Mon, Jul 19, 2010 at 7:37 PM, Alexander Best wrote: > > how about adding a periodic script to /etc/periodic/daily to backup the information? > > > > the idea was raised a long time ago already, but was abandoned [1]. > > > > cheers. > > alex > > > > I think that is a good idea, if you have a script to do that I would test it unfortunately i don't. ;) i think however that for such a script using gpart to dump a fs's layout would be suited much better than dumping the primary and backup GPT table directly (using `dd` e.g.). cheers. alex > > > -- > > Sam Fourman Jr. > Fourman Networks > http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 02:33: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 092B41065673 for ; Tue, 20 Jul 2010 02:33: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 9D4FA8FC14 for ; Tue, 20 Jul 2010 02:33:04 +0000 (UTC) Received: (qmail 10899 invoked by uid 399); 20 Jul 2010 02:33:03 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2010 02:33:03 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Mon, 19 Jul 2010 19:33:01 -0700 (PDT) From: Doug Barton To: Chris Ruiz In-Reply-To: Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> 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: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 02:33:05 -0000 On Mon, 19 Jul 2010, Chris Ruiz wrote: > On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton wrote: >> I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and >> rebooted. I decided to try your script before things went sideways so I'd >> have an idea of what to expect, and it didn't work: >> >> dtrace: failed to initialize dtrace: DTrace device not available on system >> >> Is there something else I need to do to enable it? > > You need to build the kernel with CTF. Try adding "makeoptions > WITH_CTF=yes" to your config and rebuilding your kernel. There's a > blurb in src/UPDATING about other ways to accomplish the same thing. Thanks for the suggestion, but no improvement. Doing: strings /boot/kernel/kernel | grep -i dtrace Shows lots of dtrace-related entries, unlike previous kernels built without the KDTRACE_HOOKS option, but same error with Dan's script. 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 Jul 20 02:45: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 C7D1C1065672 for ; Tue, 20 Jul 2010 02:45:49 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F73B8FC0A for ; Tue, 20 Jul 2010 02:45:49 +0000 (UTC) Received: by pwj9 with SMTP id 9so2255773pwj.13 for ; Mon, 19 Jul 2010 19:45:49 -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:mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=fVFnbWrlRAeWiUqDOxthE3qH4cWJFJgZHsuyV5LJfGA=; b=R84ImJUEJudK8HFVP74VBvKc85c4X8EmtsgmOqV/v/zD+ldsbRr8yhB/3clHskr7Qm toDtiehhSQDysM9+0nO57fjpzc+dzp4bHlVapIX61mGyQdl/6WKVPeiRAy3c/NXwlAKg CwbYu7Vs2vG/BUia1PB2HzxGY2jpzhoAaAvZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=dmFhG0wjA6MpGfEHG292FsqfZus+rADCALRIQFRdgzZVW/Fzu8nMp1hoqyxvk4jGd2 +CCOZDEDA6mPEHf1//p+WWy4F1B9rN1ojqEXV1d2FT7MT7NOKqh0gKhAZAe1XVoHDGkE waYioi0e9KZSrW7uuFdc4lKQ4/SugrZzrlkh0= Received: by 10.142.179.10 with SMTP id b10mr8445703wff.157.1279593948853; Mon, 19 Jul 2010 19:45:48 -0700 (PDT) Received: from itx (c-67-174-240-133.hsd1.ca.comcast.net [67.174.240.133]) by mx.google.com with ESMTPS id x18sm7179755wfd.8.2010.07.19.19.45.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 19:45:47 -0700 (PDT) Date: Mon, 19 Jul 2010 19:45:41 -0700 From: Navdeep Parhar To: Doug Barton Message-ID: <20100720024541.GA25037@itx> Mail-Followup-To: Doug Barton , Chris Ruiz , freebsd-current@freebsd.org References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> 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) Cc: Chris Ruiz , freebsd-current@freebsd.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 02:45:49 -0000 On Mon, Jul 19, 2010 at 07:33:01PM -0700, Doug Barton wrote: > On Mon, 19 Jul 2010, Chris Ruiz wrote: > > >On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton wrote: > >>I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and > >>rebooted. I decided to try your script before things went sideways so I'd > >>have an idea of what to expect, and it didn't work: > >> > >>dtrace: failed to initialize dtrace: DTrace device not available on system > >> > >>Is there something else I need to do to enable it? > > > >You need to build the kernel with CTF. Try adding "makeoptions > >WITH_CTF=yes" to your config and rebuilding your kernel. There's a > >blurb in src/UPDATING about other ways to accomplish the same thing. > > Thanks for the suggestion, but no improvement. Doing: > strings /boot/kernel/kernel | grep -i dtrace > > Shows lots of dtrace-related entries, unlike previous kernels built > without the KDTRACE_HOOKS option, but same error with Dan's script. Try a "kldload dtraceall" before running the script. Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 02:50: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 DD78F1065670; Tue, 20 Jul 2010 02:50:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 703828FC17; Tue, 20 Jul 2010 02:50:15 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-064-190-223.pools.arcor-ip.net [88.64.190.223]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lxbep-1P8Z9p1ynr-016az2; Tue, 20 Jul 2010 04:50:14 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 20 Jul 2010 04:50:13 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RC2; 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: <201007200450.13885.max@love2party.net> X-Provags-ID: V02:K0:QryeLv3pe5pfMG8HPoIIzONMp8jUextDe1MpBS2NiJG /vjii8UyKy9pXOHfVzX+/2QaO4kh4QeyLhPTFQq3dO8Mj3DKLH 8InptC0uwL5W8FgsoP99tkj7jSDi05cBIqYds+r/HPryCKLJZd EmAAIrgisDxB1aXXb8hperB5J01YNgzIDQul0KbKM++dTVJQ6b tUVSoUSHCpV/niHUuP3Xg== Cc: Chris Ruiz , Doug Barton Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 02:50:15 -0000 On Tuesday 20 July 2010 04:33:01 Doug Barton wrote: > On Mon, 19 Jul 2010, Chris Ruiz wrote: > > On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton wrote: > >> I added options KDTRACE_HOOKS to my kernel config, built a new kernel, > >> and rebooted. I decided to try your script before things went sideways > >> so I'd have an idea of what to expect, and it didn't work: > >> > >> dtrace: failed to initialize dtrace: DTrace device not available on > >> system > >> > >> Is there something else I need to do to enable it? > > > > You need to build the kernel with CTF. Try adding "makeoptions > > WITH_CTF=yes" to your config and rebuilding your kernel. There's a > > blurb in src/UPDATING about other ways to accomplish the same thing. > > Thanks for the suggestion, but no improvement. Doing: > strings /boot/kernel/kernel | grep -i dtrace > > Shows lots of dtrace-related entries, unlike previous kernels built > without the KDTRACE_HOOKS option, but same error with Dan's script. Just a stab in the dark, did you "kldload dtraceall"? KDTRACE_HOOKS just adds the needed linkage for the dtrace modules to work. Max From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 02:55: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 B2FED1065672 for ; Tue, 20 Jul 2010 02:55:52 +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 3F8E28FC14 for ; Tue, 20 Jul 2010 02:55:51 +0000 (UTC) Received: (qmail 10374 invoked by uid 399); 20 Jul 2010 02:55:51 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2010 02:55:51 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Mon, 19 Jul 2010 19:55:49 -0700 (PDT) From: Doug Barton To: Max Laier In-Reply-To: <201007200450.13885.max@love2party.net> Message-ID: References: <201007200450.13885.max@love2party.net> 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: Chris Ruiz , freebsd-current@freebsd.org Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 02:55:52 -0000 On Tue, 20 Jul 2010, Max Laier wrote: > Just a stab in the dark, did you "kldload dtraceall"? KDTRACE_HOOKS just adds > the needed linkage for the dtrace modules to work. No, I had not done that, in fact, I didn't even know I needed those modules. I use MODULES_OVERRIDE so I had to add dtrace, cyclic, and opensolaris to the list. In any case ... It's working now! :) I'm collecting some data for "normal" atm, then I'll try to get it into the situation where intr runs away, and I'll do the same thing again. Thanks Max and Chris, 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 Jul 20 02:58: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 9F8BF1065678 for ; Tue, 20 Jul 2010 02:58:01 +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 76D518FC08 for ; Tue, 20 Jul 2010 02:58:01 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6K2w0nZ037654 for ; Tue, 20 Jul 2010 02:58:00 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C4510B8.6090105@freebsd.org> Date: Tue, 20 Jul 2010 10:58:00 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: firefox is stuck in getbuf() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 02:58:01 -0000 With newest -HEAD code, firefox is stuck in getbuf(). top last pid: 1814; load averages: 0.00, 0.05, 0.07 up 0+00:37:11 10:54:01 135 processes: 1 running, 134 sleeping CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M Free Swap: 2020M Total, 2020M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1427 davidxu 1 45 0 114M 101M select 0 1:24 0.29% Xorg 1588 davidxu 10 44 0 279M 145M getbuf 0 2:15 0.00% firefox-bin procstat -k 1588 PID TID COMM TDNAME KSTACK 1588 100200 firefox-bin initial thread mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100207 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll syscallenter syscall Xint0x80_syscall 1588 100208 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100209 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100210 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100216 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100220 firefox-bin - mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100238 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100239 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100240 firefox-bin - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 03:31: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 51584106566B for ; Tue, 20 Jul 2010 03:31:56 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6A48FC15 for ; Tue, 20 Jul 2010 03:31:55 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o6K3VtqI078945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jul 2010 22:31:55 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o6K3Vs41094292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Jul 2010 22:31:55 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o6K3Pjcr078879; Mon, 19 Jul 2010 22:25:45 -0500 (CDT) (envelope-from dan) Date: Mon, 19 Jul 2010 22:25:45 -0500 From: Dan Nelson To: Doug Barton Message-ID: <20100720032545.GM5485@dan.emsphone.com> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Mon, 19 Jul 2010 22:31:55 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Kostik Belousov , freebsd-current@FreeBSD.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 03:31:56 -0000 In the last episode (Jul 19), Doug Barton said: > I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and > rebooted. I decided to try your script before things went sideways so I'd > have an idea of what to expect, and it didn't work: > > dtrace: failed to initialize dtrace: DTrace device not available on system > > Is there something else I need to do to enable it? I think you also need WITH_CTF=yes , either in your kernel config or directly on the make commandline. The kernel config option should work, but if it doesn't, it's guaranteed to work on the commandline. http://wiki.freebsd.org/DTrace http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016620.html -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 06:02:12 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 26BF01065672 for ; Tue, 20 Jul 2010 06:02:12 +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 A02AB8FC0A for ; Tue, 20 Jul 2010 06:02:11 +0000 (UTC) Received: (qmail 7680 invoked by uid 399); 20 Jul 2010 06:02:10 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2010 06:02:10 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Mon, 19 Jul 2010 23:02:07 -0700 (PDT) From: Doug Barton To: Dan Nelson In-Reply-To: <20100718202338.GI5485@dan.emsphone.com> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> 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: Kostik Belousov , freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 06:02:12 -0000 On Sun, 18 Jul 2010, Dan Nelson wrote: > You can also use dtrace to get a count of callouts and their time spent. > Run this for a few seconds then hit ^C: Okey dokey, here you go: http://people.freebsd.org/~dougb/normal-dtrace.txt http://people.freebsd.org/~dougb/bad-dtrace.txt Thanks again, 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 Jul 20 06:05: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 C9FA61065676 for ; Tue, 20 Jul 2010 06:05:30 +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 501C78FC1B for ; Tue, 20 Jul 2010 06:05:30 +0000 (UTC) Received: (qmail 11895 invoked by uid 399); 20 Jul 2010 06:05:29 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2010 06:05:29 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Mon, 19 Jul 2010 23:05:26 -0700 (PDT) From: Doug Barton To: Kostik Belousov In-Reply-To: <20100718194109.GU2381@deviant.kiev.zoral.com.ua> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.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, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 06:05:30 -0000 On Sun, 18 Jul 2010, Kostik Belousov wrote: > When intr time starts accumulating again, try to do > "procstat -kk " and correlate the clock thread tid > with the backtrace. Might be, it helps to guess what callouts are eating > the CPU. Ok, I thought I was going to be able to do this easily but I didn't realize that the numbers in the second column were thread ids, and I don't know how to "correlate the clock thread tid with the backtrace." Can you give me a hint? :) 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 Jul 20 09:52: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 37AEA106566B for ; Tue, 20 Jul 2010 09:52:01 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate07.web.de (fmmailgate07.web.de [217.72.192.248]) by mx1.freebsd.org (Postfix) with ESMTP id C24E58FC17 for ; Tue, 20 Jul 2010 09:52:00 +0000 (UTC) Received: from mwmweb017 ( [172.20.18.26]) by fmmailgate07.web.de (Postfix) with ESMTP id 5444335A0FE; Tue, 20 Jul 2010 11:51:59 +0200 (CEST) Received: from [77.184.69.16] by mwmweb017 with HTTP; Tue Jul 20 11:51:59 CEST 2010 Message-ID: <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017> Date: Tue, 20 Jul 2010 11:51:59 +0200 (CEST) From: Michael Gusek MIME-Version: 1.0 To: d@delphij.net References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017>, <4C44C19C.4080302@delphij.net> In-Reply-To: <4C44C19C.4080302@delphij.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-UI-ATTACHMENT-ID-POSTFIX: ba5ecdf8-f495-4d4d-a09f-513bb336e7ad X-Priority: 3 Importance: normal Sensitivity: Normal X-Provags-ID: V01U2FsdGVkX1+hfABRRYxJOCiVog3dz0O790v0jweKs5B76ke94hPDVWBfyllC66KK 2sBYpP7GRvZT6uu86HUI10XuyoJ0DW9O1TPO/JsYFjB7t+AB/MfKvA== Cc: freebsd-current@freebsd.org Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 09:52:01 -0000 -----Urspr=C3=BCngliche Nachricht----- Von: Xin LI Gesendet: 19.07.2010 23:20:28 An: Michael Gusek Betreff: Re: Problem with ZFS version 15 >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >Hi, > >On 2010/07/17 06:40, Michael Gusek wrote: >> Hi, >>=20 >> i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.f= reebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reb= oot i upgrade my pool successfully to version 15. Now, after a new reboot t= he bootloader can't boot from version 15, it supports only 13. Well, i buil= d a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it a= nd apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot= -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says "g= part: No such geom: ad0". How can i recover my gpt on ad0 and ad1 ? I'm run= ning a zfs mirror on ad0 and ad1. > >If you have previous saved gpart information (e.g. start/end) then you >can safely destroy and re-create the GPT partitions without destroying >the data. > >Note that you may need to backup and dd the first and last sector of >your hard drive before proceeding. > I don't have such a backup, only the whole disk for now. Everything else wh= at can i do ? What if i initialize the gpt header: "gpart create -s GPT ad0= " ? Do i lost my data ? Micha >Cheers, > >Cheers, >- --=20 >Xin LI =09http://www.delphij.net/ >FreeBSD - The Power to Serve!=09 Live free or die >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.15 (FreeBSD) > >iQEcBAEBCAAGBQJMRMGcAAoJEATO+BI/yjfBbVUIAMIKRxUKMRpEdDJkPKqE3hZJ >sjCUm8XveedJHVz2SupvpsQizo/hKDkgksfzeqeRd8JA1g4jerORLCNYilpcwMfc >2AiyjgvpKbsYmT27WcG4Grnl3eE4jFF+7Wm8B8WtuzE7L+YMo+QcEYiSPzL8P8hJ >1+RwLas/4nVkaDWWBW9osanLYT1v62zIN0ik1bnZypY3kYuprfJN3G7ZCKVX7ffD >4AZr7bvO57mcQOXON9gkmOMfewt89lNJiMYf5yQiGX+BL/i3pYUGSj2kt1Yc0su5 >y5NyC42wiUNVEn15pVsIS5AUJVHs574pZBH2+DX5DfvDZMgxCkcUxgKq08QVnjE=3D >=3DqQgN >-----END PGP SIGNATURE----- >_______________________________________________ >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" ___________________________________________________________ GRATIS f=C3=BCr alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 10:03: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 A46EF1065677 for ; Tue, 20 Jul 2010 10:03:23 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51801.mail.re2.yahoo.com (web51801.mail.re2.yahoo.com [206.190.38.232]) by mx1.freebsd.org (Postfix) with SMTP id 409158FC0A for ; Tue, 20 Jul 2010 10:03:22 +0000 (UTC) Received: (qmail 354 invoked by uid 60001); 20 Jul 2010 10:03:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1279620202; bh=9WBR2oGDu6nlU0TP9bX+mV837F2QVHLkCNfU/Yl1VFo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2zehmB+YgQT9mtNJfelKIQ4T2DErCBsd5zC6IvKUcpoUx0SHs3pFUES+KqIPk5uSRUetDc2FergtlKH94VkQ9xpqC7/058Tau+ee73GSYdXIASNSPjLlIGShg/0nekYb+HH/fHscIdXOXQq69lYAoxmMDvo5oloBCaOPsTmhRTE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mWFZwtRNxd92g2EWzuaQOdy99G8h2wrwzHPya1zDDGfoueYB5Zn/ckeqqJaxAM/G1fycGHP7htfyhsu3r/xJC7dBIxiEKWonaesyS74jREYP+knXhXCaSBl6E4eIxMb+Wy0d/rMImbyJixrbvjvx1cK9YEd7aYP9OE/nYRTGHuk=; Message-ID: <504334.98385.qm@web51801.mail.re2.yahoo.com> X-YMail-OSG: 4H6sSfQVM1nlRF_lds7wrQNKUPTn3X_C4C1aO08BqYrJZOc UPvTBYo3CyuL5rbI.vqc3vGmTuuQ704n3_pKPxvw_7ct925qu8cYOGTI9EkB 9I6f4QZcQxMLbOJ0Pk1a1481QuvDey0k86sriG5hIpItBHfX4S3wEHXFq1Mq J060FKmnk.9EKfQ0ujcogGw6OiB_B5FhKSe4rCjGodEup7HIEWZVTfeg5YLz 8nSYC9PUy4ZpjFqZXW3WB7bvu15tffaYxyj2bwJETlpePsOV.Y94EA8y4MTz gPnf0DvN86pOew8fzEmh2QksjBHCDRx17CK7_GVORVm6bJ7A_rKqPjLSPD3a Ouqr2UTR0ga0- Received: from [173.183.132.20] by web51801.mail.re2.yahoo.com via HTTP; Tue, 20 Jul 2010 03:03:22 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.104.276605 References: <201007141511.46190.hselasky@c2i.net> <964771.49833.qm@web51808.mail.re2.yahoo.com> <201007192117.05034.hselasky@c2i.net> Date: Tue, 20 Jul 2010 03:03:22 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky , freebsd-current@freebsd.org In-Reply-To: <201007192117.05034.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Leffler , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 10:03:23 -0000 ----- Original Message ---- > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: PseudoCylon ; Sam Leffler ; >freebsd-usb@freebsd.org > Sent: Mon, July 19, 2010 1:17:04 PM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > Hi AK, > > I've committed your patches to USB P4. I've made some additional patches. > > Can you check and verify everything? > > http://p4web.freebsd.org/@@181189?ac=10 > Hi If we change sc->cmdq_run = RUN_CMDQ_ABORT, -- begin excerpt -- @@ -4890,7 +4877,10 @@ run_stop(void *arg) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); sc->ratectl_run = RUN_RATECTL_OFF; -sc->cmdq_run = RUN_CMDQ_ABORT; + +RUN_CMDQ_LOCK(sc); +sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT; +RUN_CMDQ_UNLOCK(sc); -- end excerpt -- we also need to change this, otherwise key will be cleared. -- begin patch -- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index 017e4b0..f7abe17 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -4670,8 +4670,6 @@ run_init_locked(struct run_softc *sc) if(ic->ic_nrunning > 1) return; -run_stop(sc); - for (ntries = 0; ntries < 100; ntries++) { if (run_read(sc, RT2860_ASIC_VER_ID, &tmp) != 0) goto fail; -- end patch -- > Also please compile a kernel with WITNESS enabled to catch any LOR's, hence we > > introduced another mutex. > The 2nd mutex did solve a deadlock, but doesn't solve the LOR. -- begin message -- lock order reversal: 1st 0xffffff8000a257d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1736 2nd 0xffffff8000a19348 run0 (network driver) @ /mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:2212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 run_key_delete() at run_key_delete+0x45 _ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x9e ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x28 ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x78 ieee80211_sta_leave() at ieee80211_sta_leave+0x16 ieee80211_node_leave() at ieee80211_node_leave+0x11d hostap_recv_mgmt() at hostap_recv_mgmt+0x33f hostap_input() at hostap_input+0xc09 run_rx_frame() at run_rx_frame+0x13f run_bulk_rx_callback() at run_bulk_rx_callback+0x3b7 usbd_callback_wrapper() at usbd_callback_wrapper+0x12b usb_command_wrapper() at usb_command_wrapper+0x76 usb_callback_proc() at usb_callback_proc+0x76 usb_process() at usb_process+0xbb fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8029b4ed30, rbp = 0 --- -- end message -- or -- begin message -- lock order reversal: 1st 0xffffff8000a257d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_node.c:1736 2nd 0xffffff8000a19348 run0 (network driver) @ /mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:2212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 run_key_delete() at run_key_delete+0x47 _ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x9e ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x28 ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x78 ieee80211_sta_leave() at ieee80211_sta_leave+0x16 ieee80211_node_leave() at ieee80211_node_leave+0x11d ieee80211_node_timeout() at ieee80211_node_timeout+0x1d5 softclock() at softclock+0x2a0 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000052d30, rbp = 0 --- -- end message -- There are new warning, "acquiring duplicate lock." For example, -- begin message -- acquiring duplicate lock of same type: "network driver" 1st run0 @ /usr/src/sys/dev/usb/usb_request.c:691 2nd run0 @ /mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:4831 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x8ef _mtx_lock_flags() at _mtx_lock_flags+0x78 run_init_locked() at run_init_locked+0x753 run_ioctl() at run_ioctl+0xad taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803e5b2d30, rbp = 0 --- -- end message -- I don't know if it's worth patching or safe to patch (specially lock/unlock in run_bulk_tx_callbackN()), but here is one -- begin patch -- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index 017e4b0..2a0b5b6 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -712,14 +712,14 @@ run_detach(device_t self) /* stop all USB transfers */ usbd_transfer_unsetup(sc->sc_xfer, RUN_N_XFER); -RUN_LOCK(sc); - -sc->ratectl_run = RUN_RATECTL_OFF; - RUN_CMDQ_LOCK(sc); sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT; RUN_CMDQ_UNLOCK(sc); +RUN_LOCK(sc); + +sc->ratectl_run = RUN_RATECTL_OFF; + /* free TX list, if any */ for (i = 0; i != RUN_EP_QUEUES; i++) run_unsetup_tx_list(sc, &sc->sc_epq[i]); @@ -2865,6 +2865,9 @@ tr_setup: if ((error == USB_ERR_TIMEOUT) && (vap != NULL)) { uint8_t i; device_printf(sc->sc_dev, "device timeout\n"); + +RUN_UNLOCK(sc); + RUN_CMDQ_LOCK(sc); i = run_cmdq_append(sc); if (i < RUN_CMDQ_MAX) { @@ -2874,6 +2877,8 @@ tr_setup: RUN_CMDQ_UNLOCK(sc); if (i < RUN_CMDQ_MAX) ieee80211_runtask(ic, &sc->cmdq_task); + +RUN_LOCK(sc); } /* @@ -3134,6 +3139,8 @@ run_tx(struct run_softc *sc, struct mbuf *m, struct ieee80211_node *ni) */ uint8_t i; +RUN_UNLOCK(sc); + RUN_CMDQ_LOCK(sc); i = run_cmdq_append(sc); if (i < RUN_CMDQ_MAX) { @@ -3144,6 +3151,7 @@ run_tx(struct run_softc *sc, struct mbuf *m, struct ieee80211_node *ni) if (i < RUN_CMDQ_MAX) ieee80211_runtask(ic, &sc->cmdq_task); +RUN_LOCK(sc); } } @@ -4670,8 +4678,6 @@ run_init_locked(struct run_softc *sc) if(ic->ic_nrunning > 1) return; -run_stop(sc); - for (ntries = 0; ntries < 100; ntries++) { if (run_read(sc, RT2860_ASIC_VER_ID, &tmp) != 0) goto fail; @@ -4827,9 +4833,11 @@ run_init_locked(struct run_softc *sc) ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; ifp->if_drv_flags |= IFF_DRV_RUNNING; +RUN_UNLOCK(sc); RUN_CMDQ_LOCK(sc); sc->cmdq_run = RUN_CMDQ_GO; RUN_CMDQ_UNLOCK(sc); +RUN_LOCK(sc); for(i = 0; i != RUN_N_XFER; i++) usbd_xfer_set_stall(sc->sc_xfer[i]); @@ -4878,12 +4886,12 @@ run_stop(void *arg) sc->ratectl_run = RUN_RATECTL_OFF; +RUN_UNLOCK(sc); + RUN_CMDQ_LOCK(sc); sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT; RUN_CMDQ_UNLOCK(sc); -RUN_UNLOCK(sc); - for(i = 0; i < RUN_N_XFER; i++) usbd_transfer_drain(sc->sc_xfer[i]); -- end patch -- There is a LOR between node lock and run lock in run_raw_xmit(), but I haven't been able to reproduce with the latest driver. This LOR has been around since addition of hostap mode. I didn't fix it because everyone would have objected if I had deferred run_raw_xmit(). Following LORs are also around from the beginning and not related to this change, but just for info -- begin message -- lock order reversal: 1st 0xffffff8000a257d0 run0_node_lock (run0_node_lock) @ /usr/src/sys/net80211/ieee80211_ioctl.c:1326 2nd 0xffffff8000a24018 run0_com_lock (run0_com_lock) @ /usr/src/sys/net80211/ieee80211_node.c:2486 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 ieee80211_node_leave() at ieee80211_node_leave+0x80 setmlme_common() at setmlme_common+0x27b ieee80211_ioctl_setmlme() at ieee80211_ioctl_setmlme+0x7e ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0xaba in_control() at in_control+0x1ff ifioctl() at ifioctl+0x1100 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xf0 syscallenter() at syscallenter+0x1b5 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8008a8d4c, rsp = 0x7fffffffe898, rbp = 0x800ca6200 --- -- end message -- -- begin message -- lock order reversal: 1st 0xffffff8000a24018 run0_com_lock (run0_com_lock) @ /usr/src/sys/net80211/ieee80211_scan.c:683 2nd 0xffffff8000a25928 run0_scan_lock (run0_scan_lock) @ /usr/src/sys/net80211/ieee80211_node.c:2135 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 ieee80211_iterate_nodes() at ieee80211_iterate_nodes+0x3d hostap_newstate() at hostap_newstate+0x3a1 run_newstate() at run_newstate+0x1ef ieee80211_newstate_cb() at ieee80211_newstate_cb+0x71 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803e5b7d30, rbp = 0 --- -- end message -- AK From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 10:17: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 092C11065687 for ; Tue, 20 Jul 2010 10:17:39 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8BEC98FC0A for ; Tue, 20 Jul 2010 10:17:38 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o6KAHauJ043315; Tue, 20 Jul 2010 12:17:36 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o6KAHa6x043314; Tue, 20 Jul 2010 12:17:36 +0200 (CEST) (envelope-from marius) Date: Tue, 20 Jul 2010 12:17:36 +0200 From: Marius Strobl To: =?unknown-8bit?Q?St=E5le?= Kristoffersen Message-ID: <20100720101736.GD4706@alchemy.franken.de> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> <20100719170654.GA19889@putsch.kolbu.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100719170654.GA19889@putsch.kolbu.ws> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 10:17:39 -0000 On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote: > On 2010-07-18 at 14:20, Marius Strobl wrote: > > > > Downgrading now... > > > > > > And it crashed again, with current from r209598... > > > > > > > Ok, this at least means that your problem isn't caused by the recent > > changes to mpt(4) as the pre-r209599 version only differed from the > > 8-STABLE one in a cosmetic change at that time. > > I have another data-point, I cvsup'ed to the latest current again, and > rebuilt without INVARIANT and WITNESS, and now it seems to survive the > timeouts. That's more or less expected as the sanity check issuing the panic just isn't compiled in then. However, my understanding was that with STABLE you don't get the timeouts in the first place, or do you see them there also? Marius From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 10:48: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 6CA65106568E for ; Tue, 20 Jul 2010 10:48:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id 14BD18FC14 for ; Tue, 20 Jul 2010 10:48:14 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward12.mail.yandex.net (Yandex) with ESMTP id 5355022104E1; Tue, 20 Jul 2010 14:48:13 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1279622893; bh=/y7ag79rPAj8AW1fNRFD+kaUhHjyNJ+q5K3eclFKDlc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=D114TI7/oIV7ljGn1lR9owrztmLWLiIJBMDywWaDq/LLqzVKUkJfll8CNLxWkrE6b NpBqrNb0nIAZgvvEwVyUNXbGve0objjtwfBu32TM6KhS7Ev+bDlhv/SYp3esKBXjFF E7+39HSxH9z0uxM3fHrxfbCUgqFEqszg44VhGLf0= Received: from [10.43.163.197] (static-76-197.kirovnet.ru [92.39.76.197]) by smtp11.mail.yandex.net (Yandex) with ESMTPSA id 12FEA44D8086; Tue, 20 Jul 2010 14:48:13 +0400 (MSD) Message-ID: <4C457ED5.1010907@yandex.ru> Date: Tue, 20 Jul 2010 14:47:49 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100611 Thunderbird/3.0.4 MIME-Version: 1.0 To: Michael Gusek References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017>, <4C44C19C.4080302@delphij.net> <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017> In-Reply-To: <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig541C5CB28FD0F4031075D6C1" X-Yandex-TimeMark: 1279622893 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.mail.yandex.net Cc: freebsd-current@freebsd.org, d@delphij.net Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 10:48:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig541C5CB28FD0F4031075D6C1 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 20.07.2010 13:51, Michael Gusek wrote: >>>> and apply a new bootloader: gpart bootcode -b /boot/pmbr -p >>>> /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt >>>> scheme ! gpart show ad0 says "gpart: No such geom: ad0". How >>>> can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror >>>> on ad0 and ad1. It is very strange why this command broke your GPT. Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. >> I don't have such a backup, only the whole disk for now. Everything >> else what can i do ? What if i initialize the gpt header: "gpart >> create -s GPT ad0" ? Do i lost my data ? GPT headers and tables will be initialized. After that you should add all partitions with exactly same offsets and sizes. In this case your data will not be touched. --=20 WBR, Andrey V. Elsukov --------------enig541C5CB28FD0F4031075D6C1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJMRX7ZAAoJEAHF6gQQyKF6gqYIALFIeCK9NSo8SNgA5K1PJKPv afxItfBpSYGHu6RJH6bzX9QzzaEK90WgwYtlseikKU9l6HCyoCHbT44CT8NjXprW 6g5tsr3upbnWfzu4BrUw42iR0KYD1qJJPZtLr7IfEmQiF6mthJoKbI0FuS/xKQdC 9xfKk3N4OH/lhm2f27B54+HDPlNVDKAMlGCEkURrV09B1x9pGR8bq847VGE4nTwP LUM0mncVbWTRIqeSgxCUXEcmXg5EvgWbo2DlU03wqKsBrkfgQ/svf/mnFagvekY3 c6G57rlMB8jdqfsoUKHZGAbD/MlPLhQB9KGfxgw3SsPVvvuwcN97qNxAkhFdSz0= =CR9S -----END PGP SIGNATURE----- --------------enig541C5CB28FD0F4031075D6C1-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 10:49: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 B7A8F1065674; Tue, 20 Jul 2010 10:49:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id E617E8FC0A; Tue, 20 Jul 2010 10:49:32 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HRj3ij7MtkgA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=BYtiyKqR4ApS3tB-cVAA:9 a=Tyssu-7BCdl8jOWnyjmdT0r4CX4A:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=SV7veod9ZcQA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1376044727; Tue, 20 Jul 2010 12:49:30 +0200 From: Hans Petter Selasky To: PseudoCylon Date: Tue, 20 Jul 2010 12:46:34 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201007141511.46190.hselasky@c2i.net> <201007192117.05034.hselasky@c2i.net> <504334.98385.qm@web51801.mail.re2.yahoo.com> In-Reply-To: <504334.98385.qm@web51801.mail.re2.yahoo.com> 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-1" Content-Transfer-Encoding: 7bit Message-Id: <201007201246.34654.hselasky@c2i.net> Cc: Sam Leffler , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 10:49:33 -0000 On Tuesday 20 July 2010 12:03:22 PseudoCylon wrote: > ----- Original Message ---- > > > From: Hans Petter Selasky > > To: freebsd-current@freebsd.org > > Cc: PseudoCylon ; Sam Leffler ; > > > >freebsd-usb@freebsd.org > > > > Sent: Mon, July 19, 2010 1:17:04 PM > > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > > > Hi AK, > > > > I've committed your patches to USB P4. I've made some additional > > patches. > > > > Can you check and verify everything? > > > > http://p4web.freebsd.org/@@181189?ac=10 > > Hi > > If we change sc->cmdq_run = RUN_CMDQ_ABORT, > > -- begin excerpt -- > > > @@ -4890,7 +4877,10 @@ run_stop(void *arg) > ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); > > sc->ratectl_run = RUN_RATECTL_OFF; > -sc->cmdq_run = RUN_CMDQ_ABORT; > + > +RUN_CMDQ_LOCK(sc); > +sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT; > +RUN_CMDQ_UNLOCK(sc); > > -- end excerpt -- > > > we also need to change this, otherwise key will be cleared. Ok. Try to give the second mutex a different name, and see how many warnings go away. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 11: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 D5AC31065687 for ; Tue, 20 Jul 2010 11:25:52 +0000 (UTC) (envelope-from marcelorossi@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 8628D8FC1D for ; Tue, 20 Jul 2010 11:25:52 +0000 (UTC) Received: by qwg5 with SMTP id 5so41284qwg.13 for ; Tue, 20 Jul 2010 04:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=6CDn1Tmu2Wa4jRH+7eAQ/iFsSu4lrbMvqGwS3hjk500=; b=qBrbhtdBKm4DrdF8yhYGQeszzpz+kLXgXeWNK+7XXvPK+3pViaBkg93wzhXowX4FCo i+jfU2MZsgu8O74L2APKfVVgvOG8rGAd4rXdlDm9yzs1aV394zP+fSQm1t/S3Ifm22L9 xokAS69/uOJoHggnVN769O7CMbQkspt1xWDy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=KSVUUuhXnG9lat5ANxnOwcZVcxaXtUsvsUI9xirvV+z94x5EuQig+qABp/NR3cJbq+ VpOooLUO/eRZU9RPHX2EWA1sqUxEH5UiilPtJ2RdkuP1Gt2QyAJ7kkuzS5KaiWaAzceV /BQ2TDlM81TrsChanCTcMFw8kVXaECwu22geU= Received: by 10.224.29.4 with SMTP id o4mr5956544qac.203.1279625127199; Tue, 20 Jul 2010 04:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.92.20 with HTTP; Tue, 20 Jul 2010 04:25:07 -0700 (PDT) In-Reply-To: <20100714183834.GA19684@freebsd.org> References: <20100714183834.GA19684@freebsd.org> From: "Marcelo/Porks" Date: Tue, 20 Jul 2010 08:25:07 -0300 Message-ID: To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 11:25:52 -0000 On Wed, Jul 14, 2010 at 3:38 PM, Roman Divacky wrote: > hi, > > ClangBSD was updated to LLVM/clang revision r108243 which we plan to > merge into HEAD. We would like that revision to be tested as much as possible > and therefore we ask you to test ClangBSD to assure that the revision > we are updating to does not have some really embarassing bugs. > > How to do it (on i386 and amd64): > > 0) install fresh devel/llvm-devel port > > 1) svn co http://svn.freebsd.org/base/projects/clangbsd src > > 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf > > 3) cd src && make buildworld Hi. Until here worked fine. I'm on an AMD64-Quadcore (Phenom x4). I did 'make buildworld'. Should I use something like 'make -j 8' for testing? The 'installworld' and kernel I will test thursday. -- Marcelo Rossi "This e-mail is provided "AS IS" with no warranties, and confers no rights." "I have nothing against God, I just hate His fan club" From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 11:30: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 0BE731065677 for ; Tue, 20 Jul 2010 11:30:58 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate05.web.de (fmmailgate05.web.de [217.72.192.243]) by mx1.freebsd.org (Postfix) with ESMTP id 923118FC15 for ; Tue, 20 Jul 2010 11:30:57 +0000 (UTC) Received: from mwmweb017 ( [172.20.18.26]) by fmmailgate05.web.de (Postfix) with ESMTP id 3FE4A60EC11F; Tue, 20 Jul 2010 13:30:56 +0200 (CEST) Received: from [77.184.69.16] by mwmweb017 with HTTP; Tue Jul 20 13:30:56 CEST 2010 Message-ID: <212927891.6184084.1279625456256.JavaMail.fmail@mwmweb017> Date: Tue, 20 Jul 2010 13:30:56 +0200 (CEST) From: Michael Gusek MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017>, <4C44C19C.4080302@delphij.net> <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017>, <4C457ED5.1010907@yandex.ru> In-Reply-To: <4C457ED5.1010907@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig541C5CB28FD0F4031075D6C1" X-UI-Message-Type: mail X-Priority: 3 Importance: normal Sensitivity: Normal X-Provags-ID: V01U2FsdGVkX1/el/pfPo0D0oA7uFxfIMcaqFEOCjQXv++ZciEHQCn+Vc2qdp8nxPHf WvBtavearIoo99uzujzMGZDoCUy+hyg6CgWOCo9m51O5QvRzjQJMCw== Cc: freebsd-current@freebsd.org Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 11:30:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig541C5CB28FD0F4031075D6C1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UI-ATTACHMENT-ID-POSTFIX: 3c3ba4b7-59af-413c-a0a6-1075f8491b4d -----Urspr?ngliche Nachricht----- Von: "Andrey V. Elsukov" Gesendet: 20.07.2010 12:47:49 An: Michael Gusek Betreff: Re: Problem with ZFS version 15 >On 20.07.2010 13:51, Michael Gusek wrote: >>>>> and apply a new bootloader: gpart bootcode -b /boot/pmbr -p >>>>> /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt >>>>> scheme ! gpart show ad0 says "gpart: No such geom: ad0". How >>>>> can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror >>>>> on ad0 and ad1. > >It is very strange why this command broke your GPT. >Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. Yes, this is very strange. > >>> I don't have such a backup, only the whole disk for now. Everything >>> else what can i do ? What if i initialize the gpt header: "gpart >>> create -s GPT ad0" ? Do i lost my data ? > >GPT headers and tables will be initialized. After that you should >add all partitions with exactly same offsets and sizes. In this case >your data will not be touched. > Ok, i will try it. I did a backup of the first 16GB of my disk, because i d= on't know the exact size of my swap partition, but this is my part. Thank you, Michael >--=20 >WBR, Andrey V. Elsukov > ___________________________________________________________ GRATIS f=C3=BCr alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de --------------enig541C5CB28FD0F4031075D6C1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" X-UI-ATTACHMENT-ID-POSTFIX: bbb8916b-b49e-4272-993c-037f577dfa30 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJMRX7ZAAoJEAHF6gQQyKF6gqYIALFIeCK9NSo8SNgA5K1PJKPv afxItfBpSYGHu6RJH6bzX9QzzaEK90WgwYtlseikKU9l6HCyoCHbT44CT8NjXprW 6g5tsr3upbnWfzu4BrUw42iR0KYD1qJJPZtLr7IfEmQiF6mthJoKbI0FuS/xKQdC 9xfKk3N4OH/lhm2f27B54+HDPlNVDKAMlGCEkURrV09B1x9pGR8bq847VGE4nTwP LUM0mncVbWTRIqeSgxCUXEcmXg5EvgWbo2DlU03wqKsBrkfgQ/svf/mnFagvekY3 c6G57rlMB8jdqfsoUKHZGAbD/MlPLhQB9KGfxgw3SsPVvvuwcN97qNxAkhFdSz0= =CR9S -----END PGP SIGNATURE----- --------------enig541C5CB28FD0F4031075D6C1-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 11:55: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 B751D1065679 for ; Tue, 20 Jul 2010 11:55:31 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 36CA08FC0C for ; Tue, 20 Jul 2010 11:55:31 +0000 (UTC) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1ObBQ1-0006ti-M1; Tue, 20 Jul 2010 13:55:29 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx4.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ObBQ1-0005Pm-8j; Tue, 20 Jul 2010 13:55:29 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObBQ0-000AOP-PA; Tue, 20 Jul 2010 13:55:28 +0200 Date: Tue, 20 Jul 2010 13:55:28 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: Marius Strobl Message-ID: <20100720115528.GA88965@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> <20100719170654.GA19889@putsch.kolbu.ws> <20100720101736.GD4706@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100720101736.GD4706@alchemy.franken.de> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 787E571645372D1179EA67C39B36EB5C8270904F X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1766 max/h 11 blacklist 0 greylist 0 ratelimit 0 Cc: freebsd-current@freebsd.org, =?iso-8859-1?Q?St=E5le?= Kristoffersen Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 11:55:31 -0000 On 2010-07-20 at 12:17, Marius Strobl wrote: > On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote: > > On 2010-07-18 at 14:20, Marius Strobl wrote: > > > > > Downgrading now... > > > > > > > > And it crashed again, with current from r209598... > > > > > > > > > > Ok, this at least means that your problem isn't caused by the recent > > > changes to mpt(4) as the pre-r209599 version only differed from the > > > 8-STABLE one in a cosmetic change at that time. > > > > I have another data-point, I cvsup'ed to the latest current again, and > > rebuilt without INVARIANT and WITNESS, and now it seems to survive the > > timeouts. > > That's more or less expected as the sanity check issuing the panic > just isn't compiled in then. However, my understanding was that with > STABLE you don't get the timeouts in the first place, or do you see > them there also? I got the timeouts with STABLE as well, that was the reason for me to try out CURRENT. I'm sorry I didn't mention that earlier. My main concern is to get rid of the timeouts, but a panic on one can't be right. How can I debug this further? I can get timeout fairly consistent by putting a bit of load on the drives. If it would help I can also provide remote access. I'm trying to update the firmware on some of the drives now to see if that helps with the timeouts. -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 12:03: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 A1D6510656AC for ; Tue, 20 Jul 2010 12:03:22 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id E88A78FC12 for ; Tue, 20 Jul 2010 12:03:21 +0000 (UTC) Received: from [95.132.119.44] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObBXY-0005HI-N9; Tue, 20 Jul 2010 15:03:20 +0300 Received: from levsha by laptop.levsha.me with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ObBX3-000OIZ-Ft; Tue, 20 Jul 2010 15:02:45 +0300 Date: Tue, 20 Jul 2010 15:02:45 +0300 From: Mykola Dzham To: "M. Warner Losh" Message-ID: <20100720120245.GA77115@laptop.levsha.me> References: <20100718210154.GA94088@laptop.levsha.me> <20100718.171610.338707487962422543.imp@bsdimp.com> <20100718.224558.590164615694902393.imp@bsdimp.com> <20100719143023.GA31690@laptop.levsha.me> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100719143023.GA31690@laptop.levsha.me> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 95.132.119.44 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false X-Spam-Level: --- X-Spam-Report: 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list Cc: freebsd-current@FreeBSD.ORG, tinderbox-list@marcuscom.com Subject: Re: Can't make distribution TARGET_ARCH=... after r209510 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 12:03:22 -0000 Mykola Dzham wrote: > M. Warner Losh wrote: > > In message: <20100718.171610.338707487962422543.imp@bsdimp.com> > > "M. Warner Losh" writes: > > : In message: <20100718210154.GA94088@laptop.levsha.me> > > : Mykola Dzham writes: > > : : Hi! > > : : Attemt to make jail with different target arch on tinderbox (i386 jail > > : : on amd64 host) exits with error: > > : : > > : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp > > : : > > : : Last lines from log: > > : : > > : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution > > : : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail > > : : install: freebsd.cf: No such file or directory > > : : *** Error code 71 > > : : > > : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. > > : : *** Error code 1 > > : : > > : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. > > : : > > : : Full build and distribution logs avaliable on > > : : http://levsha.me/tmp/20100718/world.txt (20M) > > : : http://levsha.me/tmp/20100718/distribution.txt (7.4K) > > : : > > : : Reverting r209510 fixes this problem > > : > > : It works for me. > > : > > : on an amd64 box: > > : setenv TARGET=i386 > > : make buildworld > > : make installworld DESTDIR=/tmp/mumble > > : make distribution DESTDIR=/tmp/mumble > > > > To which I forgot to add: > > > > Please send me the exact sequence of commands that fails, as well as > > the uname of the host. I'd like to try to track this down... > > Hmm, all work properly with TARGET_ARCH when i build directly: > > export TARGET_ARCH=i386 > make buildworld > make installworld DESTDIR=/tmp/i386 > make distribution DESTDIR=/tmp/i386 > > Problem occurs only if i try to make i386 jail in tinderbox > > $ sudo ./tc tbversion > Tinderbox version 3.3.r1 > > $ svn info /usr/local/tinderbox/jails/9-HEAD.i386/src > Path: /usr/local/tinderbox/jails/9-HEAD.i386/src > URL: file:///usr/local/arch/base/head > Repository Root: file:///usr/local/arch/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 210161 > Node Kind: directory > Schedule: normal > Last Changed Author: imp > Last Changed Rev: 210161 > Last Changed Date: 2010-07-16 09:35:17 +0300 (ÐÔ, 16 ÌÉÐ 2010) > > > I will try to get commands, used by tinderbox to build world and > distribution, and check this commands. > > Thanks! This is tinderbox error: tinderbox run make distribution directly in ${SRCBASE}/etc and set all variables (including MAKEOBJDIRPREFIX) manually. So, after r209510 this method does not work properly. This patch on tinderbox fixes problem: --- scripts/lib/tc_command.sh.orig 2010-07-20 09:32:57.977402441 +0300 +++ scripts/lib/tc_command.sh 2010-07-20 09:35:12.935906873 +0300 @@ -774,10 +774,10 @@ # determine if we're cross-building world crossEnv="" if [ "${jailArch}" != "${myArch}" ]; then - crossEnv="TARGET_ARCH=${jailArch} MACHINE_ARCH=${jailArch} MAKEOBJDIRPREFIX=${J_OBJDIR}/${jailArch} MACHINE=${jailArch}" + crossEnv="TARGET_ARCH=${jailArch}" fi - cd ${SRCBASE}/etc && env DESTDIR=${J_TMPDIR} ${crossEnv} \ - make -m ${J_TMPDIR}/usr/share/mk distribution > ${jailBase}/distribution.tmp 2>&1 + cd ${SRCBASE} && env DESTDIR=${J_TMPDIR} ${crossEnv} \ + make distribution > ${jailBase}/distribution.tmp 2>&1 if [ $? -ne 0 ]; then echo "ERROR: distribution failed - see ${jailBase}/distribution.tmp" buildJailCleanup 1 ${jailName} ${J_SRCDIR} -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 12:16: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 26FCB106564A for ; Tue, 20 Jul 2010 12:16:50 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id 80BAD8FC0C for ; Tue, 20 Jul 2010 12:16:49 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:240a:e87c:3a8e:e791] (unknown [IPv6:2002:51af:3dc3:0:240a:e87c:3a8e:e791]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id D22F823 for ; Tue, 20 Jul 2010 14:16:23 +0200 (CEST) Message-ID: <4C45938B.8000604@stillbilde.net> Date: Tue, 20 Jul 2010 14:16:11 +0200 From: "Svein Skogen (Listmail account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> <20100719170654.GA19889@putsch.kolbu.ws> <20100720101736.GD4706@alchemy.franken.de> <20100720115528.GA88965@putsch.kolbu.ws> In-Reply-To: <20100720115528.GA88965@putsch.kolbu.ws> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C9D8BE22A5CD5A921D0B1B7" Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 12:16:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C9D8BE22A5CD5A921D0B1B7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20.07.2010 13:55, St=E5le Kristoffersen wrote: > On 2010-07-20 at 12:17, Marius Strobl wrote: >> On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote: >>> On 2010-07-18 at 14:20, Marius Strobl wrote: >>>>>> Downgrading now... >>>>> >>>>> And it crashed again, with current from r209598... >>>>> >>>> >>>> Ok, this at least means that your problem isn't caused by the recent= >>>> changes to mpt(4) as the pre-r209599 version only differed from the >>>> 8-STABLE one in a cosmetic change at that time. >>> >>> I have another data-point, I cvsup'ed to the latest current again, an= d >>> rebuilt without INVARIANT and WITNESS, and now it seems to survive th= e >>> timeouts. >> >> That's more or less expected as the sanity check issuing the panic >> just isn't compiled in then. However, my understanding was that with >> STABLE you don't get the timeouts in the first place, or do you see >> them there also? >=20 > I got the timeouts with STABLE as well, that was the reason for me to > try out CURRENT. I'm sorry I didn't mention that earlier. >=20 > My main concern is to get rid of the timeouts, but a panic on one can't= be > right. How can I debug this further? I can get timeout fairly consisten= t by > putting a bit of load on the drives. If it would help I can also provid= e > remote access. >=20 > I'm trying to update the firmware on some of the drives now to see if t= hat > helps with the timeouts. Sorry for the late response here, but what you're describing matches fairly well what I saw with RELENG_8 (just after 8.0 was released), but luckily I didn't have any disks on my MPT, just my tape autoloader. Random timeouts, and then bus resets (that made tape IO unreliable). The bad news, is that I had the exact same trouble with OpenSolaris (134), and something-similar with Linux (can't remember versions), at the time. I never did find a solution, and ended up throwing windows on the box, just to get reliable backups. My MPT is a 3801 LSI1068e based card running the latest bios. //Svein --=20 --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =D8stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ ------------------------------------------------------------ --------------enig1C9D8BE22A5CD5A921D0B1B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxFk48ACgkQODUnwSLUlKSExQCeONKY0PZSJCL+6RKURaZax2JU NeIAoIaFZN91ghfF1QF97Gozbo8kyZaZ =R8hO -----END PGP SIGNATURE----- --------------enig1C9D8BE22A5CD5A921D0B1B7-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 12:34: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 9C18D106566B for ; Tue, 20 Jul 2010 12:34:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 562D68FC17 for ; Tue, 20 Jul 2010 12:34:01 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ObC1E-0004rg-JT for freebsd-current@freebsd.org; Tue, 20 Jul 2010 14:33:56 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Jul 2010 14:33:56 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Jul 2010 14:33:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Tue, 20 Jul 2010 14:34:09 +0200 Lines: 8 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: emt64 performance degradation over amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 12:34:01 -0000 On 07/18/10 21:21, Fabio Kaminski wrote: > (note that i cant be too precise , since i didnt go any further with more > tests... its more a subjective feel (boot time, general use.. etc)) It is probable then that it is only your imagination, and if you are really serious about this you should make some objective measurements on directly comparable hardware. http://wiki.freebsd.org/BenchmarkAdvice From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 13:26: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 400701065741; Tue, 20 Jul 2010 13:26:49 +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 8B6078FC19; Tue, 20 Jul 2010 13:26:48 +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 o6KDQiRd057323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 16:26:44 +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 o6KDQhaI095455; Tue, 20 Jul 2010 16:26:43 +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 o6KDQhfu095454; Tue, 20 Jul 2010 16:26:43 +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, 20 Jul 2010 16:26:43 +0300 From: Kostik Belousov To: Doug Barton Message-ID: <20100720132643.GH2381@deviant.kiev.zoral.com.ua> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4G+GqPlnVGGS3vR6" 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.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: freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 13:26:49 -0000 --4G+GqPlnVGGS3vR6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 19, 2010 at 11:05:26PM -0700, Doug Barton wrote: > On Sun, 18 Jul 2010, Kostik Belousov wrote: >=20 > >When intr time starts accumulating again, try to do > >"procstat -kk " and correlate the clock thread tid > >with the backtrace. Might be, it helps to guess what callouts are eating > >the CPU. >=20 > Ok, I thought I was going to be able to do this easily but I didn't=20 > realize that the numbers in the second column were thread ids, and I=20 > don't know how to "correlate the clock thread tid with the backtrace."=20 > Can you give me a hint? :) It already printed the thread names, so no need. Unfortunately, the clock threads were running instead of blocking etc (I suspected that this would be a case), so procstat cannot get the backtrace. Another option is to do a backtrace from ddb. I cannot get much information from the dtrace snippets you posted in parallel. I can only see that some threads used msleep (?) with timeout a lot, and something at the address 0xc67bbe90 also raised a head. Can you manually lookup nearby symbol for 0xc67bbe90 ? --4G+GqPlnVGGS3vR6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxFpBMACgkQC3+MBN1Mb4ikKQCglCV2at0LTY3C4VrQhwivz6QV dUIAnRH9CJ9/93Mjm4fWqOLjrmDmE2VG =UbIm -----END PGP SIGNATURE----- --4G+GqPlnVGGS3vR6-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 13:29: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 75C431065676; Tue, 20 Jul 2010 13:29:38 +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 E94ED8FC15; Tue, 20 Jul 2010 13:29:37 +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 o6KDTVgg057830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 16:29:31 +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 o6KDTVxB095473; Tue, 20 Jul 2010 16:29:31 +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 o6KDTVUq095472; Tue, 20 Jul 2010 16:29:31 +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, 20 Jul 2010 16:29:31 +0300 From: Kostik Belousov To: David Xu Message-ID: <20100720132931.GI2381@deviant.kiev.zoral.com.ua> References: <4C4510B8.6090105@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pfhjpIY4DSX7ckaW" Content-Disposition: inline In-Reply-To: <4C4510B8.6090105@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.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: firefox is stuck in getbuf() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 13:29:38 -0000 --pfhjpIY4DSX7ckaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 20, 2010 at 10:58:00AM +0800, David Xu wrote: > With newest -HEAD code, firefox is stuck in getbuf(). >=20 > top >=20 > last pid: 1814; load averages: 0.00, 0.05, 0.07=20 >=20 > up 0+00:37:11 10:54:01 > 135 processes: 1 running, 134 sleeping > CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle > Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M Free > Swap: 2020M Total, 2020M Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU=20 > COMMAND > 1427 davidxu 1 45 0 114M 101M select 0 1:24 0.29% Xorg > 1588 davidxu 10 44 0 279M 145M getbuf 0 2:15 0.00%=20 > firefox-bin >=20 >=20 > procstat -k 1588 > PID TID COMM TDNAME KSTACK=20 >=20 > 1588 100200 firefox-bin initial thread mi_switch sleepq_switch=20 > sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata=20 > ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall=20 > Xint0x80_syscall > 1588 100207 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll=20 > syscallenter syscall Xint0x80_syscall > 1588 100208 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > syscallenter syscall Xint0x80_syscall > 1588 100209 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait=20 > _umtx_op syscallenter syscall Xint0x80_syscall > 1588 100210 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait=20 > _umtx_op syscallenter syscall Xint0x80_syscall > 1588 100216 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > syscallenter syscall Xint0x80_syscall > 1588 100220 firefox-bin - mi_switch sleepq_switch=20 > sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata=20 > ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall=20 > Xint0x80_syscall > 1588 100238 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > syscallenter syscall Xint0x80_syscall > 1588 100239 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > syscallenter syscall Xint0x80_syscall > 1588 100240 firefox-bin - mi_switch sleepq_switch=20 > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > syscallenter syscall Xint0x80_syscall Can you, please, do the following: show the backtraces for the system processes, in particular, syncer, bufdaemon, softdepflush daemon, pagedaemon and vm ? for the stuck firefox thread, find the address of the buffer supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? This can be done on the live/stuck system using kgdb on /dev/mem. --pfhjpIY4DSX7ckaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkxFpLoACgkQC3+MBN1Mb4iesgCg2IIFqNXpYotXrIliwt2PsR3h ploAnjATNLv7/VMpMIrn1TWUawStSd8r =Yn0/ -----END PGP SIGNATURE----- --pfhjpIY4DSX7ckaW-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 13:30: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 9A4751065670 for ; Tue, 20 Jul 2010 13:30:42 +0000 (UTC) (envelope-from erob@gthcfoundation.org) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 75D238FC19 for ; Tue, 20 Jul 2010 13:30:42 +0000 (UTC) Content-transfer-encoding: 7BIT Received: from [192.168.0.100] ([74.58.70.113]) by VL-MH-MR003.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L5U00CK5W34VGC0@VL-MH-MR003.ip.videotron.ca> for freebsd-current@freebsd.org; Tue, 20 Jul 2010 08:30:41 -0400 (EDT) Message-id: <4C459941.2050900@gthcfoundation.org> Date: Tue, 20 Jul 2010 08:40:33 -0400 From: Etienne Robillard Organization: Green Tea Hackers Club User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) To: And Clover , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Discussions ouvertes au grand public." , Aaron Watters , web-sig@python.org, Graham.dumpleton@gmail.com Subject: i love freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erob@gthcfoundation.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, 20 Jul 2010 13:30:42 -0000 stupid censored internet. elite control thru "open source" development, or a censure of legit mail messages from a subscribed developer to control the development process ? please investigate if you believe in such thing as freedom of expression. Python.org web-sig admins also blocked my e-mail address.... yet i get replies from And who is subscribed to the list? I really don't understand. only wanted to give my 2 cents. kind regards/cordiales salutations, Etienne p -s : FreeBSD: The power to serve! [1]http://www.freebsd.org/ !!!Evil Spam that You Must Block!!! !!!Support Free and Open Alternatives to Restricted Python Development!!! Open alternatives for web development with Python: 1) notmm toolkit: a general-purpose and non-monolithic web toolkit for Django: [2]http://gthc.org/projects/notmm/ 2) blogengine: a Python blogging API with zero-sql in mind... [3]http://gthc.org/projects/blogengine/ Please donate anything you have if you like thoses apps despite being censored from the net!!! "If we don't believe in freedom of expression for people we despise, we don't believe in it at all." -- Noam Chomsky -- Etienne Robillard Green Tea Hackers Club E-mail: [4]erob@gthcfoundation.org Work phone: 1 (514) 962-7703 Website: [5]https://gthc.org/ During times of universal deceit, telling the truth becomes a revolutionary act . -- George Orwell References 1. http://www.freebsd.org/ 2. http://gthc.org/projects/notmm/ 3. http://gthc.org/projects/blogengine/ 4. mailto:erob@gthcfoundation.org 5. https://gthc.org/ From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 16:49: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 3A9BF1065670 for ; Tue, 20 Jul 2010 16:49:01 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by mx1.freebsd.org (Postfix) with ESMTP id D8D958FC24 for ; Tue, 20 Jul 2010 16:49:00 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 73148A5E2A2; Wed, 21 Jul 2010 00:48:29 +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 FFeOgaWWS4nV; Wed, 21 Jul 2010 00:48:23 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id CD673A584C5; Wed, 21 Jul 2010 00:48:22 +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:subject:references:in-reply-to:x-enigmail-version:openpgp: content-type:content-transfer-encoding; b=GVJw2EBNMIqK0baSnYPQjgR5fWC9PE3tWzoNavijZA/DyBtlPvqtMeEoeFYfrDo6L c6AkY0n0dIEEZCLVSz1HQ== Message-ID: <4C45D351.2040307@delphij.net> Date: Tue, 20 Jul 2010 09:48:17 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017>, <4C44C19C.4080302@delphij.net> <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017> In-Reply-To: <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Problem with ZFS version 15 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, 20 Jul 2010 16:49:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Michael, On 2010/07/20 02:51, Michael Gusek wrote: >> I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: "gpart create -s GPT ad0" ? Do i lost my data ? No it won't touch your data (assuming you were using GPT rather than a whole disk directly in the past) as long as you create/destroy GPT partition tables/scheme on the disk. Only the partition table itself gets changed which won't modify your on-disk data. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRdNRAAoJEATO+BI/yjfBkHEH/2io9HddIfAQ8bP1foNABqsU rI43+CjUeHlCNfXyxpfQC/u8d2UX/dsvpnoWLOTLNLaHcCALIeQ1YQW2D1Pn5zLg 15TLMJLmIkNzrwGZV1qHRuDGI0JqR4cco00A/9VqTNTESJ0Ys/nuOQz3lGDo4Df0 J2smW/q05w/+D3ZZABq4OxCoEImyWiOFvlcwky2f8vuvh5rWDSFZmuH4J0Oivj0g Ok3KOEfFYrEfWiQGDTp+1GTztXsOxo+LZ5zz1o7WsuLSoVIr/M0oTYNXiy28QxeA ovd/jDKqN/YTfbGNMBc/wUYBnVYr9nTlKU7Wo+zPhXrQWCBQzfwxT2/7FNHCEgw= =55Jr -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 17: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 06F37106567F for ; Tue, 20 Jul 2010 17:15:59 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id A05C38FC14 for ; Tue, 20 Jul 2010 17:15:58 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o6KHFuwS075974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jul 2010 12:15:57 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.4) with ESMTP id o6KHFuPs099108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jul 2010 12:15:56 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o6KGk0pV028213; Tue, 20 Jul 2010 11:46:00 -0500 (CDT) (envelope-from dan) Date: Tue, 20 Jul 2010 11:46:00 -0500 From: Dan Nelson To: Doug Barton Message-ID: <20100720164600.GA85770@dan.emsphone.com> References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 8.1-PRERELEASE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.96 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 20 Jul 2010 12:15:57 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Kostik Belousov , freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 17:15:59 -0000 In the last episode (Jul 19), Doug Barton said: > On Sun, 18 Jul 2010, Dan Nelson wrote: > > You can also use dtrace to get a count of callouts and their time spent. > > Run this for a few seconds then hit ^C: > > Okey dokey, here you go: > > http://people.freebsd.org/~dougb/normal-dtrace.txt > http://people.freebsd.org/~dougb/bad-dtrace.txt I don't see any real difference between those two runs, so maybe it's not a callout eating your CPU. How about running this for a few seconds, which will print all the stack traces seen during the sampling period: dtrace -n 'profile:::profile-276hz { @pc[stack()]=count(); }' On an otherwise idle system, you should see most of the counts in cpu_idle, with the remainder clustered in whatever code is eating your CPU. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 17:40: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 B3C8C106566B for ; Tue, 20 Jul 2010 17:40:27 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE908FC0C for ; Tue, 20 Jul 2010 17:40:26 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 625A49CB070 for ; Tue, 20 Jul 2010 19:35:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm9tDQKPJt7B for ; Tue, 20 Jul 2010 19:35:37 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D2D0F9CB250 for ; Tue, 20 Jul 2010 19:35:37 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o6KHZbvo011472 for current@freebsd.org; Tue, 20 Jul 2010 19:35:37 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 20 Jul 2010 19:35:37 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20100720173537.GA10433@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [INFO]: newer clang/LLVM in HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Jul 2010 17:40:27 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, ed@ just committed an update of clang/LLVM to HEAD. This update has (at least) 3 bugs fixed that were reported from FreeBSD. these are: - annoying "unknown pragma" warning during make depend of kernel - DWARF fix that fixes dtrace (contributed by kan@) this requires libelf fix as well - clang (the driver) execing itself (the compiler) fix regardless of PATH Beside this, clang should compile C++ better than the previous snapshot. It should be faster as well. So far a few problems in clang/LLVM and FreeBSD were fixed but many other remains, what to do about it? Test clang with your code! just cd /usr/src/my/code/ && CC=clang make clang can spot problems gcc cannot and it would be nice to have those fixed. it improves the code quality and takes at most a few minutes. if you encounter something that you think is a clang bug/problem/annoyance please let us know so we can get this fixed. thank you for your help! Roman Divacky --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxF3mkACgkQLVEj6D3CBEymVQCfUk/YTg1OmAnU17US6jQUAv8B lCsAn3CW1flw8g0cMM2w1DAN89KFtuog =9izw -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 00:06: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 3CB821065674; Wed, 21 Jul 2010 00:06:27 +0000 (UTC) (envelope-from marcelorossi@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 CBCBF8FC19; Wed, 21 Jul 2010 00:06:26 +0000 (UTC) Received: by vws19 with SMTP id 19so8313460vws.13 for ; Tue, 20 Jul 2010 17:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=UocCRZz7IFmZn/8SPw6FtdQYqK/44GORc0MaSzrJj0w=; b=KLj2SMuPnDMGmULJ/iYQ4Hp6o+2NMIDaB6KvMHym+GszA357OcibkEhtGmfI0e59eL 0ldsBoiCwvggojiuRJBjFIHr59JjRSQIEBc4IS+BOWcQ5vNguhfeK3jdyOrcSdrxsNpl EwCgMGkyqe1BRdW7VHTxE0kbwdpWbZ8iVOuds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=smo6CDueXcVLJEP+vi9ZMAkY8AfhR41/yzy82e0Gy/QUbk2xYPTJr0jDzRz91/nvuX rg0HN6y/FqxsjapiHH4CBT1i7+7KFJ1Q5WDPt3wf23jtasWhHYovq2ZoFmszGabYT2Gk I+weoTueaXbfmTJ9NctHyGG2eiCVyJCJknZVE= Received: by 10.224.54.131 with SMTP id q3mr6042733qag.144.1279670785721; Tue, 20 Jul 2010 17:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.30.143 with HTTP; Tue, 20 Jul 2010 17:06:04 -0700 (PDT) In-Reply-To: References: <20100714183834.GA19684@freebsd.org> From: "Marcelo/Porks" Date: Tue, 20 Jul 2010 21:06:04 -0300 Message-ID: To: Roman Divacky Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 00:06:27 -0000 On Tue, Jul 20, 2010 at 8:25 AM, Marcelo/Porks wrote: > On Wed, Jul 14, 2010 at 3:38 PM, Roman Divacky wrote: >> hi, >> >> ClangBSD was updated to LLVM/clang revision r108243 which we plan to >> merge into HEAD. We would like that revision to be tested as much as possible >> and therefore we ask you to test ClangBSD to assure that the revision >> we are updating to does not have some really embarassing bugs. >> >> How to do it (on i386 and amd64): >> >> 0) install fresh devel/llvm-devel port >> >> 1) svn co http://svn.freebsd.org/base/projects/clangbsd src >> >> 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf >> >> 3) cd src && make buildworld > > Hi. Until here worked fine. I'm on an AMD64-Quadcore (Phenom x4). > > I did 'make buildworld'. Should I use something like 'make -j 8' for testing? > > The 'installworld' and kernel I will test thursday. > Hi again. I did a 'svn up' on http://svn.freebsd.org/base/projects/clangbsd at 2010-07-20 21:30:00 UTC make -j 8 buildworld make installworld DESTDIR=/usr/clang cd sys/amd64/conf config GENERIC export CC=clang cd ../compile/GENERIC make make install KODIR=/boot/clang nextboot -k clang shutdown -r now and... BARAD-DUR% grep clang -A 3 -B 3 /var/log/messages Jul 20 20:52:51 BARAD-DUR su: porks to root on /dev/pts/5 Jul 20 20:52:58 BARAD-DUR shutdown: reboot by porks: Jul 20 20:53:02 BARAD-DUR syslogd: exiting on signal 15 Jul 20 20:54:21 BARAD-DUR syslogd: kernel boot file is /boot/clang/kernel Jul 20 20:54:21 BARAD-DUR kernel: Copyright (c) 1992-2010 The FreeBSD Project. Jul 20 20:54:21 BARAD-DUR kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 20 20:54:21 BARAD-DUR kernel: The Regents of the University of California. All rights reserved. BARAD-DUR% uname -a FreeBSD BARAD-DUR 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r210317: Tue Jul 20 20:40:06 BRT 2010 porks@BARAD-DUR:/usr/src/sys/amd64/compile/GENERIC amd64 (I'm using GMT-3) Everything is running ok : ) -- Marcelo Rossi "This e-mail is provided "AS IS" with no warranties, and confers no rights." "I have nothing against God, I just hate His fan club" From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 04:53: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 9A39C1065673 for ; Wed, 21 Jul 2010 04:53:38 +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 6FD058FC18; Wed, 21 Jul 2010 04:53:38 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6L4rawf098921; Wed, 21 Jul 2010 04:53:37 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C467D50.1040809@freebsd.org> Date: Wed, 21 Jul 2010 12:53:36 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Kostik Belousov References: <4C4510B8.6090105@freebsd.org> <20100720132931.GI2381@deviant.kiev.zoral.com.ua> In-Reply-To: <20100720132931.GI2381@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: firefox is stuck in getbuf() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 04:53:38 -0000 Kostik Belousov wrote: > Can you, please, do the following: > show the backtraces for the system processes, in particular, syncer, > bufdaemon, softdepflush daemon, pagedaemon and vm ? > for the stuck firefox thread, find the address of the buffer > supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? > This can be done on the live/stuck system using kgdb on /dev/mem. Unfortunately, I can not always reproduce it. :-( From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 06:50: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 955B8106566B for ; Wed, 21 Jul 2010 06:50:31 +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 35BD88FC14 for ; Wed, 21 Jul 2010 06:50:31 +0000 (UTC) Received: (qmail 3056 invoked by uid 399); 21 Jul 2010 06:50:30 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Jul 2010 06:50:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Tue, 20 Jul 2010 23:50:28 -0700 (PDT) From: Doug Barton To: Dan Nelson In-Reply-To: <20100720164600.GA85770@dan.emsphone.com> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> <20100720164600.GA85770@dan.emsphone.com> 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: Kostik Belousov , freebsd-current@freebsd.org, Rui Paulo Subject: Re: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 06:50:31 -0000 On Tue, 20 Jul 2010, Dan Nelson wrote: > In the last episode (Jul 19), Doug Barton said: >> On Sun, 18 Jul 2010, Dan Nelson wrote: >>> You can also use dtrace to get a count of callouts and their time spent. >>> Run this for a few seconds then hit ^C: >> >> Okey dokey, here you go: >> >> http://people.freebsd.org/~dougb/normal-dtrace.txt >> http://people.freebsd.org/~dougb/bad-dtrace.txt > > I don't see any real difference between those two runs, so maybe it's not a > callout eating your CPU. How about running this for a few seconds, which > will print all the stack traces seen during the sampling period: > > dtrace -n 'profile:::profile-276hz { @pc[stack()]=count(); }' > > On an otherwise idle system, you should see most of the counts in cpu_idle, > with the remainder clustered in whatever code is eating your CPU. Ok, here's the output from the above: http://people.freebsd.org/~dougb/normal-dtrace-2.txt http://people.freebsd.org/~dougb/bad-dtrace-2.txt FYI, I updated to r210317 because mav's latest commits are clock related, and it seemed to help. The first flash video I tried to watch went all the way through and afterwards intr was around 2% cpu (normally it's in the 0.n% range). However, after killing all the stray npviewer.bin processes, and killing firefox, it went back down. It took watching several videos in a row to get it to the point where intr started running away again. 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 Wed Jul 21 08:07:48 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 4368B106566C; Wed, 21 Jul 2010 08:07:48 +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 4CA848FC19; Wed, 21 Jul 2010 08:07:46 +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 LAA21661; Wed, 21 Jul 2010 11:07: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 1ObULB-000Nd7-2S; Wed, 21 Jul 2010 11:07:45 +0300 Message-ID: <4C46AAD0.5080003@icyb.net.ua> Date: Wed, 21 Jul 2010 11:07:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> <20100720164600.GA85770@dan.emsphone.com> 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: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 08:07:48 -0000 Doug, could you please show your timer configuration, part of devinfo -u that describes interrupts and top of the output of top -SPH (including the header) when high interrupt load strikes? P.S. I saw output of top -SH, but I have a reason to be curious about top -SPH. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 09:27: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 03476106567D for ; Wed, 21 Jul 2010 09:27:41 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51803.mail.re2.yahoo.com (web51803.mail.re2.yahoo.com [206.190.38.234]) by mx1.freebsd.org (Postfix) with SMTP id 9DC4F8FC23 for ; Wed, 21 Jul 2010 09:27:40 +0000 (UTC) Received: (qmail 78930 invoked by uid 60001); 21 Jul 2010 09:27:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1279704460; bh=t2bPSKJVM76DLSF2Ecb5PmytcQnRnzMFS/S5Esiflto=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DtTlE5jiRAi4hzOOcnNvJmm5FuVvAmURbcVkwIbLCDcH3Dxj1uZBhjlBCcYrkQYoGixy2fzUbqA3QvLbGY91OpEWLEl3ZezolOiaxavr4ELlqPKEES60lKmVGJVitaedx+TBa7CB9Dd61VXBCho8Ou/f8eg3Z/WOKsRXwamyyoY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MfHo59sZtt3ZlFGOVSQKk9GlNJlc9ZmuXMvMYILLmkJrmyaCen4j762ugKP30PlAhsXKHbQnanilaJRLMJXN45tF5MKx85owzZIlQA7pcdDQ9PnRxuuJAcPO38o0LXxumMUrJ1mfUfBuiRU0bRS21apgoYyPDYRxAut1QXhm4h8=; Message-ID: <105354.78909.qm@web51803.mail.re2.yahoo.com> X-YMail-OSG: 1f3OuQ4VM1kMGTQLXkioJpvFFG8eroo4G5Vi4cS3DBgBAlr fiCSjNmjZCxi19x7w_Wr5c4iEt0V4lmcXo.imez1woO7Ew4ZvIqheJOwlnTE jfbiLO0qaH7haO6Ebs6zhP5n3kElLYmYnCnJBgpQGTHt5Q9hSBpZ2Bsp_X50 PteL.5.JbABoe57Dxi6SaqB5ZnBbP5suQ7BgiuirvI4FB0qLfPjIBTKD9odu aKS3EogxXbDKWZdUS91uhNKNX_DEfSl7IkwP0INetxLJ4963xEfREMYfVJ9W FpB3pk32brAcDdejD36T2tm1KSKbWOIEuuk6o1ufogDo- Received: from [173.183.132.20] by web51803.mail.re2.yahoo.com via HTTP; Wed, 21 Jul 2010 02:27:40 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 References: <201007141511.46190.hselasky@c2i.net> <201007192117.05034.hselasky@c2i.net> <504334.98385.qm@web51801.mail.re2.yahoo.com> <201007201246.34654.hselasky@c2i.net> Date: Wed, 21 Jul 2010 02:27:40 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky In-Reply-To: <201007201246.34654.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Leffler , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 09:27:41 -0000 ----- Original Message ---- > From: Hans Petter Selasky > To: PseudoCylon > Cc: freebsd-current@freebsd.org; Sam Leffler ; >freebsd-usb@freebsd.org > Sent: Tue, July 20, 2010 4:46:34 AM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > On Tuesday 20 July 2010 12:03:22 PseudoCylon wrote: > > ----- Original Message ---- > > > > > From: Hans Petter Selasky > > > To: freebsd-current@freebsd.org > > > Cc: PseudoCylon ; Sam Leffler ; > > > > > >freebsd-usb@freebsd.org > > > > > > Sent: Mon, July 19, 2010 1:17:04 PM > > > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > > > > > Hi AK, > > > > > > I've committed your patches to USB P4. I've made some additional > > > patches. > > > > > > Can you check and verify everything? > > > > > > http://p4web.freebsd.org/@@181189?ac=10 > > > > Hi > > > > If we change sc->cmdq_run = RUN_CMDQ_ABORT, > > > > -- begin excerpt -- > > > > > > @@ -4890,7 +4877,10 @@ run_stop(void *arg) > > ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); > > > > sc->ratectl_run = RUN_RATECTL_OFF; > > -sc->cmdq_run = RUN_CMDQ_ABORT; > > + > > +RUN_CMDQ_LOCK(sc); > > +sc->cmdq_run = sc->cmdq_key_set = RUN_CMDQ_ABORT; > > +RUN_CMDQ_UNLOCK(sc); > > > > -- end excerpt -- > > > > > > we also need to change this, otherwise key will be cleared. > > Ok. > > Try to give the second mutex a different name, and see how many warnings go > away. > > --HPS > Giving different name makes all of "duplicate lock" warnings away. Here is the patch includes all changes -- begin patch -- diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c index 017e4b0..da22077 100644 --- a/dev/usb/wlan/if_run.c +++ b/dev/usb/wlan/if_run.c @@ -549,7 +549,7 @@ run_attach(device_t self) mtx_init(&sc->sc_mtx, device_get_nameunit(sc->sc_dev), MTX_NETWORK_LOCK, MTX_DEF); mtx_init(&sc->sc_cmdq_mtx, device_get_nameunit(sc->sc_dev), - MTX_NETWORK_LOCK, MTX_DEF); + "command queue", MTX_DEF); iface_index = RT2860_IFACE_INDEX; @@ -4670,8 +4670,6 @@ run_init_locked(struct run_softc *sc) if(ic->ic_nrunning > 1) return; -run_stop(sc); - for (ntries = 0; ntries < 100; ntries++) { if (run_read(sc, RT2860_ASIC_VER_ID, &tmp) != 0) goto fail; -- end patch -- From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 15:35: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 8AF7C1065673 for ; Wed, 21 Jul 2010 15:35:57 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA9B8FC08 for ; Wed, 21 Jul 2010 15:35:56 +0000 (UTC) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw1.york.ac.uk (8.13.6/8.13.6) with ESMTP id o6LFZq4O008520; Wed, 21 Jul 2010 16:35:52 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ObbKq-0004Ck-Hp; Wed, 21 Jul 2010 16:35:52 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.4/8.14.4) with ESMTP id o6LFZq0p033193; Wed, 21 Jul 2010 16:35:52 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.4/8.14.4/Submit) id o6LFZqGe033192; Wed, 21 Jul 2010 16:35:52 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Kostik Belousov In-Reply-To: <20100720132931.GI2381@deviant.kiev.zoral.com.ua> References: <4C4510B8.6090105@freebsd.org> <20100720132931.GI2381@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 16:35:51 +0100 Message-ID: <1279726551.25909.17.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: David Xu , FreeBSD Current Subject: Re: firefox is stuck in getbuf() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 15:35:57 -0000 On Tue, 2010-07-20 at 16:29 +0300, Kostik Belousov wrote: > On Tue, Jul 20, 2010 at 10:58:00AM +0800, David Xu wrote: > > With newest -HEAD code, firefox is stuck in getbuf(). > >=20 > > top > >=20 > > last pid: 1814; load averages: 0.00, 0.05, 0.07=20 > >=20 > > up 0+00:37:11 10:54:01 > > 135 processes: 1 running, 134 sleeping > > CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle > > Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M F= ree > > Swap: 2020M Total, 2020M Free > >=20 > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU=20 > > COMMAND > > 1427 davidxu 1 45 0 114M 101M select 0 1:24 0.29% Xo= rg > > 1588 davidxu 10 44 0 279M 145M getbuf 0 2:15 0.00%=20 > > firefox-bin > >=20 > >=20 > > procstat -k 1588 > > PID TID COMM TDNAME KSTACK=20 > >=20 > > 1588 100200 firefox-bin initial thread mi_switch sleepq_switch=20 > > sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata=20 > > ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall=20 > > Xint0x80_syscall > > 1588 100207 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll=20 > > syscallenter syscall Xint0x80_syscall > > 1588 100208 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > > syscallenter syscall Xint0x80_syscall > > 1588 100209 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait=20 > > _umtx_op syscallenter syscall Xint0x80_syscall > > 1588 100210 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait=20 > > _umtx_op syscallenter syscall Xint0x80_syscall > > 1588 100216 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > > syscallenter syscall Xint0x80_syscall > > 1588 100220 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata=20 > > ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall=20 > > Xint0x80_syscall > > 1588 100238 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > > syscallenter syscall Xint0x80_syscall > > 1588 100239 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > > syscallenter syscall Xint0x80_syscall > > 1588 100240 firefox-bin - mi_switch sleepq_switch=20 > > sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op=20 > > syscallenter syscall Xint0x80_syscall >=20 > Can you, please, do the following: > show the backtraces for the system processes, in particular, syncer, > bufdaemon, softdepflush daemon, pagedaemon and vm ? > for the stuck firefox thread, find the address of the buffer > supplied as an argument to getdirtybuf, and print the *(struct buf *)addr= ? > This can be done on the live/stuck system using kgdb on /dev/mem. I can relatively easily recreate this, see my thread on -current on the 17th July ("Filesystem wedge, SUJ-related?"), which (and the followup emails) contain additional info. I'm currently trying to find the commit responsible for introducing this, and have established that a kernel from the 1st June does not seem to exhibit the same issue. Tonight, I'll revert to a current -current and try to get the info you need. Thanks, Gavin --=20 Gavin Atkinson FreeBSD committer and bugmeister From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 16:03: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 3CE7F1065678; Wed, 21 Jul 2010 16:03:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 5884C8FC14; Wed, 21 Jul 2010 16:03:25 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=uQlts9P3TFIiE3mXDKsOajf6rXzGvPXEyWzE93HpGms= c=1 sm=1 a=HRj3ij7MtkgA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=J8iQn0Jttzh5f6AinwsA:9 a=11xdbiD2EiQeI-ETOWF-ntwWpM8A:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1538330; Wed, 21 Jul 2010 18:03:14 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 21 Jul 2010 18:00:26 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201007141511.46190.hselasky@c2i.net> <201007201246.34654.hselasky@c2i.net> <105354.78909.qm@web51803.mail.re2.yahoo.com> In-Reply-To: <105354.78909.qm@web51803.mail.re2.yahoo.com> 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-1" Content-Transfer-Encoding: 7bit Message-Id: <201007211800.26198.hselasky@c2i.net> Cc: Sam Leffler , PseudoCylon , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 16:03:27 -0000 Hi, Please confirm that this patch is working for you: http://p4web.freebsd.org/@@181261?ac=10 --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 16:33: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 8DAF1106566C for ; Wed, 21 Jul 2010 16:33:14 +0000 (UTC) (envelope-from staale@kristoffersen.ws) Received: from mail-forward.uio.no (mail-forward.uio.no [129.240.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 107A18FC13 for ; Wed, 21 Jul 2010 16:33:13 +0000 (UTC) Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1ObcEK-000154-FV for freebsd-current@freebsd.org; Wed, 21 Jul 2010 18:33:12 +0200 Received: from putsch.kolbu.ws ([158.36.191.193]) by mail-mx1.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ObcEK-0004kZ-1c for freebsd-current@freebsd.org; Wed, 21 Jul 2010 18:33:12 +0200 Received: from chiller by putsch.kolbu.ws with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObcEJ-000KYZ-Pt for freebsd-current@freebsd.org; Wed, 21 Jul 2010 18:33:11 +0200 Date: Wed, 21 Jul 2010 18:33:11 +0200 From: =?iso-8859-1?Q?St=E5le?= Kristoffersen To: freebsd-current@freebsd.org Message-ID: <20100721163311.GA45556@putsch.kolbu.ws> References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> <20100719170654.GA19889@putsch.kolbu.ws> <20100720101736.GD4706@alchemy.franken.de> <20100720115528.GA88965@putsch.kolbu.ws> <4C45938B.8000604@stillbilde.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C45938B.8000604@stillbilde.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 816CEBF6BB699055726C719CC386C998EA5B5418 X-UiO-SPAM-Test: remote_host: 158.36.191.193 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1783 max/h 11 blacklist 0 greylist 0 ratelimit 0 Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 16:33:14 -0000 On 2010-07-20 at 14:16, Svein Skogen (Listmail account) wrote: > Sorry for the late response here, but what you're describing matches > fairly well what I saw with RELENG_8 (just after 8.0 was released), but > luckily I didn't have any disks on my MPT, just my tape autoloader. > > Random timeouts, and then bus resets (that made tape IO unreliable). > > The bad news, is that I had the exact same trouble with OpenSolaris > (134), and something-similar with Linux (can't remember versions), at > the time. > > I never did find a solution, and ended up throwing windows on the box, > just to get reliable backups. > > My MPT is a 3801 LSI1068e based card running the latest bios. Hmm, that does not sound good. Did windows work on the same hardware without problems? I -might- have solved my problem. It has now ran for 24h without timeouts, and with a bit of load on it. I think I might have ran into the seagate + NCQ-problem, even tho seagate's webpage told me my drives was not affected (according to the serial numbers). I did however update the following num drives firmware 6x ST31000340AS SD15 4x ST31500341AS SD17 to firmware SD1B (old SD17) and SD1A (old SD15), and that looks like it has done the trick. I'll report back in a week or so if the problem has not reappeared. -- Ståle Kristoffersen From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 17:17:37 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 EAB8A106564A; Wed, 21 Jul 2010 17:17:37 +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 AA49A8FC14; Wed, 21 Jul 2010 17:17:37 +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 1ObcvI-0002EF-C2; Wed, 21 Jul 2010 18:17:36 +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 1ObcvI-0005cy-7k; Wed, 21 Jul 2010 18:17:36 +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 o6LHHaOb067939; Wed, 21 Jul 2010 18:17:36 +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 o6LHHZ9L067938; Wed, 21 Jul 2010 18:17:35 +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: Wed, 21 Jul 2010 18:17:35 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20100721171735.GA67880@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: HPC on FreeBSD - proposal to EPSRC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 17:17:38 -0000 This post is primarily directed at people in the UK. EPSRC UK (Engineering and Physical Sciences Research Council) issued HPC Software Development Call for 2010/11. From their site: "This call invites proposals for High Performance Computing (HPC) software development to enable science and engineering." For full details see: http://www.epsrc.ac.uk/SiteCollectionDocuments/Calls/2010/HPCSoftwareDevelopmentCall.pdf I indend to draft a proposal for this call. I'm particularly interested in making HPC on FreeBSD ia64 a reality. Briefly, I want to propose development of an optimising MPI/OpenMP C/c++/Fortran compiler for a fbsd/ia64 cluster environment, probably based on llvm/clang. If you are in UK academia and want to participate, or if you are in business and might consider supporting a proposal of this sort (e.g. a letter of support) please get in touch directly. If you have other FreeBSD based ideas suitable for this call - I'd also love to hear. yours anton -- 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 Wed Jul 21 18:41: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 38A6F1065675 for ; Wed, 21 Jul 2010 18:41:26 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with ESMTP id B56688FC12 for ; Wed, 21 Jul 2010 18:41:25 +0000 (UTC) Received: from [IPv6:2002:51af:3dc3:0:e054:76c8:941e:5970] (unknown [IPv6:2002:51af:3dc3:0:e054:76c8:941e:5970]) (Authenticated sender: svein-listmail) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 6A77723 for ; Wed, 21 Jul 2010 20:41:01 +0200 (CEST) Message-ID: <4C473F2F.8000206@stillbilde.net> Date: Wed, 21 Jul 2010 20:40:47 +0200 From: "Svein Skogen (Listmail account)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100715123423.GC52222@putsch.kolbu.ws> <20100715160048.GA61891@alchemy.franken.de> <20100715175225.GA52693@putsch.kolbu.ws> <20100716103125.GA73878@putsch.kolbu.ws> <20100718122022.GW4706@alchemy.franken.de> <20100719170654.GA19889@putsch.kolbu.ws> <20100720101736.GD4706@alchemy.franken.de> <20100720115528.GA88965@putsch.kolbu.ws> <4C45938B.8000604@stillbilde.net> <20100721163311.GA45556@putsch.kolbu.ws> In-Reply-To: <20100721163311.GA45556@putsch.kolbu.ws> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig310F97465502DC5CA5A295AA" Subject: Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next->prev != elm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 18:41:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig310F97465502DC5CA5A295AA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21.07.2010 18:33, St=E5le Kristoffersen wrote: > On 2010-07-20 at 14:16, Svein Skogen (Listmail account) wrote: >> Sorry for the late response here, but what you're describing matches >> fairly well what I saw with RELENG_8 (just after 8.0 was released), bu= t >> luckily I didn't have any disks on my MPT, just my tape autoloader. >> >> Random timeouts, and then bus resets (that made tape IO unreliable). >> >> The bad news, is that I had the exact same trouble with OpenSolaris >> (134), and something-similar with Linux (can't remember versions), at >> the time. >> >> I never did find a solution, and ended up throwing windows on the box,= >> just to get reliable backups. >> >> My MPT is a 3801 LSI1068e based card running the latest bios. >=20 > Hmm, that does not sound good. Did windows work on the same hardware > without problems? Yup. But notice that I do _NOT_ have any disks on my MPT (I have an MFI for that), it's just a mini-sas<-->mini-sas into a HP 1/8G2 LTO3 Autoload= er. > I -might- have solved my problem. It has now ran for 24h without timeou= ts, > and with a bit of load on it. I think I might have ran into the seagate= + > NCQ-problem, even tho seagate's webpage told me my drives was not affec= ted > (according to the serial numbers). I did however update the following > num drives firmware=20 > 6x ST31000340AS SD15 > 4x ST31500341AS SD17 I have 8 of the last type (31500341AS) mine running on CC1H firmware, connected to my MFI. Not a single glitch so far. >=20 > to firmware SD1B (old SD17) and SD1A (old SD15), and that looks like it= has > done the trick. I'll report back in a week or so if the problem has not= > reappeared. Hope it's fixed for you. I'm still keeping an eye on the MPT code to see if someone changes something that CAN be affecting my timeout issues/reset, and if I see something promising, I'm willing to dump out the entire server to tapes, and test run (I have sufficient spare tapes to actually test without losing data), but such a job will take me a week to prepare, and another to test. Quite a bit of time for something that "may" solve my problem... ;) //Svein --=20 --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =D8stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ ------------------------------------------------------------ --------------enig310F97465502DC5CA5A295AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHPzMACgkQODUnwSLUlKRoOQCgtZtLes73SLFze551+Rsc3s3v 1lwAnjXhQE7oCXEatIvI7FHuGSvdJqSI =2dlo -----END PGP SIGNATURE----- --------------enig310F97465502DC5CA5A295AA-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 18:50: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 98E491065771 for ; Wed, 21 Jul 2010 18:50:31 +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 39D118FC08 for ; Wed, 21 Jul 2010 18:50:30 +0000 (UTC) Received: (qmail 9692 invoked by uid 399); 21 Jul 2010 18:50:30 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 21 Jul 2010 18:50:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Wed, 21 Jul 2010 11:50:28 -0700 (PDT) From: Doug Barton To: Andriy Gapon In-Reply-To: <4C46AAD0.5080003@icyb.net.ua> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> <20100720164600.GA85770@dan.emsphone.com> <4C46AAD0.5080003@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: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 18:50:31 -0000 On Wed, 21 Jul 2010, Andriy Gapon wrote: > > > Doug, > > could you please show your timer configuration, Nothing special in /boot/loader.conf, /etc/sysctl.conf, or my kernel. It's basically just GENERIC minus devices I don't have, plus the following: options DDB_CTF options VESA options GEOM_BDE device atapicam device sound device snd_hda Interestingly, I had a runaway intr thing again after watching a flash video, but this time it was hdac0, not swi:4. http://people.freebsd.org/~dougb/bad-dtrace-3-hdac.txt http://people.freebsd.org/~dougb/bad-dtrace-4-hdac.txt > part of devinfo -u that describes interrupts Interrupt request lines: 0 (attimer0) 1 (atkbd0) 3 (root0) 4 (uart0) 5-7 (root0) 8 (atrtc0) 9 (acpi0) 10-11 (root0) 12 (psm0) 12 (psmcpnp0) 13 (root0) 14 (ata0) 15 (ata1) 16 (root0) 17 (wpi0) 18 (cbb0) 19 (root0) 20 (ehci0) 20 (uhci0) 20 (hpet0) 21 (uhci1) 22 (uhci2) 23 (uhci3) 256 (hdac0) > and top of the output of top -SPH (including the header) > when high interrupt load strikes? Will do 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 Wed Jul 21 20:37: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 928EF1065679; Wed, 21 Jul 2010 20:37: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 C9B1F8FC14; Wed, 21 Jul 2010 20:37:30 +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 XAA04715; Wed, 21 Jul 2010 23:37:28 +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 1Obg2i-000OEt-6E; Wed, 21 Jul 2010 23:37:28 +0300 Message-ID: <4C475A87.20100@icyb.net.ua> Date: Wed, 21 Jul 2010 23:37:27 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Doug Barton References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> <20100720164600.GA85770@dan.emsphone.com> <4C46AAD0.5080003@icyb.net.ua> 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: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 20:37:33 -0000 on 21/07/2010 21:50 Doug Barton said the following: > On Wed, 21 Jul 2010, Andriy Gapon wrote: > >> >> >> Doug, >> >> could you please show your timer configuration, > > Nothing special in /boot/loader.conf, /etc/sysctl.conf, or my kernel. > It's basically just GENERIC minus devices I don't have, plus the following: I didn't mean your manual tuning, I meant how the system is configured :-) E.g. the relevant sysctl tree. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 21 20:45: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 2136D1065676 for ; Wed, 21 Jul 2010 20:45:38 +0000 (UTC) (envelope-from r.c.ladan@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 AF18D8FC14 for ; Wed, 21 Jul 2010 20:45:37 +0000 (UTC) Received: by wyj26 with SMTP id 26so23488wyj.13 for ; Wed, 21 Jul 2010 13:45:36 -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=jxre/iVsCdm04FMGplXXssFzCqjKopGBZAVxElU9nl8=; b=BGv0eGTCnCEA6B/LxR5BLFci/O0OtiK9J1XxUqqk7cMH6l/5CNDEnbUztkyVaOdpMF 4j7QEFpIEO5TVdtU1C5g6yReas774I3WF2A/XqcbcbMIACW7nx70dZNW9bU2P8dzn/Wj I4yNXLRTjoWCOulGa2H2guyslZKVa8gdNwOV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mWQ/4APII53vdPxryXcB/2DgTFBW+8tCIpyBDT90ku9WgivGBKcDomSvIeQTaB30Bv d6YNU+rI4ojZ26CTgI47vx9Nnc7TmgGTm/bpbHEXt+/hl6rHZrdCp2PMS0/sumBWIWfg zLAzCkBHNwkBS94ATq4NWg4ekWMd5269jtNrY= MIME-Version: 1.0 Received: by 10.216.231.26 with SMTP id k26mr766422weq.3.1279745136329; Wed, 21 Jul 2010 13:45:36 -0700 (PDT) Received: by 10.216.236.1 with HTTP; Wed, 21 Jul 2010 13:45:36 -0700 (PDT) Date: Wed, 21 Jul 2010 22:45:36 +0200 Message-ID: From: =?ISO-8859-1?Q?Ren=E9_Ladan?= To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 21 Jul 2010 22:11:10 +0000 Cc: Subject: panic with clangbsd kernel in kern/vfs_bio.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Jul 2010 20:45:38 -0000 Hi, on my Acer 7738G laptop running FreeBSD 9.0-amd64 r209980 (with latest clangbsd kernel), I encountered this panic (recovered from /var/log/messages), while doing some moderately light load (portmaster, openoffice, firefox, thunderbird in an xfce4 session): Jul 21 22:29:47 acer kernel: panic: buf 0xffffff80526d00c0 already counted as free Jul 21 22:29:47 acer kernel: cpuid = 1 Jul 21 22:29:47 acer kernel: KDB: enter: panic Jul 21 22:29:47 acer kernel: Jul 21 22:29:47 acer kernel: 0xffffff0005093b40: tag devfs, type VCHR Jul 21 22:29:47 acer kernel: usecount 1, writecount 0, refcount 588 mountedhere 0xffffff0004c84200 Jul 21 22:29:47 acer kernel: flags () Jul 21 22:29:47 acer kernel: v_object 0xffffff00050adbd0 ref 0 pages 12590 Jul 21 22:29:47 acer kernel: lock type devfs: EXCL by thread 0xffffff0004c59880 (pid 17) Jul 21 22:29:47 acer kernel: dev ad4s1f I have the following modules loaded: acer % kldstat Id Refs Address Size Name 1 32 0xffffffff80100000 f925f0 kernel (GENERIC) 2 1 0xffffffff81093000 1bd28 if_iwn.ko 3 1 0xffffffff810af000 296f8 snd_hda.ko 4 2 0xffffffff810d9000 85fe8 sound.ko 5 1 0xffffffff8115f000 570f8 iwn5000fw.ko 6 1 0xffffffff811b7000 dc29d0 nvidia.ko (ports/x11/nvidia-driver, version 256.35 with patches from current@) 7 3 0xffffffff81f7a000 423c8 linux.ko 8 1 0xffffffff81fbd000 d38 biosfont.ko (ports/sysutils/biosfont) 9 1 0xffffffff82012000 3a73 linprocfs.ko acer % grep -nr "already counted as free" ~/freebsd/clangbsd/sys/* | grep -v \.svn kern/vfs_bio.c:401: ("buf %p already counted as free", bp)); acer % ident kern/vfs_bio.c kern/vfs_bio.c: $FreeBSD: projects/clangbsd/sys/kern/vfs_bio.c 209170 2010-06-14 18:45:33Z rdivacky $ acer % ident /sys/kern/vfs_bio.c /sys/kern/vfs_bio.c: $FreeBSD: head/sys/kern/vfs_bio.c 209902 2010-07-11 20:11:44Z alc $ So it might be fixed already. Let me know if you need more information. Unfortunately I didn't get a core dump, although dumpdev="AUTO" in /etc/rc.conf. The laptop rebooted by itself. Regards, Rene From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 05:52: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 C7FD7106566C for ; Thu, 22 Jul 2010 05:52:54 +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 69EC48FC0C for ; Thu, 22 Jul 2010 05:52:54 +0000 (UTC) Received: (qmail 30446 invoked by uid 399); 22 Jul 2010 05:52:52 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Jul 2010 05:52:52 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Wed, 21 Jul 2010 22:52:49 -0700 (PDT) From: Doug Barton To: Andriy Gapon In-Reply-To: <4C475A87.20100@icyb.net.ua> Message-ID: References: <20100717192128.GM2381@deviant.kiev.zoral.com.ua> <20100718103003.GO2381@deviant.kiev.zoral.com.ua> <4C43541C.3060101@FreeBSD.org> <20100718194109.GU2381@deviant.kiev.zoral.com.ua> <4C435CBE.50500@FreeBSD.org> <20100718202338.GI5485@dan.emsphone.com> <20100720164600.GA85770@dan.emsphone.com> <4C46AAD0.5080003@icyb.net.ua> <4C475A87.20100@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: Why is intr taking up so much cpu? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2010 05:52:54 -0000 On Wed, 21 Jul 2010, Andriy Gapon wrote: > I didn't mean your manual tuning, I meant how the system is configured :-) E.g. > the relevant sysctl tree. Duh. :) Sorry. sysctl -a | grep timer kern.eventtimer.choice: LAPIC(500) HPET(450) HPET1(440) HPET2(440) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 83223728 kern.eventtimer.et.LAPIC.quality: 500 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.timer2: HPET kern.eventtimer.timer1: LAPIC kern.eventtimer.singlemul: 2 net.inet.tcp.timer_race: 0 net.inet.tcp.per_cpu_timers: 0 machdep.acpi_timer_freq: 3579545 p1003_1b.timers: 200112 p1003_1b.delaytimer_max: 2147483647 p1003_1b.timer_max: 32 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.ISAB.TMR_ dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.pmtimer.0.%driver: pmtimer dev.pmtimer.0.%parent: isa0 -- 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 Jul 22 09:50: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 33D54106566C for ; Thu, 22 Jul 2010 09:50:32 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51804.mail.re2.yahoo.com (web51804.mail.re2.yahoo.com [206.190.38.235]) by mx1.freebsd.org (Postfix) with SMTP id D3E378FC14 for ; Thu, 22 Jul 2010 09:50:31 +0000 (UTC) Received: (qmail 45973 invoked by uid 60001); 22 Jul 2010 09:50:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1279792231; bh=sFm7QgZfHwWj+APH1hBIZHP946OMk9QtWKQ2w9/tWoM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r7W3y3fYbv6jl3VydnSFoy7ZNG31BiPbJvEAYgzlbpztZ5+iTqZ5V8RMswXDnrNtxUHT598e2Og6mKHfy/xj67TTLgA2ieAQnAQ06kHwH8BISkANmy2tbSR2oj32N/0Zz1U2qg4+jdzyoqwDd2DtEupK9CtdJr05W+duW1q1nnc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=u3kHinCsCr1WJ2qCZW/CNaGarcLhqhroTNSc8/YN/hvYYvdVQROoIuNIykThGLYdRAP2JMcwZ5sZt+5uSmFV7J/QgrjmzudlyLyvIBCEE8BaglIeh/w381Og4pvys+i148puR3PsErJNrtx7LRe9QD/HitPIEacszEoF4GfVv6c=; Message-ID: <84548.45213.qm@web51804.mail.re2.yahoo.com> X-YMail-OSG: ES5c5qUVM1kDGq1GzYTvej2YFTVeOMYlIckCPq_lKtUvu6I MxXNlAUw.Po55_T7op1Lh8pcBMkI_rPwp1.TQrqwSKLf1Z0cHlDFx__aRnlQ 9TjC7ysXZ.bROf4sXdPMOeCNDoNiDRRQuI_JWWIpOuAbx_o2ib4W1xkOcDiU Ab2m9Su0bEHWwi_QexBjtV_3JDYNKT5oDDx6uUAQafatut7zkj73F6NYtR6b ESE_Lde9ptlquVWEX82nSSrcJakCDvTS5QzWAhjCYCvRXn6PvbZkPujE3F_2 2L87dB9ifKE8dKGzZYR12ZbxqgphI4RPsBn.MurmZzGYKRh2EVhR4TGXxKLv voQi5OAIE1dfg Received: from [173.183.132.20] by web51804.mail.re2.yahoo.com via HTTP; Thu, 22 Jul 2010 02:50:30 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.277674 References: <201007141511.46190.hselasky@c2i.net> <201007201246.34654.hselasky@c2i.net> <105354.78909.qm@web51803.mail.re2.yahoo.com> <201007211800.26198.hselasky@c2i.net> Date: Thu, 22 Jul 2010 02:50:30 -0700 (PDT) From: PseudoCylon To: Hans Petter Selasky , freebsd-current@freebsd.org In-Reply-To: <201007211800.26198.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Leffler , freebsd-usb@freebsd.org Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2010 09:50:32 -0000 ---- "FreeBSD and all other open source projects are the Tower of Babel in computer era." --me So, join me @ git://dev.nasreddine.com/run.git (or http://dev.nasreddine.com/gitweb/?p=run.git;a=summary ) Just work on any of *_dev branches. ----- Original Message ---- > From: Hans Petter Selasky > To: freebsd-current@freebsd.org > Cc: PseudoCylon ; Sam Leffler ; >freebsd-usb@freebsd.org > Sent: Wed, July 21, 2010 10:00:26 AM > Subject: Re: [panic] Race in IEEE802.11 layer towards device drivers > > Hi, > > Please confirm that this patch is working for you: > > http://p4web.freebsd.org/@@181261?ac=10 > > --HPS > Confirmed it's properly been updated. AK From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 11:09: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 CC16F1065672 for ; Thu, 22 Jul 2010 11:09:33 +0000 (UTC) (envelope-from niclas.zeising@gmail.com) Received: from mxf1.bahnhof.se (mxf1.bahnhof.se [213.80.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 887738FC17 for ; Thu, 22 Jul 2010 11:09:33 +0000 (UTC) Received: from localhost (mxf1.local [127.0.0.1]) by mxf1-reinject (Postfix) with ESMTP id C61861E31BB for ; Thu, 22 Jul 2010 12:42:31 +0200 (CEST) X-Virus-Scanned: by amavisd-new using ClamAV at bahnhof.se (MXF1) X-Spam-Score: 4.468 X-Spam-Level: **** X-Spam-Status: No, score=4.468 tagged_above=-99 required=5 tests=[DNS_FROM_RFC_POST=1.708, RATWARE_GECKO_BUILD=1.691, SPF_NEUTRAL=1.069] Received: from mxf1.bahnhof.se ([127.0.0.1]) by localhost (mxf1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajbbLqNkdKhk for ; Thu, 22 Jul 2010 12:42:24 +0200 (CEST) Received: from [10.32.0.4] (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) by mxf1.bahnhof.se (Postfix) with ESMTP id 5A6481E31D4 for ; Thu, 22 Jul 2010 12:42:24 +0200 (CEST) Message-ID: <4C482089.7050105@gmail.com> Date: Thu, 22 Jul 2010 12:42:17 +0200 From: Niclas Zeising User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [PATCH] update to NTP in 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, 22 Jul 2010 11:09:33 -0000 Hello! The instructions at http://www.freebsd.org/cgi/query-pr.cgi?pr=148836 (Pr bin/148836) contains an update to the base system NTP program suite. Please test it and report successes and failures. Known issues: The html doc distribution is not installed, but it can be found on the internet if needed. If it is requested by many to include it I'll make a new patch for it. The patch can be found here http://www.lysator.liu.se/~zeising/FreeBSD/ntp-update/ntpupdate.diff (uncompressed, 10M) http://www.lysator.liu.se/~zeising/FreeBSD/ntp-update/ntpupdate.diff.bz2 (compressed with bz2, 1.7M) The reason for the sizes is that the patches include a lot of changes to the vendor code. See the PR for details. Best Regards! //Niclas From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 11:48: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 D3BA61065670 for ; Thu, 22 Jul 2010 11:48:49 +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 8F7778FC15 for ; Thu, 22 Jul 2010 11:48:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 163308067 for ; Thu, 22 Jul 2010 13:48:47 +0200 (CEST) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 6CD408053 for ; Thu, 22 Jul 2010 13:48:44 +0200 (CEST) From: Alban Hertroys Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Date: Thu, 22 Jul 2010 13:48:44 +0200 Message-Id: <33A60F31-52B7-4D53-82A1-316ED5CCB5DC@solfertje.student.utwente.nl> To: FreeBSD Current Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jul 22 13:48:47 2010 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 930,4c48301f286215329633792 X-DSPAM-Factors: 27, but, 0.01000, From*Alban, 0.01000, Mime-Version*Message, 0.01000, of, 0.01000, Received*ESMTP, 0.01000, Content-Transfer-Encoding*8bit, 0.01000, would, 0.01000, would, 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, something, 0.01000, From*Hertroys, 0.01000, From*solfertje.student.utwente.nl>, 0.01000, Received*with, 0.01000, be, 0.01000, Received*id, 0.01000, Received*ESMTP+id, 0.01000, to+the, 0.01000, to+the, 0.01000, I+have, 0.01000, Alban, 0.01000, there, 0.01000, Received*[10.236.150.4]), 0.01000 Cc: Subject: Is 802.11p supported? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2010 11:48:49 -0000 Hello all, On behalf of a friend I have an inquiry whether FreeBSD supports the wireless 802.11p protocol? More specifically, is it supported on Atheros 5k cards? I realise "5k" is a bit generic, I don't have any more details than that (yet) though. He is actually looking for a Linux driver, so I'm not sure knowing that there's a FreeBSD driver (if there is one) would help him at all, but it would be a good opportunity to make him sway to the "light side" ;) Regards, Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4c48301f286215329633792! From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 12:18: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 BB11A1065675 for ; Thu, 22 Jul 2010 12:18:53 +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 941E78FC0C for ; Thu, 22 Jul 2010 12:18:53 +0000 (UTC) Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id C33A934E59C; Thu, 22 Jul 2010 07:18:52 -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 8JQUFKBOJEID; Thu, 22 Jul 2010 07:18:52 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <33A60F31-52B7-4D53-82A1-316ED5CCB5DC@solfertje.student.utwente.nl> Date: Thu, 22 Jul 2010 13:18:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9EA4D889-F7A7-4C08-AE95-457989C74633@FreeBSD.org> References: <33A60F31-52B7-4D53-82A1-316ED5CCB5DC@solfertje.student.utwente.nl> To: Alban Hertroys X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current Subject: Re: Is 802.11p supported? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2010 12:18:53 -0000 On 22 Jul 2010, at 12:48, Alban Hertroys wrote: > Hello all, >=20 > On behalf of a friend I have an inquiry whether FreeBSD supports the = wireless 802.11p protocol? > More specifically, is it supported on Atheros 5k cards? I realise "5k" = is a bit generic, I don't have any more details than that (yet) though. >=20 > He is actually looking for a Linux driver, so I'm not sure knowing = that there's a FreeBSD driver (if there is one) would help him at all, = but it would be a good opportunity to make him sway to the "light side" = ;) We don't support 802.11p (the kernel side).=20 Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 13:15: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 5C19F1065677 for ; Thu, 22 Jul 2010 13:15:11 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id E2A3C8FC1D for ; Thu, 22 Jul 2010 13:15:10 +0000 (UTC) Received: from smtp05.web.de ( [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id 0844215C1A8CC for ; Thu, 22 Jul 2010 15:15:10 +0200 (CEST) Received: from [77.184.98.203] (helo=janice.localnet.de) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #4) id 1ObvcD-0001vO-00 for freebsd-current@freebsd.org; Thu, 22 Jul 2010 15:15:09 +0200 Message-ID: <4C48445D.5070008@web.de> Date: Thu, 22 Jul 2010 15:15:09 +0200 From: Michael Gusek User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de; rv:1.9.1.10) Gecko/20100701 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017>, <4C44C19C.4080302@delphij.net> <1830885268.6104807.1279619519340.JavaMail.fmail@mwmweb017>, <4C457ED5.1010907@yandex.ru> <212927891.6184084.1279625456256.JavaMail.fmail@mwmweb017> In-Reply-To: <212927891.6184084.1279625456256.JavaMail.fmail@mwmweb017> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: michael.gusek@web.de X-Sender: michael.gusek@web.de X-Provags-ID: V01U2FsdGVkX18VtNXO3C1vMQhH0oh5CVcybamT1qOkqkEbypvw ds2YCkhT+LUP5QZDH4vOTSQw4lc3b2nsjWdhdnvW0iAgLjbsIn GIKuD2TSjOSYRYfFvkzg== Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2010 13:15:11 -0000 After reinitialized my gpt scheme, i can successfully import my zpool. After this there was a little bit trouble with my zpool.cache and booting from my pool, but now it works. Thank you to all for your help, Michael Am 20.07.2010 13:30, schrieb Michael Gusek: > -----Urspr?ngliche Nachricht----- > Von: "Andrey V. Elsukov" > Gesendet: 20.07.2010 12:47:49 > An: Michael Gusek > Betreff: Re: Problem with ZFS version 15 > >> On 20.07.2010 13:51, Michael Gusek wrote: >>>>>> and apply a new bootloader: gpart bootcode -b /boot/pmbr -p >>>>>> /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt >>>>>> scheme ! gpart show ad0 says "gpart: No such geom: ad0". How >>>>>> can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror >>>>>> on ad0 and ad1. >> >> It is very strange why this command broke your GPT. >> Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. > > Yes, this is very strange. > >> >>>> I don't have such a backup, only the whole disk for now. Everything >>>> else what can i do ? What if i initialize the gpt header: "gpart >>>> create -s GPT ad0" ? Do i lost my data ? >> >> GPT headers and tables will be initialized. After that you should >> add all partitions with exactly same offsets and sizes. In this case >> your data will not be touched. >> > > Ok, i will try it. I did a backup of the first 16GB of my disk, because i don't know the exact size of my swap partition, but this is my part. > > Thank you, > > Michael > >> -- >> WBR, Andrey V. Elsukov >> > ___________________________________________________________ > GRATIS fÃŒr alle WEB.DE Nutzer: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://movieflat.web.de From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 14:28: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 A26F5106564A; Thu, 22 Jul 2010 14:28:55 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 768308FC27; Thu, 22 Jul 2010 14:28:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6MEStP6035807; Thu, 22 Jul 2010 14:28:55 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6MEStnW035806; Thu, 22 Jul 2010 14:28:55 GMT (envelope-from danger) Date: Thu, 22 Jul 2010 14:28:55 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20100722142855.GA35739@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Status Report April-June, 2010 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@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: Thu, 22 Jul 2010 14:28:55 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between April and June 2010. It is the second of the four reports planned for 2010, and contains 47 entries. During this period, a lot of work has gone into the development of new minor version of FreeBSD, 8.1-RELEASE, which should be released within days. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Please note that the deadline for submissions covering the period between July and September 2010 is October 15th, 2010. __________________________________________________________________ Google Summer of Code * Binary Package Patch Infrastructure -- pkg_patch * Collective Resource Limits (aka. Jobs) * ExtFS Status Report * File System Changes Notification * Google Summer of Code 2010 * Making Ports Work with Clang * Namecache Improvements -- dircache * Package Management Library -- libpkg * Packet-Capturing Stack -- ringmap Projects * Clang Replacing GCC in the Base System * DAHDI/FreeBSD Project * Distributed Audit * General-Purpose DMA Framework * GEOM-Based Pseudo-RAID Implementation -- geom_pseudoraid * GPIO Framework * New System Installer -- pc-sysinstall * OpenAFS Port * Resource Containers * V4L Support in Linux Emulator FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Core Team Election * Release Engineering Team * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * libnetstat(3) Kernel * Interrupt Threads * Jail-Based Virtualization * Kernel Event Timers Infrastructure * ZFS Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Japanese Documentation Project * The FreeBSD Spanish Documentation Project Userland Programs * BSD-Licensed grep in Base System * BSD-Licensed iconv in Base System * FreeBSD Services Control -- fsc Architectures * Flattened Device Tree for Embedded FreeBSD * FreeBSD on the Sony Playstation 3 * FreeBSD/avr32 * FreeBSD/powerpc64 * FreeBSD/sparc64 Ports * Chromium Web Browser * FreeBSD Haskell * Ports Collection Miscellaneous * BSD-Day@2010 * BSDCan * meetBSD 2010 -- The BSD Conference __________________________________________________________________ Binary Package Patch Infrastructure -- pkg_patch URL: http://wiki.FreeBSD.org/IvanVoras/pkg_patch Contact: Ivan Voras The pkg_patch project is about creating a binary package patch infrastructure which would allow users to patch their live system's packages in an easy and efficient way. It is a C program written to interface with libpkg (for things which are common to all pkg utilities) meant to be included in the base system when it is done. It comes with built-in mass patch creation and application commands. It is funded by Google Summer of Code 2010. Open tasks: 1. Finish the project. 2. Get some testing for it. 3. Convince the Port Management Team it is actually a Good Thing to have even as an experimental feature. 4. Agree upon the policy on which package patches will be created (i.e. from which point in time to which point in time), assuming the "stable" package tree idea has still not gotten traction. __________________________________________________________________ BSD-Day@2010 URL: http://wiki.freebsd.org/BSDDay_2010 Contact: Gábor Páli The purpose of this one-day event is to gather Central European developers of today's open-source BSD systems to popularize their work and their organization, and to provide an interface for real-life communication. There are no formalities, no papers, and no registration or participation fee. However the invited developers are encouraged to give a talk on their favorite BSD-related topic or join the live forum, then have a beer with the other folks around. The goal is to motivate potential future developers and users, especially undergraduate university students to work with BSD systems. This year's BSD-Day will be held in Budapest, Hungary at Eötvös Loránd University, Faculty of Informatics on November 20, 2010. Open tasks: 1. Apply as a developer, we are still looking for BSD people in the area. __________________________________________________________________ BSD-Licensed grep in Base System URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 008/gabor_textproc/grep Contact: Gábor Kövesdán A portbuild test showed that grep is basically ready to enter HEAD, but there were a few failures that seem to be related. These have to be investigated and fixed before committing grep to 9-CURRENT. Open tasks: 1. Investigate and fix some minor issues. __________________________________________________________________ BSD-Licensed iconv in Base System URL: http://kovesdan.org/patches/iconv-20100708.diff Contact: Gábor Kövesdán The work has been completed and the GNU compatibility levels seems to be quite high. One exception is the fallback support. It is difficult to implement that facility in this implementation because the design is somewhat different. Probably, it will not be a big problem because that functionality is not even documented in the GNU version so few applications might use it. Open tasks: 1. Run a portbuild test and solve possible problems that show up. __________________________________________________________________ BSDCan URL: http://www.BSDCan.org/2010/ Contact: Dan Langille BSDCan 2010 was our 7th conference. As has become the custom, a FreeBSD developer summit was held in the two days before the conference. Record numbers attended the Dev Summit which carried over into the conference proper. It was great to see representatives from so many more companies. I saw many great ideas take root and the start of cooperation on several projects. The talks during the Dev Summit are beginning to attract a wider audience, and we have been talking about opening this up to the general audience by creating a fourth track at BSDCan 2011. As impossible as it sounds, each year has seen an increase in the quality of talks and the number of proposals submitted. Open tasks: 1. I need people to help with various pre-conference tasks: website updates, booking travel, etc. __________________________________________________________________ Chromium Web Browser URL: http://chromium.hybridsource.org URL: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=146302 Contact: Ruben Chromium is a Webkit-based web browser that is largely BSD-licensed. It works very well on FreeBSD and supports new features like HTML 5 video. This effort uses a new hybrid-source model, where the FreeBSD patches are largely kept closed for a limited time. I submitted Chromium to ports a couple of months ago and recently updated the submission to the stable 5.0.375 branch. The port is ready to be committed pending final legal approval by the FreeBSD Foundation. Further work remains to port Chromium to FreeBSD completely, such as porting the task manager fully and making sure extensions work properly. __________________________________________________________________ Clang Replacing GCC in the Base System URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach In the past quarter we imported Clang into FreeBSD and it is being built by default on i386/amd64/powerpc. We have not yet commited the necessary changes to let world compile with Clang. Some bugs and warnings were fixed in HEAD as a result of the Clang import and people are exploring more and more areas (DTrace, etc). There are some bug fixes in Clang/LLVM as well that stem from the import (unknown pragmas warnings, etc). Roman Divacky and Matthew Fleming are working on ELF writer in LLVM. This is meant as a replacement for assembler (currently we use an outdated GNU as(1)). This work is progressing nice, currently it is able to produce working variants of hello world in C and C++, and some other small programs from "configure run". Open tasks: 1. Import of newer Clang/LLVM into HEAD. 2. Help with ARM/MIPS/SPARC64. 3. Start pushing src patches into HEAD. 4. More testing of Clang on third-party applications (ports). 5. More work on the ELF writer. __________________________________________________________________ Collective Resource Limits (aka. Jobs) URL: http://wiki.FreeBSD.org/G%C3%A1borSoC2010 URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 010/gabor_jobs/irix_jobs Contact: Gábor Kövesdán The SGI IRIX operating system has a concept, called job, which is used to group processes together and then apply resource limits on them. The purpose of this project is to implement this facility on FreeBSD. I spent most of the time familiarizing myself with how things are done inside the kernel, how syscalls work, etc. So far, I have the basic understanding needed and I added the most important syscalls to group processes together into jobs and manipulate collective resource limits on them. There is a bug, which I am tracking down at the moment, after this I can start to implement actual resource limit enforcement. For some of the limit types, it will be relatively easy but some others will take more effort and studies. Open tasks: 1. Fix the showstopper bug, which prevent me working on actual limit enforcement. 2. Implement limit enforcements for all of the limits supported by IRIX. 3. Add support for userland facilities and make utilities jobs-aware, like showing jobs in ps(1), etc. __________________________________________________________________ DAHDI/FreeBSD Project URL: http://www.asterisk.org/dahdi/ URL: https://spreadsheets.google.com/pub?key=0Arw6eRL10yIwdGhLdGJWUHF4b3ExQz Bsd3BGd2tublE&hl=en&single=true&gid=0&output=html Contact: Max Khon The purpose of DAHDI/FreeBSD project is to make it possible to use FreeBSD as a base system for software PBX solutions. DAHDI (Digium/Asterisk Hardware Device Interface) is an open-source device driver framework and a set of hardware drivers for E1/T1, ISDN digital, and FXO/FXS analog cards [1]. Asterisk is one of the most popular open-source software PBX solutions [2]. The project includes porting DAHDI framework and hardware drivers for E1/T1, FXO/FXS analog, and ISDN digital cards to FreeBSD. This also includes TDMoE support, software and HW echo cancellation (Octasic, VPMADT032), and hardware transcoding support (TC400B). The work is ongoing in the official DAHDI SVN repository with the close collaboration with DAHDI folks at Digium. The project is nearing completion. The DAHDI framework and hardware drivers telephony cards have been ported and tested. There are a number of success stories from early adopters who have been using E1/T1 and FXO/FXS cards on FreeBSD for several months. __________________________________________________________________ Distributed Audit URL: http://p4web.freebsd.org/@md=d&cd=//&c=wHa@//depot/projects/soc2010/dis audit/?ac=83 URL: http://wiki.FreeBSD.org/SOC2010SergioLigregni Contact: Sergio Ligregni 90% of the functionality is working, the daemons sync two systems in a master-slave paradigm. Open tasks: 1. Standardize the code to meet FreeBSD requirements. 2. Implement SSL in network communication. 3. Perform security improvements and bug fixing, strlxxx() functions, memcpy() instead of strcpy() when using non-char variables. 4. Integrate with the current Audit subsystem. __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDfoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart SIFTR was recently imported into HEAD and will be backported to 8-STABLE in time to be included in 8.2-RELEASE. TCP reassembly queue autotuning will be ready for public testing within the next week and will be committed soon after. It too will be backported to 8-STABLE after an appropriate burn in period. Open tasks: 1. Try SIFTR out and let me know if you run into any problems. 2. Solicit external testing for and commit the reassembly queue autotuning patch. __________________________________________________________________ ExtFS Status Report URL: http://wiki.FreeBSD.org/SOC2010ZhengLiu Contact: Zheng Liu This project has two goals: pre-allocation algorithm and ext4 read-only mode. The aim of pre-allocation algorithm is to implement a reservation window mechanism. Now this mechanism has been introduced. The performance comparison can be found on the wiki. The aim of ext4 read-only mode is to make it possible to read ext4 file system in read-only mode when the hard disk is formatted with default features. Currently it only supports a few features, such as extents, huge_file. Others features will be added, such as dir_index, uninit_bg, dir_nlink, flex_bg and extra_isize. My work resides in extfs and ext4fs branch of Perforce. __________________________________________________________________ File System Changes Notification Contact: Ilya Putsikau The aim of the project is to implement an inotify-compatible file system change notification mechanism for FreeBSD and later, and add inotify support to linuxulator. The result, fsnotify is already functional but not yet compatible with inotify in some details. Open tasks: 1. Add access permissions checks. 2. Port inotify test cases. 3. Fix compatibility issues. 4. Add linuxulator support. __________________________________________________________________ Flattened Device Tree for Embedded FreeBSD URL: http://wiki.FreeBSD.org/FlattenedDeviceTree Contact: Rafal Jaworowski The purpose of this project was to provide FreeBSD with support for the Flattened Device Tree (FDT) technology. A mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumers of this technology are embedded FreeBSD platforms (ARM, MIPS, PowerPC), where a lot of designs are based on similar chips, but have different assignment of pins, memory layout, addresses ranges, interrupts routing and other resources. Current state highlights: * All code and documentation developed during the course of this project was merged with HEAD, which covers FDT support for the following platforms and systems: * Marvell ARM + DB-88F5182 + DB-88F5281 + DB-88F6281 + DB-78100 + SheevaPlug * Freescale PowerPC + MPC8555CDS + MPC8572DS * The FDT infrastructure (bus drivers, helper libraries, and routines shared across architectures and platforms) allows for easier porting to new platforms or variations. The initially supported systems offer a working example of how to migrate towards FDT approach. Work on this project was sponsored by the FreeBSD Foundation. Open tasks: 1. Improve how-to and guidelines for new adopters (how to convert to FDT and so on). 2. Migrate more existing embedded FreeBSD platforms (ARM, MIPS) to FDT approach. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://wiki.FreeBSD.org/Bugathons URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/easy_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/prs_for_all_groups.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth After a long hiatus, we aim to hold a bugathon on the weekend of the 6th - 9th August. Everybody is welcome to help resolve or progress PRs from the database. We appreciate the help of committers and non-committers alike, please join us on IRC in #freebsd-bugbusters on EFnet if you are free at any time over that weekend and can help. Please see the "Bugathon" URL for more information. Mark Linimon and Gavin Atkinson held a session on the State of Bugbusting at BSDCan, which was well attended and led to some interesting discussions. Time was also found to sit down with several committers to discuss long-standing PRs. The bugbusting team continue work on trying to make the GNATS PR database more accessible and easier for committers to find and resolve PRs. As a result, PRs continue to be classified as they arrive, by adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. Reports are generated from these nightly, grouping related PRs in one place, sorted by tag or man page. Mark Linimon continues work on producing a new report, Summary Chart of PRs with Tags, which sorts tagged PRs into logical groups such as file system, network drivers, libraries, and so forth. The slice labels are clickable and may further subdivide the groups. The chart is updated once a day. You can consider it as a prototype for browsing "subcategories" of kernel PRs. The "recommended list" has been split up into "non-trivial PRs which need committer evaluation" and the "easy list" of trivial PRs, to try to focus some attention on the latter. Various new reports exist, including "PRs containing code for new device drivers", "PRs which are from FreeBSD vendors or OEMs", and "PRs referencing other BSDs". It is now possible for interested parties to be emailed a weekly, customized, report similar in style to the above. If you are interested in setting one up, contact linimon@FreeBSD.org. Our clearance rate of PRs, especially in kern and bin, seems to be improving. The number of non-ports PRs has stayed almost constant since the last status report. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Plan and manage the bugathon in August, and get as many people as possible interested in participating. 2. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Core Team Election Contact: Core Team The 2010 FreeBSD core team election was recently completed. The FreeBSD core team acts as the project's "board of directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, et cetera), and making any other administrative or policy decisions as needed. The core team has been elected by FreeBSD developers every 2 years since 2000, and this marks our 6th democratically elected core team. The new core team would like to thank outgoing members Kris Kennaway, Giorgos Keramidas, George V. Neville-Neil, Murray Stokely, and Peter Wemm for their service over the past two (and in some cases, many more) years. The core team would also especially like to thank Dag-Erling Smřgrav for running the election. The newly elected core team members are: * John Baldwin * Konstantin Belousov * Warner Losh * Pav Lucistnik * Colin Percival The returning core team members are: * Wilko Bulte * Brooks Davis * Hiroki Sato * Robert Watson __________________________________________________________________ FreeBSD Haskell URL: http://wiki.FreeBSD.org/Haskell URL: http://www.FreeBSD.org/ports/haskell.html URL: http://www.haskell.org/mailman/listinfo/freebsd-haskell Contact: Gábor Páli Contact: Giuseppe Pilichi Contact: Ashish Shukla Our efforts on porting the generalized, general-purpose purely functional programming language, Haskell has rallied, since two new committers, Giuseppe Pilichi and Ashish Shukla joined recently, forming the FreeBSD Haskell Team. Over the last months, FreeBSD/i386 and FreeBSD/amd64 have become Tier-1 platforms, featuring officially supported vanilla binary distributions for the Glasgow Haskell Compiler starting from version 6.12.1. We introduced a unified ports infrastructure for Haskell Cabal ports, which also makes possible the direct translation of Cabal package descriptions to FreeBSD ports. The number of Haskell package ports increases steadily. Open tasks: 1. Improve support for Haskell Cabal packages and their translation. 2. Create a port for Haskell Platform. 3. Add more Haskell package ports. 4. Test and send feedback. __________________________________________________________________ FreeBSD on the Sony Playstation 3 URL: http://svn.FreeBSD.org/viewvc/base/user/nwhitehorn/ps3/ Contact: Nathan Whitehorn Work has begun to port FreeBSD/powerpc64 to the IBM Cell-based Sony Playstation 3, using the OtherOS feature present on some models of the console. As of July 14, the FreeBSD boot loader is ported, and it is possible to netboot a kernel, which has support for the framebuffer, MMU, and device discovery. Once work on drivers for the network interface and interrupt controller is complete, it will be possible to boot the console multi-user. __________________________________________________________________ FreeBSD Services Control -- fsc URL: http://people.FreeBSD.org/~trhodes/fsc/ Contact: Tom Rhodes FreeBSD Services Control is a mix of binaries which integrate into the rc.d system and provide for service (daemon) monitoring. It knows about signals, pidfiles, and uses very few resources. The fsc daemon (fscd) runs in the background once the system has started. Services are then added to this daemon via the fscadm control utility, and from there they will be monitored. When they die, depending on the reason, they will be restarted. Certain signals may be ignored (list not decided) and fscd will remove that service from monitoring. Every action is logged to the system logging daemon. Additionally, the fscadm utility may be used to inquire about what services are monitored, their pidfile location, and current process ID. FSC provides several advantages over the third-party daemontools package. For example, fscd uses push notifications instead of polling; fscd is an internal, FreeBSD-maintained software package accessible to all developers, where daemontools would have to be a port and require us to maintain patches; fscd could be easily integrated with the current rc.d infrastructure. Partially based on the ideas of daemontools and Solaris Service Service Mangement Facility (SMF), this could be an extremely useful tool for FreeBSD systems. Open tasks: 1. Testing. Get feedback on how it works in various environments. 2. Code review. 3. Other ideas on the rc.d integration. 4. Update the manual pages. __________________________________________________________________ FreeBSD/avr32 URL: http://wiki.FreeBSD.org/FreeBSD/avr32 Contact: Oleksandr Tymoshenko The FreeBSD/avr32 project was started by Arnar Mar Sing, and actively developed by him and Ulf Lilleengen. It successfully reached single-user stage but since then has not progressed much. At the moment I am trying to get it back into shape. So far some problems with toolchain on i386 host have been fixed, buildkernel succeeds, buildworld succeeds with some exceptions. Next step would be fixing pmap and bringing port back to single-user stage. __________________________________________________________________ FreeBSD/powerpc64 URL: http://people.FreeBSD.org/~nwhitehorn/FreeBSD-9.0-20100715-SNAP-powerpc 64/ Contact: Nathan Whitehorn On July 13, FreeBSD/powerpc64 was integrated into HEAD. This provides support for fully 64-bit operation on 64-bit PowerPC machines conforming to the Book-S specification, including the PowerPC 970, Cell, and POWER4-7. Hardware support is currently limited to Apple machines, although this should expand in the near future. Currently supported hardware: * Apple Xserve G5 * Apple Power Macintosh G5 * Apple iMac G5 __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Since the last status report some issues with cas(4) have been fixed, allowing it to work with Sun GigaSwift Ethernet 1.0 MMF cards (Cassini Kuheen, part no. 501-5524) as well as the on-board interfaces of Sun Fire B100s server blades (for the Sun Fire B1600 platform). Support for Fujitsu (Siemens) PRIMEPOWER 250 based on SPARC64 V CPUs has been added. PRIMEPOWER 450, 650, and 850 likely also work but have not been tested. This also means that the building blocks for support of machines based on SPARC64 VI and VII CPUs like the Fujitsu/Sun SPARC Enterprise Mx000 series are now in place, but they need testing as well. The problems with Schizo version 7 bridges (actually the firmware of these machines) triggering panics during boot finally should be solved. The work on getting Sun Fire V1280 supported has been stalled due to access to such machines no longer being available. The above mentioned improvements are/will be available in FreeBSD 8.1-RELEASE and 7.4-RELEASE. Open tasks: 1. Access to machines based on SPARC64 VI and VII CPUs, like the Fujitsu/Sun SPARC Enterprise Mx000 series would be appreciated. 2. Someone adding support for 64-bit SPARC V9 to Clang/LLVM, and getting it on par with GCC would be appreciated. __________________________________________________________________ General-Purpose DMA Framework URL: http://wiki.FreeBSD.org/SOC2010JakubKlama URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=eCv@//depot/projects/soc2010/jce el_dma/?ac=83 Contact: Jakub Klama This project purpose is adding support for general purpose DMA engines found in most embedded devices. GPDMA framework provides a unified KOBJ interface to DMA engine drivers and unified programming interface to use direct memory transfers in kernel and userspace applications. This project is a part of Google Summer of Code 2010 and it is a work in progress. Current status can be observed on the wiki page. Open tasks: 1. Add support for more DMA engines. 2. Complete, clean up, and merge with HEAD. __________________________________________________________________ GEOM-Based Pseudo-RAID Implementation -- geom_pseudoraid URL: http://acm.poly.edu/~spawk/geom_pseudoraid-20100715.tbz Contact: Boris Kochergin The old ata(4) driver is believed to be going away sometime in the future, to be replaced with ATA_CAM [1]. However, ATA pseudo-RAID support in FreeBSD, ataraid(4), is implemented as part of said ata(4) driver, which means that it, too, will be going away. It was decided that pseudo-RAID support is desirable and that it should be reimplemented in GEOM [2] [ 3], which this project aims to do. Currently, RAID-1 arrays can be used on VIA Tech V-RAID and Adaptec HostRAID controllers in a limited capacity. There is no support for writing metadata yet, so disks are not marked degraded, there is no rebuild support, etc. These features are planned, along with support for more hardware and RAID-0 and SPAN arrays. A major setback for the current code is that it uses the device(9) family of functions to identify ATA pseudo-RAID controllers and constructs arrays based on that information. Unfortunately, ATA_CAM does not appear to add its devices to the device tree, so that tactic cannot be used with ATA_CAM. While this is fine for development of the actual RAID parts of the code, the project will be somewhat useless in the absence of the old ata(4) driver. There has been talk of exporting PCI information to GEOM [4] [5], but the work does not appear to have been completed yet. Open tasks: 1. Obtain documentation for or reverse-engineer metadata formats for which there is no write support in the ataraid(4) driver (for example, Adaptec HostRAID). 2. Add CAM support for exporting PCI information to GEOM. __________________________________________________________________ Google Summer of Code 2010 URL: http://wiki.FreeBSD.org/SummerOfCode2010Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson We are once again participating in the Google Summer of Code. This is our 6th year of participation and we hope to once again see great results from our 18 students. Coding officially began May 24th, and we are in the middle of the mid-term evaluation period. You can see and comment on weekly status reports on the mailing list or on the wiki. __________________________________________________________________ GPIO Framework URL: http://wiki.FreeBSD.org/GPIO Contact: Luiz Otavio O Souza Contact: Oleksandr Tymoshenko Implementation of General Purpose Input/Output interface for FreeBSD. Current GPIO bus implementation allows user to control pins from userland and it could be expanded to support various type of peripheral devices. So far there are two drivers: * gpioled provides simple led(4) functionality. * gpioiic implements I2C over GPIO. Framework is used in Alexandr Rybalko's port of FreeBSD to D-Link DIR-320 and in Luis Otavio O Souza's work of bringing FreeBSD to RouterBoard. __________________________________________________________________ Interrupt Threads Contact: John Baldwin For a while I have wanted to rework interrupt threads to address a few issues. The new design uses per-CPU queues of interrupt handlers. Interrupt threads are allocated by a CPU from a pool and bound to that CPU while draining that CPU's queue of handlers. Non-filter handlers can also reschedule themselves at the back of the current CPU's queue while executing. Filters with handlers are now always enabled and should provide a full replacement for the various uses of filters with "fast" taskqueues. A new class of "manual" handlers are also available which are not automatically scheduled, but are only explicitly scheduled from a filter. Thus, a filter can potentially schedule multiple handlers. The code has been tested on amd64, but it needs wider review and testing. I hope to start soliciting review and feedback soon with the goal of getting the code into 9.0. __________________________________________________________________ Jail-Based Virtualization URL: http://www.FreeBSDFoundation.org/project%20announcements.shtml#Bjoern URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=Z8Q@//depot/user/bz/vimage/src/? ac=83 Contact: Bjoern A. Zeeb The project started with some cleanup on the network stack after all the import work and adjustments for virtualization to minimize changes to earlier branches. These made it into the tree already and to 8-STABLE, and it will be included in the upcoming 8.1 release. The first major task was to generalize the virtualization framework, so that virtualization of further subsystems would be easier and could be achieved with less duplication. In addition some documentation on the virtual network stack programming was written to help developers virtualizing their code. The interactive kernel debugger support was improved and libjail along with jls and netstat can work on core dumps now and query individual jails and attached virtual network stacks. The second major task was network stack teardown, a concept introduced with the network stack virtualization. The primary goal was to prototype a shutdown of the (virtual) network stacks from top to bottom, which means letting interfaces go last rather than first. Work in this area is still in progress and will have to continue to allow long term stability and a leak and panic free shutdown. The work on this project had been sponsored by the FreeBSD Foundation and CK Software GmbH. Special thanks also to John Baldwin and Philip Paeps for helping with review and suggestions. Open tasks: 1. Merge stabilised change sets. 2. Work further down the network stack freeing all resources for a stable, safe teardown. __________________________________________________________________ Kernel Event Timers Infrastructure Contact: Alexander Motin Modern x86 systems include four different types of event timers: i8254, RTC, LAPIC, and HPET. First three are already supported by FreeBSD. Depending on hardware and loader tunables, periodic interrupts from them are used to trigger all time-based events in kernel. That code has a long history, that made it tangled and at the same time limited and hard-coded. New kernel event timers infrastructure was started to allow different event timer hardware to be operated in uniform way and to allow more features to be supported. Work consists of three main parts: writing machine-independent timer driver API and management code, updating existing drivers and improving HPET driver to support event timers. The new driver API provides unified support for both per-CPU (independent for every CPU core) and global timers in periodic and one-shot modes. Management code at this moment uses only periodic mode, while one-shot mode use is planned by later tickless kernel work. Different kinds of timers have different capabilities and could be present in hardware in different combinations. In every situation the infrastructure automatically chooses two best event timers to supply system with hardclock(), statclock(), and profclock() events. If some timer is not functioning -- it will be replaced. If there is no second timer -- it will be emulated. The administrator may affect that choice using loader tunables during boot and sysctl variables in run-time (kern.eventtimer.*, and so on). Most of the code was recently committed to HEAD. Now it is used by i386 and amd64 architectures. Open tasks: 1. Troubleshoot possible hardware and software issues. 2. Port other architectures to the new infrastructure. 3. Implement tickless kernel, utilizing new features, such as per-CPU and one-shot timers. __________________________________________________________________ libnetstat(3) URL: http://wiki.FreeBSD.org/LibNetstat URL: http://people.FreeBSD.org/~pgj/libnetstat/ URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2009/&c=mGl@//dep ot/projects/soc2009/pgj_libstat/?ac=83 Contact: Gábor Páli Contact: Aman Jassal This project is about creating a wrapper library to support monitoring and management of networking with avoiding direct use of the FreeBSD kvm(3) and sysctl(3) interfaces. This approach would allow the kernel implementation to change and monitoring applications to be extended without breaking applications and requiring them to be recompiled. We decided to merge the sources from the last year's Summer of Code project back to the FreeBSD src/ repository piece by piece, and we have defined several phases of integration. * Standardize the in-kernel networking statistics structures. * Build a sysctl(3) interface, and add export routines. * Add a library, libnetstat(3) to work with the exported information, and to provide further functions in order to support extracting information via kvm(3). This library implements abstractions over the gathered data. * Adapt sources of the existing applications, i.e. netstat(1) and bsnmpd(1) to use the abstractions offered by the library, resulting in a cleaner and simpler code. * Add new applications on the top of the library, e.g. nettop(1). The first phase has been already posted for review. Note that we are looking for a sponsor with an src commit bit and enough time to represent the effort towards the Project. Open tasks: 1. Review the sources. 2. Pick a task from the list, and send patches. 3. Comment the patches, help them to improve. __________________________________________________________________ Making Ports Work with Clang URL: http://wiki.FreeBSD.org/SOC2010AndriusMorkunas URL: http://wiki.FreeBSD.org/PortsAndClang URL: http://rainbow-runner.nl/~andrius/soc/ URL: http://rainbow-runner.nl/clang/patches/ Contact: Andrius Morkunas First part of the project is mostly complete. I added support for new PORTS_CC variable which should be used in make.conf instead of CC to change ports compiler. This allows user to change ports compiler easily, while still respecting USE_GCC. Some patches were written to get ports to work with Clang, and a lot of old patches written prior to the Google Summer of Code project were updated. There are still a lot of broken ports, and some that cannot be built because of Clang/LLVM bugs, but at this point, Clang can build most ports. Open tasks: 1. Fix broken ports that do not work with Clang. 2. Test patched ports with Clang, report Clang bugs. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetbsd.org URL: http://picasaweb.google.com/meetbsd/MeetBSD2010Day1# URL: http://picasaweb.google.com/meetbsd/MeetBSD2010Day2# URL: http://picasaweb.google.com/meetbsd/MeetBSD2010SocialEvent# Contact: meetBSD Information meetBSD 2010 took place on July 2 - 3 in Krakow, Poland at the Faculty of Mathematics and Computer Science building of the Jagiellonian University. The gathering was a much successful event which brought together developers, contributors, and users of the BSD systems from around the world. We had many interesting presentations, of various character and appeal for the diversified audience. Attendees had a chance for taking the BSD Certification exam during the conference, as well as the advantage of face to face side conversations and discussions, which continued long during the social event on Friday night! The conference presentation slides are already available for download. Video recordings edition is being finalized, and their publication is expected shortly. We hope you enjoyed the event and had great time in Krakow. See you again soon! __________________________________________________________________ Namecache Improvements -- dircache URL: http://wiki.FreeBSD.org/SOC2010GlebKurtsov Contact: Gleb Kurtsou I have been reimplementing VFS namecache to make it granularly locked and supporting reliable full-path lookup without calling underlying file system routines. I have successfully implemented directory cache that works in idealized environment with tmpfs. I am currently working on adding support for entries without associated vnodes and for "weak" entries and incomplete cached path. __________________________________________________________________ New System Installer -- pc-sysinstall URL: http://lists.FreeBSD.org/pipermail/svn-src-all/2010-June/025660.html URL: http://www.BSDCan.org/2010/schedule/attachments/142_pc-sysinstall-kris- moore-2010.pdf Contact: Kris Moore Contact: M. Warner Losh The new system installation backend, pc-sysinstall, was merged into HEAD recently and work is already underway to make it more functional and useful as a complete replacement to standard "sysinstall". It is written 100% in shell, not requiring any additional tools from what is standard to FreeBSD. The backend already supports a number of exciting features such as: * ZFS (Including support for raidz/mirror/multiple device pool setups). * Disk encryption via GELI(8). * Auto labeling of file systems with glabel(8). * Big disk support using GPT/EFI. * Full Installation Logging, which is saved to disk for post-install inspection. In addition to the features above, pc-sysinstall is unique, in that every install ends up being a scripted install. Front-ends, be it GUI- or text-based, simply generate the appropriate system configuration file, and pc-sysinstall does the grunt work of the actual installation. This is important for a couple of reasons. First, it makes the task of front-end development much easier by not needing to worry about a backend-driven program flow. Second it means that any front-end can be used to generate the installation configuration file, which can then be copied or modified to perform automated installs. While pc-sysinstall is still relatively new, it is already in use as the default backend for PC-BSD 8.0 and 8.1, and has been getting a very good reception and any bugs found are fixed quickly. A text-based front-end is already in the works which will allow installation media to be created without X11 support. __________________________________________________________________ OpenAFS Port URL: http://openafs.org URL: http://web.mit.edu/freebsd/openafs/openafs.shar Contact: Benjamin Kaduk Contact: Derrick Brashear AFS is a distributed network filesystem that originated from the Andrew Project at Carnegie-Mellon University; the OpenAFS client implementation has not been particularly useful on FreeBSD since the 4.X releases. Recent work on the OpenAFS codebase has updated it to be consistent with current versions of FreeBSD, and the client, though still considered experimental, is now relatively stable for light (single-threaded) use on 9-CURRENT. The auxiliary utilities for managing and examining the filesystem are functional, and reading and writing files works sufficiently well to copy /usr/src into and out of AFS. Compiling and running executables in AFS is unsuccessful, though, as mmap() is not always reliable. There are several known outstanding issues that are being worked on, but detailed bug reports are welcome at port-freebsd@openafs.org. Open tasks: 1. Fix the {get,put}pages vnode operations for more reliable mmap() operation. 2. Update VFS locking to allow the use of disk-based client caches as well as memory-based caches. 3. Track down races and deadlocks that appear under load. 4. Integrate with the bsd.kmod.mk kernel-module build infrastructure. __________________________________________________________________ Package Management Library -- libpkg URL: http://wiki.FreeBSD.org/SOC2010DavidForsythe URL: http://code.google.com/p/libpkg Contact: David Forsythe The libpkg library will allow for fairly fine grained control over package management. Presently libpkg has complete read functionality. Info and delete tools that have most of the current package tool features have already been implemented, and once they are completed they can be considered replacements for their counterparts. Once the write and logging aspects of the library are more mature, add and create tools can be created quickly. A new set of more maintainable package tools that leverage libpkg will hopefully be available soon after. __________________________________________________________________ Packet-Capturing Stack -- ringmap URL: http://code.google.com/p/ringmap/ URL: http://ringmap.googlecode.com/files/ringmap_slides.pdf Contact: Alexander Fiveg The ringmap stack is a complete FreeBSD packet-capturing mplementation specialized for very high-speed networks. Similar to the "zero-copy BPF" implementation, the idea of ringmap is to eliminate packet copy operations by using shared memory buffers. However, unlike the "zero-copy BPF" model, ringmap eliminates ALL packet copies during capturing: the network adapter's DMA buffer is mapped directly into user-space. The ringmap stack also adapts libpcap accordingly to provide userspace applications with access to the captured packets without any additional overhead. In the context of Google Summer of Code 2010: * The ringmap software was ported to 9-CURRENT. * Ringmap was redesigned to make it easier to port to other adapters and to integrate it with other network drivers. * Also ringmap was extended to be multi-threaded. Open tasks: 1. Porting ringmap to 10GbE (integrating with ixgbe driver). 2. Porting the entire ringmap code from 9-CURRENT to -STABLE. 3. Evaluation tests. 4. Documentation. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://blogs.FreeBSDish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/group.php?gid=135441496471197 URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team A significant part of quarter two was spent coordinating efforts for inclusion of Xorg 7.5, KDE 4, GNOME 2, plus preparation of ports for the 8.1 release process. Due to the success of enforcing Feature Safe ports commits during 7.3-RELEASE, it was continued for the recent src/ freeze. The port count is approaching 22,000 ports. The open PR count currently floats at about 1200 entries. Since the last report, we added four new committers, and had two old committers rejoin us. The Ports Management Team is very grateful to the FreeBSD Foundation for sponsoring two new head nodes for the ports building cluster, pointyhat. Each of the new head nodes has a larger capacity, both with regard to performance but also in amount of space available for the staging areas, allowing for faster, and thus more, build cycles. Additionally, having two head nodes will allow us to dedicate one of them for building production-ready binary packages, adding predicability for our users to when what types of packages are available for installation, and dedicate the other for regression testing of large port updates, ports infrastructure improvements, the cluster scheduling code, and FreeBSD itself. Over the last few weeks, Mark Linimon has been working hard to get the first of the two new nodes online and has already completed its first package build. This has involved a substantial rework of our custom codebase. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * ale: Update of math/gmp. * delphij: Changes to Mk/bsd.ldap.mk. * gahr: Inclusion of USE_GL=glew. * pgollucci: Changes to Mk/bsd.*apache.mk plus updates to devel/apr and www/apache*. * Testing of x11/xorg, x11/gnome2, x11/kde4, and lang/mono * A test run make fetch run. * A test run for devel/gettext. * mm: Inclusion of USE_XZ. * ale: Request to switch default mysql from 5.0-EOL to 5.1-GA. alepulver's Licensing Framework Summer of Code project has made it into the tree and the Port Management Team is currently assessing the fallout and it will come up with guidelines and documentation in due time. Open tasks: 1. Looking for help fixing ports broken on 9-CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing, and closing. __________________________________________________________________ Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team has been working on the FreeBSD 8.1-RELEASE. At the time of this writing the final builds have been completed and uploaded to the master FTP site. The release announcement should be made within the next couple of days. __________________________________________________________________ Resource Containers Contact: Edward Tomasz Napieral/a As of now, FreeBSD only offers very rudimentary resource controls -- resource limits for many resources (e.g. SysV IPC) are missing, and there is no way to set resource limits for jails. As a result, users who want to run many different workloads on a single physical machine often have to replace jails with several FreeBSD instances running in virtual machines. The goal of this project is to implement resource containers and a simple per-jail resource limits mechanism. Resource containers are also a prerequisite for other resource management mechanisms, such as Hierarchical Resource Limits, for "Collective Limits on Set of Processes (aka. Jobs)" Google Summer of Code 2010 project, for implementing mechanism similar to Linux cgroups, and might be also used to e.g. provide precise resource usage accounting for administrative or billing purposes. This project is being sponsored by The FreeBSD Foundation. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We were proud to be a sponsor for BSDCan in May. We also committed to sponsoring MeetBSD 2010 Poland and California. We provided 12 travel grants for BSDCan. The Foundation and Core Team held a summit on BSD-licensed toolchains at BSDCan 2010. We officially kicked off five new projects that we are funding. They are BSNMP Improvements by Shteryana Shopova, Userland DTrace by Rui Paulo, FreeBSD jail-based virtualization by Bjoern Zeeb, DAHDI FreeBSD driver port by Max Khon, and Resource Containers project by Edward Tomasz Napieral/a. We continued our work on infrastructure projects to beef up hardware for package building, network testing, etc. This includes purchasing equipment as well as managing equipment donations. We are half way through the year and we have raised around $48,000 towards our goal of $350,000. Find out how to make a donation at http://www.FreeBSDFoundation.org/donate/. Our semi-annual newsletter will be published soon. Check out our website to find out more! __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de URL: http://www.FreeBSD.de/mailinglists.html Contact: Johann Kois Contact: Benedict Reuschling A number of updates to the documentation were made since the last status report. We are especially grateful for the contributions from external people who sent the translations. People like Fabian Ruch, who updated the porters-handbook to the latest version (which had been on his to-do list for quite some time), and Benjamin Lukas, who did a great job with the from-scratch translation of the MAC chapter of the German handbook. We thank them both for their contributions and hope they will continue their efforts to enhance the German documentation. Frank Börner was released from Benedicts mentorship and is now a full committer to the German Documentation Project. We are always looking for fresh blood that is willing to be mentored by us as a first step in becoming committers for the documentation project themselves. Johann is keeping up the German website with the latest version. But we could use more translators for sections that are not fully translated yet. Open tasks: 1. Read the translations and report bugs that you have found (even small ones). 2. Translate new parts of the documentation and the website. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli Thanks to Katalin Konkoly, the first few chapters of the FreeBSD Handbook translation have been reviewed, therefore many typos and mistranslations were spotted and fixed. Apart from this, we are still keeping the existing documentation and web page translations up to date, currently without plans on further work. If you are interested in helping us, or you have any comments, or requests regarding the translations, do not hesitate to contact the project via the email addresses mentioned in the entry. Open tasks: 1. Review translations and send feedback. 2. Translate release notes. 3. Add more article translations. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki This project focuses on updating the www/ja and doc/ja_JP.eucJP/ trees. Since last year www/ja tree has been mostly synchronized with the English counterpart and doc/ja_JP.eucJP has also been updated steadily. We are now working on FreeBSD Handbook and Porter's Handbook. Open tasks: 1. More Japanese translation of FreeBSD Handbook and contents of www.FreeBSD.org. 2. Pre-/post-commit review of the translation. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/doc/es/articles/fdp-es/ Contact: Gábor Kövesdán Contact: Vicente Carrasco Vayá We need manpower. Existing documentation set has not been updated for quite some time because of lack of volunteers. Current members are busy with other projects and real life at the moment and we have not received anything from outside contributors. It is a shame because there are lots of users in Spain and Latin-America, as well. Besides, the world's first Free Software Street has been recently inaugurated in Spain. This obviously means that there is interest in free software but unfortunately, this translation project is not going very well nowadays. Open tasks: 1. Review and update existing translations. __________________________________________________________________ V4L Support in Linux Emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd Some bug fixes were applied, and the code was also tested and made to work with the cuse4bsd webcam driver, which supports a great many camera chipsets. The code is still only in 9-CURRENT. We were going to MFC it to 8.x but ran into the code freeze for 8.1, so missed that. However, the code does work on 8-STABLE. We will try to get it MFC'd for 8.2. __________________________________________________________________ ZFS URL: http://wiki.FreeBSD.org/ZFS URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/ zfs Contact: Pawel Jakub Dawidek Contact: Martin Matuska Contact: Xin Li The ZFS file system has been updated to version 15 on HEAD and it will be MFC'ed to 8-STABLE around September 13th, 2010. Work is in progress on porting the recent ZFS version 26 with deduplication functionality. Open tasks: 1. Fix bugs, unresolved issues and to-dos in Perforce. __________________________________________________________________ (c) 1995-2010 The FreeBSD Project. All rights reserved. From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 18:40:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A45591065674; Thu, 22 Jul 2010 18:40:12 +0000 (UTC) Date: Thu, 22 Jul 2010 18:40:12 +0000 From: Alexander Best To: "Sam Fourman Jr." Message-ID: <20100722184012.GA74306@freebsd.org> References: <242312022.4636340.1279374040721.JavaMail.fmail@mwmweb017> <4C44C19C.4080302@delphij.net> <4C44D0BA.5080705@delphij.net> <20100720003742.GA95384@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Xin Li , Michael Gusek Subject: Re: Problem with ZFS version 15 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Jul 2010 18:40:12 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 19, 2010 at 08:31:11PM -0500, Sam Fourman Jr. wrote: > On Mon, Jul 19, 2010 at 7:37 PM, Alexander Best wrote: > > how about adding a periodic script to /etc/periodic/daily to backup the information? > > > > the idea was raised a long time ago already, but was abandoned [1]. > > > > cheers. > > alex > > > > I think that is a good idea, if you have a script to do that I would test it ok here's a dirty dirty patch. what i did was take the etc/periodic/daily/210.backup-aliases script and do some hacking. this is the work of 2 minutes or so. that's why the script is pretty crappy and probably plain wrong in a few cases. however somebody else who has more time might be able to improve it. :) changes to etc/defaults/periodic.conf and etc/periodic/daily/Makefile (or where you want the script to go) need to be hacked in by hand. cheers. alex > > > -- > > Sam Fourman Jr. > Fourman Networks > http://www.fourmannetworks.com --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="backup.gpart.diff" --- /dev/null 2010-07-22 20:33:01.000000000 +0200 +++ etc/periodic/daily/220.backup-geom 2010-07-22 20:09:13.000000000 +0200 @@ -0,0 +1,49 @@ +#!/bin/sh +# +# $FreeBSD:$ +# + +# If there is a global system configuration file, suck it in. +# +if [ -r /etc/defaults/periodic.conf ] +then + . /etc/defaults/periodic.conf + source_periodic_confs +fi + +case "$daily_backup_gpart_enable" in + [Yy][Ee][Ss]) + temp=/tmp/gpart_temp.bak + gpart show > $temp + if [ ! -s $temp ] + then + echo "nothing to backup" + rm $temp || rc=2 + else + bak=/var/backups + rc=0 + + echo "" + echo "Backing up geom partition information:" + + if [ ! -f $bak/gpart.bak ] + then + echo "no $bak/gpart.bak" + mv $temp $bak/gpart.bak || rc=3 + + elif ! cmp -s $bak/gpart.bak $temp + then + [ $rc -lt 1 ] && rc=1 + echo "geom partition layout has been altered:" + diff -u $bak/gpart.bak $temp + mv $bak/gpart.bak $bak/gpart.bak2 + mv $temp $bak/gpart.bak || rc=3 + else + echo "geom partition layout hasn't been altered. skipping backup." + fi + fi;; + + *) rc=0;; +esac + +exit $rc --liOOAslEiF7prFVr-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 23 12:08: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 8F231106566B; Fri, 23 Jul 2010 12:08:46 +0000 (UTC) (envelope-from naylor.b.david@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 2877E8FC14; Fri, 23 Jul 2010 12:08:44 +0000 (UTC) Received: by wyj26 with SMTP id 26so138533wyj.13 for ; Fri, 23 Jul 2010 05:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=UUe55PAa6oyWW2viyml2YOzjbxO1hdTfwCpVX3ZFo6I=; b=GfwsiE6cJvQsKHEo8usxSQq+Im54xTuv88UoMarBTC3tGuZrQ+rFEYMuzRSQ0Ogz/b G8TJmSixJSd+GsiSxPWhdXdyc36W2f+Y0+uB+eckghiUNCudYxb3FOEc+5xjDTSoSrFV VGoYXR4P6305MXTolpCCr8RVx4r+62DT4w5Gs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=gzMuPM2MaTzUsb/UgVKS1tst59eroC/s7oWZ9RJkgwN5cdRBjqpTG1ZkMJsAv64Yy3 5r3YbbzZOksxDCvZr1x/7zhwktmjFc6hrxNKRXxA6eMJF/ruwPK8l10HoXd+hluPBoq0 Kl+obpUUFbtX/ruslIqKWP3L1jeLrMGTAyJAE= Received: by 10.227.156.21 with SMTP id u21mr3398336wbw.56.1279886923847; Fri, 23 Jul 2010 05:08:43 -0700 (PDT) Received: from dragon.dg (41-132-92-33.dsl.mweb.co.za [41.132.92.33]) by mx.google.com with ESMTPS id e31sm146229wbe.17.2010.07.23.05.08.34 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 05:08:41 -0700 (PDT) From: David Naylor Organization: Private To: Christian Zander Date: Fri, 23 Jul 2010 14:08:36 +0200 User-Agent: KMail/1.13.3 (FreeBSD/9.0-CURRENT; KDE/4.4.3; amd64; ; ) References: <201007021146.46542.naylor.b.david@gmail.com> <201007171624.58434.naylor.b.david@gmail.com> <20100717152527.GA26038@panther.nvidia.com> In-Reply-To: <20100717152527.GA26038@panther.nvidia.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3933015.Mqv6Xxsr9p"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201007231408.39453.naylor.b.david@gmail.com> Cc: Christian Zander , "danfe@freebsd.org" , Doug Barton , Yuri Pankov , "freebsd-current@freebsd.org" , Rene Ladan Subject: Re: nvidia-driver crashing kernel on head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2010 12:08:46 -0000 --nextPart3933015.Mqv6Xxsr9p Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday 17 July 2010 17:25:27 Christian Zander wrote: > On Sat, Jul 17, 2010 at 07:24:54AM -0700, David Naylor wrote: > (...) >=20 > > > >>> These freezes and panics are due to the driver using a spin mutex > > > >>> instead of a > > > >>> regular mutex for the per-file descriptor event_mtx. If you patch > > > >>> the driver > > > >>> to change it to be a regular mutex I think that should fix the > > > >>> problems. > > > >>=20 > > > >> Can you give an example? :) I don't mind creating a patch for all = of > > > >> them if you can illustrate what needs to be changed. > > > >=20 > > > > See the attached patch > > >=20 > > > In order to use 195.36.15 it was necessary to use the patch Rene sent, > > > the suggestion from jhb previously to remove some locks, plus a bit > > > more. The patch that got it working on HEAD for me (specifically > > > r209633) is attached. With that patch I could start X, and run it for= a > > > while, but performance was very poor, even in comparison with the sto= ck > > > nv driver, and it crashed a couple times (although not nearly as bad = as > > > previously). > > >=20 > > > So based on other suggestions I tried the newest release version at > > > nvidia, 256.35. Some of the same locking stuff was needed to patch it, > > > a patch for the port which includes the locking patch is also > > > attached. If you are running an amd64 system you'll have to type 'make > > > makesum' after applying this patch to the port. I'm not sure this > > > patch is complete, or what Alexey might want to do with the update, > > > but it does create an accurate plist which means you can cleanly > > > deinstall/pkg_delete when you're done. > > >=20 > > > With 256.35 performance and stability have both been quite good, > > > comparable even to before the the drama started. The only concern I > > > have at this point is that I'm periodically getting a strange sort of > > > "flash" popping up on my screen that I didn't get while I was running > > > the nv driver recently. It looks sort of like the default X background > > > (the tiny gray crosshatch) is popping through for just a split second. > >=20 > > I've been getting these messages on the console: > >=20 > > NVRM: Xid (0001:00): 16, Head 00000000 Count 000218d5 > > NVRM: Xid (0001:00): 8, Channel 00000000 > > NVRM: Xid (0001:00): 16, Head 00000000 Count 000218d6 > > NVRM: Xid (0001:00): 8, Channel 00000002 > >=20 > > This is preceded by X locking hard. I cannot VT switch to a normal > > console and sometimes the computer needs a hard reset (i.e. does not > > respond to power button). It appears to only trigger when under heavy > > load. eg > > make -C /usr/src -j8 buildworld > >=20 > > This seems to be messing with interrupts with other subsystems as my > > network drivers are less than reliable of late. (Watchdog timeouts). >=20 > The messages indicate that the NVIDIA driver hasn't received > interrupts from the GPU @ PCI:1:00.0 over a significant > period of time. If you are seeing similar problems with other > system components, there's a good chance that the above is > a symptom of some larger problem. I think you are right. I'm not sure if this is a hardware problem or FreeB= SD. =20 I reverted to a kernel from May 01 and the system is solid (~5 days). I'm= =20 using the patched 256.35 driver without problem. =20 > > This happens with 195.36.15 unpatched and 256.35 patched. > >=20 > > I have not checked if booting with WITNESS enabled works. > >=20 > > Regards > >=20 > > * David Naylor > > * 0xFF6916B2 --nextPart3933015.Mqv6Xxsr9p Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkxJhkcACgkQUaaFgP9pFrIzyQCdE3KRNNbEW98TTm/XQOA6GF9u ff4An2FLYBBb5Bltf99fspfVW1GuJ93a =lvRd -----END PGP SIGNATURE----- --nextPart3933015.Mqv6Xxsr9p-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 23 18:35: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 AFE76106566B for ; Fri, 23 Jul 2010 18:35:43 +0000 (UTC) (envelope-from roberto@keltia.net) Received: from keltia.net (unknown [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 67A168FC12 for ; Fri, 23 Jul 2010 18:35:43 +0000 (UTC) Received: from [IPv6:2a01:240:fe5c::226:4aff:fef1:1dd7] (unknown [IPv6:2a01:240:fe5c:0:226:4aff:fef1:1dd7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 55BF49458; Fri, 23 Jul 2010 20:35:42 +0200 (CEST) References: <4C482089.7050105@gmail.com> In-Reply-To: <4C482089.7050105@gmail.com> Mime-Version: 1.0 (iPhone Mail 8A306) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <049F560F-6469-4BFC-9E3F-166B908D3425@keltia.net> X-Mailer: iPhone Mail (8A306) From: Ollivier Robert Date: Fri, 23 Jul 2010 20:35:44 +0200 To: Niclas Zeising X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Fri, 23 Jul 2010 20:35:42 +0200 (CEST) X-Mailman-Approved-At: Fri, 23 Jul 2010 18:58:20 +0000 Cc: "current@freebsd.org" Subject: Re: [PATCH] update to NTP in 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, 23 Jul 2010 18:35:43 -0000 Thanks to Niclas for taking this, I will look at it in the next few days. Le 22 juil. 2010 =C3=A0 12:42, Niclas Zeising a =C3= =A9crit : > Hello! > The instructions at > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148836 > (Pr bin/148836) contains an update to the base system NTP program suite. P= lease test it and report successes and failures. > Known issues: The html doc distribution is not installed, but it can be fo= und on the internet if needed. If it is requested by many to include it I'll= make a new patch for it. From owner-freebsd-current@FreeBSD.ORG Fri Jul 23 22:22:34 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 E9846106564A for ; Fri, 23 Jul 2010 22:22:34 +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 7C6088FC1A for ; Fri, 23 Jul 2010 22:22:34 +0000 (UTC) Received: (qmail 20967 invoked by uid 399); 23 Jul 2010 22:22:33 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Jul 2010 22:22:33 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 23 Jul 2010 15:22:32 -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: Subject: Can't compile today's kernel: sys/cam/cam.c + CTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2010 22:22:35 -0000 I'm getting this with r210435. World built fine: cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/local/src/sys/i386/i386/locore.s cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/local/src/sys/cam/cam.c *** Signal 11 Removing makeoptions WITH_CTF=yes does the trick. -- 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 Jul 23 22:28:17 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 4716E106566C; Fri, 23 Jul 2010 22:28:17 +0000 (UTC) (envelope-from nparhar@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 D681D8FC14; Fri, 23 Jul 2010 22:28:16 +0000 (UTC) Received: by qyk32 with SMTP id 32so607054qyk.13 for ; Fri, 23 Jul 2010 15:28:16 -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=2RLqxjCvi5nvWBGD3LdQ2kSfb7Ab7JIZNfikr6jl30k=; b=o4hDUDGYQvO65BnJ5ned4u4lk9GJEn3b872fKN0mggw/CxBwZRPuVhmhYK938XIJMD MHSMG9n2mo75nc9RMmJ5C0JLubZ5OtEk+YxEX5z1Eb/YySVfhf1etWFek2Mz4kgh0Oyo KHjM1kYy9mlwJfuFSqY/ypxyvD5SXBTerI/R8= 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=QoiirQFmJjEs+q1J6O0LgIRuQfYNsZph1GR7xoT+rvM45ZL9aAoH3FjbLcAfu1h/Rd Moge1YTbbSD/xLfkVnClyzcJeki1hLy6kzyBQbpJ3+00MghV1yLcRG0jeeJ7YOBAkaF2 //WhiFdKmImfpZ28MC2n2t6vivgv/K/HAVQPY= MIME-Version: 1.0 Received: by 10.224.79.104 with SMTP id o40mr3170265qak.41.1279924095955; Fri, 23 Jul 2010 15:28:15 -0700 (PDT) Received: by 10.229.41.204 with HTTP; Fri, 23 Jul 2010 15:28:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 15:28:15 -0700 Message-ID: From: Navdeep Parhar To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Can't compile today's kernel: sys/cam/cam.c + CTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2010 22:28:17 -0000 On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: > I'm getting this with r210435. World built fine: > > cc -c -x assembler-with-cpp -DLOCORE -O -pipe =A0-std=3Dc99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototyp= es > -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc =A0-I. -I/usr/local/src/sys > -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=3D8000 --param > inline-unit-growth=3D100 --param large-function-growth=3D1000 > =A0-mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3= dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/local/src/sys/i386/i386/locore.s > cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I= . > -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=3D8000 --param inline-unit-growth=3D100 --param > large-function-growth=3D1000 =A0-mno-align-long-strings > -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/local/src/sys/cam/cam.c > *** Signal 11 > > Removing makeoptions =A0 =A0 WITH_CTF=3Dyes does the trick. I ran into this earlier today. ctfconvert would dump core during buildkern= el. Please try r210438 Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Fri Jul 23 22:40: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 B7ABC106566B for ; Fri, 23 Jul 2010 22:40:06 +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 587538FC16 for ; Fri, 23 Jul 2010 22:40:05 +0000 (UTC) Received: (qmail 14468 invoked by uid 399); 23 Jul 2010 22:40:05 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Jul 2010 22:40:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 23 Jul 2010 15:40:03 -0700 (PDT) From: Doug Barton To: Navdeep Parhar In-Reply-To: Message-ID: References: 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: MULTIPART/MIXED; BOUNDARY="0-971481798-1279924805=:1713" Cc: freebsd-current@freebsd.org, Kai Wang Subject: Re: Can't compile today's kernel: sys/cam/cam.c + CTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2010 22:40:06 -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. --0-971481798-1279924805=:1713 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 23 Jul 2010, Navdeep Parhar wrote: > On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: >> I'm getting this with r210435. World built fine: >> >> cc -c -x assembler-with-cpp -DLOCORE -O -pipe  -std=c99 -g -Wall >> -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign >> -fformat-extensions -nostdinc  -I. -I/usr/local/src/sys >> -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >> -include opt_global.h -fno-common -finline-limit=8000 --param >> inline-unit-growth=100 --param large-function-growth=1000 >>  -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow >> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror >> /usr/local/src/sys/i386/i386/locore.s >> cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs >> -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline >> -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. >> -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL >> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000  -mno-align-long-strings >> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno-sse3 -ffreestanding -fstack-protector -Werror >> /usr/local/src/sys/cam/cam.c >> *** Signal 11 >> >> Removing makeoptions     WITH_CTF=yes does the trick. > > I ran into this earlier today. ctfconvert would dump core during buildkernel. > Please try r210438 I updated to that revision, tried just rebuilding ctfconvert, didn't work. Then I tried installing the new ctfconvert, still doesn't work. Do I need to go farther up the tree? Thanks for the response, 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 --0-971481798-1279924805=:1713-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 23 22:44: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 25CC61065672; Fri, 23 Jul 2010 22:44:44 +0000 (UTC) (envelope-from nparhar@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 9AB508FC14; Fri, 23 Jul 2010 22:44:43 +0000 (UTC) Received: by qwk3 with SMTP id 3so580869qwk.13 for ; Fri, 23 Jul 2010 15:44: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 :content-transfer-encoding; bh=JrjSnwTUmBMeZViM6s9sxO77uyzvYUVUG+KbuYQ+Fik=; b=g4MBeowz45NuoQ81Y7tmOtovCwAu5iAFSkoWJ/f4iJtvsuwlUG5MaLNXaN0JsmZksq +7pcYYvBT3RKcRzfiCy4ICr25GK4gGoXSXmvIFFR8D4MWRpgPqKGR7GplavPMR5D4YuS 6LxoU+AgTGqJORCdnjGcgcCgsjot/QG87ZaS4= 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=q372Nbp0PtS0leK6fpJ9Jt2ODpp9MaK08lGIrWqNd/SD/mPjw70nxbp9wZDIbgsWMm Z3pAxEeFgCohtw55UF2cGY0XUazfof/9i8WC2HomqnuulJuRq6mtkdbmDnxANzdN5W89 b613c4Zo17e7+tWx5m+F8F+BHWtJqLlydUot4= MIME-Version: 1.0 Received: by 10.224.2.85 with SMTP id 21mr3170749qai.74.1279925082783; Fri, 23 Jul 2010 15:44:42 -0700 (PDT) Received: by 10.229.41.204 with HTTP; Fri, 23 Jul 2010 15:44:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 15:44:42 -0700 Message-ID: From: Navdeep Parhar To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Kai Wang Subject: Re: Can't compile today's kernel: sys/cam/cam.c + CTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Jul 2010 22:44:44 -0000 On Fri, Jul 23, 2010 at 3:40 PM, Doug Barton wrote: > On Fri, 23 Jul 2010, Navdeep Parhar wrote: > >> On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: >>> >>> I'm getting this with r210435. World built fine: >>> >>> cc -c -x assembler-with-cpp -DLOCORE -O -pipe =A0-std=3Dc99 -g -Wall >>> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes >>> -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign >>> -fformat-extensions -nostdinc =A0-I. -I/usr/local/src/sys >>> -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S >>> -include opt_global.h -fno-common -finline-limit=3D8000 --param >>> inline-unit-growth=3D100 --param large-function-growth=3D1000 >>> =A0-mno-align-long-strings -mpreferred-stack-boundary=3D2 -mno-mmx -mno= -3dnow >>> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/local/src/sys/i386/i386/locore.s >>> cc -c -O -pipe =A0-std=3Dc99 -g -Wall -Wredundant-decls -Wnested-extern= s >>> -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline >>> -Wcast-qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc = -I. >>> -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >>> -finline-limit=3D8000 --param inline-unit-growth=3D100 --param >>> large-function-growth=3D1000 =A0-mno-align-long-strings >>> -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>> -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/local/src/sys/cam/cam.c >>> *** Signal 11 >>> >>> Removing makeoptions =A0 =A0 WITH_CTF=3Dyes does the trick. >> >> I ran into this earlier today. =A0ctfconvert would dump core during >> buildkernel. >> Please try r210438 > > I updated to that revision, tried just rebuilding ctfconvert, didn't work= . > Then I tried installing the new ctfconvert, still doesn't work. Do I need= to > go farther up the tree? Hmm. I think a "make toolchain" in /usr/src before you build your kernel should fix it. You probably have an old ctfconvert sitting around. Regards, Navdeep From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 01:55: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 04E58106566C; Sat, 24 Jul 2010 01:55:33 +0000 (UTC) (envelope-from swell.k@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 5FAFB8FC16; Sat, 24 Jul 2010 01:55:31 +0000 (UTC) Received: by fxm13 with SMTP id 13so5819428fxm.13 for ; Fri, 23 Jul 2010 18:55:31 -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:date :message-id:user-agent:mime-version:content-type; bh=JD8BaV5xnFU0SSf0qJ4Uvv/LQ0D2gNT+a17JtVpXw5k=; b=Tp/XDOpp8EdkxNqXCH8xvjh8pyK3KlluL8KmQT/cxbuVvGotu6FUEqFsPx6mNFBenZ uFiCZbKnHDLzueGHOgPrZjkHXUTSeggt0q2F7BrrMpNXXbkD/PIWuRriqGT+13qELk7t vIxm1R/sk5rN3m7Jk6GjmuBaZqQB22rrwgKUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:user-agent:mime-version :content-type; b=n9wA25y6VV+7emIiWPffvQLopD1+MMuV9dhyMcbwWzlw+nOXwaTSeTlIQZH7dj5w/s nDWp41Dmr7Zy4IRf+Ky9LWQ6YnEEaosjHxhWi+EU44lTIKs7ZvtG+Bf2dlkfnTzx98EU N5QhU/mdzBB723oG+dV8ycOyZ212AvpvL5fHg= Received: by 10.223.103.80 with SMTP id j16mr3887399fao.100.1279936531106; Fri, 23 Jul 2010 18:55:31 -0700 (PDT) Received: from localhost ([61.32.46.3]) by mx.google.com with ESMTPS id m3sm313040fai.41.2010.07.23.18.55.24 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jul 2010 18:55:30 -0700 (PDT) From: Anonymous To: freebsd-current@freebsd.org Date: Sat, 24 Jul 2010 05:50:25 +0400 Message-ID: <86iq45d4wu.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: Gabor Kovesdan Subject: [bsdgrep] outputs color sequences even when stdout is not tty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 01:55:33 -0000 I've got a breakage in bin/csh $ make depend grep '[FV]_' /usr/src/bin/csh/../../contrib/tcsh/ed.defns.c | grep '^#define' >> ed.defns.h grep 'ERR_' /usr/src/bin/csh/../../contrib/tcsh/sh.err.c | grep '^#define' >> sh.err.h cc -E -O2 -pipe -march=native -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DNO_NLS_CATALOGS -ggdb -std=gnu99 -fstack-protector -Wno-pointer-sign /usr/src/bin/csh/../../contrib/tcsh/tc.const.c /usr/src/bin/csh/../../contrib/tcsh/sh.char.h /usr/src/bin/csh/config.h /usr/src/bin/csh/../../contrib/tcsh/config_f.h /usr/src/bin/csh/../../contrib/tcsh/sh.types.h sh.err.h -D_h_tc_const | grep 'Char STR' | sed -e 's/Char \([a-zA-Z0-9_]*\)\(.*\)/extern Char \1[];/' | sort >> tc.const.h cc -o gethost -O2 -pipe -march=native -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh -D_PATH_TCSHELL='"/bin/csh"' -DNO_NLS_CATALOGS -ggdb -std=gnu99 -fstack-protector -Wno-pointer-sign /usr/src/bin/csh/../../contrib/tcsh/gethost.c In file included from /usr/src/bin/csh/../../contrib/tcsh/sh.h:488:0, from /usr/src/bin/csh/../../contrib/tcsh/gethost.c:33: ./sh.err.h:4:1: error: stray '\33' in program ./sh.err.h:4:2: error: expected identifier or '(' before '[' token ./sh.err.h:4:5: error: invalid suffix "m" on integer constant ./sh.err.h:4:5: error: expected identifier or '(' before numeric constant ... $ vis $(make -V .OBJDIR)/sh.err.h | head /* Do not edit this file, make creates it. */ #ifndef _h_sh_err #define _h_sh_err \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KFLAGS 0xf0000000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KNAME 0x10000000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KSILENT 0x20000000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KOLD 0x40000000 \^[[1;33m\^[[K#define\^[[m\^[[K \^[[1;33m\^[[KERR_\^[[m\^[[KSYNTAX 0 $ printenv | fgrep -i grep GREP_COLOR=1;33 GREP_OPTIONS=--color --exclude \*.svn\* I think it should behave like ls(1) and gnu grep(1) and strip color sequences if stdout is not associated with terminal. From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 03:19: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 12853106564A for ; Sat, 24 Jul 2010 03:19:40 +0000 (UTC) (envelope-from cheeky.m@live.com) Received: from bay0-omc2-s11.bay0.hotmail.com (bay0-omc2-s11.bay0.hotmail.com [65.54.190.86]) by mx1.freebsd.org (Postfix) with ESMTP id F2AF88FC14 for ; Sat, 24 Jul 2010 03:19:39 +0000 (UTC) Received: from BAY147-W50 ([65.54.190.125]) by bay0-omc2-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 20:19:39 -0700 Message-ID: X-Originating-IP: [68.186.243.52] From: Roger Hammerstein To: Date: Fri, 23 Jul 2010 23:19:39 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jul 2010 03:19:39.0434 (UTC) FILETIME=[0CFF90A0:01CB2ADF] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [CFT] ZFS v15 patch (version 3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 03:19:40 -0000 Forwarding to the list. I put the patch on a Sun blade 100 with 256 megs of ram and no issues so far. (sparc64 architecture) sunburn# uname -a FreeBSD sunburn 8.1-PRERELEASE FreeBSD=20 8.1-PRERELEASE #6: Tue Jul 6 20:59:09 UTC 2010 =20 root@sunburn:/usr/obj/usr/src/sys/GENERIC sparc64 sunburn# This machine only has 256 megs of memory=2C but i made two 100 megabyte memory disks=2C=20 mirrored them=2C wrote some stuff=2C offlined each one=20 individually=2C and it all worked okay. sunburn# zpool status =20 pool: tank state: ONLINE scrub: scrub completed after 0h0m with 0 errors on Wed Jul 7 19:26:25 2010 config: =20 NAME STATE READ WRITE CKSUM tank =20 ONLINE 0 0 0 mirror ONLINE 0 =20 0 0 md101 ONLINE 0 0 0 =20 md102 ONLINE 0 0 0 errors: No known data errors sunburn# sunburn# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 37.8M 25.7M 37.6M /tank Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979=2C 1980=2C 1983=2C=20 1986=2C 1988=2C 1989=2C 1991=2C 1992=2C 1993=2C 1994 The Regents of the=20 University of California. All rights reserved. FreeBSD is a=20 registered trademark of The FreeBSD Foundation. FreeBSD=20 8.1-PRERELEASE #6: Tue Jul 6 20:59:09 UTC 2010 =20 root@sunburn:/usr/obj/usr/src/sys/GENERIC sparc64 real memory =3D=20 268435456 (256 MB) avail memory =3D 243982336 (232 MB) cpu0: Sun=20 Microsystems UltraSparc-IIe Processor (502.00 MHz CPU) ispfw:=20 registered firmware ispfw: registered firmware=20 ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware=20 ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware=20 ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware=20 ispfw: registered firmware ispfw: registered firmware ispfw: registered=20 firmware ispfw: registered firmware=20 kbd0 at kbdmux0 nexus0: pcib0: mem=20 0x1fe00000000-0x1fe0000ffff=2C0x1fe01000000-0x1fe010000ff irq=20 2032=2C2030=2C2031=2C2021 on nexus0 pcib0: Hummingbird compatible=2C impl 0=2C=20 version 0=2C IGN 0x1f=2C bus A=2C 33MHz pcib0: DVMA map: 0xc0000000 to=20 0xc3ffffff 8192 entries pcib0: [FILTER] pcib0: [FILTER] pcib0:=20 [GIANT-LOCKED] pcib0: [ITHREAD] pcib0: [FILTER] pci0: on pcib0 ebus0: mem=20 0xf0000000-0xf0ffffff=2C0xf1000000-0xf17fffff at device 12.0 on pci0 ebus0: : incomplete ebus0: addr 0-0xfffff=20 (no driver attached) eeprom0: addr=20 0x100000000-0x100001fff on ebus0 eeprom0: model mk48t59 isab0:=20 at device 7.0 on pci0 isa0: on isab0 gem0: mem 0x400000-0x41ffff at device 12.1 on pci0 miibus0: on gem0 ukphy0:=20 PHY 1 on miibus0 ukphy0:=20 10baseT=2C 10baseT-FDX=2C 100baseTX=2C 100baseTX-FDX=2C auto gem0: 2kB RX=20 FIFO=2C 2kB TX FIFO gem0: Ethernet address: xx:xx:xx:xx:xx gem0:=20 [ITHREAD] fwohci0: mem=20 0x420000-0x4207ff=2C0x422000-0x4227ff at device 12.2 on pci0 fwohci0:=20 [ITHREAD] fwohci0: OHCI version 1.0 (ROM=3D0) fwohci0: No. of=20 Isochronous channels is 4. fwohci0: EUI64 00:03:ba:ff:fe:0c:de:34 fwohci0: Phy 1394a available S400=2C 2 ports. fwohci0: Link S400=2C max_rec 2048=20 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr=20 0xc1128000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:03:ba:0c:de:34 fwe0: Ethernet address:=20 02:03:ba:0c:de:34 fwip0: on firewire0 fwip0: Firewire address: 00:03:ba:ff:fe:0c:de:34 @ 0xfffe00000000=2C S400=2C=20 maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000=2C SelfID=20 Count=3D1=2C CYCLEMASTER mode ohci0: =20 mem 0x2000000-0x2007fff at device 12.3 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 pci0: at device 3.0 (no driver attached) pci0:=20 at device 8.0 (no driver attached) atapci0: port=20 0xa00-0xa07=2C0xa18-0xa1b=2C0xa10-0xa17=2C0xa08-0xa0b=2C0xa20-0xa2f at devi= ce=20 13.0 on pci0 atapci0: [ITHREAD] atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug=2C expect reduced=20 performance ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] machfb0: port 0xb00-0xbff mem 0x3000000-0x3ffffff=2C0x426000-0x426fff=20 at device 19.0 on pci0 machfb0: 8 MB aperture at 0xce376000 swapped machfb0: 8188 KB SDRAM 114.765 MHz=2C maximum RAMDAC clock 230 MHz=2C DSP machfb0: resolution 1152x900 at 8 bpp pcib1: at=20 device 5.0 on pci0 pci1: on pcib1 syscons0:=20 on nexus0 syscons0: Unknown <16 virtual=20 consoles=2C flags=3D0x100> uart0: <16550 or compatible> at port=20 0x3f8-0x3ff irq 43 on isa0 uart0: [FILTER] uart0: console=20 (9600=2Cn=2C8=2C1) uart1: <16550 or compatible> at port 0x2e8-0x2ef=20 irq 43 on isa0 uart1: [FILTER] Timecounter "tick" frequency=20 502000000 Hz quality 1000 Timecounters tick every 1.000 msec firewire0: 1 nodes=2C maxhop <=3D 0 cable IRM irm(0) (me) firewire0: bus=20 manager 0 usbus0: 12Mbps Full Speed USB v1.0 ad0: 8223MB=20 at ata2-master UDMA66 ugen0.1:=20 at usbus0 uhub0: on usbus0 acd0: CDROM at=20 ata2-slave PIO4 GEOM: ad0: adding VTOC8 information. uhub0: 4=20 ports with 4 removable=2C self powered Trying to mount root from=20 ufs:/dev/ad0a ZFS NOTICE: Prefetch is disabled by default if less=20 than 4GB of RAM is present=3B to enable=2C add=20 "vfs.zfs.prefetch_disable=3D0" to /boot/loader.conf. ZFS WARNING:=20 Recommended minimum RAM size is 512MB=3B expect unstable behavior. ZFS=20 WARNING: Recommended minimum kmem_size is 512MB=3B expect unstable=20 behavior. Consider tuning vm.kmem_size and=20 vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 4 ZFS storage pool version 15 =20 Hotmail is redefining busy with tools for the New Busy. Get more from your = inbox. See how. =20 _________________________________________________________________ Hotmail has tools for the New Busy. Search=2C chat and e-mail from your inb= ox. http://www.windowslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL:O= N:WL:en-US:WM_HMP:042010_1= From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 03:38: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 4FE901065673 for ; Sat, 24 Jul 2010 03:38:14 +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 CFFD18FC15 for ; Sat, 24 Jul 2010 03:38:13 +0000 (UTC) Received: (qmail 31135 invoked by uid 399); 24 Jul 2010 03:38:12 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jul 2010 03:38:12 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 23 Jul 2010 20:38:08 -0700 (PDT) From: Doug Barton To: Navdeep Parhar In-Reply-To: Message-ID: References: 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, Kai Wang Subject: Re: Can't compile today's kernel: sys/cam/cam.c + CTF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 03:38:14 -0000 On Fri, 23 Jul 2010, Navdeep Parhar wrote: > Hmm. I think a "make toolchain" in /usr/src before you build your > kernel should fix it. You probably have an old ctfconvert sitting > around. Building with a clean obj directory did the trick. Thanks again! 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 Jul 24 04:19: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 94E131065673 for ; Sat, 24 Jul 2010 04:19: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 3585B8FC1B for ; Sat, 24 Jul 2010 04:19:27 +0000 (UTC) Received: (qmail 17011 invoked by uid 399); 24 Jul 2010 04:19:27 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jul 2010 04:19:27 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 23 Jul 2010 21:19:24 -0700 (PDT) From: Doug Barton To: Gabor Kovesdan 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: freebsd-current@FreeBSD.org Subject: [bsdgrep] grep -ql does not supress output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 04:19:28 -0000 There are several places in portmaster where I use '[e]grep -ql ' to signal existence of something without having to deal with the output of grep. In oldgrep this worked as advertised. In bsdgrep it doesn't. Furthermore, looking at the code it doesn't seem like it's a trivial fix since you seem to be conflating the idea of -q with "don't output the matching lines" instead of "don't output anything" which is what the old one did: case 'l': Lflag = false; lflag = qflag = true; break; Also, looking at the code it's not clear to me that the -q option has its previous behavior of halting processing for that file on the first match, but I've only given it a quick look. So, request number 1, fix it so that bsdgrep -ql doesn't output anything, and make sure that -q actually halts processing on the first match. Request number 2, think about whether or not introducing this as the default was the right course of action. I held my tongue on this when you committed it, but in the past when such things have been added they start life as an option, allowing those who choose to do so to regression test them. Once they've had a shakeout period THEN the switch is flipped to make them the default. I'm not at the point yet where I'm ready to ask for you to change this, but between the color thing and this issue, that ball has started to roll, in my mind at least. We'll see what happens with more testing. 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 Jul 24 04:41: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 79C7D1065678; Sat, 24 Jul 2010 04:41:50 +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 1B4C78FC0A; Sat, 24 Jul 2010 04:41:49 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 224CE14DC2A0; Sat, 24 Jul 2010 06:41:48 +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 qpqqJmJvJolQ; Sat, 24 Jul 2010 06:41:45 +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 ED45F14DC294; Sat, 24 Jul 2010 06:41:44 +0200 (CEST) Message-ID: <4C4A6F00.9000203@FreeBSD.org> Date: Sat, 24 Jul 2010 06:41:36 +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: Doug Barton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [bsdgrep] grep -ql does not supress output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 04:41:50 -0000 Em 2010.07.24. 6:19, Doug Barton escreveu: > There are several places in portmaster where I use '[e]grep -ql ' > to signal existence of something without having to deal with the > output of grep. In oldgrep this worked as advertised. In bsdgrep it > doesn't. > > Furthermore, looking at the code it doesn't seem like it's a trivial > fix since you seem to be conflating the idea of -q with "don't output > the matching lines" instead of "don't output anything" which is what > the old one did: > > case 'l': > Lflag = false; > lflag = qflag = true; > break; > > Also, looking at the code it's not clear to me that the -q option has > its previous behavior of halting processing for that file on the first > match, but I've only given it a quick look. > > So, request number 1, fix it so that bsdgrep -ql doesn't output > anything, and make sure that -q actually halts processing on the first > match. Of course both this and the color issue will be fixed. > > Request number 2, think about whether or not introducing this as the > default was the right course of action. I held my tongue on this when > you committed it, but in the past when such things have been added > they start life as an option, allowing those who choose to do so to > regression test them. Once they've had a shakeout period THEN the > switch is flipped to make them the default. I'm not at the point yet > where I'm ready to ask for you to change this, but between the color > thing and this issue, that ball has started to roll, in my mind at > least. We'll see what happens with more testing. This change was thoroughly tested on pointyhat and by several interested people even by you. Actually, the compatibility for non-standard GNU regexes were added when you requested it after trying out with portmaster. Why didn't you tell me earlier about this bug then, as well? Gabor From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 04:50: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 A20FD1065675 for ; Sat, 24 Jul 2010 04:50: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 447608FC14 for ; Sat, 24 Jul 2010 04:50:48 +0000 (UTC) Received: (qmail 21804 invoked by uid 399); 24 Jul 2010 04:50:48 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jul 2010 04:50:48 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 23 Jul 2010 21:50:45 -0700 (PDT) From: Doug Barton To: Gabor Kovesdan In-Reply-To: <4C4A6F00.9000203@FreeBSD.org> Message-ID: References: <4C4A6F00.9000203@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: MULTIPART/MIXED; boundary="0-1335630748-1279946638=:1697" Content-ID: Cc: freebsd-current@FreeBSD.org Subject: Re: [bsdgrep] grep -ql does not supress output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 04:50:49 -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. --0-1335630748-1279946638=:1697 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-ID: On Sat, 24 Jul 2010, Gabor Kovesdan wrote: > Em 2010.07.24. 6:19, Doug Barton escreveu: >> There are several places in portmaster where I use '[e]grep -ql ' to >> signal existence of something without having to deal with the output of >> grep. In oldgrep this worked as advertised. In bsdgrep it doesn't. >> >> Furthermore, looking at the code it doesn't seem like it's a trivial fix >> since you seem to be conflating the idea of -q with "don't output the >> matching lines" instead of "don't output anything" which is what the old >> one did: >> >> case 'l': >> Lflag = false; >> lflag = qflag = true; >> break; >> >> Also, looking at the code it's not clear to me that the -q option has its >> previous behavior of halting processing for that file on the first match, >> but I've only given it a quick look. >> >> So, request number 1, fix it so that bsdgrep -ql doesn't output anything, >> and make sure that -q actually halts processing on the first match. > > Of course both this and the color issue will be fixed. Thanks. I took another look at it, and I think the attached patch does the trick, although you'll probably want to regression test it. I'm running some limited tests now as well. I still haven't verified that -q halts processing on the first match however. >> Request number 2, think about whether or not introducing this as the >> default was the right course of action. I held my tongue on this when you >> committed it, but in the past when such things have been added they start >> life as an option, allowing those who choose to do so to regression test >> them. Once they've had a shakeout period THEN the switch is flipped to make >> them the default. I'm not at the point yet where I'm ready to ask for you >> to change this, but between the color thing and this issue, that ball has >> started to roll, in my mind at least. We'll see what happens with more >> testing. > > This change was thoroughly tested on pointyhat and by several interested > people even by you. Actually, the compatibility for non-standard GNU regexes > were added when you requested it after trying out with portmaster. Yes, IIRC that was when I last tested it for you about 2 years ago. And I appreciate you adding that support. > Why didn't you tell me earlier about this bug then, as well? My fuzzy recollection is that the various micro-optimizations such as this one have been added to portmaster in the intervening 2 years, but I could be wrong. If the bug and my code were both there 2 years ago, please accept my apologies for not reporting it sooner. Meanwhile, pointyhat runs are great for trying to assess bare technical compatibility with known combinations of options; however as I've learned in trying to regression-test portmaster, real human users are roughly infinitely more creative than that. :) 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 --0-1335630748-1279946638=:1697 Content-Type: TEXT/PLAIN; charset=us-ascii; name=bsdgrep-ql.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=bsdgrep-ql.diff SW5kZXg6IGdyZXAuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGdy ZXAuYwkocmV2aXNpb24gMjEwNDM4KQ0KKysrIGdyZXAuYwkod29ya2luZyBj b3B5KQ0KQEAgLTQ2NiwxMSArNDY2LDExIEBADQogCQkJYnJlYWs7DQogCQlj YXNlICdMJzoNCiAJCQlsZmxhZyA9IGZhbHNlOw0KLQkJCUxmbGFnID0gcWZs YWcgPSB0cnVlOw0KKwkJCUxmbGFnID0gdHJ1ZTsNCiAJCQlicmVhazsNCiAJ CWNhc2UgJ2wnOg0KIAkJCUxmbGFnID0gZmFsc2U7DQotCQkJbGZsYWcgPSBx ZmxhZyA9IHRydWU7DQorCQkJbGZsYWcgPSB0cnVlOw0KIAkJCWJyZWFrOw0K IAkJY2FzZSAnbSc6DQogCQkJbWZsYWcgPSB0cnVlOw0KSW5kZXg6IHV0aWwu Yw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIHV0aWwuYwkocmV2aXNp b24gMjEwNDM4KQ0KKysrIHV0aWwuYwkod29ya2luZyBjb3B5KQ0KQEAgLTIy Niw5ICsyMjYsOSBAQA0KIAkJCXByaW50ZigiJXM6IiwgbG4uZmlsZSk7DQog CQlwcmludGYoIiV1XG4iLCBjKTsNCiAJfQ0KLQlpZiAobGZsYWcgJiYgYyAh PSAwKQ0KKwlpZiAobGZsYWcgJiYgIXFmbGFnICYmIGMgIT0gMCkNCiAJCXBy aW50ZigiJXNcbiIsIGZuKTsNCi0JaWYgKExmbGFnICYmIGMgPT0gMCkNCisJ aWYgKExmbGFnICYmICFxZmxhZyAmJiBjID09IDApDQogCQlwcmludGYoIiVz XG4iLCBmbik7DQogCWlmIChjICYmICFjZmxhZyAmJiAhbGZsYWcgJiYgIUxm bGFnICYmDQogCSAgICBiaW5iZWhhdmUgPT0gQklORklMRV9CSU4gJiYgZi0+ YmluYXJ5ICYmICFxZmxhZykNCkBAIC0zNDIsNyArMzQyLDcgQEANCiAJCXJl dHVybiAoYyk7IC8qIEJpbmFyeSBmaWxlICovDQogDQogCS8qIERlYWxpbmcg d2l0aCB0aGUgY29udGV4dCAqLw0KLQlpZiAoKHRhaWwgfHwgYykgJiYgIWNm bGFnICYmICFxZmxhZykgew0KKwlpZiAoKHRhaWwgfHwgYykgJiYgIWNmbGFn ICYmICFxZmxhZyAmJiAhbGZsYWcpIHsNCiAJCWlmIChjKSB7DQogCQkJaWYg KCFmaXJzdCAmJiAhcHJldiAmJiAhdGFpbCAmJiBBZmxhZykNCiAJCQkJcHJp bnRmKCItLVxuIik7DQo= --0-1335630748-1279946638=:1697-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 04:54: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 1568C1065674 for ; Sat, 24 Jul 2010 04:54: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 AD1F18FC0C for ; Sat, 24 Jul 2010 04:54:19 +0000 (UTC) Received: (qmail 25318 invoked by uid 399); 24 Jul 2010 04:54:18 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jul 2010 04:54:18 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Fri, 23 Jul 2010 21:54:16 -0700 (PDT) From: Doug Barton To: Gabor Kovesdan In-Reply-To: Message-ID: References: <4C4A6F00.9000203@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: MULTIPART/MIXED; BOUNDARY="0-1162088418-1279947258=:1697" Cc: freebsd-current@FreeBSD.org Subject: Re: [bsdgrep] grep -ql does not supress output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 04:54: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. --0-1162088418-1279947258=:1697 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 23 Jul 2010, Doug Barton wrote: > Thanks. I took another look at it, and I think the attached patch does the > trick, Oops, forgot !Lflag in the last bit, this one fixes it. 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 --0-1162088418-1279947258=:1697 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=bsdgrep-ql.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=bsdgrep-ql.diff SW5kZXg6IGdyZXAuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGdy ZXAuYwkocmV2aXNpb24gMjEwNDM4KQ0KKysrIGdyZXAuYwkod29ya2luZyBj b3B5KQ0KQEAgLTQ2NiwxMSArNDY2LDExIEBADQogCQkJYnJlYWs7DQogCQlj YXNlICdMJzoNCiAJCQlsZmxhZyA9IGZhbHNlOw0KLQkJCUxmbGFnID0gcWZs YWcgPSB0cnVlOw0KKwkJCUxmbGFnID0gdHJ1ZTsNCiAJCQlicmVhazsNCiAJ CWNhc2UgJ2wnOg0KIAkJCUxmbGFnID0gZmFsc2U7DQotCQkJbGZsYWcgPSBx ZmxhZyA9IHRydWU7DQorCQkJbGZsYWcgPSB0cnVlOw0KIAkJCWJyZWFrOw0K IAkJY2FzZSAnbSc6DQogCQkJbWZsYWcgPSB0cnVlOw0KSW5kZXg6IHV0aWwu Yw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIHV0aWwuYwkocmV2aXNp b24gMjEwNDM4KQ0KKysrIHV0aWwuYwkod29ya2luZyBjb3B5KQ0KQEAgLTIy Niw5ICsyMjYsOSBAQA0KIAkJCXByaW50ZigiJXM6IiwgbG4uZmlsZSk7DQog CQlwcmludGYoIiV1XG4iLCBjKTsNCiAJfQ0KLQlpZiAobGZsYWcgJiYgYyAh PSAwKQ0KKwlpZiAobGZsYWcgJiYgIXFmbGFnICYmIGMgIT0gMCkNCiAJCXBy aW50ZigiJXNcbiIsIGZuKTsNCi0JaWYgKExmbGFnICYmIGMgPT0gMCkNCisJ aWYgKExmbGFnICYmICFxZmxhZyAmJiBjID09IDApDQogCQlwcmludGYoIiVz XG4iLCBmbik7DQogCWlmIChjICYmICFjZmxhZyAmJiAhbGZsYWcgJiYgIUxm bGFnICYmDQogCSAgICBiaW5iZWhhdmUgPT0gQklORklMRV9CSU4gJiYgZi0+ YmluYXJ5ICYmICFxZmxhZykNCkBAIC0zNDIsNyArMzQyLDcgQEANCiAJCXJl dHVybiAoYyk7IC8qIEJpbmFyeSBmaWxlICovDQogDQogCS8qIERlYWxpbmcg d2l0aCB0aGUgY29udGV4dCAqLw0KLQlpZiAoKHRhaWwgfHwgYykgJiYgIWNm bGFnICYmICFxZmxhZykgew0KKwlpZiAoKHRhaWwgfHwgYykgJiYgIWNmbGFn ICYmICFxZmxhZyAmJiAhbGZsYWcgJiYgIUxmbGFnKSB7DQogCQlpZiAoYykg ew0KIAkJCWlmICghZmlyc3QgJiYgIXByZXYgJiYgIXRhaWwgJiYgQWZsYWcp DQogCQkJCXByaW50ZigiLS1cbiIpOw0K --0-1162088418-1279947258=:1697-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 15:41: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 D0875106566C for ; Sat, 24 Jul 2010 15:41:31 +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 8ADCD8FC08 for ; Sat, 24 Jul 2010 15:41:31 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id B22ED14DC2B9; Sat, 24 Jul 2010 17:41:30 +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 e2WbIwO0Detu; Sat, 24 Jul 2010 17:41:28 +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 3D5AC14DC124; Sat, 24 Jul 2010 17:41:28 +0200 (CEST) Message-ID: <4C4B099F.3020605@FreeBSD.org> Date: Sat, 24 Jul 2010 17:41:19 +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: Anonymous References: <86iq45d4wu.fsf@gmail.com> In-Reply-To: <86iq45d4wu.fsf@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: [bsdgrep] outputs color sequences even when stdout is not tty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 15:41:31 -0000 > I think it should behave like ls(1) and gnu grep(1) and strip color > sequences if stdout is not associated with terminal. > Thanks for letting me know about this. The fix is being worked on just like for the -q/-l bug. Gabor From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 20:28: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 16426106566B for ; Sat, 24 Jul 2010 20:28:25 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 24EDD8FC19 for ; Sat, 24 Jul 2010 20:28:24 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id F2CDE1E006E7; Sat, 24 Jul 2010 22:28:23 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id o6OKOfKl005626 for ; Sat, 24 Jul 2010 22:24:41 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id o6OKOfYl005625 for freebsd-current@FreeBSD.org; Sat, 24 Jul 2010 22:24:41 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 24 Jul 2010 22:24:40 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20100724202440.GA5245@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: -nostdinc, , and X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 20:28:25 -0000 So I just looked at portsmon and saw this: http://portsmon.freebsd.org/portoverview.py?category=emulators&portname=kqemu&wildcard=yes http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20100703121112/kqemu-kmod-devel-1.4.0.p1_4.log.bz2 ... gcc -Wall -O2 -fomit-frame-pointer -fno-strict-aliasing -Werror -fno-stack-protector -D__KERNEL__ -nostdinc -iwithprefix include -I. -I.. -c -o monitor.o monitor.c In file included from monitor.c:19: kqemu_int.h:20:20: error: stddef.h: No such file or directory kqemu_int.h:21:20: error: stdarg.h: No such file or directory In file included from monitor.c:19: ... both kqemu ports are affected, but only on 9/i386 - amd64 is either fine or wasn't built recently enough, and everything 8 and earlier is fine too. Bug? :) (If not I can work around, just wanted to make sure since it might also affect other things...) Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 21:17: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 83A601065676 for ; Sat, 24 Jul 2010 21:17:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B3BE8FC08 for ; Sat, 24 Jul 2010 21:17:52 +0000 (UTC) Received: by ewy26 with SMTP id 26so536987ewy.13 for ; Sat, 24 Jul 2010 14:17: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:to:cc:content-type; bh=oDwtpUoWbhbSyrZGO6V7a8ulFsjNTuxTC96xRqvMqrw=; b=RcwqBJmogqdJkvf3NJ3d/pr5UxoJlYNAEJWOBGtsy58Bm/PiEUV5Q2tGiA019OKoLE dd1ndo9X+upAIU/wgsd7M3cCNtEftssi7siyDUOBsiUPaCi8rUV1PqCO+Hw/Mt764T+K dgj4WhYhPc5owQ44X2M0bFRkopXXDuP88YKJQ= 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=sHTAr/A9pXPPniw1qnJY+K3w31vBAH2AsKkPmAXb++h2MNd4OGwAdpPQvJjOUKJT3z mgSrFrZ/sXuHHQ5mblpUH8POUsRMvpb3uumhljwcMcXUVKa9P4Y9KkvHhUqt+gFlf5m2 e85xdR1QuPk/1R4if13mufwnzZio0u5fvw+qY= MIME-Version: 1.0 Received: by 10.213.77.75 with SMTP id f11mr2025180ebk.15.1280006271617; Sat, 24 Jul 2010 14:17:51 -0700 (PDT) Received: by 10.213.113.195 with HTTP; Sat, 24 Jul 2010 14:17:51 -0700 (PDT) In-Reply-To: <20100724202440.GA5245@triton8.kn-bremen.de> References: <20100724202440.GA5245@triton8.kn-bremen.de> Date: Sat, 24 Jul 2010 17:17:51 -0400 Message-ID: From: Ryan Stone To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: -nostdinc, , and X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 21:17:53 -0000 I believe that you should be using and From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 21:19: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 5AE1E1065672 for ; Sat, 24 Jul 2010 21:19:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 440358FC13 for ; Sat, 24 Jul 2010 21:19:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUHAG31SkyDaFvH/2dsb2JhbACTFQEBjElxvn2FNgQ X-IronPort-AV: E=Sophos;i="4.55,255,1278302400"; d="scan'208";a="86041930" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 24 Jul 2010 17:19:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id F17AE107816F for ; Sat, 24 Jul 2010 17:19:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeYOfOZl+j-W for ; Sat, 24 Jul 2010 17:19:03 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 4072B107816D for ; Sat, 24 Jul 2010 17:19:03 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o6OLb0I14801 for ; Sat, 24 Jul 2010 17:37:00 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 24 Jul 2010 17:37:00 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [HEADSUP]: commit that makes nfs_lock.c a separate module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 21:19:05 -0000 I will soon be committing a change to head that makes sys/nfsclient/nfs_lock.c into a separate module. Once this commit goes in, a kernel will need to be rebuilt from config on, since the build glue will have changed. rick From owner-freebsd-current@FreeBSD.ORG Sat Jul 24 23:01: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 9D7B41065673 for ; Sat, 24 Jul 2010 23:01:57 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id A061F8FC08 for ; Sat, 24 Jul 2010 23:01:57 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 39FB31E006E1; Sun, 25 Jul 2010 01:01:56 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id o6OMx0US003446; Sun, 25 Jul 2010 00:59:00 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id o6OMx0QE003443; Sun, 25 Jul 2010 00:59:00 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 25 Jul 2010 00:59:00 +0200 To: Ryan Stone Message-ID: <20100724225900.GA3433@triton8.kn-bremen.de> References: <20100724202440.GA5245@triton8.kn-bremen.de> 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) Cc: freebsd-current@freebsd.org, Juergen Lock Subject: Re: -nostdinc, , and X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jul 2010 23:01:57 -0000 On Sat, Jul 24, 2010 at 05:17:51PM -0400, Ryan Stone wrote: > I believe that you should be using and Aaah thank you! :) I shall make a patch tomorrow. Juergen