From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 00:54: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 3415D106566B for ; Sun, 25 Apr 2010 00:54:15 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id F0E0F8FC14 for ; Sun, 25 Apr 2010 00:54:14 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D571897FF for ; Sun, 25 Apr 2010 00:54:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-3.5 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Sun, 25 Apr 2010 00:54:13 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 01:54:07 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201004250154.07703.bruce@cran.org.uk> Subject: New IPv6 settings in rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 00:54:15 -0000 I updated my router to the latest -CURRENT yesterday and now I'm getting an error on startup from ifconfig saying the the IPv6 addresses I've configured are wrong ("bad value"). The settings I've got in rc.conf are: # IPv4 setup defaultrouter="a.b.c.d" gateway_enable="YES" ifconfig_vr0="a.b.c.d netmask 255.255.248.0 up" cloned_interfaces="bridge0" ifconfig_bridge0="addm dc0 addm dc1 addm dc2 addm dc3 192.168.1.1 netmask 255.255.255.0 up" ifconfig_dc0="up" ifconfig_dc1="up" ifconfig_dc2="up" ifconfig_dc3="up" # IPv6 setup ipv6_prefer="YES" ipv6_gateway_enable="YES" ipv6_defaultrouter="2001:abcd:abcd:abc::x" gif_interfaces="gif0 gif1" gifconfig_gif0="a.b.c.d e.f.g.h" gifconfig_gif1="a.b.c.d i.j.k.l" ifconfig_gif0_ipv6="2001:abcd:abcd:abc::x abcd:abc:abcd:abc::x prefixlen 128" ifconfig_gif1_ipv6="2a01:abcd:a:bc::x abcd:abc:x:ab::x prefixlen 128" # if_bridge doesn't have a link-local address by default, so add one ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" ifconfig_bridge0_ipv6_alias0="2001:abcd:abcd:abcd::x" # DHCP, DHCPv6 and rtadvd settings follow I can manually run ifconfig once the systems running so I guess I've missed out a required setting somewhere? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 01: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 C5D6E106566C; Sun, 25 Apr 2010 01:06:27 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7328FC0C; Sun, 25 Apr 2010 01:06:27 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 7BBB1C400C; Sun, 25 Apr 2010 01:06:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.7 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sun, 25 Apr 2010 01:06:26 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 02:06:25 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004250206.25452.bruce@cran.org.uk> Cc: Jeff Roberson , current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 01:06:27 -0000 On Tuesday 20 April 2010 23:15:48 Jeff Roberson wrote: > Hi Folks, > > You may have seen my other Soft-updates journaling (SUJ) announcements. > If not, it is a journaling system that works cooperatively with > soft-updates to eliminate the full background filesystem check after an > unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled > with tunefs -j disable on an unmounted filesystem. It is backwards > compatible with soft-updates with no journal. > > I'm going to do another round of tests and buildworld this afternoon to > verify the diff and then I'm committing to head. This is a very large > feature and fundamentally changes softupdates. Although it has been > extensively tested by many there may be unforseen problems. If you run > into an issue that you think may be suj please email me directly as well > as posting on current as I sometimes miss list email and this will ensure > the quickest response. Should fsck always report that the filesystem has been modified when the journal is skipped, even when no errors are reported? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 01:06: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 C5D6E106566C; Sun, 25 Apr 2010 01:06:27 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8C7328FC0C; Sun, 25 Apr 2010 01:06:27 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 7BBB1C400C; Sun, 25 Apr 2010 01:06:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.7 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sun, 25 Apr 2010 01:06:26 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 02:06:25 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004250206.25452.bruce@cran.org.uk> Cc: Jeff Roberson , current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 01:06:27 -0000 On Tuesday 20 April 2010 23:15:48 Jeff Roberson wrote: > Hi Folks, > > You may have seen my other Soft-updates journaling (SUJ) announcements. > If not, it is a journaling system that works cooperatively with > soft-updates to eliminate the full background filesystem check after an > unclean shutdown. SUJ may be enabled with tunefs -j enable and disabled > with tunefs -j disable on an unmounted filesystem. It is backwards > compatible with soft-updates with no journal. > > I'm going to do another round of tests and buildworld this afternoon to > verify the diff and then I'm committing to head. This is a very large > feature and fundamentally changes softupdates. Although it has been > extensively tested by many there may be unforseen problems. If you run > into an issue that you think may be suj please email me directly as well > as posting on current as I sometimes miss list email and this will ensure > the quickest response. Should fsck always report that the filesystem has been modified when the journal is skipped, even when no errors are reported? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 01:55: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 B6DCF106564A for ; Sun, 25 Apr 2010 01:55:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 636A78FC08 for ; Sun, 25 Apr 2010 01:55:18 +0000 (UTC) Received: (qmail 28524 invoked by uid 399); 25 Apr 2010 01:55:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Apr 2010 01:55:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BD3A104.4020703@FreeBSD.org> Date: Sat, 24 Apr 2010 18:55:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Bruce Cran References: <201004250154.07703.bruce@cran.org.uk> In-Reply-To: <201004250154.07703.bruce@cran.org.uk> 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 Subject: Re: New IPv6 settings in rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 01:55:18 -0000 On 04/24/10 17:54, Bruce Cran wrote: > I updated my router to the latest -CURRENT yesterday Did you run mergemaster after you upgraded? How old/what version of FreeBSD did you upgrade from? > and now I'm getting an > error on startup from ifconfig saying the the IPv6 addresses I've configured > are wrong ("bad value"). Can you please paste the exact error message? > The settings I've got in rc.conf are: > # IPv6 setup > ipv6_prefer="YES" This is no longer needed. > ipv6_gateway_enable="YES" > ipv6_defaultrouter="2001:abcd:abcd:abc::x" > > gif_interfaces="gif0 gif1" > gifconfig_gif0="a.b.c.d e.f.g.h" > gifconfig_gif1="a.b.c.d i.j.k.l" > ifconfig_gif0_ipv6="2001:abcd:abcd:abc::x abcd:abc:abcd:abc::x prefixlen 128" > ifconfig_gif1_ipv6="2a01:abcd:a:bc::x abcd:abc:x:ab::x prefixlen 128" > > # if_bridge doesn't have a link-local address by default, so add one > ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" It's likely that you need to add inet6 before fe80 there: ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" > ifconfig_bridge0_ipv6_alias0="2001:abcd:abcd:abcd::x" See the rc.conf man page on this one, this should probably be: ifconfig_bridge0_alias0="inet6 2001:abcd:abcd:abcd::x prefixlen 64" > I can manually run ifconfig once the systems running so I guess I've missed > out a required setting somewhere? If the above doesn't fix your problems, what ifconfig command line(s) work for you? hth, 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 Apr 25 02:58: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 E6406106564A for ; Sun, 25 Apr 2010 02:58:09 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by mx1.freebsd.org (Postfix) with ESMTP id C48F58FC0C for ; Sun, 25 Apr 2010 02:58:09 +0000 (UTC) Received: by pzk29 with SMTP id 29so2352156pzk.3 for ; Sat, 24 Apr 2010 19:57:58 -0700 (PDT) Received: by 10.141.23.12 with SMTP id a12mr1995742rvj.145.1272164278565; Sat, 24 Apr 2010 19:57:58 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id c16sm811857rvn.6.2010.04.24.19.57.56 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Apr 2010 19:57:57 -0700 (PDT) Date: Sat, 24 Apr 2010 16:57:59 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alex Keda In-Reply-To: <4BD35437.2060208@lissyara.su> Message-ID: References: r2x7d6fde3d1004210606o25fdf542j42cb5fdef75991e2@mail.gmail.com <4BD35437.2060208@lissyara.su> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 02:58:10 -0000 On Sun, 25 Apr 2010, Alex Keda wrote: > try in single user mode: > > tunefs -j enable / > tunefs: Insuffient free space for the journal > tunefs: soft updates journaling can not be enabled > > tunefs -j enable /dev/ad0s2a > tunefs: Insuffient free space for the journal > tunefs: soft updates journaling can not be enabled > tunefs: /dev/ad0s2a: failed to write superblock There is a bug that prevents enabling journaling on a mounted filesystem. So for now you can't enable it on /. I see that you have a large / volume but in general I would also suggest people not enable suj on / anyway as it's typically not very large. I only run it on my /usr and /home filesystems. I will send a mail out when I figure out why tunefs can't enable suj on / while it is mounted read-only. Thanks, Jeff > > on / (/dev/ad0s2a) ~40Gb free. > dc7700p$ uname -a > FreeBSD dc7700p.lissyara.su 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r207156: Sun > Apr 25 00:04:24 MSD 2010 > lissyara@dc7700p.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 > dc7700p$ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 03:17: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 DC0CF1065673 for ; Sun, 25 Apr 2010 03:17:12 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id B7C8F8FC12 for ; Sun, 25 Apr 2010 03:17:12 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o3P3HAnD014969; Sat, 24 Apr 2010 20:17:11 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BD3B433.2080009@feral.com> Date: Sat, 24 Apr 2010 20:17:07 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jeff Roberson References: r2x7d6fde3d1004210606o25fdf542j42cb5fdef75991e2@mail.gmail.com <4BD35437.2060208@lissyara.su> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Sat, 24 Apr 2010 20:17:12 -0700 (PDT) Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 03:17:12 -0000 Jeff Roberson wrote: > On Sun, 25 Apr 2010, Alex Keda wrote: > >> try in single user mode: >> >> tunefs -j enable / >> tunefs: Insuffient free space for the journal >> tunefs: soft updates journaling can not be enabled >> >> tunefs -j enable /dev/ad0s2a >> tunefs: Insuffient free space for the journal >> tunefs: soft updates journaling can not be enabled >> tunefs: /dev/ad0s2a: failed to write superblock > > There is a bug that prevents enabling journaling on a mounted > filesystem. So for now you can't enable it on /. I see that you have > a large / volume but in general I would also suggest people not enable > suj on / anyway as it's typically not very large. I only run it on my > /usr and /home filesystems. > > I will send a mail out when I figure out why tunefs can't enable suj > on / while it is mounted read-only. > > Thanks, > Jeff One of the attractions for suj would be for appliancized FreeBSD which now has to set 'fsck -y' for power fail/resets- and this means root as well. From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 04:32: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 CE4E91065674 for ; Sun, 25 Apr 2010 04:32:41 +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 6D8528FC0C for ; Sun, 25 Apr 2010 04:32:41 +0000 (UTC) Received: (qmail 9414 invoked by uid 60001); 25 Apr 2010 04:32:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1272169958; bh=uc/ewHnalGbQqTMrC9zqBKZrDessQ2kdTOWE/aytiek=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ki1ypyXPOhi2lxSdAyyL16bzxzaExG738oVCUpVaX07ML96xc+ZVrfDfdLvDu8Ybj0LyIpSeQ3xAxFbw1jsNBiwtZ/1/Uh08KTmUTbFKPz5BKnBlL1USLSt7XAn8y6Z81qLpCFi1sj32Yv65o+1OkfHy2edIIRKxpYvIzqNO7wc= 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=TZmE8xft0gFTCCMCurbs0ttNp0aN0XRaAvpe9st/ZyWyqHrOgezX2qFSiHLsJ1D7RHJeT3x3Cgyv/uUUX6JkTyt4Ja/MNDVBsRSy37txm9akLoYCPbwuYuxSkOgSetJijKMRgEeNjPaF2qbHdjCYOMUwZn4/CalalAKLuQh2K0w=; Message-ID: <332448.8676.qm@web51801.mail.re2.yahoo.com> X-YMail-OSG: EkwSV3MVM1mn3XY6H4HOWMMHHDBOH368vGnYQ_SrUwZsRC1 lSZgAlgNFr0XdR9Sb8sJ3FQTNn1H6Q.v0aQZHjpGjFf8OM7r4roV848fwtSK lDaid_iaaK5oEYtFHxH1EXpLpQJiVn1V_m4oa8qn9dxcJUGihOS0OHvUg1lk FL.SA5JXzVivgB63Kddc_cnf2CCkaRoSuLh6yDDDt3GULEh1OCaPevnoiTZ3 bLs2Px6tVBVuJOSHWRhLLeGxa.4pmvvq2RA6AOLg8.sDIap1IhLbDw_pA_ak AfXSaccJUbLPj2TeuwRpaYMNnMOHjbktIJLYjjXKDTbUr_a_6CBlhWloNBA5 hCOqOCjTr_1pCYIV16vMjKIMPD4fRwGIPgqJV3V4UCafLx_b90w-- Received: from [173.183.132.20] by web51801.mail.re2.yahoo.com via HTTP; Sat, 24 Apr 2010 21:32:38 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.102.267879 References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> <4BB3575D.4040506@gmail.com> <87836.79143.qm@web51804.mail.re2.yahoo.com> <4BBB372C.1060302@gmail.com> <665283.95271.qm@web51802.mail.re2.yahoo.com> <4BBDEC8F.9050803@gmail.com> <490521.32714.qm@web51804.mail.re2.yahoo.com> <4BD307DE.5080507@gmail.com> Date: Sat, 24 Apr 2010 21:32:38 -0700 (PDT) From: PseudoCylon To: Ganbold In-Reply-To: <4BD307DE.5080507@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ganbold Tsagaankhuu , freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 04:32:42 -0000 Hello, Thank you for all the info. This one shall work. http://projects.nasreddine.com/projects/run/repository/revisions/mips_fix/show/dev/usb/wlan Please update if_run.c and if_runvar.h (2 files). Just in case, after kldload, please issue # sysctl hw.usb.run.debug=1 Now it prints out very little messages, and no need to issue wlandebug. Thanks AK > Got another panic. Maybe it is > something else. > > run_rx_frame: rx done > run_rx_frame: rx done > run_rx_frame: rx done > run_rx_frame: rx done > run_rx_frame: rx done > Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) > [ thread pid 0 tid 100062 ] > Stopped at run_drain_fifo+0xd8: lw v0,6444(a1) > db> bt > Tracing pid 0 tid 100062 td 0xc0f88be0 > db_trace_thread+30 (?,?,?,?) ra 800ac688 sp c7e83970 sz 24 > 800ac56c+11c (0,?,ffffffff,?) ra 800abd30 sp c7e83988 sz 32 > 800ab99c+394 (?,?,?,?) ra 800abec0 sp c7e839a8 sz 168 > db_command_loop+78 (?,?,?,?) ra 800ae4d8 sp c7e83a50 sz 24 > 800ae3d0+108 (?,?,?,?) ra 80208060 sp c7e83a68 sz 424 > kdb_trap+108 (?,?,?,?) ra 80407624 sp c7e83c10 sz 32 > trap+ff4 (?,?,?,?) ra 803ff090 sp c7e83c30 sz 168 > MipsKernGenException+134 (1a3,0,0,21c) ra c7e5bd24 sp c7e83cd8 sz 200 > PC 0xc7e5bd24: not in kernel > 0+c7e5bd24 (?,?,?,?) ra 0 sp c7e83da0 sz 0 > pid 0 > db> > > Ganbold From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 07:00:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0C91065674; Sun, 25 Apr 2010 07:00:04 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 426138FC29; Sun, 25 Apr 2010 07:00:04 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 98DF3C400C; Sun, 25 Apr 2010 07:00:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sun, 25 Apr 2010 07:00:01 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 08:00:00 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <201004250154.07703.bruce@cran.org.uk> <4BD3A104.4020703@FreeBSD.org> In-Reply-To: <4BD3A104.4020703@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004250800.00145.bruce@cran.org.uk> Cc: Doug Barton Subject: Re: New IPv6 settings in rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 07:00:04 -0000 On Sunday 25 April 2010 02:55:16 Doug Barton wrote: > On 04/24/10 17:54, Bruce Cran wrote: > > # if_bridge doesn't have a link-local address by default, so add one > > ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" > > It's likely that you need to add inet6 before fe80 there: > ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 07:44: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 055E9106564A for ; Sun, 25 Apr 2010 07:44:36 +0000 (UTC) (envelope-from ganbold@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 C09008FC15 for ; Sun, 25 Apr 2010 07:44:35 +0000 (UTC) Received: by pwi9 with SMTP id 9so7982888pwi.13 for ; Sun, 25 Apr 2010 00:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Edrcze2f+oCLG1DvtTtHHI9vTzsP/LD5S7n53vJrwWc=; b=XYg89QzbynSpkoIcUAO1fz3l+pSReije9H89WCtx2OsvLBBwD1dF8H0m6LzD+O+WLy 7wAEaeI6UcC45KDs4CYC7yNQj4xHizxfK22NdXh94YMXhp/i8DVuWB8sL7UeDZ0R6T44 J6U7CaIh//prhgrG2P4XmeKZwDq9fM2n6uGgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jmheBrjQ9F5yleZ8tHgwxswEZKx9Pwx1Nyg4h6X4uwCbugEvv/EzIdxZPn0cZtUUj2 y/Y4ThfxdiRmwVERVw6ybVhnEFb99koN+eY+leY/A8vclw+bbMjOZQjoplB4TcLJS8rH Qxe6adtl1TZUkgQlwTNPRz1wUAelhDf1z4G/I= Received: by 10.115.25.6 with SMTP id c6mr2464937waj.129.1272181471731; Sun, 25 Apr 2010 00:44:31 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.137]) by mx.google.com with ESMTPS id c14sm10025595waa.13.2010.04.25.00.44.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Apr 2010 00:44:31 -0700 (PDT) Message-ID: <4BD3F2D4.8000007@gmail.com> Date: Sun, 25 Apr 2010 15:44:20 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> <4BB3575D.4040506@gmail.com> <87836.79143.qm@web51804.mail.re2.yahoo.com> <4BBB372C.1060302@gmail.com> <665283.95271.qm@web51802.mail.re2.yahoo.com> <4BBDEC8F.9050803@gmail.com> <490521.32714.qm@web51804.mail.re2.yahoo.com> <4BD307DE.5080507@gmail.com> <332448.8676.qm@web51801.mail.re2.yahoo.com> In-Reply-To: <332448.8676.qm@web51801.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ganbold Tsagaankhuu , freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 07:44:36 -0000 AK-san, PseudoCylon wrote: > Hello, > > Thank you for all the info. > This one shall work. > http://projects.nasreddine.com/projects/run/repository/revisions/mips_fix/show/dev/usb/wlan > Please update if_run.c and if_runvar.h (2 files). > > Just in case, after kldload, please issue > # sysctl hw.usb.run.debug=1 > Now it prints out very little messages, and no need to issue wlandebug. > > Thank you very much. However it still panics when I tried to use bridge. ... run0: flags=8843 metric 0 mtu 2290 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running wlan0: flags=8943 metric 0 mtu 1500 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid bsd channel 6 (2437 MHz 11g) bssid 00:22:cf:03:e0:30 country US authmode OPEN privacy OFF txpower 0 scanvalid 60 protmode CTS wme dtimperiod 1 -dfs bridge0: flags=8843 metric 0 mtu 1500 ether 06:ba:f8:33:07:6d id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: arge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 200000 member: wlan0 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 370370 ... wlan0: Ethernet address: 00:22:cf:03:e0:30 run_vap_create: rvp_id=0 bmap=1 rvp_cnt=1 run_media_change: called run_init_locked: called run_stop: All Tx cleared run_newstate: INIT -> INIT run_newstate: INIT -> SCAN run_newstate: SCAN -> RUN run_enable_tsf_sync: rvp_id=0 ic_opmode=4 bridge0: Ethernet address: 06:ba:f8:33:07:6d panic: Trying sleep, but thread marked as sleeping prohibited KDB: enter: panic [ thread pid 11 tid 100031 ] Stopped at kdb_enter+0x50: lui at,0x8054 db> bt Tracing pid 11 tid 100031 td 0xc0c96720 db_trace_thread+30 (?,?,?,?) ra 800ac688 sp c7967558 sz 24 800ac56c+11c (0,?,ffffffff,?) ra 800abd30 sp c7967570 sz 32 800ab99c+394 (?,?,?,?) ra 800abec0 sp c7967590 sz 168 db_command_loop+78 (?,?,?,?) ra 800ae4d8 sp c7967638 sz 24 800ae3d0+108 (?,?,?,?) ra 80208060 sp c7967650 sz 424 kdb_trap+108 (?,?,?,?) ra 80407380 sp c79677f8 sz 32 trap+d50 (?,?,?,?) ra 803ff090 sp c7967818 sz 168 MipsKernGenException+134 (0,a,806c8fe4,109) ra 802082e8 sp c79678c0 sz 200 kdb_enter+50 (?,?,?,?) ra 801d1a04 sp c7967988 sz 24 panic+f8 (?,4,80480eb8,120) ra 80212f10 sp c79679a0 sz 40 sleepq_add+120 (?,?,?,?) ra 8018f174 sp c79679c8 sz 56 _cv_wait+1f0 (?,?,?,?) ra 80147ba8 sp c7967a00 sz 64 usbd_do_request_flags+540 (?,?,?,?) ra c7e56358 sp c7967a40 sz 104 PC 0xc7e56358: not in kernel 0+c7e56358 (?,?,?,?) ra 0 sp c7967aa8 sz 0 pid 11 db> thanks, Ganbold > Thanks > AK > > >> Got another panic. Maybe it is >> something else. >> >> run_rx_frame: rx done >> run_rx_frame: rx done >> run_rx_frame: rx done >> run_rx_frame: rx done >> run_rx_frame: rx done >> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) >> [ thread pid 0 tid 100062 ] >> Stopped at run_drain_fifo+0xd8: lw v0,6444(a1) >> db> bt >> Tracing pid 0 tid 100062 td 0xc0f88be0 >> db_trace_thread+30 (?,?,?,?) ra 800ac688 sp c7e83970 sz 24 >> 800ac56c+11c (0,?,ffffffff,?) ra 800abd30 sp c7e83988 sz 32 >> 800ab99c+394 (?,?,?,?) ra 800abec0 sp c7e839a8 sz 168 >> db_command_loop+78 (?,?,?,?) ra 800ae4d8 sp c7e83a50 sz 24 >> 800ae3d0+108 (?,?,?,?) ra 80208060 sp c7e83a68 sz 424 >> kdb_trap+108 (?,?,?,?) ra 80407624 sp c7e83c10 sz 32 >> trap+ff4 (?,?,?,?) ra 803ff090 sp c7e83c30 sz 168 >> MipsKernGenException+134 (1a3,0,0,21c) ra c7e5bd24 sp c7e83cd8 sz 200 >> PC 0xc7e5bd24: not in kernel >> 0+c7e5bd24 (?,?,?,?) ra 0 sp c7e83da0 sz 0 >> pid 0 >> db> >> >> Ganbold >> > > > > -- As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 08:01: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 3D46D1065672; Sun, 25 Apr 2010 08:01:28 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id A09108FC0C; Sun, 25 Apr 2010 08:01:27 +0000 (UTC) Received: from nskntotgx01p.mx.bigpond.com ([124.188.161.100]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20100425080125.JLNK4632.nskntmtas02p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com>; Sun, 25 Apr 2010 08:01:25 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20100425080125.FQUN1945.nskntotgx01p.mx.bigpond.com@duncan.reilly.home>; Sun, 25 Apr 2010 08:01:25 +0000 Date: Sun, 25 Apr 2010 18:01:25 +1000 From: Andrew Reilly To: Marius Strobl Message-ID: <20100425080125.GA12283@duncan.reilly.home> References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100424193034.GA9853@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sun, 25 Apr 2010 08:01:25 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4BD3F6D5.00BD,ss=1,fgs=0 X-SIH-MSG-ID: rBEzFdb2TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rANv1RsM6kxDxJJhqNNGEhaa7hTY3Rs9mK Cc: Alexander Motin , FreeBSD-Current , freebsd-geom@freebsd.org Subject: usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 08:01:28 -0000 Hi all, Sorry to interrupt this thread with an off-topic question, but it seems vaguely related, and you folk seem to be the right ones to ask: I've recently done a drive upgrade in a 1U rack machine that only had space for the two active drives that were in it, and I couldn't afford the down-time that it would take to install from scratch. So I formatted and populated the first replacement drive in an external USB cradle, and when it was looking like a good replacement for the (gmirror'd) image that was running, I did the physical swap, and all was good, as expected. All except that that the identical drive that I inserted as the second element of the mirror would *not* accept a copy of the first disk's MBR block (with fdisk). It said that the calculated geometry was incompatible. Luckily for me (I think) the calculated geometry was a megabyte or so *larger* than the first drive, so I was still able to bsdlabel it to match, and slot it into the gmirror as planned. Was this the result of the umass/da driver having a different synthetic geometry calculation routine than the SATA driver? This was all on an 8-STABLE system about 400 days old, fwiw. Should I expect any on-going badness as a result of this difference in "geometry" between two identical drives? Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 10:06: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 97483106566C; Sun, 25 Apr 2010 10:06:51 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id C37828FC23; Sun, 25 Apr 2010 10:06:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.52,269,1270418400"; d="scan'208";a="32204838" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 25 Apr 2010 12:06:49 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id A0A8E1B0769; Sun, 25 Apr 2010 12:06:49 +0200 (CEST) Date: Sun, 25 Apr 2010 12:06:49 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Roman Divacky , Ulrich =?iso-8859-1?Q?Sp=F6rlein?= , Andrew Reilly Message-ID: In-Reply-To: <20100424080533.GA77435@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@freebsd.org, freebsd-current@FreeBSD.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 10:06:51 -0000 Roman Divacky schrieb am 2010-04-24: > ping.... any progress on this? :) sorry it took some time, but i've been rather busy. i was able to pinpoint the exact function which is causing the problem: it's snd_xbytes(). [snip] > > > Great stuff to have narrowed it down so much. Next logical step > > > would > > > be > > > to do the bisect on function-level scope. > > > Copy one half of buffer.c to buffer-clang.c, the other half to > > > buffer-gcc.c, > > > adjust the Makefile to use buffer-{gcc,clang}.c instead of > > > buffer.c > > > and > > > compile them accordingly. Redo your tests till we know the single > > > function(s) > > > where clang produces bad code. [snip] -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 10:23: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 201DB106566C; Sun, 25 Apr 2010 10:23:27 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay1.uni-muenster.de (ZIVM-RELAY1.UNI-MUENSTER.DE [128.176.192.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5E08FC13; Sun, 25 Apr 2010 10:23:25 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.52,269,1270418400"; d="scan'208";a="303246467" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay1.uni-muenster.de with ESMTP; 25 Apr 2010 12:23:25 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5D1E71B0769; Sun, 25 Apr 2010 12:23:25 +0200 (CEST) Date: Sun, 25 Apr 2010 12:23:25 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Jaakko Heinonen , Andriy Gapon , Scott Long Message-ID: In-Reply-To: <20100423140037.GA5851@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 10:23:27 -0000 Jaakko Heinonen schrieb am 2010-04-23: > On 2010-04-23, Alexander Best wrote: > > has anybody thought about adding scsi support to burncd(8)? i've > > been using > > ATA CAM for quite a while now and really love it. however i miss > > burncd(8). > I have thought about it. The mail I posted in December didn't > generate > any interest. i'm sorry i didn't notice your mail back then. i'm very interested in using burncd on a pass(4) device and would like to test any patches you may have. another option would be to have a ata(4)->cam(4)->ata(4) emulation. layer (the opposite of the current ATA_CAM option). that way all ata binaries would continue to work. what /dev/ata* would be used for is to receive ata commands, convert them to cam commands and then send them to pass. i wrote a mail with the idea to freebsd-questions@, but also got no response [1]. [1]: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg229439.html > http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 10:38: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 40059106564A for ; Sun, 25 Apr 2010 10:38:49 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 07F298FC0C for ; Sun, 25 Apr 2010 10:38:49 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 2620AC400C for ; Sun, 25 Apr 2010 10:38:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-3.4 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Sun, 25 Apr 2010 10:38:48 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 11:38:45 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201004251138.45852.bruce@cran.org.uk> Subject: sysinstall core dumps when using gsched X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 10:38:49 -0000 There seems to be something about the conftxt that geom produces when gsched is being used that libdisk doesn't like. sysinstall segfaults on startup when it's being used, with a NULL pointer being passed to strchr in open_disk.c:55 (Int_Open_Disk). -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 11:17: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 7567A1065673; Sun, 25 Apr 2010 11:17:42 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id 338828FC0A; Sun, 25 Apr 2010 11:17:42 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (Postfix) with ESMTPS id 1B0975CAC; Sun, 25 Apr 2010 13:17:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1272194261; bh=XXpP//J7BKmFrJfL6jvGnHrHzs0FTstZcR/dKAuASU4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=j6btTZ0w7EuNpUcuaXKFWRIURrtP1g7PgHR1J65oNZVjey0w/JgSojpbFZGfeidxb aHH+IXOKdeOQJsaKad3lxVeHSErUNyTRFTsKv3OAYGhFSRxVBZtkEnFA6rKNxHYO4Q DVvu4Ns4UGpuCzJDpmBhI80yss/WTrACca3lBLLE= Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o3PBHebc037821; Sun, 25 Apr 2010 13:17:40 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Sun, 25 Apr 2010 13:17:40 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Pegasus Mc Cleaft Message-ID: <20100425111740.GI92627@acme.spoerlein.net> Mail-Followup-To: Pegasus Mc Cleaft , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <201004241642.38017.ken@mthelicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201004241642.38017.ken@mthelicon.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: kern+world / ports make options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 11:17:42 -0000 On Sat, 24.04.2010 at 16:42:37 +0000, Pegasus Mc Cleaft wrote: > Hello Hackers & Current, > > I was wondering it if is possible, or if it can be done so a separate set > of CC, CXX, etc can be specified for building the world and kernel > independently of a ports build? > > Right now, I use the base GCC to compile the world and kernel, and GCC44 > for most of the other ports (when it complies cleanly). But I have to keep > editing the /etc/make.conf file to switch between the two. > > It may already be implemented, but it would be nice if there was > something defined while the kernel and/or world is being built to that a > nested block of ifdefs can select which env variables to be set. src.conf has already been mentioned, I don't use it myself but have the following set in make.conf .if ${.CURDIR:M*/usr/ports/*} NOCLEANDEPENDS= true WRKDIRPREFIX= /usr/obj .include "/etc/ports.conf" .endif I guess you can figure it out from there ... hth Ulrich Spörlein From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 11:48:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9DC9106568C for ; Sun, 25 Apr 2010 11:48:35 +0000 (UTC) (envelope-from gljennjohn@googlemail.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 75A5F8FC1B for ; Sun, 25 Apr 2010 11:48:34 +0000 (UTC) Received: by fxm15 with SMTP id 15so46166fxm.13 for ; Sun, 25 Apr 2010 04:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=l2GQTouN3CZT1bQPt+BtA1A7hgXh3tFZf7RiMjyM7Bc=; b=jeVD+wisI7PuphFy1kutH79c/oQBWtIHAxCrulvE4keVoE9VNoWuRupcraN7osqTgz f8N35oBsmec7xhhTxRT4bQRI6f+PUuo5kGJKxj4N+mizqrRNwJ4syGhXoYgUrVrbi6Cf H9zUmnLeQQWVDd30VSV41m4eYiXjhQL/lc800= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=a8Bbv+aScFPi8pTTyKXN/XRKoINKUbTnpzS+pKCdDrqzv0COmAVyXT+KAPjkS0J5tV nHx9Ck4xPiKtApxwWncpe+1llQXFJTAjY31HO+aptj8jL47jD2lhatIaet+ZtbZtIfQx 9trXFHBXkDBVqXExSBZ08LBRylqIamNq9VkxM= Received: by 10.87.64.25 with SMTP id r25mr4440446fgk.20.1272194655855; Sun, 25 Apr 2010 04:24:15 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE2230.dip0.t-ipconnect.de [87.174.34.48]) by mx.google.com with ESMTPS id g28sm914355fkg.28.2010.04.25.04.24.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Apr 2010 04:24:15 -0700 (PDT) Date: Sun, 25 Apr 2010 13:24:13 +0200 From: Gary Jennejohn To: Jeff Roberson Message-ID: <20100425132413.44d66b10@ernst.jennejohn.org> In-Reply-To: References: <4BD35437.2060208@lissyara.su> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 11:48:36 -0000 On Sat, 24 Apr 2010 16:57:59 -1000 (HST) Jeff Roberson wrote: > On Sun, 25 Apr 2010, Alex Keda wrote: > > > try in single user mode: > > > > tunefs -j enable / > > tunefs: Insuffient free space for the journal > > tunefs: soft updates journaling can not be enabled > > > > tunefs -j enable /dev/ad0s2a > > tunefs: Insuffient free space for the journal > > tunefs: soft updates journaling can not be enabled > > tunefs: /dev/ad0s2a: failed to write superblock > > There is a bug that prevents enabling journaling on a mounted filesystem. > So for now you can't enable it on /. I see that you have a large / volume > but in general I would also suggest people not enable suj on / anyway as > it's typically not very large. I only run it on my /usr and /home > filesystems. > > I will send a mail out when I figure out why tunefs can't enable suj on / > while it is mounted read-only. > Jeff - One thing which surprised me was that I couldn't reuse the existing .sujournal files on my disks. I did notice that there are now more flags set on them. Was that the reason? Or were you just being careful? -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 12:33: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 E052A1065676 for ; Sun, 25 Apr 2010 12:33:09 +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 698F18FC22 for ; Sun, 25 Apr 2010 12:33:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O611E-0001uX-V9 for freebsd-current@freebsd.org; Sun, 25 Apr 2010 14:33:05 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Apr 2010 14:33:04 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Apr 2010 14:33:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org connect(): No such file or directory From: Marcin Cieslak Date: Sun, 25 Apr 2010 12:32:51 +0000 (UTC) Organization: http://saper.info Lines: 63 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info X-Face: "MPx|KfVwz7Gg!ayb)rH,hKiCBJXvLY7t+%r1s0Uiw; (%xWn-C-H38.2Oa4JL|4Cx}a"V ~a pL4%i"s20r0%z0yZew?2><1ZfOFF27cPqcAKp?wG+-c&%BgXeJVm[lylYKH?j User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Sun, 25 Apr 2010 13:16:35 +0000 Subject: State of tun(4) in -CURRENT? No buffer space available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 12:33:10 -0000 Hello, I'm running r203753 (i386) for some time on my IPv6 router. This box uses net/sixxs-aiccu to establish an IPv6 tunnel to one of the SixXS POPs. Unfortunately, tun(4) interface exhibits strange behaviour: after some traffic burst (like opening a ncurses application via ssh) the interface stops delivering packets. I manually restart the sixxs-aiccu utility and then it usually works, sometimes for few packets only, sometimes for minutes or hours. When the link is mostly idle (e.g. overnight) it stays up. aiccu (when stopped with SIGQUIT) exhibits three threads, One of them is the tunnel watchdog thread (probably unreladed). The other one waits from the data encapsulated via IPv4: [Switching to thread 1 (Thread 28240ec0 (LWP 100074))]#0 0x2814c797 in recvfrom () from /lib/libc.so.7 (gdb) bt #0 0x2814c797 in recvfrom () from /lib/libc.so.7 #1 0x280a04d1 in recvfrom () from /lib/libthr.so.3 #2 0x0804fee3 in ayiya_writer (arg=0x2822c300) at ../common/ayiya.c:177 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x00000000 in ?? () ayiya.c:177: n = recvfrom(ayiya_socket->socket, (char *)buf, sizeof (buf), 0, (struct sockaddr *)&ci, &cl); Third thread is waiting for packets from tun(4): [Switching to thread 2 (Thread 28241140 (LWP 100053))]#0 0x28194869 in read () from /lib/libc.so.7 (gdb) bt #0 0x28194869 in read () from /lib/libc.so.7 #1 0x280a0576 in read () from /lib/libthr.so.3 #2 0x0804a2fa in tun_reader (arg=0x8055944) at ../common/tun.c:185 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x00000000 in ?? () tun.c:185: n = read(tun_fd, buf, sizeof(buf)); When the tunnel is "hung" ping6 packets to the other tunnel end do not go out and after a while: ping6: sendmsg: No buffer space available IPv4 connectivity to the tunnel provider is fine, (ping over IPv4 to the tunnel destination works fine), I didn't notice any intermittent connectivity failures that could cause this. Packets neither come in or come out (checked looking using some other IPv6 on the network as I don't control the other end of the tunnel). I know there has been updates to the tun(4) code since r203753, but a friend of mine doing the same on his box with kernel as of April 13th has the same problem. Any ideas what's wrong? --Marcin From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 18:38:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28A451065670; Sun, 25 Apr 2010 18:38:03 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id EECC78FC1F; Sun, 25 Apr 2010 18:38:02 +0000 (UTC) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id o3PIc1b9044744; Sun, 25 Apr 2010 18:38:01 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 18:38:01 +0000 User-Agent: KMail/1.12.4 (FreeBSD/9.0-CURRENT; KDE/4.3.5; amd64; ; ) References: <201004241642.38017.ken@mthelicon.com> <20100425111740.GI92627@acme.spoerlein.net> In-Reply-To: <20100425111740.GI92627@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201004251838.01073.ken@mthelicon.com> Cc: freebsd-hackers@freebsd.org Subject: Re: kern+world / ports make options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 18:38:03 -0000 On Sunday 25 April 2010 11:17:40 Ulrich Sp=C3=B6rlein wrote: > On Sat, 24.04.2010 at 16:42:37 +0000, Pegasus Mc Cleaft wrote: > > It may already be implemented, but it would be nice if there was > > something defined while the kernel and/or world is being built to that a > > nested block of ifdefs can select which env variables to be set. >=20 > src.conf has already been mentioned, I don't use it myself but have the > following set in make.conf >=20 > .if ${.CURDIR:M*/usr/ports/*} > NOCLEANDEPENDS=3D true > WRKDIRPREFIX=3D /usr/obj > .include "/etc/ports.conf" > .endif Hi Ulrich,=20 Thank you for that. This is pretty much what I was looking for as I can=20 use the .if block to add in only the pieces I want. The src.conf solution w= as=20 an option, but since both make.conf and src.conf are called, I ended up=20 basically undoing everything in src.conf that I did in make.conf; and that= =20 didn't work so well as I kept breaking the build (couldn't find headers and= =20 all sorts of thing). No doubt, it was the way that I did it.. Your solution= is=20 cleaner and makes sense to me.=20 Thanks again,=20 Peg From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 18:44: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 D425F106566C; Sun, 25 Apr 2010 18:44:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 905D38FC1E; Sun, 25 Apr 2010 18:44:47 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3PIij4J093636; Sun, 25 Apr 2010 12:44:46 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Sun, 25 Apr 2010 12:44:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alexander Best X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Jaakko Heinonen , freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 18:44:47 -0000 On Apr 25, 2010, at 4:23 AM, Alexander Best wrote: > Jaakko Heinonen schrieb am 2010-04-23: >> On 2010-04-23, Alexander Best wrote: >>> has anybody thought about adding scsi support to burncd(8)? i've >>> been using >>> ATA CAM for quite a while now and really love it. however i miss >>> burncd(8). >=20 >> I have thought about it. The mail I posted in December didn't >> generate >> any interest. >=20 > i'm sorry i didn't notice your mail back then. i'm very interested in = using > burncd on a pass(4) device and would like to test any patches you may = have. >=20 > another option would be to have a ata(4)->cam(4)->ata(4) emulation. = layer (the > opposite of the current ATA_CAM option). that way all ata binaries = would > continue to work. what /dev/ata* would be used for is to receive ata > commands, convert them to cam commands and then send them to pass. i = wrote a > mail with the idea to freebsd-questions@, but also got no response = [1]. >=20 Compatibility is a good thing, and I see nothing wrong with adding a = simple ioctl module to the pass or cd driver that achieves this. The only thing that I'd = worry about is that there might be semantics to the old ata ioctls that rely on quirky = operations of the old ata driver. It's really going to be counter-productive to try too hard = to emulate the old driver; the whole point of CAM_ATA is to move on from the sins of it. = Also, other than burncd, what else exists to justify this emulation layer? If it's just = burncd, have you considered writing a CAM-oriented replacement for it? Maybe something = that is as versatile as cdrecord, but with an unencumbered BSD license so it can = exist in the base system? Scott From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 18:47: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 928BF1065673 for ; Sun, 25 Apr 2010 18:47:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 353828FC1D for ; Sun, 25 Apr 2010 18:47:02 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3PIkvM0093651; Sun, 25 Apr 2010 12:46:58 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Sun, 25 Apr 2010 12:47:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> References: r2x7d6fde3d1004210606o25fdf542j42cb5fdef75991e2@mail.gmail.com <4BD35437.2060208@lissyara.su> To: Jeff Roberson X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 18:47:02 -0000 On Apr 24, 2010, at 8:57 PM, Jeff Roberson wrote: > On Sun, 25 Apr 2010, Alex Keda wrote: >=20 >> try in single user mode: >>=20 >> tunefs -j enable / >> tunefs: Insuffient free space for the journal >> tunefs: soft updates journaling can not be enabled >>=20 >> tunefs -j enable /dev/ad0s2a >> tunefs: Insuffient free space for the journal >> tunefs: soft updates journaling can not be enabled >> tunefs: /dev/ad0s2a: failed to write superblock >=20 > There is a bug that prevents enabling journaling on a mounted = filesystem. So for now you can't enable it on /. I see that you have a = large / volume but in general I would also suggest people not enable suj = on / anyway as it's typically not very large. I only run it on my /usr = and /home filesystems. >=20 > I will send a mail out when I figure out why tunefs can't enable suj = on / while it is mounted read-only. >=20 This would preclude enabling journaling on / on an existing system, but = I would think that you could enable it on / on a system that is being = installed, since (at least in theory) the target / filesystem won't be = the actual root of the system, and therefore can be unmounted at will. Scott From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 18:55: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 F3C26106564A for ; Sun, 25 Apr 2010 18:55:05 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id B87CA8FC1B for ; Sun, 25 Apr 2010 18:55:05 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id D74B58313; Sun, 25 Apr 2010 18:55:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sun, 25 Apr 2010 18:55:04 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Sun, 25 Apr 2010 19:55:03 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <4BD35437.2060208@lissyara.su> <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> In-Reply-To: <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004251955.03492.bruce@cran.org.uk> Cc: Alex Keda , Jeff Roberson Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 18:55:06 -0000 On Sunday 25 April 2010 19:47:00 Scott Long wrote: > On Apr 24, 2010, at 8:57 PM, Jeff Roberson wrote: > > On Sun, 25 Apr 2010, Alex Keda wrote: > >> try in single user mode: > >> > >> tunefs -j enable / > >> tunefs: Insuffient free space for the journal > >> tunefs: soft updates journaling can not be enabled > >> > >> tunefs -j enable /dev/ad0s2a > >> tunefs: Insuffient free space for the journal > >> tunefs: soft updates journaling can not be enabled > >> tunefs: /dev/ad0s2a: failed to write superblock > > > > There is a bug that prevents enabling journaling on a mounted filesystem. > > So for now you can't enable it on /. I see that you have a large / > > volume but in general I would also suggest people not enable suj on / > > anyway as it's typically not very large. I only run it on my /usr and > > /home filesystems. > > > > I will send a mail out when I figure out why tunefs can't enable suj on / > > while it is mounted read-only. > > This would preclude enabling journaling on / on an existing system, but I > would think that you could enable it on / on a system that is being > installed, since (at least in theory) the target / filesystem won't be the > actual root of the system, and therefore can be unmounted at will. It worked here - it's shown as enabled after I booted in single-user mode and enabled it yesterday: core# dumpfs / | grep -i journal flags soft-updates+journal -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 20:42:24 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3138A1065670; Sun, 25 Apr 2010 20:42:24 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id A49698FC20; Sun, 25 Apr 2010 20:42:23 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id o3PKgLki007840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 25 Apr 2010 22:42:21 +0200 Received: from [192.168.100.195] (82.Red-88-7-161.staticIP.rima-tde.net [88.7.161.82]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o3PKgGdr016985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2010 22:42:20 +0200 Message-ID: <4BD4A928.8020901@entel.upc.edu> Date: Sun, 25 Apr 2010 22:42:16 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Thunderbird 2.0.0.24 (X11/20100416) MIME-Version: 1.0 To: weongyo@freebsd.org References: <20091223035331.GA1293@weongyo> <4b31cb29.9413f30a.5f4a.ffff8382@mx.google.com> <20100226005115.GP14937@weongyo> <20100227011535.ed3f2486.ray@ddteam.net> <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <4BD2201E.3090409@entel.upc.edu> <20100424231755.GI65380@weongyo> In-Reply-To: <20100424231755.GI65380@weongyo> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Sun, 25 Apr 2010 22:42:21 +0200 (CEST) Cc: Gustau P?rez , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 20:42:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I've been testing the driver for a few time with AMD64/CURRENT. A >> few time ago I started to see messages like : >> >> bwn0: unsupported rate 0 >> >> I've checked the code and I found it seems to fail when trying to >> check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate >> routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate >> is called, to see how 'rate' is calculated. This is where I got lost :( >> >> My AP is FreeBSD 8.0 box with an atheros card. My hostapd works >> with both WPA2-PSK and WPA2-EAP (although >> I thinks this is not the problem) but with default values for rates >> and friends. I then forced my hostapd to use only a subset of transmit >> rates (with supported_rates and basic_rates) with no luck. >> >> My laptop is a DELL D630 with a BCM4310 UART adapter. >> >> Any need info will be provided and any help will be appreciated. > > First I think we need to know that where rate == 0 comes from. Rate > information on TX could be got from the following points: > > tp->mgmtrate > tp->mcastrate > tp->ucastrate > ni->ni_txrate > Added some device_printf to test those values. This is what I got : bwn0: tp->mgmtrate : 2 bwn0: tp->mcastrate : 2 bwn0: tp->ucastrate : 255 bwn0: ni->ni_txrate : 0 I didn't have time to follow the code to find out why it has a 0 value. If you need more info let me know. Regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL1KknAAoJEH+VVM1WSYnPAPUQAJrpVOOJ4KzUAe6GQHwFnM15 bUiuUeL+5b7sujjLY9j/zuCHQxPDak+/F7eG5AeaJ1bQFkuexG1oDJDLx3oTR06x xhSOKUPZuabrqVeX9xT2d9h8PHa8soEG1GtOPgKzLLfbP8emaimwEnNTlp9G+typ IFxI/LOGzSkpXsqupsXzHTjNiHOxjkijj7e2tEvU8qHh133JebrxBX0jpqSBrZKg +TAC6QnKxh+Mygumsc/5nVQiOPFJEQEEXXdSLXZbr2SqczDeDw98MXxiR4M7TnF/ 20j5fQQE65r6YoPx4X5h2IvaBz2f9aeXlP/t3XIepwuVl3cjL+7B9/CRkV5+T4B1 C5u1Je3tZU0c6fcXOAVOVo7A2c6d+tHXP014CKONPrsTUR2HmLHYNuCQZ+d9LBKx luMcPlqTeRjo+L+VxsM+P+2feegJ7/eV6gweYt3bWsbYzMwfPvjpX2HqgqDtx3DO IT/V8mO76GyCZ21MOdfDQC/1UTHztJVUEGTIXw1HO3aAn3LOsKMPegvF0ZdFyU+5 xv8xkgtbrIBxSA6TzsAu6E+JhksJw9KeEQ4bcaKND7EttnGGelawBB+FeRQiNDYt 6hlSdaX/hHn76tGGx0eJZ/qpdESo8WJvOgaQrt41s1RlfCFnMWmQxDeRY6Dj47LN aB2pONw41gG9OfrPcGi/ =f70p -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Apr 25 21:31: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 E7EBD106566C for ; Sun, 25 Apr 2010 21:31:10 +0000 (UTC) (envelope-from lwindschuh@googlemail.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 7D2D98FC24 for ; Sun, 25 Apr 2010 21:31:10 +0000 (UTC) Received: by wye20 with SMTP id 20so3778180wye.13 for ; Sun, 25 Apr 2010 14:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5jnGE8+Dmo+WXQRSwj/ApkmidgZ6asMZXRTdKt1i9B0=; b=cY96Mv4lR78wuZGDWHf5pv3Vf+Io2fEurV1Ng+UepQE6yHKR56kVgOSpNW79oAKNVL vRxUpBjsB3eUMSEbCXWwrnsd8Z0mq1Tu9Dm/GD23tdrcuiDHp21cjEEDEJjio+DzdjrD xCbpj5c7Ab2ADectMJJnsU3zVJ2+p0YEj1c4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BOd6LJt5cCZfIqU6q8R22VJSIdGvhYiINiVK9X5070DeNQke715cFouHkIfSnBnXWH D9fC8Lkn3leu0AXnygFPL67zAys+0dhiiNnl2nAAOUpuin8GZDW6Efbn8ek3kGew+1kT AO+KKCCJj+OG83TREBoLk5BNdGNv+pMPa7t6k= MIME-Version: 1.0 Received: by 10.216.184.132 with SMTP id s4mr3833345wem.122.1272231065626; Sun, 25 Apr 2010 14:31:05 -0700 (PDT) Received: by 10.216.154.207 with HTTP; Sun, 25 Apr 2010 14:31:05 -0700 (PDT) In-Reply-To: References: <4BD35437.2060208@lissyara.su> Date: Sun, 25 Apr 2010 23:31:05 +0200 Message-ID: From: Lucius Windschuh To: Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Apr 2010 21:31:11 -0000 Hi Jeff, thank you for your effort in implementing the soft update journaling. I tried to test SUJ on a provider with 4 kB block size. My system runs 9-CURRENT r207195 (i386). Unfortunately, tunefs is unable to cope with the device. It can easily reproduced with these steps: # mdconfig -s 128M -S 4096 0 # newfs -U /dev/md0 /dev/md0: 128.0MB (262144 sectors) block size 16384, fragment size 4096 using 4 cylinder groups of 32.02MB, 2049 blks, 2112 inodes. with soft updates # tunefs -j enable /dev/md0 Using inode 4 in cg 0 for 4194304 byte journal tunefs: Failed to read dir block: Invalid argument tunefs: soft updates journaling can not be enabled The bread() in tunefs.c:701 fails as the requested block size (512) is smaller than the provider's block size (4096 bytes). As a simply attempt to fix it, I changed tunefs.c:760 to " if (dir_extend(blk, nblk, size, ino) == -1)", as I thought that this made more sense. Then, tunefs succeeded, but mounting the file system resulted in a panic: panic: ufs_dirbad: /mnt/md-test: bad dir ino 2 at offset 512: mangled entry db:0:kdb.enter.default> bt Tracing pid 2714 tid 100262 td 0xc7ea6480 kdb_enter(c0a21226,c0a21226,c0a49886,eb1e6714,0,...) at kdb_enter+0x3a panic(c0a49886,c688f468,2,200,c0a498df,...) at panic+0x136 ufs_dirbad(c81bb000,200,c0a498df,0,eb1e67b0,...) at ufs_dirbad+0x46 ufs_lookup_ino(c81d5990,0,eb1e67d8,eb1e6800,0,...) at ufs_lookup_ino+0x367 softdep_journal_lookup(c688f288,eb1e68c4,c0a45eca,750,eb1e6834,...) at softdep_journal_lookup+0xb0 softdep_mount(c7e3fbb0,c688f288,c8165000,c7bdf900,c7bdf900,...) at softdep_mount+0xdb ffs_mount(c688f288,0,c0a2df89,3d6,0,...) at ffs_mount+0x23e1 vfs_donmount(c7ea6480,0,c7bc6100,c7bc6100,c8031000,...) at vfs_donmount+0x1000 nmount(c7ea6480,eb1e6cf8,c,c,207,...) at nmount+0x64 syscall(eb1e6d38) at syscall+0x1da Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280f205b, esp = 0xbfbfdcec, ebp = 0xbfbfe248 --- ... so this attempt did not succeed, but was worth a try ;-) But it would be nice to use SUJ even on such a unusual configuration. Lucius From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 01:49: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 04E721065674; Mon, 26 Apr 2010 01:49:57 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AF6428FC23; Mon, 26 Apr 2010 01:49:56 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 8A61460D2; Sun, 25 Apr 2010 21:49:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1272246595; bh=HpYHrRTHazRXQuaQ5SM7rkgX3MIey2HIOBwaMdrGaA8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Fbye6V8PO0MmhJUMivWvfmAAjZcP2sQ1mtuSEzhqwzzxJsjOTNnPYFeDe6S0r569L VRXpR9ppuqWjePn6n4nkTTy1SCqtSMSkTaXCccsF0VcbPKXYZhRFWcD3muuQGU7 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type; b=dWOQy1PfgyUFsiPUwha411a1jxElrqcXP+8DFPjsyvqpyCtWKsq9XJNmv4cyQtPDg oZLVmh5odoQJr1XDkWcje6yBNUYPEPFhJuRyEdui/HvMzyws/1YW31Upummhvzc Message-ID: <4BD4F13B.4080205@protected-networks.net> Date: Sun, 25 Apr 2010 21:49:47 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100422 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Motin References: <4BCA325A.1060600@protected-networks.net> <4BCA9F44.50002@FreeBSD.org> <987831E7-4893-4F2F-B96F-A1E25BD9BCA0@freebsd.org> <4BCB03AA.1050405@FreeBSD.org> <9B82ED79-C168-482C-A3A9-26D71060BB0F@freebsd.org> <4BCBF87C.7020400@FreeBSD.org> In-Reply-To: <4BCBF87C.7020400@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04D5146E391C2A25641DA674" Cc: FreeBSD-Current , Rui Paulo Subject: Re: SVN rev 206755 breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 01:49:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04D5146E391C2A25641DA674 Content-Type: multipart/mixed; boundary="------------070506060909040809040701" This is a multi-part message in MIME format. --------------070506060909040809040701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/19/10 02:30, Alexander Motin wrote: > Rui Paulo wrote: >> On 18 Apr 2010, at 14:05, Alexander Motin wrote: >>> Most of AHCI controllers could also work as usual PCI ATA, but not ev= ery >>> PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvb= c` >>> output in both working (Rui) and not working (Michael) cases. >> >> ahci0@pci0:0:31:2: class=3D0x01018f card=3D0x72708086 chip=3D0x27c4808= 6 rev=3D0x02 hdr=3D0x00 >> vendor =3D 'Intel Corporation' >> device =3D '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Co= ntroller' >> class =3D mass storage >> subclass =3D ATA >=20 > ^^^ > It doesn't report itself as AHCI. >=20 >> bar [10] =3D type I/O Port, range 32, base 0x20d8, size 8, enab= led >> bar [14] =3D type I/O Port, range 32, base 0x20fc, size 4, enab= led >> bar [18] =3D type I/O Port, range 32, base 0x20d0, size 8, enab= led >> bar [1c] =3D type I/O Port, range 32, base 0x20f8, size 4, enab= led >> bar [20] =3D type I/O Port, range 32, base 0x2020, size 16, enab= led >> bar [24] =3D type Memory, range 32, base 0x90445000, size 1024, = enabled >=20 > This resource (BAR(5)) is absent on Michael's system. It is needed to > work in AHCI mode, but not required for legacy PCI ATA. Probably some > kind of BIOS magic in your case makes it appear in this mode with this > chip ID. More for my own amusement than anything, I came up with an _horrible_ patch to force my ICH7M into AHCI mode (attached). It has two issues: 1) I haven't figured out how to automagically determine which address(es) I can use without colliding with anything else. Simply letting bus_allocate_any() decide where to point BAR(5) doesn't appear to work. I suspect I have to dig through the SMAP stuff to find out what the BIOS has already claimed and use something outside of those ranges. 2) Since my laptop has both a SATA drive and a PATA DVD-R/W, the manufacturer commissioned a BIOS which brings the ICH7M up in "combined mode" with D31-F1 completely disabled. Since it can't (per Intel spec) be re-enabled without a "platform reset", flipping into AHCI mode effectively removes the DVD. However - on the "up side", I now get NCQ ;-) ahci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf at device 31.2 on pci0 ahci0: BAR(5): 0xf0d44400 AHCI_CAP: 0xdf12ff03 PI: 0x1 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 1.5Gbps PM PMD SSC PSC 32cmd 4ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: [ .. ] ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number K82BT89256VDGEOM: new disk ada0 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) --------------070506060909040809040701 Content-Type: text/plain; name="ahci-a105-patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ahci-a105-patch" *** sys/dev/ahci/ahci.c.orig Sat Apr 24 21:36:42 2010 --- sys/dev/ahci/ahci.c Sun Apr 25 21:30:57 2010 *************** *** 126,131 **** --- 126,132 ---- {0x26838086, 0x00, "Intel ESB2", 0}, {0x27c18086, 0x00, "Intel ICH7", 0}, {0x27c38086, 0x00, "Intel ICH7", 0}, + {0x27c48086, 0x00, "Intel ICH7M", 0}, {0x27c58086, 0x00, "Intel ICH7M", 0}, {0x27c68086, 0x00, "Intel ICH7M", 0}, {0x28218086, 0x00, "Intel ICH8", 0}, *************** *** 321,331 **** --- 322,353 ---- ctlr->quirks =3D ahci_ids[i].quirks; resource_int_value(device_get_name(dev), device_get_unit(dev), "ccc", &ctlr->ccc); +=20 + #define AHCI_MEM_HACK 0xF0D44400 /* 0xf0d443ff is the last used by othe= rs on Toshiba A105 */ +=20 + /* Need to set the SCRAE bit and ensure SCRD not set */ + pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200) & = ~0x4000, 4); + /* enable MSE */ + pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2); + pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);=09 + pci_write_config(dev, 0x90, 0x40, 1); /* AHCI + non-combined */ +=20 + /* allocate a free memory window for BAR(5) */ + ctlr->r_rid =3D PCIR_BAR(5); + bus_set_resource(dev, SYS_RES_MEMORY, ctlr->r_rid, AHCI_MEM_HACK, 0x40= 0); +=20 /* if we have a memory BAR(5) we are likely on an AHCI part */ ctlr->r_rid =3D PCIR_BAR(5); if (!(ctlr->r_mem =3D bus_alloc_resource_any(dev, SYS_RES_MEMORY, &ctlr->r_rid, RF_ACTIVE))) return ENXIO; +=20 + /* enable ICH7M ports in AHCI space */ + ATA_OUTL(ctlr->r_mem, AHCI_PI, ATA_INL(ctlr->r_mem, AHCI_PI) | 5); + #if 0 + device_printf(dev, "BAR(5): 0x%lx AHCI_CAP: 0x%lx PI: 0x%lx\n", (unsig= ned long)pci_read_config(dev, 0x24, 4), + (unsigned long)ATA_INL(ctlr->r_mem, 0), (unsigned long)ATA_INL(ctlr->= r_mem, AHCI_PI)); + #endif /* Setup our own memory management for channels. */ ctlr->sc_iomem.rm_type =3D RMAN_ARRAY; ctlr->sc_iomem.rm_descr =3D "I/O memory addresses"; --------------070506060909040809040701-- --------------enig04D5146E391C2A25641DA674 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvU8T8ACgkQQv9rrgRC1JL4bACfcP2qWfDsoYSiAr2i02/4Nc7Z 8/sAoMPWiQ0lvK/Ka/0ZucaoP22cxAfa =Hb7M -----END PGP SIGNATURE----- --------------enig04D5146E391C2A25641DA674-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 01:58:55 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E5E106566B for ; Mon, 26 Apr 2010 01:58:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 12F418FC08 for ; Mon, 26 Apr 2010 01:58:54 +0000 (UTC) Received: (qmail 32662 invoked by uid 399); 26 Apr 2010 01:58:54 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Apr 2010 01:58:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BD4F35C.4020608@FreeBSD.org> Date: Sun, 25 Apr 2010 18:58:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Best References: In-Reply-To: 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 Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 01:58:55 -0000 On 04/25/10 03:23, Alexander Best wrote: > another option would be to have a ata(4)->cam(4)->ata(4) emulation. What would be the value of doing all of that work as opposed to just using one of the available options that already work with cam such as cdrecord? 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 Mon Apr 26 02:01: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 C1113106564A for ; Mon, 26 Apr 2010 02:01:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 535108FC13 for ; Mon, 26 Apr 2010 02:01:41 +0000 (UTC) Received: (qmail 2552 invoked by uid 399); 26 Apr 2010 02:01:40 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Apr 2010 02:01:40 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BD4F403.3070606@FreeBSD.org> Date: Sun, 25 Apr 2010 19:01:39 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Bruce Cran References: <201004250154.07703.bruce@cran.org.uk> <4BD3A104.4020703@FreeBSD.org> <201004250800.00145.bruce@cran.org.uk> In-Reply-To: <201004250800.00145.bruce@cran.org.uk> 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 Subject: Re: New IPv6 settings in rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 02:01:41 -0000 On 04/25/10 00:00, Bruce Cran wrote: > On Sunday 25 April 2010 02:55:16 Doug Barton wrote: >> On 04/24/10 17:54, Bruce Cran wrote: > >>> # if_bridge doesn't have a link-local address by default, so add one >>> ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" >> >> It's likely that you need to add inet6 before fe80 there: >> ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" > > Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem. I'm glad to hear that, although now I have a sinking feeling about the state of the -current code. In your OP you said you "updated to -current," what version of FreeBSD did you upgrade from? 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 Mon Apr 26 02:03: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 1F7A5106567F; Mon, 26 Apr 2010 02:03:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D05908FC19; Mon, 26 Apr 2010 02:03:19 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3Q23GGc095309; Sun, 25 Apr 2010 20:03:16 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BD4F35C.4020608@FreeBSD.org> Date: Sun, 25 Apr 2010 20:03:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <60DC882E-266C-46CA-9AB6-71B487418C15@samsco.org> References: <4BD4F35C.4020608@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Best , freebsd-current@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 02:03:20 -0000 On Apr 25, 2010, at 7:58 PM, Doug Barton wrote: > On 04/25/10 03:23, Alexander Best wrote: >> another option would be to have a ata(4)->cam(4)->ata(4) emulation.=20= >=20 > What would be the value of doing all of that work as opposed to just > using one of the available options that already work with cam such as > cdrecord? >=20 I think that there's a valid argument for having a cd recording program = in the base system. cdrecord is an excellent program, but I don't = believe that it's a good candidate to try to import into FreeBSD. Scoot From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 03:09:35 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D748106564A for ; Mon, 26 Apr 2010 03:09:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD008FC0A for ; Mon, 26 Apr 2010 03:09:34 +0000 (UTC) Received: (qmail 10479 invoked by uid 399); 26 Apr 2010 03:09:32 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Apr 2010 03:09:32 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BD503D9.6050307@FreeBSD.org> Date: Sun, 25 Apr 2010 20:09:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Scott Long References: <4BD4F35C.4020608@FreeBSD.org> <60DC882E-266C-46CA-9AB6-71B487418C15@samsco.org> In-Reply-To: <60DC882E-266C-46CA-9AB6-71B487418C15@samsco.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 03:09:35 -0000 On 04/25/10 19:03, Scott Long wrote: > On Apr 25, 2010, at 7:58 PM, Doug Barton wrote: >> On 04/25/10 03:23, Alexander Best wrote: >>> another option would be to have a ata(4)->cam(4)->ata(4) >>> emulation. >> >> What would be the value of doing all of that work as opposed to >> just using one of the available options that already work with cam >> such as cdrecord? >> > > I think that there's a valid argument for having a cd recording > program in the base system. I'm not sure I agree with you, but that's orthogonal to the OP. :) > cdrecord is an excellent program, but I > don't believe that it's a good candidate to try to import into > FreeBSD. Agreed on that ... and I'm not opposed to your previous idea of rewriting burncd to work with the new world order. I'm just not sure that the multi-layer idea to make the old burncd work is a good idea. 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 Mon Apr 26 06:47:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 808C8106566C; Mon, 26 Apr 2010 06:47:55 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (unknown [IPv6:2001:470:1f09:679::1]) by mx1.freebsd.org (Postfix) with ESMTP id 468828FC13; Mon, 26 Apr 2010 06:47:55 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 4268A97FF; Mon, 26 Apr 2010 06:47:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Mon, 26 Apr 2010 06:47:54 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Mon, 26 Apr 2010 07:47:52 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <201004250154.07703.bruce@cran.org.uk> <201004250800.00145.bruce@cran.org.uk> <4BD4F403.3070606@FreeBSD.org> In-Reply-To: <4BD4F403.3070606@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004260747.52365.bruce@cran.org.uk> Cc: Doug Barton Subject: Re: New IPv6 settings in rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 06:47:55 -0000 On Monday 26 April 2010 03:01:39 Doug Barton wrote: > On 04/25/10 00:00, Bruce Cran wrote: > > On Sunday 25 April 2010 02:55:16 Doug Barton wrote: > >> On 04/24/10 17:54, Bruce Cran wrote: > >>> # if_bridge doesn't have a link-local address by default, so add one > >>> ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" > >> > >> It's likely that you need to add inet6 before fe80 there: > >> ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" > > > > Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem. > > I'm glad to hear that, although now I have a sinking feeling about the > state of the -current code. In your OP you said you "updated to > -current," what version of FreeBSD did you upgrade from? It was an earlier version of -CURRENT from maybe a couple of months ago. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 08:12: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 20D131065673 for ; Mon, 26 Apr 2010 08:12:36 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp114.plus.mail.re1.yahoo.com (smtp114.plus.mail.re1.yahoo.com [69.147.102.77]) by mx1.freebsd.org (Postfix) with SMTP id B2D5E8FC16 for ; Mon, 26 Apr 2010 08:12:35 +0000 (UTC) Received: (qmail 7165 invoked from network); 26 Apr 2010 08:12:35 -0000 Received: from [10.141.21.121] (se@80.187.149.48 with plain) by smtp114.plus.mail.re1.yahoo.com with SMTP; 26 Apr 2010 01:12:31 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: 4Z4wvW4VM1lFZcjXn.XL7cmr76RUFvNUuBbNFIu1iQ_Gd00 St19zCC46XnkOerZcd87PRuh0IiRy2SJg5G._DiiCNvvJMHpGIAkGS4v9x2T Gcl2Q1urv366CBmpMT3Mn4ZKRd_Z4aiQuTM68tBbFImdIhpttqpc2JLFJVpB 6tULHjIGwyv1rZdylgZjL.xkW0mRsiXaW3EQ4x6RMkFBbBA0HzMFLFfWLBIP Z7JgnKzNBVCpVCfgkmM8euySiMNzmf.NCXzwaEMFN31.hqFp_ewT6Z3cdpQ_ ac6hvaj0G96yDVNDZAWsGIIjXwhk9n1KP9lPNpah7VFaWTzCEUXiMDQK_Brv bRy_ct7hRwAGwNyqfm5uN.39a95HrV6o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BD54AC7.7090301@FreeBSD.org> Date: Mon, 26 Apr 2010 10:11:51 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 ThunderBrowse/3.2.2.1 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Marin Atanasov References: <4B28F841.1070900@skylinetele.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , freebsd-stable@freebsd.org, "Prokofiev S.P." , freebsd-net@freebsd.org, Qing Li , freebsd-current@freebsd.org Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 08:12:36 -0000 Am 22.04.2010 20:43, schrieb Marin Atanasov: > Hello, > > Thanks a lot for the patch, Qing! > > It works fine. However I've noticed one thing, after I start mpd5 and > connect to my home network: > > kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() > > Not very sure if this is something to worry about or not? There was a problem with the initialization order of network "domains", which caused kernel crashes with ISDN+INET6 some two years ago. The reason was, that there was an implicit assumption, that all domains were initialized when the network interfaces are initialized, with NULL dereferences if domains are added (and relevant to a device) after the device has been initialized. I debugged this problem and prepared a patch for discussion, which later was committed by Max Laier (if memory serves me right). The message was added in order to identify further situations, where network domains are added after network interfaces have been initialized. This message ought to be informational right now, since the interface init is repeated whenever a network domain is added as part of above mentioned patch. Init order should be fixed, if this message is printed for compiled in drivers, but in case of a kernel module (like netgraph) that adds a domain, it is unadvoidable that the init order is reversed. Perhaps the message should be made conditional on the start-up of the kernel not having finished, or it should be completely removed, since time has shown, that the init order is correct in general. I'll remove that message (or make it conditional on "bootverbose") unless there is opposition to this change ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 12:51:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BE80106564A; Mon, 26 Apr 2010 12:51:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 95B088FC0A; Mon, 26 Apr 2010 12:51:20 +0000 (UTC) Received: by ewy24 with SMTP id 24so3405787ewy.33 for ; Mon, 26 Apr 2010 05:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Pnnr3KtMJEqenHrrQr3cArJah/TlZ0SkTkpzdfp6wWo=; b=FVHCrkR60fxhnIFwwZaHRxfG6mTt5QAhuZTWMDR2ngfCNOo3rH4X1tjlVkZnfq6ubX ahPLMZUwyPzfv8ZFpB53WRgQZv3jPrtixjC5CW+GPWbefR6sTo5hS98kjVxgZrDv3IdE HS8aDBOIZkoxkgg55tOgOfxakbknUfih8T2W4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=MNsos9322zVxi/xZQDbm76lHFv7cCu4KS50yjtmcbK+hdiPm0WyGvEujBVhLGDvI7v Y7zNIsMmTGDVyLUnb5YYlEXUdusPilp3KaAWgbDKcVF6FYg0ZrnOYojO7gBhsVZpPNca Z1PYagx1pkfbmEwLmww3D1wRtJfvmvH4EQ24E= Received: by 10.102.16.36 with SMTP id 36mr2220042mup.124.1272286276496; Mon, 26 Apr 2010 05:51:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm16181453mug.21.2010.04.26.05.51.14 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 05:51:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD58C35.2010305@FreeBSD.org> Date: Mon, 26 Apr 2010 15:51:01 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Marius Strobl References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> In-Reply-To: <20100424193034.GA9853@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 12:51:21 -0000 Marius Strobl wrote: > As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform > geometry translation as done by ad_firmware_geom_adjust() for ad(4), > which the following patch hooks up to both: > http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff > You preferred to implement such functionality via XPT_CALC_GEOMETRY > though (I'm still not convinced that it makes sense to put this > functionality into every ATA SIM the same way it is done for SCSI > rather than letting ada(4) handle it the same way for all SIMs > however). Have you looked into implementing XPT_CALC_GEOMETRY for > ATA CAM or is it okay to commit the above patch? Sorry, I have forgotten about this. I don't have better idea. For ATA translation seems indeed more platform- then controller-specific. May be I would just preferred to see this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done now for PC98 SCSI. But looking that whole this topic is quite crappy and hopefully going to die sometimes, I won't argue much against committing this as-is for now. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 13:07: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 E12941065670; Mon, 26 Apr 2010 13:07:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 42A728FC1F; Mon, 26 Apr 2010 13:07:55 +0000 (UTC) Received: by ewy24 with SMTP id 24so3417040ewy.33 for ; Mon, 26 Apr 2010 06:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=3taVqRM+buewQXXUtEz8GyVSZa07awlY3KfEcxkaEzE=; b=ajf1d3QvddD6HJKfD7cCTfFRxyVc0d+bbv4wUu2Rb6EmM6/k3285NTnyR+ppw4rg9e QJREn/dty20LYzmWTGHqIPUNvHBeu9VeL0aPTS154ec9vqK2UGEKaLyvY/GyodxnyagR ISHxZQFQISEEXgm44UnBz4QtiX+Ue5Y0BxxQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FvHBMF2gf9T5m6Sabnb+rEOom/xlfrhbG+C/Wb77qaAGnkw4dY2LH2fYwHQ0n+x1/w gnA5Hl7OdMb5cmotlXG2HjiPo+BdoUU1bslDy+vBGd/FTnoygmMbARpc0F69qeDHMkh4 EtD2Ptjr2m2OVuYqVQOKTXrqzwLWhRhYGG8fM= Received: by 10.103.48.21 with SMTP id a21mr2241433muk.98.1272287270308; Mon, 26 Apr 2010 06:07:50 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j2sm16958160mue.23.2010.04.26.06.07.48 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 06:07:49 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD59018.40805@FreeBSD.org> Date: Mon, 26 Apr 2010 16:07:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andrew Reilly References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> <20100425080125.GA12283@duncan.reilly.home> In-Reply-To: <20100425080125.GA12283@duncan.reilly.home> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org, FreeBSD-Current , Marius Strobl Subject: Re: usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 13:07:57 -0000 Andrew Reilly wrote: > Was this the result of the umass/da driver having a different > synthetic geometry calculation routine than the SATA driver? ATA and SCSI disk drivers indeed have different geometry calculation algorithms. ATA fetches geometry from DEVICE IDENTIFY data, while SCSI seems just fakes them in many cases. > This was all on an 8-STABLE system about 400 days old, fwiw. > > Should I expect any on-going badness as a result of this > difference in "geometry" between two identical drives? I hope not. LBA-aware loaders should use LBA offsets of the partitions, which are not depending on geometry. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 14:04: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 86EBF106566B for ; Mon, 26 Apr 2010 14:04:27 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 5E98B8FC14 for ; Mon, 26 Apr 2010 14:04:27 +0000 (UTC) Received: by pzk39 with SMTP id 39so581037pzk.7 for ; Mon, 26 Apr 2010 07:04:21 -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:content-type; bh=Z34mvtJpZTvT5HK/z95hMD6QKYjug2e+3BNCxh19qLA=; b=hiIXFjK/1CPMo4wqthMbMNZGAxmAWQ6txMR2iKN3RJ35jNfJbxIDdHBxilGom3ZBWW MFDWai7psYkQbKURIaWJDOflXfVKyfiRL09OqBzsAPmSrTJ16+exaLS6Lk8lbOejl3xX 1JlhxcnLUbP4zz0yOV/L4eOo9w02tp0nInNpQ= 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 :content-type; b=GSVDBROwOzcYTOwaB0y+H0ggnr/WHJOOFcd5MTn635pFgj/ivjF0DrJpuxTm54DiMt ieN2Z1Q5p+k/7vi+TQ9qmIrvNj+/JFqjqcPEchVrHJEtSYwVxByM4h8k2Up62hUYfJ82 EUbeWcHCRFnc3qLT7cZ0taf0RYUCGwNm6tlrg= Received: by 10.143.193.8 with SMTP id v8mr1793461wfp.162.1272289344101; Mon, 26 Apr 2010 06:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.168.6 with HTTP; Mon, 26 Apr 2010 06:42:04 -0700 (PDT) In-Reply-To: References: From: dikshie Date: Mon, 26 Apr 2010 22:42:04 +0900 Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 14:04:27 -0000 Hi Jeff, thanks for SUJ. btw, why there is nan% utilization? and what does it mean? -------------- ** SU+J Recovering /dev/ad0s1g ** Reading 33554432 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 0 journal records in 0 bytes for nan% utilization <==== ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. -------------- thanks! -dikshie- From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 14:20:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76A4D1065670 for ; Mon, 26 Apr 2010 14:20:23 +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 A43748FC1A for ; Mon, 26 Apr 2010 14:20:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA05240; Mon, 26 Apr 2010 17:20:18 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD5A122.5090204@icyb.net.ua> Date: Mon, 26 Apr 2010 17:20:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: dikshie References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 14:20:23 -0000 on 26/04/2010 16:42 dikshie said the following: > Hi Jeff, > thanks for SUJ. > btw, why there is nan% utilization? and what does it mean? 0/0 I guess. Floating point allows that :-) > -------------- > ** SU+J Recovering /dev/ad0s1g > ** Reading 33554432 byte journal from inode 4. > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > ** 0 journal records in 0 bytes for nan% utilization <==== > ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. > -------------- -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 14:39:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52F2F1065673 for ; Mon, 26 Apr 2010 14:39:41 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id B39ED8FC08 for ; Mon, 26 Apr 2010 14:39:39 +0000 (UTC) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o3QEdZK5022624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 18:39:37 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6PTC-0000qY-Pq; Mon, 26 Apr 2010 18:39:34 +0400 From: Vladimir Grebenschikov To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2010 18:39:34 +0400 Message-ID: <1272292774.2424.38.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.0.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today - panic on rename() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 14:39:41 -0000 Hi=20 First, many thanks for this effort, it is really very appreciated,=20 Panic on Gnome starting: # kgdb -q /usr/obj/usr/src/sys/VBOOK/kernel.debug /var/crash/vmcore.12 ... #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) x/s panicstr 0xc07c2160 : "remove_from_journal: 0xc581ec40 is not in journal= " (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc056b883 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 16 #2 0xc056babd in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc0488ba9 in db_fncall (dummy1=3D1, dummy2=3D0, dummy3=3D-1065321792, = dummy4=3D0xd90d572c "") at /usr/src/sys/ddb/db_command.c:548 #4 0xc0488fa1 in db_command (last_cmdp=3D0xc07abb1c, cmd_table=3D0x0, dopa= ger=3D1) at /usr/src/sys/ddb/db_command.c:445 #5 0xc04890fa in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xc048af7d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:229 #7 0xc0597f54 in kdb_trap (type=3D3, code=3D0, tf=3D0xd90d58c4) at /usr/sr= c/sys/kern/subr_kdb.c:535 #8 0xc06f842e in trap (frame=3D0xd90d58c4) at /usr/src/sys/i386/i386/trap.= c:694 #9 0xc06dcf7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc05980ba in kdb_enter (why=3D0xc0747a43 "panic", msg=3D0xc0747a43 "pa= nic") at cpufunc.h:71 #11 0xc056baa1 in panic (fmt=3D0xc0755fee "remove_from_journal: %p is not i= n journal") at /usr/src/sys/kern/kern_shutdown.c:573 #12 0xc0672135 in remove_from_journal (wk=3D0xc0c3ec2f) at /usr/src/sys/ufs= /ffs/ffs_softdep.c:2204 #13 0xc067e273 in cancel_jaddref (jaddref=3D0xc581ec40, inodedep=3D0xc5c587= 00, wkhd=3D0xc5c5875c) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3336 #14 0xc067f163 in softdep_revert_link (dp=3D0xc681f9f8, ip=3D0xc681f910) at= /usr/src/sys/ufs/ffs/ffs_softdep.c:3871 #15 0xc0697fd0 in ufs_rename (ap=3D0xd90d5c1c) at /usr/src/sys/ufs/ufs/ufs_= vnops.c:1546 #16 0xc070ead6 in VOP_RENAME_APV (vop=3D0xc0796340, a=3D0xd90d5c1c) at vnod= e_if.c:1474 #17 0xc05f2902 in kern_renameat (td=3D0xc586e8c0, oldfd=3D-100, old=3D0x485= 6ca30
, newfd=3D-100,=20 new=3D0x4856ca90
, pathseg=3DUIO_USER= SPACE) at vnode_if.h:636 #18 0xc05f29b6 in kern_rename (td=3D0xc586e8c0, from=3D0x4856ca30
, to=3D0x4856ca90
, pathseg=3DUIO_USERSPACE) at /usr/src/sys/kern/vfs_syscalls.c:3574 #19 0xc05f29e9 in rename (td=3D0xc586e8c0, uap=3D0xd90d5cf8) at /usr/src/sy= s/kern/vfs_syscalls.c:3551 #20 0xc06f7c49 in syscall (frame=3D0xd90d5d38) at /usr/src/sys/i386/i386/tr= ap.c:1113 #21 0xc06dcfe0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :261 #22 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Just after fsck -y && tunefs -j enable for both / and /usr in single-user mode and then usual boot panic is reproducible --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 14:43:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645D0106564A for ; Mon, 26 Apr 2010 14:43:06 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id E74AB8FC14 for ; Mon, 26 Apr 2010 14:43:05 +0000 (UTC) Received: by bwz8 with SMTP id 8so11252624bwz.3 for ; Mon, 26 Apr 2010 07:43:02 -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=CB80qaItV0+6AUr9cjUt9eWGN7dZcrvpTsBrAE5boR4=; b=ngYFwr0qqlo3JgOri+J0OrcZucKkcgyDqsxSbiGzOiBRIme/79SiBBhqpuawLM15Dl AjgLKrhRks6JTl0Usp+1HcN0TFuEfyLzXZAWh78hNsrLiM3O7HQDxKkCzKasRkck9k0c vLP0FJrOvM6mSsG7qNW5yddOFr7HkYeI06eP4= 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=oXC3Q2KF4xNojPVos2+3gPs4sX4WH1AcQ3/B1Mmw3bxtq57xh7KmGA7CCPBpV+93P3 4KyoHmKXOF0KNWLzBTIJXKvUhQbn2CiyNFscfbTAZAQTP6j6/stccwJ74u5OL6V4o2lp jiGTpxdlYNifYn4ozYW0nB9Xyp2Y/UxIKwiuE= MIME-Version: 1.0 Received: by 10.204.42.6 with SMTP id q6mr2652098bke.156.1272292982137; Mon, 26 Apr 2010 07:43:02 -0700 (PDT) Received: by 10.204.79.3 with HTTP; Mon, 26 Apr 2010 07:43:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Apr 2010 18:43:02 +0400 Message-ID: From: pluknet To: dikshie Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 14:43:06 -0000 On 26 April 2010 17:42, dikshie wrote: > Hi Jeff, > thanks for SUJ. > btw, why there is nan% utilization? and what does it mean? > -------------- > ** SU+J Recovering /dev/ad0s1g > ** Reading 33554432 byte journal from inode 4. > ** Building recovery table. > ** Resolving unreferenced inode list. > ** Processing journal entries. > ** 0 journal records in 0 bytes for nan% utilization <==== > ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. > -------------- > That may be due to an empty journal (the only plausible version for me), so jrecs and jblocks are not updated. /* Next ensure that segments are ordered properly. */ seg = TAILQ_FIRST(&allsegs); if (seg == NULL) { if (debug) printf("Empty journal\n"); return; } -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 15: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 5FC611065676; Mon, 26 Apr 2010 15:18:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8D88FC13; Mon, 26 Apr 2010 15:18:13 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3QFI7kJ098383; Mon, 26 Apr 2010 09:18:07 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4BD58C35.2010305@FreeBSD.org> Date: Mon, 26 Apr 2010 09:18:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5446E60D-0EE8-403E-A409-071ECE2EC534@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <20100424193034.GA9853@alchemy.franken.de> <4BD58C35.2010305@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-geom@freebsd.org, FreeBSD-Current , Marius Strobl Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 15:18:14 -0000 On Apr 26, 2010, at 6:51 AM, Alexander Motin wrote: > Marius Strobl wrote: >> As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform >> geometry translation as done by ad_firmware_geom_adjust() for ad(4), >> which the following patch hooks up to both: >> http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff >> You preferred to implement such functionality via XPT_CALC_GEOMETRY >> though (I'm still not convinced that it makes sense to put this >> functionality into every ATA SIM the same way it is done for SCSI >> rather than letting ada(4) handle it the same way for all SIMs >> however). Have you looked into implementing XPT_CALC_GEOMETRY for >> ATA CAM or is it okay to commit the above patch? >=20 > Sorry, I have forgotten about this. >=20 > I don't have better idea. For ATA translation seems indeed more > platform- then controller-specific. May be I would just preferred to = see > this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done = now > for PC98 SCSI. But looking that whole this topic is quite crappy and > hopefully going to die sometimes, I won't argue much against = committing > this as-is for now. Put this into XPT_CALC_GEOMETRY. There's no point in perpetuating the = mistakes of the ata driver. Give me a day or two to think of a reasonable way to do it right. Scott From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 16:03:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D662A106564A; Mon, 26 Apr 2010 16:03:00 +0000 (UTC) (envelope-from julianelischer@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 7F1648FC12; Mon, 26 Apr 2010 16:02:59 +0000 (UTC) Received: by fxm15 with SMTP id 15so126697fxm.13 for ; Mon, 26 Apr 2010 09:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yZnnSNr3LsoqlgjgNG2Mw1WfGJ1j6aB7j/XbS7MhCOU=; b=hnzjtoLDNF67QKKMPxNfImNQYoaIqH+GZaO5MtFxxvR1JpNn9mJo82x4/m5XdPWtWG ea2llOrTFc23OCbcABi7RN54HVX92uSLe3Z5H3zgW/lG+R6ksL6ozjEZ+kj9DJ/mFHwk V6Ctrqpc6nxX1+omhdaTJCVZsGaJUZPjfJhOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kRn972FUuk9ZwXdyCsqxHvEE9Cr1yuwM3p1T2XNUIdlzgAHVbQovB9scNr4VfISG9v /b5B69bO5FNJ0hbrHNSm+szgo/fGkvlv7HelobC8rj2xpKINKLeljji28CgtyMq7Miil POr2x/bjOA33noMX96KzwoLYrXo6QaR+/cvu4= Received: by 10.87.69.8 with SMTP id w8mr7730196fgk.58.1272297763037; Mon, 26 Apr 2010 09:02:43 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 4sm6915980fge.13.2010.04.26.09.02.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 09:02:40 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BD5B91B.2050606@elischer.org> Date: Mon, 26 Apr 2010 09:02:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stefan Esser References: <4B28F841.1070900@skylinetele.com> <4BD54AC7.7090301@FreeBSD.org> In-Reply-To: <4BD54AC7.7090301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , freebsd-stable@freebsd.org, "Prokofiev S.P." , freebsd-net@freebsd.org, Qing Li , freebsd-current@freebsd.org, Marin Atanasov Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 16:03:01 -0000 On 4/26/10 1:11 AM, Stefan Esser wrote: > Am 22.04.2010 20:43, schrieb Marin Atanasov: >> Hello, >> >> Thanks a lot for the patch, Qing! >> >> It works fine. However I've noticed one thing, after I start mpd5 and >> connect to my home network: >> >> kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() >> >> Not very sure if this is something to worry about or not? > > There was a problem with the initialization order of network "domains", > which caused kernel crashes with ISDN+INET6 some two years ago. The > reason was, that there was an implicit assumption, that all domains > were initialized when the network interfaces are initialized, with > NULL dereferences if domains are added (and relevant to a device) > after the device has been initialized. > > I debugged this problem and prepared a patch for discussion, which > later was committed by Max Laier (if memory serves me right). The > message was added in order to identify further situations, where > network domains are added after network interfaces have been > initialized. This message ought to be informational right now, since > the interface init is repeated whenever a network domain is added > as part of above mentioned patch. Init order should be fixed, if > this message is printed for compiled in drivers, but in case of a > kernel module (like netgraph) that adds a domain, it is unadvoidable > that the init order is reversed. > > Perhaps the message should be made conditional on the start-up of > the kernel not having finished, or it should be completely removed, > since time has shown, that the init order is correct in general. > > I'll remove that message (or make it conditional on "bootverbose") > unless there is opposition to this change ... please do.. it's an unavoidable thing that domains added after boot are done after boot completes :-) > Regards, STefan > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 16:41: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 2D4A61065675; Mon, 26 Apr 2010 16:41:44 +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 E1F438FC13; Mon, 26 Apr 2010 16:41:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3QGXGAG058943; Mon, 26 Apr 2010 10:33:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Apr 2010 10:33:27 -0600 (MDT) Message-Id: <20100426.103327.319083499807534535.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4BD06BD9.6030401@FreeBSD.org> References: <4BD06BD9.6030401@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 16:41:44 -0000 I've read most of this thread. I think this is cool technology. However, before we move forward with this, we need to have a plan for the various issues that have come up. The plan needs to be specific, have owners for key items, warnings about ownerless == obsoleted, and target dates. I think this is one of the cases where we should record the plan of record on a wiki. It worked well for other times we've had big, disruptive changes. My opinion for the path forward: (1) Send a big heads up about the future of ataraid(5). It will be shot in the head soon, to be replaced be a bunch of geom classes for each different container format. At least that seems to be the rough consensus I've seen so far. We need worker bees to do many of these classes, although much can be mined from the ataraid code today. (2) Send another big heads up strongly recommending people go to glabel based fstabs. Maybe the right option here is to provide a simple script walk people through the conversion. This will render the carnage of ad -> ada (or da) a mostly non-event, and also protect people from 'oops' of rebooting with that thumb drive in the system. (3) Create a wiki to record all the new geom classes needed. Find people to own each one, or note it is unowned, and support will be dropped if no owner can be found. (4) sysinstall should default to creating label systems, if it doesn't already. (5) Issues with glabel and ataraid(5) need an owner, and need to be resolved, since the device names here are likely to change. (6) Someone needs to write-up a detailed description of how to do this for UPDATING. Maybe we can reuse text from #2. (7) We need a target time line for these things to happen. We can't just break ataraid(5) by default with little or no warning. Realistically, this will be for 9.0 and later systems, so we have some time before the branch to give warning, as well as pull the switch and have adequate testing time. (8) Fill in all the parts that I've missed :) Comments? Warner From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 17:36: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 728741065670 for ; Mon, 26 Apr 2010 17:36:25 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0016E8FC18 for ; Mon, 26 Apr 2010 17:36:24 +0000 (UTC) Received: by ewy24 with SMTP id 24so3656535ewy.33 for ; Mon, 26 Apr 2010 10:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=PtrYDLU4t55brNv07T3BLzn/ROCgF2tro+bTbB5N+OE=; b=ux8/3vQh7MNP6fhBinMAWodmY4LvXMCiq/+c+DVIhII28GjbJacxLfom96ngJUzVzc O2u1mI8++czKbGfdu7hc1azTx4FqQLEH7Etm7gTK98H+2HCcC3xU8ZkMk9377CFHRCYc 6rrCzOLZObHFac/uDR0O6TVMAHRjkYNN76syU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=ZU6q6xwrg7a305WtapFEPKTO3l86LgYvaXyREzzbzHv851Nj+3QI+r59NHyxA6BS8Z c1tkn0CxUK3NPakRsyStyjXOZToXloaLbjdBe7Krboz8ii+qRebBVJPE3w7ZgJ5nrZTy XS/gxuAitM3pjsmH/Kc0ISXM5B+KugNwuttXk= Received: by 10.103.80.25 with SMTP id h25mr2496060mul.60.1272303377065; Mon, 26 Apr 2010 10:36:17 -0700 (PDT) Received: from [10.0.0.1] ([77.41.31.122]) by mx.google.com with ESMTPS id i5sm18246077mue.49.2010.04.26.10.36.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 10:36:16 -0700 (PDT) Message-Id: From: Arseny Nasokin To: Pegasus Mc Cleaft In-Reply-To: <201004241642.38017.ken@mthelicon.com> Content-Type: text/plain; charset=windows-1251; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPhone Mail 7E18) Date: Mon, 26 Apr 2010 01:42:22 +0400 References: <201004241642.38017.ken@mthelicon.com> X-Mailer: iPhone Mail (7E18) Cc: "freebsd-hackers@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: kern+world / ports make options X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 17:36:25 -0000 On 24 Apr 2010, at 20:42, Pegasus Mc Cleaft wrote: > Hello Hackers & Current, > > I was wondering it if is possible, or if it can be done so a =20 > separate set > of CC, CXX, etc can be specified for building the world and kernel > independently of a ports build? > > Right now, I use the base GCC to compile the world and kernel, =20 > and GCC44 > for most of the other ports (when it complies cleanly). But I have =20 > to keep > editing the /etc/make.conf file to switch between the two. > > It may already be implemented, but it would be nice if there was > something defined while the kernel and/or world is being built to =20 > that a > nested block of ifdefs can select which env variables to be set. > # make toolchain buildworld buildkernel =85 This forces build core gcc and others to build world & kernel > Peg > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org=20 > " From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 18:12: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 C79CC1065674; Mon, 26 Apr 2010 18:12:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id E32A08FC15; Mon, 26 Apr 2010 18:12:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7177845F21; Mon, 26 Apr 2010 20:12:14 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4CC9D45F22; Mon, 26 Apr 2010 20:12:10 +0200 (CEST) Date: Mon, 26 Apr 2010 20:12:09 +0200 From: Pawel Jakub Dawidek To: "M. Warner Losh" Message-ID: <20100426181209.GB3012@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 18:12:19 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: > I've read most of this thread. I think this is cool technology. > However, before we move forward with this, we need to have a plan for > the various issues that have come up. The plan needs to be specific, > have owners for key items, warnings about ownerless =3D=3D obsoleted, and > target dates. >=20 > I think this is one of the cases where we should record the plan of > record on a wiki. It worked well for other times we've had big, > disruptive changes. >=20 > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. This shouldn't be a bunch of GEOM classes. This should one class which recognize multiple formats, just like the LABEL class. I don't think it is feasible to reuse gmirror for that, it wasn't designed in something like this in mind. > (2) Send another big heads up strongly recommending people go to > glabel based fstabs. Maybe the right option here is to provide a > simple script walk people through the conversion. This will > render the carnage of ad -> ada (or da) a mostly non-event, and > also protect people from 'oops' of rebooting with that thumb drive > in the system. > (3) Create a wiki to record all the new geom classes needed. Find > people to own each one, or note it is unowned, and support will be > dropped if no owner can be found. > (4) sysinstall should default to creating label systems, if it doesn't > already. > (5) Issues with glabel and ataraid(5) need an owner, and need to be > resolved, since the device names here are likely to change. What are the issues? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvV13kACgkQForvXbEpPzT6MgCg4JrUw+ONC0VBCXtKBYrfQJXI HV4An28X0VJICNPg3RFHT5+o7MExBaTx =bI6x -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 18:13: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 F28CC1065675; Mon, 26 Apr 2010 18:13:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE87A8FC0A; Mon, 26 Apr 2010 18:13:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 443D346B35; Mon, 26 Apr 2010 14:13:20 -0400 (EDT) Date: Mon, 26 Apr 2010 19:13:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> Message-ID: References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 18:13:21 -0000 On Mon, 26 Apr 2010, M. Warner Losh wrote: > I've read most of this thread. I think this is cool technology. However, > before we move forward with this, we need to have a plan for the various > issues that have come up. The plan needs to be specific, have owners for > key items, warnings about ownerless == obsoleted, and target dates. > > I think this is one of the cases where we should record the plan of record > on a wiki. It worked well for other times we've had big, disruptive > changes. This is my reading too: this is a big deal change, it's excellent that it's happening, but if we want it to go well we need to do a bit of planning. In particular, if we want to maximize our effectiveness in convincing people to write replacements parts for ataraid, doing the heads up and schedule/warnings the right way will help a lot. While the schedule doesn't need to be as long as the mpsafe network stack/device drivers process, it worked well in practice and so I'd encourage something similar. More generally, and to raise a point not so much in your list: I wonder if global-based fstabs are the right way to go or not. If they are we need to push the migration heavily, and especially provide a pre-upgrade tool to help users get their fstab changes right (i.e., a script that takes your /etc/fstab and system configuration and tells you what to put in your new fstab). I still wonder if we should be trying a bit harder to provide compatibility with the old ata names -- our experience is that "flag day" upgrades cause a lot of user attrition on -current and in the releases, and it might be that making a few architectural sacrifices to ease the upgrade path is worth it. I for one don't want to be on the wrong end of all the users who install a new kernel and discover that /etc/fstab isn't forwards-compatible! All that said: this is really great work, and I'm sure I speak for many when I say thanks to Alexander for the hard work that has gone into this. A bit more perserverence and we'll be there :-). Robert > > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. > (2) Send another big heads up strongly recommending people go to > glabel based fstabs. Maybe the right option here is to provide a > simple script walk people through the conversion. This will > render the carnage of ad -> ada (or da) a mostly non-event, and > also protect people from 'oops' of rebooting with that thumb drive > in the system. > (3) Create a wiki to record all the new geom classes needed. Find > people to own each one, or note it is unowned, and support will be > dropped if no owner can be found. > (4) sysinstall should default to creating label systems, if it doesn't > already. > (5) Issues with glabel and ataraid(5) need an owner, and need to be > resolved, since the device names here are likely to change. > (6) Someone needs to write-up a detailed description of how to do this > for UPDATING. Maybe we can reuse text from #2. > (7) We need a target time line for these things to happen. We can't > just break ataraid(5) by default with little or no warning. > Realistically, this will be for 9.0 and later systems, so we have > some time before the branch to give warning, as well as pull the > switch and have adequate testing time. > (8) Fill in all the parts that I've missed :) > > Comments? > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 18:28: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 F1363106564A; Mon, 26 Apr 2010 18:28:58 +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 8EBE78FC1B; Mon, 26 Apr 2010 18:28:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3QIJavp060327; Mon, 26 Apr 2010 12:19:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 26 Apr 2010 12:19:46 -0600 (MDT) Message-Id: <20100426.121946.506212773266921087.imp@bsdimp.com> To: pjd@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100426181209.GB3012@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> 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: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 18:28:59 -0000 In message: <20100426181209.GB3012@garage.freebsd.pl> Pawel Jakub Dawidek writes: : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: : > I've read most of this thread. I think this is cool technology. : > However, before we move forward with this, we need to have a plan for : > the various issues that have come up. The plan needs to be specific, : > have owners for key items, warnings about ownerless == obsoleted, and : > target dates. : > : > I think this is one of the cases where we should record the plan of : > record on a wiki. It worked well for other times we've had big, : > disruptive changes. : > : > My opinion for the path forward: : > (1) Send a big heads up about the future of ataraid(5). It will be : > shot in the head soon, to be replaced be a bunch of geom classes : > for each different container format. At least that seems to be : > the rough consensus I've seen so far. We need worker bees to do : > many of these classes, although much can be mined from the ataraid : > code today. : : This shouldn't be a bunch of GEOM classes. This should one class which : recognize multiple formats, just like the LABEL class. : I don't think it is feasible to reuse gmirror for that, it wasn't : designed in something like this in mind. OK. Maybe I got the consensus wrong... My key point is that we need a plan moving forward, we need to identify what's actively being worked on vs "somebody else[tm] should do tihs" and when it needs to be done "or else". : > (2) Send another big heads up strongly recommending people go to : > glabel based fstabs. Maybe the right option here is to provide a : > simple script walk people through the conversion. This will : > render the carnage of ad -> ada (or da) a mostly non-event, and : > also protect people from 'oops' of rebooting with that thumb drive : > in the system. : > (3) Create a wiki to record all the new geom classes needed. Find : > people to own each one, or note it is unowned, and support will be : > dropped if no owner can be found. : > (4) sysinstall should default to creating label systems, if it doesn't : > already. : > (5) Issues with glabel and ataraid(5) need an owner, and need to be : > resolved, since the device names here are likely to change. : : What are the issues? ataraid doesn't remove the underlying ad* devices, so glabel often picks those up instead of the ataraid device, and you only get 1 disk's worth of raid device... So no mirroring or only 1/2 a striped volume. Warner From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 18:33:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE6F1106564A for ; Mon, 26 Apr 2010 18:33:36 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id EFB5E8FC0C for ; Mon, 26 Apr 2010 18:33:35 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1O6T7d-0006E2-G0; Mon, 26 Apr 2010 20:33:33 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1O6T7Z-0000WL-9f; Mon, 26 Apr 2010 20:33:29 +0200 To: Buganini , current@freebsd.org From: Ian FREISLICH In-Reply-To: <20100424235827.GK65380@weongyo> References: <20100424235827.GK65380@weongyo> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <20100313231205.5e68a89a.ray@ddteam.net> <20100314005558.GB88159@weongyo> <20100315004357.fca53c7f.ray@ddteam.net> <20100316225113.GF88159@weongyo> X-Attribution: BOFH Date: Mon, 26 Apr 2010 20:33:29 +0200 Message-Id: Cc: Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 18:33:36 -0000 Weongyo Jeong wrote: > > > The corollery is that it doesn't work first time on reboot. ??I need > > > to either '/etc/rc.d/netif restart' and if that panics the machine, > > > destroy wlan0 and then restart netif. > > > > > > Then wlan0/bwn0 associates correctly with this device. > > If you're a CURRENT user could you please show me the result of `netstat > -ni' after updating latest CURRENT and keeping scanning channels? [mini] /usr/home/ianf $ netstat -niI bwn0 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll bwn0 2290 00:26:5e:57:23:33 913 0 0 537 0 0 [mini] /usr/home/ianf # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:26:5e:57:23:33 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11g) country US authmode WPA privacy ON deftxkey UNDEF txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL [mini] /usr/home/ianf $ ifconfig wlan0 list scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS quasar 00:30:4f:58:bf:94 1 54M -108:-95 100 EP WPA WME 00:1f:33:01:76:f4 11 54M -137:-95 100 EPS WPA WME ATH It's not scanning. Now: [mini] /usr/home/ianf # ifconfig wlan0 destroy [mini] /usr/home/ianf # /etc/rc.d/netif restart [mini] /usr/home/ianf # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:26:5e:57:23:33 inet 10.0.2.232 netmask 0xffffff00 broadcast 10.0.2.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid quasar channel 1 (2412 MHz 11g) bssid 00:30:4f:58:bf:94 country US authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 19:10:24 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4B4A106566C; Mon, 26 Apr 2010 19:10:23 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2775D8FC18; Mon, 26 Apr 2010 19:10:22 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A835845E35; Mon, 26 Apr 2010 21:10:20 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A04745E97; Mon, 26 Apr 2010 21:10:14 +0200 (CEST) Date: Mon, 26 Apr 2010 21:10:12 +0200 From: Pawel Jakub Dawidek To: "M. Warner Losh" Message-ID: <20100426191012.GA1711@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> <20100426.121946.506212773266921087.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20100426.121946.506212773266921087.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 19:10:24 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2010 at 12:19:46PM -0600, M. Warner Losh wrote: > In message: <20100426181209.GB3012@garage.freebsd.pl> > Pawel Jakub Dawidek writes: > : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: > : > I've read most of this thread. I think this is cool technology. > : > However, before we move forward with this, we need to have a plan for > : > the various issues that have come up. The plan needs to be specific, > : > have owners for key items, warnings about ownerless =3D=3D obsoleted,= and > : > target dates. > : >=20 > : > I think this is one of the cases where we should record the plan of > : > record on a wiki. It worked well for other times we've had big, > : > disruptive changes. > : >=20 > : > My opinion for the path forward: > : > (1) Send a big heads up about the future of ataraid(5). It will be > : > shot in the head soon, to be replaced be a bunch of geom classes > : > for each different container format. At least that seems to be > : > the rough consensus I've seen so far. We need worker bees to do > : > many of these classes, although much can be mined from the ataraid > : > code today. > :=20 > : This shouldn't be a bunch of GEOM classes. This should one class which > : recognize multiple formats, just like the LABEL class. > : I don't think it is feasible to reuse gmirror for that, it wasn't > : designed in something like this in mind. >=20 > OK. Maybe I got the consensus wrong... My key point is that we need > a plan moving forward, we need to identify what's actively being > worked on vs "somebody else[tm] should do tihs" and when it needs to > be done "or else". You most likely got it right, I'm just saying creating separate GEOM class for each metadata format is wrong direction. :) > : > (5) Issues with glabel and ataraid(5) need an owner, and need to be > : > resolved, since the device names here are likely to change. > :=20 > : What are the issues? >=20 > ataraid doesn't remove the underlying ad* devices, so glabel often > picks those up instead of the ataraid device, and you only get 1 > disk's worth of raid device... So no mirroring or only 1/2 a striped > volume. It not only leave ad* devices, it doesn't even open them properly using GEOM. It's internal ATA hack, which is PITA. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvV5RQACgkQForvXbEpPzTregCg0NfgcdQonjy4PBIFQ+7EQJsU Md8An1JWmyXVZuTwnO0xAqqVUrjXKDqo =K6k2 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 19:32: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 F17B41065675 for ; Mon, 26 Apr 2010 19:32:04 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 933448FC19 for ; Mon, 26 Apr 2010 19:32:03 +0000 (UTC) Received: from localhost (system.jails.se [87.237.210.209]) by system.jails.se (Postfix) with SMTP id 1CF7CB6244 for ; Mon, 26 Apr 2010 21:31:57 +0200 (CEST) Received: from pi.pean.org (c-ae06e155.166-7-64736c14.cust.bredbandsbolaget.se [85.225.6.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 0DA4DB6237; Mon, 26 Apr 2010 21:31:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <201004250951.19561.hselasky@c2i.net> Date: Mon, 26 Apr 2010 21:31:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <660B95EC-08D5-4D7B-B5C2-9E8AC97462C7@pean.org> References: <201004250951.19561.hselasky@c2i.net> To: Hans Petter Selasky , freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1078) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Apr 26 21:31:56 2010 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4bd5ea2c16291482959872 X-DSPAM-Factors: 27, solved+by, 0.40000, keymap, 0.40000, keymap, 0.40000, >>+choose, 0.40000, using+the, 0.40000, >>+installed, 0.40000, but, 0.40000, strncmp(sysenv+"MacBookPro1, 0.40000, strncmp(sysenv+"MacBookPro1, 0.40000, area+for, 0.40000, Received*cipher+AES128, 0.40000, Petter+Selasky, 0.40000, looks, 0.40000, Message-Id*<660B95EC+08D5, 0.40000, Cc*rpaulo+freebsd.org, 0.40000, Mime-Version*Message, 0.40000, Date*Apr, 0.40000, the+keyboard, 0.40000, the+keyboard, 0.40000, made, 0.40000, btw, 0.40000, newly+released, 0.40000, pressed+or, 0.40000, or, 0.40000, or, 0.40000, 13"+(7, 0.40000, ctrl+and, 0.40000 X-Mailman-Approved-At: Mon, 26 Apr 2010 19:51:08 +0000 Cc: Matthew Seaman , rpaulo@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Keyboard problem with new MacBook Pro. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Apr 2010 19:32:05 -0000 On 25 apr 2010, at 09.51, Hans Petter Selasky wrote: > On Sunday 25 April 2010 09:30:12 Peter Ankerst=E5l wrote: >> Hi, >>=20 >> I have the newly released macbook pro 13" (7,1). (swedish keyboard) = And it >> seems that I have some problem with the USB-keyboard driver. The = keyboard >> seems to work more or less in the boot meny, I can type and so on. = But >> when the system is booted the keyboard dosent work. It seems like = ctrl is >> constantly pressed or something like that. Nothing that I've done = gives me >> normal characters on screen. Its the FreeBSD 7.3 amd64 version i have >> installed btw. (8.0 or 9.0 freeezes during boot due to some = acpi-problem >> = http://wiki.freebsd.org/AppleMacbook#head-083ebc072fcd20e07a74a11565fc41af= >> b2ca099b) >>=20 >> I have got the keyboard to partially work when using the fixit cd. If = I >> choose US UNIX keymap first and then switch to some other keymap, say = US >> ISO och Swedish ISO it works to type but shift, ctrl and so on doesnt >> work. >=20 > Hi, >=20 > In 8-stable and 9-current, we have made several patches in the USB = keyboard=20 > area for Apple Keyboards, like supporting the eject key, swapping = keys, etc. >=20 > Regaring the boot issue with Mac, I think it can be solved by adding a = quirk=20 > in the kernel: >=20 > amd64/machdep.c: if (strncmp(sysenv, "MacBook1,1", 10) = =3D=3D 0 || > amd64/machdep.c: strncmp(sysenv, "MacBook3,1", 10) = =3D=3D 0 || > amd64/machdep.c: strncmp(sysenv, "MacBookPro1,1", = 13) =3D=3D 0=20 > || > amd64/machdep.c: strncmp(sysenv, "MacBookPro1,2", = 13) =3D=3D 0=20 > || > amd64/machdep.c: strncmp(sysenv, "MacBookPro3,1", = 13) =3D=3D 0=20 > || > amd64/pmap.c: if (strncmp(sysenv, "MacBook5,1", 10) = =3D=3D 0 || > amd64/pmap.c: strncmp(sysenv, "MacBookPro5,5", = 13) =3D=3D 0=20 > || >=20 > Similar for i386. >=20 > Could you print out your sysenv during boot and try adding your = MacBook to the=20 > quirk list? >=20 > --HPS >=20 Hi! I managed to get the boot-process past the ACPI-part by adding=20 similar lines like above (MacBookPro7,1) to the FreeBSD HEAD branch (as = of 26 April 19:00 CEST). Made a release iso like this: = http://romana.now.ie/writing/customfreebsdiso.html But now the boot-process panics at a later stage in the process and it = looks like this: http://www.pean.org/macbook_boot.jpg Any pointers?=20= From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 19:54: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 88DCB106566B; Mon, 26 Apr 2010 19:54:56 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBDD8FC13; Mon, 26 Apr 2010 19:54:56 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (85-142-52-164.well-com.net [85.142.52.164]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 0B2D013DF5D; Mon, 26 Apr 2010 23:48:17 +0400 (MSD) Date: Mon, 26 Apr 2010 23:48:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <609355278.20100426234808@serebryakov.spb.ru> To: Pawel Jakub Dawidek In-Reply-To: <20100426191012.GA1711@garage.freebsd.pl> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> <20100426.121946.506212773266921087.imp@bsdimp.com> <20100426191012.GA1711@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, "M. Warner Losh" , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 19:54:56 -0000 Hello, Pawel. You wrote 26 =E0=EF=F0=E5=EB=FF 2010 =E3., 23:10:12: > You most likely got it right, I'm just saying creating separate GEOM > class for each metadata format is wrong direction. :) Does ataraid translations and checksuming (in case of RAID5) now or it configures chipsets only? All these ``raids'' are known as ``soft raids'' or ``fake raids'', but what does do real work -- BIOS or driver (Ataraid in case of FreeBSD)? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 02:37: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 58AE5106564A; Tue, 27 Apr 2010 02:37:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C271D8FC13; Tue, 27 Apr 2010 02:37:39 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o3R2bDwB035377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Apr 2010 12:07:19 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=koi8-r From: "Daniel O'Connor" X-Priority: 3 (Normal) In-Reply-To: <609355278.20100426234808@serebryakov.spb.ru> Date: Tue, 27 Apr 2010 12:07:13 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <035A6E1D-6537-476B-9427-52072E60C41D@gsoft.com.au> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <20100426181209.GB3012@garage.freebsd.pl> <20100426.121946.506212773266921087.imp@bsdimp.com> <20100426191012.GA1711@garage.freebsd.pl> <609355278.20100426234808@serebryakov.spb.ru> To: lev@freebsd.org X-Mailer: Apple Mail (2.1078) X-Spam-Score: -2.431 () ALL_TRUSTED,AWL,BAYES_00,MIME_CHARSET_FARAWAY X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: mav@freebsd.org, freebsd-current@freebsd.org, Pawel Jakub Dawidek , "M. Warner Losh" , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 02:37:40 -0000 On 27/04/2010, at 5:18 AM, Lev Serebryakov wrote: > Hello, Pawel. > You wrote 26 =C1=D0=D2=C5=CC=D1 2010 =C7., 23:10:12: >=20 >> You most likely got it right, I'm just saying creating separate GEOM >> class for each metadata format is wrong direction. :) > Does ataraid translations and checksuming (in case of RAID5) now or > it configures chipsets only? >=20 > All these ``raids'' are known as ``soft raids'' or ``fake raids'', > but what does do real work -- BIOS or driver (Ataraid in case of > FreeBSD)? Both.. ataraid does it when FreeBSD is running but the BIOS does it before then = so boot0, the loader, et al can read the disk without having an = underlying driver. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 04:50: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 C022F1065672; Tue, 27 Apr 2010 04:50:56 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas04p.mx.bigpond.com (nschwmtas04p.mx.bigpond.com [61.9.189.146]) by mx1.freebsd.org (Postfix) with ESMTP id 01AE78FC15; Tue, 27 Apr 2010 04:50:55 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20100427045054.MHBU9850.nschwmtas04p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Tue, 27 Apr 2010 04:50:54 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100427045054.EAPH2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Tue, 27 Apr 2010 04:50:54 +0000 Date: Tue, 27 Apr 2010 14:50:53 +1000 From: Andrew Reilly To: Alexander Best Message-ID: <20100427045053.GA64971@duncan.reilly.home> References: <20100424080533.GA77435@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Tue, 27 Apr 2010 04:50:54 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4BD66D2E.00ED,ss=1,fgs=0 X-SIH-MSG-ID: rRw7FNX/TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHNvZRsM6kxDxLJhqBNGQgaangTY3Rs9mK Cc: freebsd-multimedia@freebsd.org, Roman Divacky , freebsd-current@FreeBSD.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 04:50:56 -0000 On Sun, Apr 25, 2010 at 12:06:49PM +0200, Alexander Best wrote: > i was able to pinpoint the > exact function which is causing the problem: > > it's snd_xbytes(). This is an odd-looking function. Its purpose is to compute the size of a target buffer for a block of audio samples that might be sample-rate-converted or format changed. It has a loop to compute the gcd of the second two arguments (from, to), so that it can divide by that common factor so that it can then do v * (to/x) / (from/x). It's not immediately obvious to me why it bothers to find the gcd, since the division by the original from should work anyway, as it's using a 64-bit numerator... The only difference that I can see when this is compiled with cc vs clang on my amd64 system is that the latter uses a divq in the loop and the former uses a divl. I haven't figured out why, yet. Hmm. If the same division logic is being used in the i386 version of clang, then it's possible that this is resulting in a call to an extended precision divide subroutine, which could slow things down a bit. Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 05:53: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 C30ED106566C for ; Tue, 27 Apr 2010 05:53:43 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A00B88FC12 for ; Tue, 27 Apr 2010 05:53:43 +0000 (UTC) Received: by pxi17 with SMTP id 17so2089490pxi.13 for ; Mon, 26 Apr 2010 22:53:37 -0700 (PDT) Received: by 10.142.202.5 with SMTP id z5mr2653737wff.296.1272347616827; Mon, 26 Apr 2010 22:53:36 -0700 (PDT) Received: from [10.0.1.198] ([72.14.240.14]) by mx.google.com with ESMTPS id 20sm50701pzk.15.2010.04.26.22.53.34 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 22:53:35 -0700 (PDT) Date: Mon, 26 Apr 2010 19:53:36 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Vladimir Grebenschikov In-Reply-To: <1272292774.2424.38.camel@localhost> Message-ID: References: <1272292774.2424.38.camel@localhost> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today - panic on rename() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 05:53:43 -0000 On Mon, 26 Apr 2010, Vladimir Grebenschikov wrote: > Hi > > First, many thanks for this effort, it is really very appreciated, > > Panic on Gnome starting: Thank you for the report with stack. That was very helpful. I know how to fix this bug but it will take me a day or two as my primary test machine seems to have died. For now you will have to tunefs -j disable on that volume. Thanks, Jeff > > # kgdb -q /usr/obj/usr/src/sys/VBOOK/kernel.debug /var/crash/vmcore.12 > ... > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) x/s panicstr > 0xc07c2160 : "remove_from_journal: 0xc581ec40 is not in journal" > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc056b883 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xc056babd in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 0xc0488ba9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1065321792, dummy4=0xd90d572c "") at /usr/src/sys/ddb/db_command.c:548 > #4 0xc0488fa1 in db_command (last_cmdp=0xc07abb1c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #5 0xc04890fa in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #6 0xc048af7d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 > #7 0xc0597f54 in kdb_trap (type=3, code=0, tf=0xd90d58c4) at /usr/src/sys/kern/subr_kdb.c:535 > #8 0xc06f842e in trap (frame=0xd90d58c4) at /usr/src/sys/i386/i386/trap.c:694 > #9 0xc06dcf7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0xc05980ba in kdb_enter (why=0xc0747a43 "panic", msg=0xc0747a43 "panic") at cpufunc.h:71 > #11 0xc056baa1 in panic (fmt=0xc0755fee "remove_from_journal: %p is not in journal") at /usr/src/sys/kern/kern_shutdown.c:573 > #12 0xc0672135 in remove_from_journal (wk=0xc0c3ec2f) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2204 > #13 0xc067e273 in cancel_jaddref (jaddref=0xc581ec40, inodedep=0xc5c58700, wkhd=0xc5c5875c) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3336 > #14 0xc067f163 in softdep_revert_link (dp=0xc681f9f8, ip=0xc681f910) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3871 > #15 0xc0697fd0 in ufs_rename (ap=0xd90d5c1c) at /usr/src/sys/ufs/ufs/ufs_vnops.c:1546 > #16 0xc070ead6 in VOP_RENAME_APV (vop=0xc0796340, a=0xd90d5c1c) at vnode_if.c:1474 > #17 0xc05f2902 in kern_renameat (td=0xc586e8c0, oldfd=-100, old=0x4856ca30
, newfd=-100, > new=0x4856ca90
, pathseg=UIO_USERSPACE) at vnode_if.h:636 > #18 0xc05f29b6 in kern_rename (td=0xc586e8c0, from=0x4856ca30
, to=0x4856ca90
, pathseg=UIO_USERSPACE) > at /usr/src/sys/kern/vfs_syscalls.c:3574 > #19 0xc05f29e9 in rename (td=0xc586e8c0, uap=0xd90d5cf8) at /usr/src/sys/kern/vfs_syscalls.c:3551 > #20 0xc06f7c49 in syscall (frame=0xd90d5d38) at /usr/src/sys/i386/i386/trap.c:1113 > #21 0xc06dcfe0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #22 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > Just after fsck -y && tunefs -j enable for both / and /usr in > single-user mode and then usual boot > > panic is reproducible > > > -- > Vladimir B. Grebenschikov > vova@fbsd.ru > From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 05:55: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 9F5501065673 for ; Tue, 27 Apr 2010 05:55:05 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA928FC14 for ; Tue, 27 Apr 2010 05:55:05 +0000 (UTC) Received: by pvc21 with SMTP id 21so808392pvc.13 for ; Mon, 26 Apr 2010 22:55:02 -0700 (PDT) Received: by 10.140.82.42 with SMTP id f42mr5091414rvb.146.1272347702437; Mon, 26 Apr 2010 22:55:02 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 20sm3725889iwn.1.2010.04.26.22.55.00 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 22:55:01 -0700 (PDT) Date: Mon, 26 Apr 2010 19:55:02 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Lucius Windschuh In-Reply-To: Message-ID: References: <4BD35437.2060208@lissyara.su> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 05:55:05 -0000 On Sun, 25 Apr 2010, Lucius Windschuh wrote: > Hi Jeff, > thank you for your effort in implementing the soft update journaling. > I tried to test SUJ on a provider with 4 kB block size. My system runs > 9-CURRENT r207195 (i386). > Unfortunately, tunefs is unable to cope with the device. It can easily > reproduced with these steps: > > # mdconfig -s 128M -S 4096 > 0 > # newfs -U /dev/md0 Thanks for the repro. This is an interesting case. I'll have to slightly rewrite the directory handling code in tunefs but it should not take long. Thanks, Jeff > /dev/md0: 128.0MB (262144 sectors) block size 16384, fragment size 4096 > using 4 cylinder groups of 32.02MB, 2049 blks, 2112 inodes. > with soft updates > # tunefs -j enable /dev/md0 > Using inode 4 in cg 0 for 4194304 byte journal > tunefs: Failed to read dir block: Invalid argument > tunefs: soft updates journaling can not be enabled > > The bread() in tunefs.c:701 fails as the requested block size (512) is > smaller than the provider's block size (4096 bytes). > > As a simply attempt to fix it, I changed tunefs.c:760 to " if > (dir_extend(blk, nblk, size, ino) == -1)", as I thought that this made > more sense. Then, tunefs succeeded, but mounting the file system > resulted in a panic: > panic: ufs_dirbad: /mnt/md-test: bad dir ino 2 at offset 512: mangled entry > > db:0:kdb.enter.default> bt > Tracing pid 2714 tid 100262 td 0xc7ea6480 > kdb_enter(c0a21226,c0a21226,c0a49886,eb1e6714,0,...) at kdb_enter+0x3a > panic(c0a49886,c688f468,2,200,c0a498df,...) at panic+0x136 > ufs_dirbad(c81bb000,200,c0a498df,0,eb1e67b0,...) at ufs_dirbad+0x46 > ufs_lookup_ino(c81d5990,0,eb1e67d8,eb1e6800,0,...) at ufs_lookup_ino+0x367 > softdep_journal_lookup(c688f288,eb1e68c4,c0a45eca,750,eb1e6834,...) at > softdep_journal_lookup+0xb0 > softdep_mount(c7e3fbb0,c688f288,c8165000,c7bdf900,c7bdf900,...) at > softdep_mount+0xdb > ffs_mount(c688f288,0,c0a2df89,3d6,0,...) at ffs_mount+0x23e1 > vfs_donmount(c7ea6480,0,c7bc6100,c7bc6100,c8031000,...) at vfs_donmount+0x1000 > nmount(c7ea6480,eb1e6cf8,c,c,207,...) at nmount+0x64 > syscall(eb1e6d38) at syscall+0x1da > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280f205b, esp = > 0xbfbfdcec, ebp = 0xbfbfe248 --- > > ... so this attempt did not succeed, but was worth a try ;-) > > But it would be nice to use SUJ even on such a unusual configuration. > > Lucius > From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 05:55:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C0B31065672; Tue, 27 Apr 2010 05:55:39 +0000 (UTC) (envelope-from LukeD@pobox.com) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 21C038FC14; Tue, 27 Apr 2010 05:55:38 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 77256AEBA3; Tue, 27 Apr 2010 01:39:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :reply-to:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=sasl; bh=jzcgKvEzBB2Y7OPElAHOjGd7h XA=; b=we6efP3X6TJa44wjGWgDRoSAvFaPG/9mc/tdrtCpPepYxPS4sZmcvKa3V 1udrnrTJyno73zQ5Wu9cZopBqI6xrVl6WIFHR4nKNr5biJ/yXzH9XA+6WZ/z0Umc 5MuWfHAHVZaWV2W+Xf6LTtp45zuzY4HhgjR9er6TD7dkUw4Clg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :reply-to:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; q=dns; s=sasl; b=q6ZCGkyJvyFNwimYaAV t921/GFe4mzlvoi59hHUG3jECYlj5qQZQTiUVlQ3eGXyj6FkAf2y0iO2HjooEt0h DCJuBUVIt0Z2Px2HZbsLp52vgd+Z7LKv4OKQlXboSvaOQDZFQ8wTK3UmBYrWh1Ss /AkqFpYD7sug4jjTgCTbIGRE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 538E0AEB9E; Tue, 27 Apr 2010 01:39:09 -0400 (EDT) Received: from lukas.is-a-geek.org (unknown [71.112.198.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 712E7AEB9D; Tue, 27 Apr 2010 01:39:06 -0400 (EDT) Date: Mon, 26 Apr 2010 22:39:02 -0700 (PDT) From: Luke Dean X-X-Sender: lukas@border.lukas.is-a-geek.org To: Alexander Motin In-Reply-To: <4BD06BD9.6030401@FreeBSD.org> Message-ID: References: <4BD06BD9.6030401@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Pobox-Relay-ID: 33BE711E-51BF-11DF-AD23-D033EE7EF46B-96347044!a-pb-sasl-quonix.pobox.com Cc: FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Luke Dean List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 05:55:39 -0000 On Thu, 22 Apr 2010, Alexander Motin wrote: > So what is the public opinion: Is the lack of ataraid(4) fatal or we can > live without it? Hardware mirroring is very important to me. It's the only solution I'm aware of for realtime protection from drive failure in systems that boot multiple operating systems. From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 05:56: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 C17AA1065674 for ; Tue, 27 Apr 2010 05:56:46 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D31A8FC13 for ; Tue, 27 Apr 2010 05:56:46 +0000 (UTC) Received: by pvc21 with SMTP id 21so809220pvc.13 for ; Mon, 26 Apr 2010 22:56:41 -0700 (PDT) Received: by 10.141.213.23 with SMTP id p23mr5168649rvq.159.1272347782216; Mon, 26 Apr 2010 22:56:22 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 22sm3713934iwn.8.2010.04.26.22.56.19 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 22:56:21 -0700 (PDT) Date: Mon, 26 Apr 2010 19:56:21 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Gary Jennejohn In-Reply-To: <20100425132413.44d66b10@ernst.jennejohn.org> Message-ID: References: <4BD35437.2060208@lissyara.su> <20100425132413.44d66b10@ernst.jennejohn.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 05:56:46 -0000 On Sun, 25 Apr 2010, Gary Jennejohn wrote: > On Sat, 24 Apr 2010 16:57:59 -1000 (HST) > Jeff Roberson wrote: > >> On Sun, 25 Apr 2010, Alex Keda wrote: >> >>> try in single user mode: >>> >>> tunefs -j enable / >>> tunefs: Insuffient free space for the journal >>> tunefs: soft updates journaling can not be enabled >>> >>> tunefs -j enable /dev/ad0s2a >>> tunefs: Insuffient free space for the journal >>> tunefs: soft updates journaling can not be enabled >>> tunefs: /dev/ad0s2a: failed to write superblock >> >> There is a bug that prevents enabling journaling on a mounted filesystem. >> So for now you can't enable it on /. I see that you have a large / volume >> but in general I would also suggest people not enable suj on / anyway as >> it's typically not very large. I only run it on my /usr and /home >> filesystems. >> >> I will send a mail out when I figure out why tunefs can't enable suj on / >> while it is mounted read-only. >> > > Jeff - > One thing which surprised me was that I couldn't reuse the existing > .sujournal files on my disks. I did notice that there are now more > flags set on them. Was that the reason? Or were you just being > careful? There were a few iterations of the code to create and discover the actual journal inode. I may have introduced an incompatibility when making fsck more careful about what it treats as a journal. If it were to attempt to apply changes from a garbage file it could corrupt your filesystem. Thanks, Jeff > > -- > Gary Jennejohn > From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 05:59: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 50067106564A for ; Tue, 27 Apr 2010 05:59:33 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9598FC08 for ; Tue, 27 Apr 2010 05:59:32 +0000 (UTC) Received: by pvc21 with SMTP id 21so810531pvc.13 for ; Mon, 26 Apr 2010 22:59:29 -0700 (PDT) Received: by 10.143.85.10 with SMTP id n10mr2625663wfl.106.1272347969467; Mon, 26 Apr 2010 22:59:29 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 22sm3719333iwn.4.2010.04.26.22.59.27 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 22:59:28 -0700 (PDT) Date: Mon, 26 Apr 2010 19:59:29 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Scott Long In-Reply-To: <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> Message-ID: References: r2x7d6fde3d1004210606o25fdf542j42cb5fdef75991e2@mail.gmail.com <4BD35437.2060208@lissyara.su> <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 05:59:33 -0000 On Sun, 25 Apr 2010, Scott Long wrote: > On Apr 24, 2010, at 8:57 PM, Jeff Roberson wrote: >> On Sun, 25 Apr 2010, Alex Keda wrote: >> >>> try in single user mode: >>> >>> tunefs -j enable / >>> tunefs: Insuffient free space for the journal >>> tunefs: soft updates journaling can not be enabled >>> >>> tunefs -j enable /dev/ad0s2a >>> tunefs: Insuffient free space for the journal >>> tunefs: soft updates journaling can not be enabled >>> tunefs: /dev/ad0s2a: failed to write superblock >> >> There is a bug that prevents enabling journaling on a mounted filesystem. So for now you can't enable it on /. I see that you have a large / volume but in general I would also suggest people not enable suj on / anyway as it's typically not very large. I only run it on my /usr and /home filesystems. >> >> I will send a mail out when I figure out why tunefs can't enable suj on / while it is mounted read-only. >> > > This would preclude enabling journaling on / on an existing system, but I would think that you could enable it on / on a system that is being installed, since (at least in theory) the target / filesystem won't be the actual root of the system, and therefore can be unmounted at will. That's definitely true. Some users have had mixed success enabling it on /. It looks like it is a bug either in g_access or ffs's use of g_access which does not allow tunefs to write after a downgrade. I'm not yet sure how this is presently working for the softdep flag itself, or if it actually is at all. To clarify my earlier statements: Journaling only makes sense when the fsck time is longer than a few tens of seconds. So volumes less than a gig or two don't really need journaling. It just costs extra writes and fsck time will likely be similar. In some pathological cases it can even be faster to fsck a small volume than it is to run the journal recovery on it. Thanks, Jeff > > Scott > From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 06:00: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 009D71065674 for ; Tue, 27 Apr 2010 06:00:57 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF3C88FC0A for ; Tue, 27 Apr 2010 06:00:56 +0000 (UTC) Received: by pvc21 with SMTP id 21so811191pvc.13 for ; Mon, 26 Apr 2010 23:00:51 -0700 (PDT) Received: by 10.141.124.13 with SMTP id b13mr4779016rvn.284.1272348051350; Mon, 26 Apr 2010 23:00:51 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 23sm3722997iwn.2.2010.04.26.23.00.48 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 23:00:50 -0700 (PDT) Date: Mon, 26 Apr 2010 20:00:50 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Bruce Cran In-Reply-To: <201004251955.03492.bruce@cran.org.uk> Message-ID: References: <4BD35437.2060208@lissyara.su> <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> <201004251955.03492.bruce@cran.org.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 06:00:57 -0000 On Sun, 25 Apr 2010, Bruce Cran wrote: > On Sunday 25 April 2010 19:47:00 Scott Long wrote: >> On Apr 24, 2010, at 8:57 PM, Jeff Roberson wrote: >>> On Sun, 25 Apr 2010, Alex Keda wrote: >>>> try in single user mode: >>>> >>>> tunefs -j enable / >>>> tunefs: Insuffient free space for the journal >>>> tunefs: soft updates journaling can not be enabled >>>> >>>> tunefs -j enable /dev/ad0s2a >>>> tunefs: Insuffient free space for the journal >>>> tunefs: soft updates journaling can not be enabled >>>> tunefs: /dev/ad0s2a: failed to write superblock >>> >>> There is a bug that prevents enabling journaling on a mounted filesystem. >>> So for now you can't enable it on /. I see that you have a large / >>> volume but in general I would also suggest people not enable suj on / >>> anyway as it's typically not very large. I only run it on my /usr and >>> /home filesystems. >>> >>> I will send a mail out when I figure out why tunefs can't enable suj on / >>> while it is mounted read-only. >> >> This would preclude enabling journaling on / on an existing system, but I >> would think that you could enable it on / on a system that is being >> installed, since (at least in theory) the target / filesystem won't be the >> actual root of the system, and therefore can be unmounted at will. > > It worked here - it's shown as enabled after I booted in single-user mode and > enabled it yesterday: I think some people are enabling after returning to single user from a live system rather than booting into single user. This is a different path in the filesystem as booting directly just mounts read-only while the other option updates a mount from read/write. I believe this is the path that is broken. Thanks, Jeff > > core# dumpfs / | grep -i journal > flags soft-updates+journal > > -- > Bruce Cran > From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 06:01:32 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 2FA69106566B for ; Tue, 27 Apr 2010 06:01:32 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF7D8FC15 for ; Tue, 27 Apr 2010 06:01:31 +0000 (UTC) Received: by pwi9 with SMTP id 9so9267212pwi.13 for ; Mon, 26 Apr 2010 23:01:29 -0700 (PDT) Received: by 10.142.117.27 with SMTP id p27mr2598856wfc.252.1272348088972; Mon, 26 Apr 2010 23:01:28 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 21sm3717633iwn.7.2010.04.26.23.01.26 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 23:01:27 -0700 (PDT) Date: Mon, 26 Apr 2010 20:01:28 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: pluknet In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dikshie , current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 06:01:32 -0000 On Mon, 26 Apr 2010, pluknet wrote: > On 26 April 2010 17:42, dikshie wrote: >> Hi Jeff, >> thanks for SUJ. >> btw, why there is nan% utilization? and what does it mean? >> -------------- >> ** SU+J Recovering /dev/ad0s1g >> ** Reading 33554432 byte journal from inode 4. >> ** Building recovery table. >> ** Resolving unreferenced inode list. >> ** Processing journal entries. >> ** 0 journal records in 0 bytes for nan% utilization <==== >> ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. >> -------------- >> > > That may be due to an empty journal (the only plausible version for me), > so jrecs and jblocks are not updated. Yes, this is it exactly. It's a simple bug, I will post a fix in the next few days. Thanks, Jeff > > /* Next ensure that segments are ordered properly. */ > seg = TAILQ_FIRST(&allsegs); > if (seg == NULL) { > if (debug) > printf("Empty journal\n"); > return; > } > > -- > wbr, > pluknet > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 06:22: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 CDF35106566C for ; Tue, 27 Apr 2010 06:22:11 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 9769C8FC13 for ; Tue, 27 Apr 2010 06:22:09 +0000 (UTC) Received: from mobileKamikaze.norad (vpn-cl-162-223.rz.uni-karlsruhe.de [141.3.162.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 541BE8A1BD3; Tue, 27 Apr 2010 08:21:44 +0200 (CEST) Message-ID: <4BD68275.6020509@bsdforen.de> Date: Tue, 27 Apr 2010 08:21:41 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rdivacky@freebsd.org Subject: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 06:22:12 -0000 Hello, I wanted to make some performance comparisons, building ClangBSD with different compilers. The host system is: FreeBSD mobileKamikaze.norad 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Apr 5 12:45:41 CEST 2010 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 An interesting result is that buildkernel with clang takes longer: CC=clang time -l make buildkernel 921.31 real 802.25 user 114.93 sys time -l make buildkernel -j3 645.17 real 838.46 user 143.03 sys CC=cc time -l make buildkernel 877.14 real 757.42 user 115.11 sys time -l make buildkernel -j3 628.32 real 798.03 user 149.52 sys All the tests are run on a 4g memory disk (src and objdir), which is recreated for every test. I cannot make this comparison for buildworld, because buildworld with CC=cc, CXX=c++ fails: ===> usr.bin/clang/lib/libclanglex (all) c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONS TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:39: /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:63:18: error: use of undeclared identifier '__builtin_ia32_vec_init_v2si' return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:106:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2si' return __builtin_ia32_vec_ext_v2si ((__v2si)__i, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:189:18: error: use of undeclared identifier '__builtin_ia32_punpckhbw' return (__m64) __builtin_ia32_punpckhbw ((__v8qi)__m1, (__v8qi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:203:18: error: use of undeclared identifier '__builtin_ia32_punpckhwd' return (__m64) __builtin_ia32_punpckhwd ((__v4hi)__m1, (__v4hi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:217:18: error: use of undeclared identifier '__builtin_ia32_punpckhdq' return (__m64) __builtin_ia32_punpckhdq ((__v2si)__m1, (__v2si)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:231:18: error: use of undeclared identifier '__builtin_ia32_punpcklbw' return (__m64) __builtin_ia32_punpcklbw ((__v8qi)__m1, (__v8qi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:259:18: error: use of undeclared identifier '__builtin_ia32_punpckldq' return (__m64) __builtin_ia32_punpckldq ((__v2si)__m1, (__v2si)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:272:18: error: use of undeclared identifier '__builtin_ia32_paddb' return (__m64) __builtin_ia32_paddb ((__v8qi)__m1, (__v8qi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:285:18: error: use of undeclared identifier '__builtin_ia32_paddw' return (__m64) __builtin_ia32_paddw ((__v4hi)__m1, (__v4hi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:298:18: error: use of undeclared identifier '__builtin_ia32_paddd' return (__m64) __builtin_ia32_paddd ((__v2si)__m1, (__v2si)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:312:18: error: use of undeclared identifier '__builtin_ia32_paddq' return (__m64) __builtin_ia32_paddq ((long long)__m1, (long long)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:376:18: error: use of undeclared identifier '__builtin_ia32_psubb' return (__m64) __builtin_ia32_psubb ((__v8qi)__m1, (__v8qi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:389:18: error: use of undeclared identifier '__builtin_ia32_psubw' return (__m64) __builtin_ia32_psubw ((__v4hi)__m1, (__v4hi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:402:18: error: use of undeclared identifier '__builtin_ia32_psubd' return (__m64) __builtin_ia32_psubd ((__v2si)__m1, (__v2si)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:416:18: error: use of undeclared identifier '__builtin_ia32_psubq' return (__m64) __builtin_ia32_psubq ((long long)__m1, (long long)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:510:18: error: use of undeclared identifier '__builtin_ia32_pmullw' return (__m64) __builtin_ia32_pmullw ((__v4hi)__m1, (__v4hi)__m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:523:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psllw ((__v4hi)__m, (long long)__count); ^~~~~~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:535:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an lvalue of type 'int' return (__m64) __builtin_ia32_psllw ((__v4hi)__m, __count); ^~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:548:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_pslld ((__v2si)__m, (long long)__count); ^~~~~~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:560:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an lvalue of type 'int' return (__m64) __builtin_ia32_pslld ((__v2si)__m, __count); ^~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:573:40: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psllq ((long long)__m, (long long)__count); ^~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:585:40: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psllq ((long long)__m, (long long)__count); ^~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:598:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psraw ((__v4hi)__m, (long long)__count); ^~~~~~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:610:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an lvalue of type 'int' return (__m64) __builtin_ia32_psraw ((__v4hi)__m, __count); ^~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:623:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psrad ((__v2si)__m, (long long)__count); ^~~~~~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:635:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an lvalue of type 'int' return (__m64) __builtin_ia32_psrad ((__v2si)__m, __count); ^~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:648:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psrlw ((__v4hi)__m, (long long)__count); ^~~~~~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:660:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an lvalue of type 'int' return (__m64) __builtin_ia32_psrlw ((__v4hi)__m, __count); ^~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:673:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psrld ((__v2si)__m, (long long)__count); ^~~~~~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:685:53: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an lvalue of type 'int' return (__m64) __builtin_ia32_psrld ((__v2si)__m, __count); ^~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:698:40: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psrlq ((long long)__m, (long long)__count); ^~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:710:40: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long' with an rvalue of type 'long long' return (__m64) __builtin_ia32_psrlq ((long long)__m, (long long)__count); ^~~~~~~~~~~~~~ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:723:10: error: use of undeclared identifier '__builtin_ia32_pand' return __builtin_ia32_pand (__m1, __m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:737:10: error: use of undeclared identifier '__builtin_ia32_pandn' return __builtin_ia32_pandn (__m1, __m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:750:10: error: use of undeclared identifier '__builtin_ia32_por' return __builtin_ia32_por (__m1, __m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:763:10: error: use of undeclared identifier '__builtin_ia32_pxor' return __builtin_ia32_pxor (__m1, __m2); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:861:18: error: use of undeclared identifier '__builtin_ia32_vec_init_v2si' return (__m64) __builtin_ia32_vec_init_v2si (__i0, __i1); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:868:18: error: use of undeclared identifier '__builtin_ia32_vec_init_v4hi' return (__m64) __builtin_ia32_vec_init_v4hi (__w0, __w1, __w2, __w3); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:876:18: error: use of undeclared identifier '__builtin_ia32_vec_init_v8qi' return (__m64) __builtin_ia32_vec_init_v8qi (__b0, __b1, __b2, __b3, ^ In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:42: /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mm_malloc.h:37:16: error: exception specification in declaration does not match previous declaration extern "C" int posix_memalign (void **, size_t, size_t) throw (); ^ In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:27: In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include/clang/Lex/Lexer.h:17: In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include/clang/Lex/PreprocessorLexer.h:18: In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include/clang/Lex/Token.h:21: In file included from /usr/include/c++/4.2/cstdlib:71: /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/stdlib.h:156:6: note: previous declaration is here int posix_memalign(void **, size_t, size_t); /* (ADV) */ ^ In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:105:19: error: use of undeclared identifier '__builtin_ia32_addss' return (__m128) __builtin_ia32_addss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:111:19: error: use of undeclared identifier '__builtin_ia32_subss' return (__m128) __builtin_ia32_subss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:117:19: error: use of undeclared identifier '__builtin_ia32_mulss' return (__m128) __builtin_ia32_mulss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:123:19: error: use of undeclared identifier '__builtin_ia32_divss' return (__m128) __builtin_ia32_divss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:161:19: error: use of undeclared identifier '__builtin_ia32_addps' return (__m128) __builtin_ia32_addps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:167:19: error: use of undeclared identifier '__builtin_ia32_subps' return (__m128) __builtin_ia32_subps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:173:19: error: use of undeclared identifier '__builtin_ia32_mulps' return (__m128) __builtin_ia32_mulps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:179:19: error: use of undeclared identifier '__builtin_ia32_divps' return (__m128) __builtin_ia32_divps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:217:10: error: use of undeclared identifier '__builtin_ia32_andps' return __builtin_ia32_andps (__A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:223:10: error: use of undeclared identifier '__builtin_ia32_andnps' return __builtin_ia32_andnps (__A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:229:10: error: use of undeclared identifier '__builtin_ia32_orps' return __builtin_ia32_orps (__A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:235:10: error: use of undeclared identifier '__builtin_ia32_xorps' return __builtin_ia32_xorps (__A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:245:19: error: use of undeclared identifier '__builtin_ia32_cmpeqss' return (__m128) __builtin_ia32_cmpeqss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:251:19: error: use of undeclared identifier '__builtin_ia32_cmpltss' return (__m128) __builtin_ia32_cmpltss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:257:19: error: use of undeclared identifier '__builtin_ia32_cmpless' return (__m128) __builtin_ia32_cmpless ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:265:6: error: use of undeclared identifier '__builtin_ia32_cmpltss' __builtin_ia32_cmpltss ((__v4sf) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:275:6: error: use of undeclared identifier '__builtin_ia32_cmpless' __builtin_ia32_cmpless ((__v4sf) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:283:19: error: use of undeclared identifier '__builtin_ia32_cmpneqss' return (__m128) __builtin_ia32_cmpneqss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:289:19: error: use of undeclared identifier '__builtin_ia32_cmpnltss' return (__m128) __builtin_ia32_cmpnltss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:295:19: error: use of undeclared identifier '__builtin_ia32_cmpnless' return (__m128) __builtin_ia32_cmpnless ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:303:6: error: use of undeclared identifier '__builtin_ia32_cmpnltss' __builtin_ia32_cmpnltss ((__v4sf) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:313:6: error: use of undeclared identifier '__builtin_ia32_cmpnless' __builtin_ia32_cmpnless ((__v4sf) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:321:19: error: use of undeclared identifier '__builtin_ia32_cmpordss' return (__m128) __builtin_ia32_cmpordss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:327:19: error: use of undeclared identifier '__builtin_ia32_cmpunordss' return (__m128) __builtin_ia32_cmpunordss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:337:19: error: use of undeclared identifier '__builtin_ia32_cmpeqps' return (__m128) __builtin_ia32_cmpeqps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:343:19: error: use of undeclared identifier '__builtin_ia32_cmpltps' return (__m128) __builtin_ia32_cmpltps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:349:19: error: use of undeclared identifier '__builtin_ia32_cmpleps' return (__m128) __builtin_ia32_cmpleps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:355:19: error: use of undeclared identifier '__builtin_ia32_cmpgtps' return (__m128) __builtin_ia32_cmpgtps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:361:19: error: use of undeclared identifier '__builtin_ia32_cmpgeps' return (__m128) __builtin_ia32_cmpgeps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:367:19: error: use of undeclared identifier '__builtin_ia32_cmpneqps' return (__m128) __builtin_ia32_cmpneqps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:373:19: error: use of undeclared identifier '__builtin_ia32_cmpnltps' return (__m128) __builtin_ia32_cmpnltps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:379:19: error: use of undeclared identifier '__builtin_ia32_cmpnleps' return (__m128) __builtin_ia32_cmpnleps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:385:19: error: use of undeclared identifier '__builtin_ia32_cmpngtps' return (__m128) __builtin_ia32_cmpngtps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:391:19: error: use of undeclared identifier '__builtin_ia32_cmpngeps' return (__m128) __builtin_ia32_cmpngeps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:397:19: error: use of undeclared identifier '__builtin_ia32_cmpordps' return (__m128) __builtin_ia32_cmpordps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:403:19: error: use of undeclared identifier '__builtin_ia32_cmpunordps' return (__m128) __builtin_ia32_cmpunordps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:532:10: error: use of undeclared identifier '__builtin_ia32_cvttss2si' return __builtin_ia32_cvttss2si ((__v4sf) __A); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:548:10: error: use of undeclared identifier '__builtin_ia32_cvttss2si64' return __builtin_ia32_cvttss2si64 ((__v4sf) __A); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:555:10: error: use of undeclared identifier '__builtin_ia32_cvttss2si64' return __builtin_ia32_cvttss2si64 ((__v4sf) __A); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:577:19: error: use of undeclared identifier '__builtin_ia32_cvtsi2ss' return (__m128) __builtin_ia32_cvtsi2ss ((__v4sf) __A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:593:19: error: use of undeclared identifier '__builtin_ia32_cvtsi642ss' return (__m128) __builtin_ia32_cvtsi642ss ((__v4sf) __A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:600:19: error: use of undeclared identifier '__builtin_ia32_cvtsi642ss' return (__m128) __builtin_ia32_cvtsi642ss ((__v4sf) __A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:632:21: error: use of undeclared identifier '__builtin_ia32_punpckhwd' __hisi = (__v2si) __builtin_ia32_punpckhwd ((__v4hi)__A, __sign); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:638:9: error: use of undeclared identifier '__builtin_ia32_movlhps' __r = __builtin_ia32_movlhps (__r, __r); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:652:21: error: use of undeclared identifier '__builtin_ia32_punpckhwd' __hisi = (__v2si) __builtin_ia32_punpckhwd ((__v4hi)__A, (__v4hi)0LL); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:658:9: error: use of undeclared identifier '__builtin_ia32_movlhps' __r = __builtin_ia32_movlhps (__r, __r); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:676:17: error: use of undeclared identifier '__builtin_ia32_punpcklbw' __A = (__m64) __builtin_ia32_punpcklbw ((__v8qi)__A, __sign); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:685:17: error: use of undeclared identifier '__builtin_ia32_punpcklbw' __A = (__m64) __builtin_ia32_punpcklbw ((__v8qi)__A, (__v8qi)0LL); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:696:19: error: use of undeclared identifier '__builtin_ia32_movlhps' return (__m128) __builtin_ia32_movlhps (__sfa, __sfb); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:704:19: error: use of undeclared identifier '__builtin_ia32_movhlps' __v4sf __losf = __builtin_ia32_movhlps (__hisf, __hisf); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:735:19: error: use of undeclared identifier '__builtin_ia32_unpckhps' return (__m128) __builtin_ia32_unpckhps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:742:19: error: use of undeclared identifier '__builtin_ia32_unpcklps' return (__m128) __builtin_ia32_unpcklps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:750:19: error: use of undeclared identifier '__builtin_ia32_loadhps' return (__m128) __builtin_ia32_loadhps ((__v4sf)__A, (__v2si *)__P); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:764:19: error: use of undeclared identifier '__builtin_ia32_movhlps' return (__m128) __builtin_ia32_movhlps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:771:19: error: use of undeclared identifier '__builtin_ia32_movlhps' return (__m128) __builtin_ia32_movlhps ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:779:19: error: use of undeclared identifier '__builtin_ia32_loadlps' return (__m128) __builtin_ia32_loadlps ((__v4sf)__A, (__v2si *)__P); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:919:19: error: use of undeclared identifier '__builtin_ia32_shufps' return (__m128) __builtin_ia32_shufps (__tmp, __tmp, _MM_SHUFFLE (0,1,2,3)); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:940:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v4sf' *__P = __builtin_ia32_vec_ext_v4sf ((__v4sf)__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:946:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v4sf' return __builtin_ia32_vec_ext_v4sf ((__v4sf)__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:968:18: error: use of undeclared identifier '__builtin_ia32_shufps' __v4sf __tmp = __builtin_ia32_shufps (__va, __va, _MM_SHUFFLE (0,0,0,0)); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:983:18: error: use of undeclared identifier '__builtin_ia32_shufps' __v4sf __tmp = __builtin_ia32_shufps (__va, __va, _MM_SHUFFLE (0,1,2,3)); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:991:19: error: use of undeclared identifier '__builtin_ia32_movss' return (__m128) __builtin_ia32_movss ((__v4sf)__A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:1204:26: error: cannot initialize a parameter of type '__attribute__((__vector_size__(1 * sizeof(long long)))) long long *' with an rvalue of type 'unsigned long long *' __builtin_ia32_movntq ((unsigned long long *)__P, (unsigned long long)__A); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:97:20: error: use of undeclared identifier '__builtin_ia32_movsd' return (__m128d) __builtin_ia32_movsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:139:10: error: use of undeclared identifier '__builtin_ia32_shufpd' return __builtin_ia32_shufpd (__tmp, __tmp, _MM_SHUFFLE2 (0,1)); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:160:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2df' *__P = __builtin_ia32_vec_ext_v2df (__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:166:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2df' return __builtin_ia32_vec_ext_v2df (__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:179:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2df' *__P = __builtin_ia32_vec_ext_v2df (__A, 1); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:187:22: error: use of undeclared identifier '__builtin_ia32_shufpd' _mm_store_pd (__P, __builtin_ia32_shufpd (__A, __A, _MM_SHUFFLE2 (0,0))); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:200:22: error: use of undeclared identifier '__builtin_ia32_shufpd' _mm_store_pd (__P, __builtin_ia32_shufpd (__A, __A, _MM_SHUFFLE2 (0,1))); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:206:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v4si' return __builtin_ia32_vec_ext_v4si ((__v4si)__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:214:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2di' return __builtin_ia32_vec_ext_v2di ((__v2di)__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:221:10: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2di' return __builtin_ia32_vec_ext_v2di ((__v2di)__A, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:228:19: error: use of undeclared identifier '__builtin_ia32_addpd' return (__m128d)__builtin_ia32_addpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:234:19: error: use of undeclared identifier '__builtin_ia32_addsd' return (__m128d)__builtin_ia32_addsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:240:19: error: use of undeclared identifier '__builtin_ia32_subpd' return (__m128d)__builtin_ia32_subpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:246:19: error: use of undeclared identifier '__builtin_ia32_subsd' return (__m128d)__builtin_ia32_subsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:252:19: error: use of undeclared identifier '__builtin_ia32_mulpd' return (__m128d)__builtin_ia32_mulpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:258:19: error: use of undeclared identifier '__builtin_ia32_mulsd' return (__m128d)__builtin_ia32_mulsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:264:19: error: use of undeclared identifier '__builtin_ia32_divpd' return (__m128d)__builtin_ia32_divpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:270:19: error: use of undeclared identifier '__builtin_ia32_divsd' return (__m128d)__builtin_ia32_divsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:283:18: error: use of undeclared identifier '__builtin_ia32_movsd' __v2df __tmp = __builtin_ia32_movsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:314:19: error: use of undeclared identifier '__builtin_ia32_andpd' return (__m128d)__builtin_ia32_andpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:320:19: error: use of undeclared identifier '__builtin_ia32_andnpd' return (__m128d)__builtin_ia32_andnpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:326:19: error: use of undeclared identifier '__builtin_ia32_orpd' return (__m128d)__builtin_ia32_orpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:332:19: error: use of undeclared identifier '__builtin_ia32_xorpd' return (__m128d)__builtin_ia32_xorpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:338:19: error: use of undeclared identifier '__builtin_ia32_cmpeqpd' return (__m128d)__builtin_ia32_cmpeqpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:344:19: error: use of undeclared identifier '__builtin_ia32_cmpltpd' return (__m128d)__builtin_ia32_cmpltpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:350:19: error: use of undeclared identifier '__builtin_ia32_cmplepd' return (__m128d)__builtin_ia32_cmplepd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:356:19: error: use of undeclared identifier '__builtin_ia32_cmpgtpd' return (__m128d)__builtin_ia32_cmpgtpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:362:19: error: use of undeclared identifier '__builtin_ia32_cmpgepd' return (__m128d)__builtin_ia32_cmpgepd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:368:19: error: use of undeclared identifier '__builtin_ia32_cmpneqpd' return (__m128d)__builtin_ia32_cmpneqpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:374:19: error: use of undeclared identifier '__builtin_ia32_cmpnltpd' return (__m128d)__builtin_ia32_cmpnltpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:380:19: error: use of undeclared identifier '__builtin_ia32_cmpnlepd' return (__m128d)__builtin_ia32_cmpnlepd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:386:19: error: use of undeclared identifier '__builtin_ia32_cmpngtpd' return (__m128d)__builtin_ia32_cmpngtpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:392:19: error: use of undeclared identifier '__builtin_ia32_cmpngepd' return (__m128d)__builtin_ia32_cmpngepd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:398:19: error: use of undeclared identifier '__builtin_ia32_cmpordpd' return (__m128d)__builtin_ia32_cmpordpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:404:19: error: use of undeclared identifier '__builtin_ia32_cmpunordpd' return (__m128d)__builtin_ia32_cmpunordpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:410:19: error: use of undeclared identifier '__builtin_ia32_cmpeqsd' return (__m128d)__builtin_ia32_cmpeqsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:416:19: error: use of undeclared identifier '__builtin_ia32_cmpltsd' return (__m128d)__builtin_ia32_cmpltsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:422:19: error: use of undeclared identifier '__builtin_ia32_cmplesd' return (__m128d)__builtin_ia32_cmplesd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:430:7: error: use of undeclared identifier '__builtin_ia32_cmpltsd' __builtin_ia32_cmpltsd ((__v2df) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:440:7: error: use of undeclared identifier '__builtin_ia32_cmplesd' __builtin_ia32_cmplesd ((__v2df) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:448:19: error: use of undeclared identifier '__builtin_ia32_cmpneqsd' return (__m128d)__builtin_ia32_cmpneqsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:454:19: error: use of undeclared identifier '__builtin_ia32_cmpnltsd' return (__m128d)__builtin_ia32_cmpnltsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:460:19: error: use of undeclared identifier '__builtin_ia32_cmpnlesd' return (__m128d)__builtin_ia32_cmpnlesd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:468:7: error: use of undeclared identifier '__builtin_ia32_cmpnltsd' __builtin_ia32_cmpnltsd ((__v2df) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:478:7: error: use of undeclared identifier '__builtin_ia32_cmpnlesd' __builtin_ia32_cmpnlesd ((__v2df) __B, ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:486:19: error: use of undeclared identifier '__builtin_ia32_cmpordsd' return (__m128d)__builtin_ia32_cmpordsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:492:19: error: use of undeclared identifier '__builtin_ia32_cmpunordsd' return (__m128d)__builtin_ia32_cmpunordsd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:707:23: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2di' *(long long *)__P = __builtin_ia32_vec_ext_v2di ((__v2di)__B, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:713:18: error: use of undeclared identifier '__builtin_ia32_vec_ext_v2di' return (__m64) __builtin_ia32_vec_ext_v2di ((__v2di)__B, 0); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:826:10: error: use of undeclared identifier '__builtin_ia32_cvttsd2si' return __builtin_ia32_cvttsd2si ((__v2df) __A); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:834:10: error: use of undeclared identifier '__builtin_ia32_cvttsd2si64' return __builtin_ia32_cvttsd2si64 ((__v2df) __A); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:841:10: error: use of undeclared identifier '__builtin_ia32_cvttsd2si64' return __builtin_ia32_cvttsd2si64 ((__v2df) __A); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:848:18: error: use of undeclared identifier '__builtin_ia32_cvtsd2ss' return (__m128)__builtin_ia32_cvtsd2ss ((__v4sf) __A, (__v2df) __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:854:19: error: use of undeclared identifier '__builtin_ia32_cvtsi2sd' return (__m128d)__builtin_ia32_cvtsi2sd ((__v2df) __A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:862:19: error: use of undeclared identifier '__builtin_ia32_cvtsi642sd' return (__m128d)__builtin_ia32_cvtsi642sd ((__v2df) __A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:869:19: error: use of undeclared identifier '__builtin_ia32_cvtsi642sd' return (__m128d)__builtin_ia32_cvtsi642sd ((__v2df) __A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:876:19: error: use of undeclared identifier '__builtin_ia32_cvtss2sd' return (__m128d)__builtin_ia32_cvtss2sd ((__v2df) __A, (__v4sf)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:884:19: error: use of undeclared identifier '__builtin_ia32_unpckhpd' return (__m128d)__builtin_ia32_unpckhpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:890:19: error: use of undeclared identifier '__builtin_ia32_unpcklpd' return (__m128d)__builtin_ia32_unpcklpd ((__v2df)__A, (__v2df)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:896:19: error: use of undeclared identifier '__builtin_ia32_loadhpd' return (__m128d)__builtin_ia32_loadhpd ((__v2df)__A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:902:19: error: use of undeclared identifier '__builtin_ia32_loadlpd' return (__m128d)__builtin_ia32_loadlpd ((__v2df)__A, __B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:932:19: error: use of undeclared identifier '__builtin_ia32_punpckhbw128' return (__m128i)__builtin_ia32_punpckhbw128 ((__v16qi)__A, (__v16qi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:938:19: error: use of undeclared identifier '__builtin_ia32_punpckhwd128' return (__m128i)__builtin_ia32_punpckhwd128 ((__v8hi)__A, (__v8hi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:944:19: error: use of undeclared identifier '__builtin_ia32_punpckhdq128' return (__m128i)__builtin_ia32_punpckhdq128 ((__v4si)__A, (__v4si)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:950:19: error: use of undeclared identifier '__builtin_ia32_punpckhqdq128' return (__m128i)__builtin_ia32_punpckhqdq128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:956:19: error: use of undeclared identifier '__builtin_ia32_punpcklbw128' return (__m128i)__builtin_ia32_punpcklbw128 ((__v16qi)__A, (__v16qi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:962:19: error: use of undeclared identifier '__builtin_ia32_punpcklwd128' return (__m128i)__builtin_ia32_punpcklwd128 ((__v8hi)__A, (__v8hi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:968:19: error: use of undeclared identifier '__builtin_ia32_punpckldq128' return (__m128i)__builtin_ia32_punpckldq128 ((__v4si)__A, (__v4si)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:974:19: error: use of undeclared identifier '__builtin_ia32_punpcklqdq128' return (__m128i)__builtin_ia32_punpcklqdq128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:980:19: error: use of undeclared identifier '__builtin_ia32_paddb128' return (__m128i)__builtin_ia32_paddb128 ((__v16qi)__A, (__v16qi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:986:19: error: use of undeclared identifier '__builtin_ia32_paddw128' return (__m128i)__builtin_ia32_paddw128 ((__v8hi)__A, (__v8hi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:992:19: error: use of undeclared identifier '__builtin_ia32_paddd128' return (__m128i)__builtin_ia32_paddd128 ((__v4si)__A, (__v4si)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:998:19: error: use of undeclared identifier '__builtin_ia32_paddq128' return (__m128i)__builtin_ia32_paddq128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1028:19: error: use of undeclared identifier '__builtin_ia32_psubb128' return (__m128i)__builtin_ia32_psubb128 ((__v16qi)__A, (__v16qi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1034:19: error: use of undeclared identifier '__builtin_ia32_psubw128' return (__m128i)__builtin_ia32_psubw128 ((__v8hi)__A, (__v8hi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1040:19: error: use of undeclared identifier '__builtin_ia32_psubd128' return (__m128i)__builtin_ia32_psubd128 ((__v4si)__A, (__v4si)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1046:19: error: use of undeclared identifier '__builtin_ia32_psubq128' return (__m128i)__builtin_ia32_psubq128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1088:19: error: use of undeclared identifier '__builtin_ia32_pmullw128' return (__m128i)__builtin_ia32_pmullw128 ((__v8hi)__A, (__v8hi)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1246:19: error: use of undeclared identifier '__builtin_ia32_pand128' return (__m128i)__builtin_ia32_pand128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1252:19: error: use of undeclared identifier '__builtin_ia32_pandn128' return (__m128i)__builtin_ia32_pandn128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1258:19: error: use of undeclared identifier '__builtin_ia32_por128' return (__m128i)__builtin_ia32_por128 ((__v2di)__A, (__v2di)__B); ^ /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:1264:19: error: use of undeclared identifier '__builtin_ia32_pxor128' return (__m128i)__builtin_ia32_pxor128 ((__v2di)__A, (__v2di)__B); ^ 186 diagnostics generated. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd/usr.bin. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd. *** Error code 1 Stop in /root/clangbsd.gcc.1272316273/clangbsd. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 07:07: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 5C588106566B for ; Tue, 27 Apr 2010 07:07:30 +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 096568FC18 for ; Tue, 27 Apr 2010 07:07:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 55DD69CB0DE; Tue, 27 Apr 2010 09:04:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkliA3BLwEI8; Tue, 27 Apr 2010 09:04:53 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1DF6B9CB452; Tue, 27 Apr 2010 09:04:53 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o3R74qqE017138; Tue, 27 Apr 2010 09:04:52 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 27 Apr 2010 09:04:51 +0200 From: Roman Divacky To: Andrew Reilly Message-ID: <20100427070451.GA16910@freebsd.org> References: <20100424080533.GA77435@freebsd.org> <20100427045053.GA64971@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100427045053.GA64971@duncan.reilly.home> User-Agent: Mutt/1.4.2.3i Cc: freebsd-multimedia@FreeBSD.org, Alexander Best , freebsd-current@FreeBSD.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 07:07:30 -0000 while I agree that the function is strange there indeed is a bug in llvm. See: http://llvm.org/bugs/show_bug.cgi?id=6941 On Tue, Apr 27, 2010 at 02:50:53PM +1000, Andrew Reilly wrote: > On Sun, Apr 25, 2010 at 12:06:49PM +0200, Alexander Best wrote: > > i was able to pinpoint the > > exact function which is causing the problem: > > > > it's snd_xbytes(). > > This is an odd-looking function. Its purpose is to compute the > size of a target buffer for a block of audio samples that might > be sample-rate-converted or format changed. It has a loop to > compute the gcd of the second two arguments (from, to), so that > it can divide by that common factor so that it can then do v * > (to/x) / (from/x). It's not immediately obvious to me why it > bothers to find the gcd, since the division by the original > from should work anyway, as it's using a 64-bit numerator... > > The only difference that I can see when this is compiled with cc > vs clang on my amd64 system is that the latter uses a divq in > the loop and the former uses a divl. I haven't figured out why, > yet. Hmm. If the same division logic is being used in the i386 > version of clang, then it's possible that this is resulting in > a call to an extended precision divide subroutine, which could > slow things down a bit. > > Cheers, > > -- > Andrew From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 07:11: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 1CCF5106564A for ; Tue, 27 Apr 2010 07:11:11 +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 B33198FC30 for ; Tue, 27 Apr 2010 07:11:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 547F29CB0D0; Tue, 27 Apr 2010 09:08:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE1T7SoYkC15; Tue, 27 Apr 2010 09:08:35 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1DFF49CB0F1; Tue, 27 Apr 2010 09:08:35 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o3R78ZQv017591; Tue, 27 Apr 2010 09:08:35 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 27 Apr 2010 09:08:35 +0200 From: Roman Divacky To: Dominic Fandrey Message-ID: <20100427070835.GB16910@freebsd.org> References: <4BD68275.6020509@bsdforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4BD68275.6020509@bsdforen.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 07:11:11 -0000 On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: > Hello, >=20 > I wanted to make some performance comparisons, building ClangBSD > with different compilers. >=20 > The host system is: > FreeBSD mobileKamikaze.norad 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Apr 5= 12:45:41 CEST 2010 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/= usr/src/sys/HP6510b-8 amd64 >=20 > An interesting result is that buildkernel with clang takes longer: > CC=3Dclang > time -l make buildkernel > 921.31 real 802.25 user 114.93 sys > time -l make buildkernel -j3 > 645.17 real 838.46 user 143.03 sys >=20 > CC=3Dcc > time -l make buildkernel > 877.14 real 757.42 user 115.11 sys > time -l make buildkernel -j3 > 628.32 real 798.03 user 149.52 sys =20 this is really strange... almost everyone is seeing much faster builds with= clang > All the tests are run on a 4g memory disk (src and objdir), which > is recreated for every test. >=20 > I cannot make this comparison for buildworld, because buildworld > with CC=3Dcc, CXX=3Dc++ fails: >=20 > =3D=3D=3D> usr.bin/clang/lib/libclanglex (all) > c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316= 273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/roo= t/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clang= bsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c+= +/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.127231= 6273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbs= d.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.12723= 16273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/inclu= de -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/.= ./../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273= /clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clan= g/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/li= bclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MAC= ROS -D__STDC_CONS > TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=3D\"amd64-undermydesk-freebsd9.0\= " -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang= /lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp > c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316= 273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/roo= t/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clang= bsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c+= +/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.127231= 6273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbs= d.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.12723= 16273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/inclu= de -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/.= ./../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273= /clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clan= g/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/li= bclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MAC= ROS -D__STDC_CONS > TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=3D\"amd64-undermydesk-freebsd9.0\= " -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang= /lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.= cpp > c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316= 273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/roo= t/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clang= bsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c+= +/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.127231= 6273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbs= d.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.12723= 16273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/inclu= de -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/.= ./../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273= /clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clan= g/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/li= bclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MAC= ROS -D__STDC_CONS > TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=3D\"amd64-undermydesk-freebsd9.0\= " -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang= /lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp > In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clan= g/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:11= 16: > In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc= .1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: > In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc= .1272316273/clangbsd/tmp/usr/include/xmmintrin.h:39: > /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/t= mp/usr/include/mmintrin.h:63:18: error: use of undeclared identifier '__bui= ltin_ia32_vec_init_v2si' > return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); you are using old clangbsd.. please update and this will go away From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 08:07: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 B9677106566C for ; Tue, 27 Apr 2010 08:07:56 +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 758F78FC0C for ; Tue, 27 Apr 2010 08:07:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id F31869CB0D6; Tue, 27 Apr 2010 10:05:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmtRsvRBz5H5; Tue, 27 Apr 2010 10:05:18 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8D20B9CB16D; Tue, 27 Apr 2010 10:05:18 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o3R85Ilb032133; Tue, 27 Apr 2010 10:05:18 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 27 Apr 2010 10:05:18 +0200 From: Roman Divacky To: Dominic Fandrey Message-ID: <20100427080518.GA31918@freebsd.org> References: <4BD68275.6020509@bsdforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD68275.6020509@bsdforen.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 08:07:56 -0000 On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: > Hello, > > I wanted to make some performance comparisons, building ClangBSD > with different compilers. > > The host system is: > FreeBSD mobileKamikaze.norad 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Apr 5 12:45:41 CEST 2010 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 > > An interesting result is that buildkernel with clang takes longer: > CC=clang > time -l make buildkernel > 921.31 real 802.25 user 114.93 sys > time -l make buildkernel -j3 > 645.17 real 838.46 user 143.03 sys > > CC=cc > time -l make buildkernel > 877.14 real 757.42 user 115.11 sys > time -l make buildkernel -j3 > 628.32 real 798.03 user 149.52 sys fwiw.. these are my times: clang: 403.342u 42.516s 6:53.30 107.8% 21957+2248k 33+56671io 364pf+0w gcc: 451.952u 42.860s 7:23.16 111.6% 6564+2012k 78+43200io 3pf+0w note that clang build had more page faults thus would be a little faster without them From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 08:39:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D4F1065672 for ; Tue, 27 Apr 2010 08:39:07 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1D88FC0C for ; Tue, 27 Apr 2010 08:39:06 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [188.46.73.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 950CE8A1BD3 for ; Tue, 27 Apr 2010 10:38:45 +0200 (CEST) Message-ID: <4BD6A28F.1060600@bsdforen.de> Date: Tue, 27 Apr 2010 10:38:39 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4BD68275.6020509@bsdforen.de> <20100427070835.GB16910@freebsd.org> In-Reply-To: <20100427070835.GB16910@freebsd.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 08:39:07 -0000 On 27/04/2010 09:08, Roman Divacky wrote: > On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: >> I cannot make this comparison for buildworld, because buildworld >> with CC=cc, CXX=c++ fails: >> >> ===> usr.bin/clang/lib/libclanglex (all) >> c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_C ONS >> TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp >> c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_C ONS >> TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp >> c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_C ONS >> TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=\"amd64-undermydesk-freebsd9.0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp >> In file included from /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:1116: >> In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/emmintrin.h:34: >> In file included from /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/xmmintrin.h:39: >> /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/usr/include/mmintrin.h:63:18: error: use of undeclared identifier '__builtin_ia32_vec_init_v2si' >> return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); > > > you are using old clangbsd.. please update and this will go away "Old" as in less than 12 hours. :) I'll retry and report. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 08:44: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 5D22B106564A for ; Tue, 27 Apr 2010 08:44:47 +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 177AF8FC1B for ; Tue, 27 Apr 2010 08:44:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 785849CB0D6; Tue, 27 Apr 2010 10:42:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yh3bus5tbWT; Tue, 27 Apr 2010 10:42:11 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 588689CB151; Tue, 27 Apr 2010 10:42:11 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o3R8gBxw036748; Tue, 27 Apr 2010 10:42:11 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 27 Apr 2010 10:42:11 +0200 From: Roman Divacky To: Dominic Fandrey Message-ID: <20100427084211.GA36551@freebsd.org> References: <4BD68275.6020509@bsdforen.de> <20100427070835.GB16910@freebsd.org> <4BD6A28F.1060600@bsdforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4BD6A28F.1060600@bsdforen.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 08:44:47 -0000 On Tue, Apr 27, 2010 at 10:38:39AM +0200, Dominic Fandrey wrote: > On 27/04/2010 09:08, Roman Divacky wrote: > > On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: > >> I cannot make this comparison for buildworld, because buildworld > >> with CC=3Dcc, CXX=3Dc++ fails: > >> > >> =3D=3D=3D> usr.bin/clang/lib/libclanglex (all) > >> c++ -isystem /root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272= 316273/clangbsd/tmp/usr/include -isystem /root/clangbsd.gcc.1272316273/obj/= root/clangbsd.gcc.1272316273/clangbsd/tmp/include/c++/4.2 -isystem /root/cl= angbsd.gcc.1272316273/obj/root/clangbsd.gcc.1272316273/clangbsd/tmp/include= /c++/4.2/backward -B/root/clangbsd.gcc.1272316273/obj/root/clangbsd.gcc.127= 2316273/clangbsd/tmp/usr/lib/ -L/root/clangbsd.gcc.1272316273/obj/root/clan= gbsd.gcc.1272316273/clangbsd/tmp/usr/lib/ -O2 -pipe -I/root/clangbsd.gcc.12= 72316273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/in= clude -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib/libclangle= x/../../../../contrib/llvm/tools/clang/include -I/root/clangbsd.gcc.1272316= 273/clangbsd/usr.bin/clang/lib/libclanglex/../../../../contrib/llvm/tools/c= lang/lib/Lex -I. -I/root/clangbsd.gcc.1272316273/clangbsd/usr.bin/clang/lib= /libclanglex/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_= MACROS -D__STDC_C > ONS > >> TANT_MACROS -fno-rtti -DLLVM_HOSTTRIPLE=3D\"amd64-undermydesk-freebsd9= .0\" -fstack-protector -c /root/clangbsd.gcc.1272316273/clangbsd/usr.bin/cl= ang/lib/libclanglex/../../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.= cpp > >=20 > >=20 > > you are using old clangbsd.. please update and this will go away >=20 > "Old" as in less than 12 hours. :) >=20 > I'll retry and report. oh... I got confused. sorry. anyway, can you take a look at where the mmint= rin.h comes from? ie. is it the gcc copy or the clang copy? what is "c++" anyway? is it clang or gcc? From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 08:49: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 97585106564A for ; Tue, 27 Apr 2010 08:49:34 +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 528138FC1C for ; Tue, 27 Apr 2010 08:49:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B9C009CB0D6; Tue, 27 Apr 2010 10:47:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRqClO5l6AEt; Tue, 27 Apr 2010 10:46:58 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A1E5D9CB151; Tue, 27 Apr 2010 10:46:58 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o3R8kwwn037338; Tue, 27 Apr 2010 10:46:58 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 27 Apr 2010 10:46:58 +0200 From: Roman Divacky To: Dominic Fandrey Message-ID: <20100427084658.GA37139@freebsd.org> References: <4BD68275.6020509@bsdforen.de> <20100427070835.GB16910@freebsd.org> <4BD6A28F.1060600@bsdforen.de> <20100427084211.GA36551@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100427084211.GA36551@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 08:49:34 -0000 I see whats going on... you have CC=cc and CXX=c++ in your share/mk/sys.mk and the "c++" is clang thus the .if ${CC} == "clang" || ${CXX} == "clang++" MMINTRIN_CLANG= -isystem ${WORLDTMP}/usr/include/clang/1.5 .endif condition does not add the -isystem thus the gcc mmintrin.h is used. you have to change the share/mk/sys.mk to have CC/CXX either "gcc/g++" or "clang/clang++" I have to think of some better way to test this as this proves way too fragile :( thnx for the report! From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 09:07: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 7A7561065672; Tue, 27 Apr 2010 09:07:51 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id B51238FC34; Tue, 27 Apr 2010 09:07:50 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [188.46.73.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id B144B8A1BC9; Tue, 27 Apr 2010 11:07:20 +0200 (CEST) Message-ID: <4BD6A943.8010807@bsdforen.de> Date: Tue, 27 Apr 2010 11:07:15 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Roman Divacky References: <4BD68275.6020509@bsdforen.de> <20100427070835.GB16910@freebsd.org> <4BD6A28F.1060600@bsdforen.de> <20100427084211.GA36551@freebsd.org> <20100427084658.GA37139@freebsd.org> In-Reply-To: <20100427084658.GA37139@freebsd.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 09:07:51 -0000 On 27/04/2010 10:46, Roman Divacky wrote: > I see whats going on... you have CC=cc and CXX=c++ in your share/mk/sys.mk > and the "c++" is clang thus the Actually I set CC and CXX in the environment. The definition in sys.mk is CC?=, so it shouldn't be a problem. > .if ${CC} == "clang" || ${CXX} == "clang++" > MMINTRIN_CLANG= -isystem ${WORLDTMP}/usr/include/clang/1.5 > .endif > > condition does not add the -isystem thus the gcc mmintrin.h is used. > > you have to change the share/mk/sys.mk to have CC/CXX either "gcc/g++" > or "clang/clang++" > > I have to think of some better way to test this as this proves way > too fragile :( Thanks a lot for your quick analysis. I already changed my test script to gcc and g++. Though I didn't think it would have an effect, I figured sticking to the guide would generally be a good idea. I didn't rerun the test, though. I have to wait for the night, when the machine is not in use. Anyway, thank you for figuring this out so quickly. It would seriously have confused me that it would start working for no apparent reason and I'd probably have blamed my hardware. > thnx for the report! I'm working on a small clang introductory paper, and some self-performed test seemed like the necessary salt, to give it the right flavour. If you're interested I can notify you or the entire list, when it's done. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 09:16: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 C3DC7106566B; Tue, 27 Apr 2010 09:16:49 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 859EE8FC14; Tue, 27 Apr 2010 09:16:49 +0000 (UTC) Received: from mobileKamikaze.norad (unknown [188.46.73.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 2E5068A1BC9; Tue, 27 Apr 2010 11:16:24 +0200 (CEST) Message-ID: <4BD6AB65.1010503@bsdforen.de> Date: Tue, 27 Apr 2010 11:16:21 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Roman Divacky References: <4BD68275.6020509@bsdforen.de> <20100427080518.GA31918@freebsd.org> In-Reply-To: <20100427080518.GA31918@freebsd.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ClangBSD build failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 09:16:49 -0000 On 27/04/2010 10:05, Roman Divacky wrote: > On Tue, Apr 27, 2010 at 08:21:41AM +0200, Dominic Fandrey wrote: >> An interesting result is that buildkernel with clang takes longer: >> CC=clang >> time -l make buildkernel >> 921.31 real 802.25 user 114.93 sys >> time -l make buildkernel -j3 >> 645.17 real 838.46 user 143.03 sys >> >> CC=cc >> time -l make buildkernel >> 877.14 real 757.42 user 115.11 sys >> time -l make buildkernel -j3 >> 628.32 real 798.03 user 149.52 sys > > fwiw.. these are my times: > > > clang: > 403.342u 42.516s 6:53.30 107.8% 21957+2248k 33+56671io 364pf+0w > > gcc: > 451.952u 42.860s 7:23.16 111.6% 6564+2012k 78+43200io 3pf+0w > > > note that clang build had more page faults thus would be a little faster > without them Nice compile times, and thank you for destroying my illusions that my Core2Duo notebook performs quite decently. :( The difference is alarmingly huge. I wonder whether the memory disk actually hurts performance. I will have to test this. I normally use ccache, and am used to a lot faster buildkernels and buildworlds, but I turned this off for the performance tests. So this didn't alarm me until I saw your measurements. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 09:57:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25F01065672 for ; Tue, 27 Apr 2010 09:57:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1EC8FC1D for ; Tue, 27 Apr 2010 09:57:10 +0000 (UTC) Received: by bwz8 with SMTP id 8so12063826bwz.3 for ; Tue, 27 Apr 2010 02:57:04 -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=6/tGyzrjeQfCBUxOF24G302upXKPWoxLovYgPCZ9n6g=; b=dJs6LU9QdRY0b0d+EMpKrAaEKvWKb1x8gkotdRWxx1szopZGF4AH9yKH7t9+njh++E wlZPtjx+yc1/vQLDDf84LcvvqSMrwDckemSjCzuxnhdTiXPO3TwMl6lnF2JqLmbP4qcL lzSLZCo5/UQdDB+a50LMc9AHF3ld9qE8k20d0= 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=e3BFmreIGwJCodmh69zmV0Q/npWq7wfZ/rb8ws/xqg1UJWQtABFJm2evMEPzXLDSmH eFdA+nfft93vtv5Y8zw01FuroeX8LEfe/CS8Znoby2HTodfu8lGxgJ9iX8bcjuiSzV+l uddMw4ga3zjCDQE/D7eKbagjpx46lVuheLZMw= MIME-Version: 1.0 Received: by 10.204.140.212 with SMTP id j20mr3467637bku.119.1272362224051; Tue, 27 Apr 2010 02:57:04 -0700 (PDT) Received: by 10.204.79.3 with HTTP; Tue, 27 Apr 2010 02:57:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Apr 2010 13:57:04 +0400 Message-ID: From: pluknet To: Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dikshie , current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 09:57:11 -0000 On 27 April 2010 10:01, Jeff Roberson wrote: > On Mon, 26 Apr 2010, pluknet wrote: > >> On 26 April 2010 17:42, dikshie wrote: >>> >>> Hi Jeff, >>> thanks for SUJ. >>> btw, why there is nan% utilization? and what does it mean? >>> -------------- >>> ** SU+J Recovering /dev/ad0s1g >>> ** Reading 33554432 byte journal from inode 4. >>> ** Building recovery table. >>> ** Resolving unreferenced inode list. >>> ** Processing journal entries. >>> ** 0 journal records in 0 bytes for nan% utilization <=3D=3D=3D=3D >>> ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. >>> -------------- >>> >> >> That may be due to an empty journal (the only plausible version for me), >> so jrecs and jblocks are not updated. > > Yes, this is it exactly. =A0It's a simple bug, I will post a fix in the n= ext > few days. > > Thanks, > Jeff > While here, could you please look at my another su+j issue email? (to not create a new thread of the same thing). Thanks in advance. http://lists.freebsd.org/pipermail/svn-src-all/2010-April/023303.html --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 11:33: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 8F6FC106566B; Tue, 27 Apr 2010 11:33:26 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 0282E8FC23; Tue, 27 Apr 2010 11:33:25 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id o3RBXAee002203; Tue, 27 Apr 2010 12:33:10 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1O6j2M-0005cL-Mq; Tue, 27 Apr 2010 12:33:10 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id o3RBXA3b098505; Tue, 27 Apr 2010 12:33:10 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id o3RBXAvH098504; Tue, 27 Apr 2010 12:33:10 +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: "M. Warner Losh" In-Reply-To: <20100426.103327.319083499807534535.imp@bsdimp.com> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 12:33:09 +0100 Message-ID: <1272367989.97887.47.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: mav@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 11:33:26 -0000 On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. Losing ataraid would be bad. I suspect there are a lot of installs using it - especially as there is no way to create any other mirror from sysinstall. However, I'm not actually sure that the functionality it provides is easy to push down into GEOM. ataraid depends on knowing a lot about the underlying hardware, in order to know which format of metadata to use. i.e. it needs to know that the disks are attached to (say) a Highpoint controller. This is especially important when creating new ATA RAID devices, although there is so little identifying metadata on the disks themselves that in some cases it doesn't look like it is possible to identify or even confirm the existence of metadata without knowing the PCI ID of the controller to which the disks are attached. I'm not sure I can see a way to do this from within GEOM. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 11:34:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 350251065676 for ; Tue, 27 Apr 2010 11:34:45 +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 7783F8FC14 for ; Tue, 27 Apr 2010 11:34:44 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA12130; Tue, 27 Apr 2010 14:34:22 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD6CBBE.3030901@icyb.net.ua> Date: Tue, 27 Apr 2010 14:34:22 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Jeff Roberson References: <4BD35437.2060208@lissyara.su> <622DDEDF-0320-49DA-8037-CA8C1F682CC1@samsco.org> <201004251955.03492.bruce@cran.org.uk> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Alex Keda , freebsd-current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 11:34:45 -0000 on 27/04/2010 09:00 Jeff Roberson said the following: > I think some people are enabling after returning to single user from a > live system rather than booting into single user. This is a different > path in the filesystem as booting directly just mounts read-only while > the other option updates a mount from read/write. I believe this is the > path that is broken. Yes, this seems to be broken and perhaps by design. g_vfs_open() calls g_access like this: g_access(cp, 1, wr, 1); That means that 'e' count (exclusive) is always bumped, even for R/O mounts, and that prevents opening the provider for writing. ffs_mountfs has this special code: /* * If we are a root mount, drop the E flag so fsck can do its magic. * We will pick it up again when we remount R/W. */ if (error == 0 && ronly && (mp->mnt_flag & MNT_ROOTFS)) error = g_access(cp, 0, 0, -1); So, basically for read-only UFS root mount we allow concurrent open, even for writing. This is needed primarily for fsck, but also helps tunefs. But I believe that this code is exercised only during original mount. Remounting to R/O at later time doesn't drop 'e' count. I think that this is by design, to prevent foot-shooting. We either should document this behavior or re-consider it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 11:35:05 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 4EE2110657A4 for ; Tue, 27 Apr 2010 11:35:05 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 07D748FC0C for ; Tue, 27 Apr 2010 11:35:04 +0000 (UTC) Received: from [195.93.240.106] (port=51465 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6j4A-000OSG-U1 for current@freebsd.org; Tue, 27 Apr 2010 15:35:02 +0400 Message-ID: <4BD6CBE6.9030303@lissyara.su> Date: Tue, 27 Apr 2010 15:35:02 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 11:35:05 -0000 Following recent changes in dri, xorg server freezes after 20-30 seconds of work. mouse works, but the image does not change. process xorg get 100% cpu if I delete/rename drm.ko - all OK (but, very slow) vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c chip=0x791e1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI RADEON X1200 Series (RS690)' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, size 134217728, enabled bar [18] = type Memory, range 64, base 0xd8500000, size 65536, enabled bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled bar [24] = type Memory, range 32, base 0xd8400000, size 1048576, enabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[80] = MSI supports 1 message, 64 bit From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 11:41:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D2E106566C; Tue, 27 Apr 2010 11:41:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 02ABD8FC13; Tue, 27 Apr 2010 11:41:06 +0000 (UTC) Received: by bwz8 with SMTP id 8so12168224bwz.3 for ; Tue, 27 Apr 2010 04:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=dkqWsNhpdJCmDkefQbf3oauoTh+cHZaW9DiJb0M1dPc=; b=I1V60HnlFQoO+iY0phCCDA/q4h3Qu098PE/Ye3mAKk1Yf925airStM0KUzgLv7l1Cl GMqZfZZ8bjkPEgrsytDq92uqzVZ/VsFaBKofNspFIqY7u43XbCF2cE8pwGTs996DU3ET vymkavFhJPHafCaYKW/wWsg/FhzvHJCP6NYe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=qjuDS19tvdLdmNsy5Cop3euT0TvwDjais9FZP9b9zEAny/ZfnTTgiPRLdbx01+KOrY aMih/iwU0wJeOuaPrCxH+Y1i/CFmHRox2MO+Uj5bn76kBfv53uG8M5l/i5clXzXAnnZ1 mfSy4QP5d8rFaE6b/n9fc9nTekYPqI9TSLpgU= Received: by 10.102.254.26 with SMTP id b26mr3140413mui.118.1272368462295; Tue, 27 Apr 2010 04:41:02 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm21567922muo.16.2010.04.27.04.41.01 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 04:41:01 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6CD3F.5080903@FreeBSD.org> Date: Tue, 27 Apr 2010 14:40:47 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Gavin Atkinson References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> In-Reply-To: <1272367989.97887.47.camel@buffy.york.ac.uk> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 11:41:07 -0000 Gavin Atkinson wrote: > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. > > ataraid depends on knowing a lot about the underlying hardware, in order > to know which format of metadata to use. i.e. it needs to know that the > disks are attached to (say) a Highpoint controller. This is especially > important when creating new ATA RAID devices, although there is so > little identifying metadata on the disks themselves that in some cases > it doesn't look like it is possible to identify or even confirm the > existence of metadata without knowing the PCI ID of the controller to > which the disks are attached. > > I'm not sure I can see a way to do this from within GEOM. CAM allows every SIM driver to report several arbitrary string values, describing driver and hardware. They are almost unused now. I don't see much problems in exporting them to GEOM and making tasting method to analyze them. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 12:35:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3582B106564A for ; Tue, 27 Apr 2010 12:35:09 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3598FC16 for ; Tue, 27 Apr 2010 12:35:08 +0000 (UTC) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.4/8.14.4) with ESMTP id o3RCZ7Re014444 for ; Tue, 27 Apr 2010 16:35:07 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1272371707; bh=QMzMJGIO5u4gpPTkFtOGqJS//I2lTrM2GO2ON6aidzo=; l=657; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=dGbeowxdPt27rJKk4yvIQ5UwuaycGsNN1O0B/jWN94vU/Z2WYKNMVudmcoxtRhnM2 J4WtGn93+2QI+T/oF37kM7grpsODMm/nU/cVLS1u++o/F1Iu02xPUiL2DMRkxumwao K1YBNME8MEtB205bWHAITCpgWV7OsvI7hm9Hulr8= Received: (from ache@localhost) by nagual.pp.ru (8.14.4/8.14.4/Submit) id o3RCZ6xB014443 for current@freebsd.org; Tue, 27 Apr 2010 16:35:06 +0400 (MSD) (envelope-from ache) Date: Tue, 27 Apr 2010 16:35:06 +0400 From: Andrey Chernov To: current@freebsd.org Message-ID: <20100427123506.GA14350@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org 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: Something wrong with TCP connections in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 12:35:09 -0000 See subj. They appears to work for ~10 minutes then all hangs deadly. No one TCP service responds, but ICMP and UDP goes normally. The machine is x86 Pentium 4 IPv4-only, IPv6 is turned off in every place. Last kernel I have that works nice compiled at Mar 19. Ethernet info: fxp0: port 0xc000-0xc03f mem 0xed100000-0xed100fff,0xed000000-0xed0fffff irq 11 at device 11.0 on pci1 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto This is remote machine, so I don't have console access. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 12:54:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 234DC106566B for ; Tue, 27 Apr 2010 12:54:51 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id CDEF98FC12 for ; Tue, 27 Apr 2010 12:54:50 +0000 (UTC) Received: from [195.93.240.106] (port=43211 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6kJL-0000x4-HB for freebsd-current@freebsd.org; Tue, 27 Apr 2010 16:54:47 +0400 Message-ID: <4BD6DE97.8070906@lissyara.su> Date: Tue, 27 Apr 2010 16:54:47 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100427123506.GA14350@nagual.pp.ru> In-Reply-To: <20100427123506.GA14350@nagual.pp.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: Something wrong with TCP connections in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 12:54:51 -0000 27.04.2010 16:35, Andrey Chernov пишет: > See subj. > They appears to work for ~10 minutes then all hangs deadly. No one TCP > service responds, but ICMP and UDP goes normally. > The machine is x86 Pentium 4 IPv4-only, IPv6 is turned off in every place. > Last kernel I have that works nice compiled at Mar 19. > > Ethernet info: > fxp0: port 0xc000-0xc03f mem > 0xed100000-0xed100fff,0xed000000-0xed0fffff irq 11 at device 11.0 on pci1 > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > This is remote machine, so I don't have console access. > > I too have it bug but, time > 2-3 hours. lissyara$ ifconfig bge0: flags=8943 metric 0 mtu 1500 options=c0098 ether 00:1c:c4:98:77:a8 inet 172.17.4.127 netmask 0xffffff00 broadcast 172.17.4.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=21 tap0: flags=8902 metric 0 mtu 1500 options=80000 ether 00:bd:3c:81:00:00 bridge0: flags=8843 metric 0 mtu 1500 ether 42:16:df:e5:3c:68 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 2000000 member: bge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 55 gif0: flags=8051 metric 0 mtu 1280 tunnel inet 172.17.4.127 --> 172.29.200.25 inet 10.10.20.26 --> 10.10.10.16 netmask 0xffffffff options=1 lissyara$ From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 12:59: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 507CF1065670 for ; Tue, 27 Apr 2010 12:59:06 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 06D1F8FC19 for ; Tue, 27 Apr 2010 12:59:05 +0000 (UTC) Received: from [195.93.240.106] (port=45888 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6kNV-00017g-0l for freebsd-current@freebsd.org; Tue, 27 Apr 2010 16:59:05 +0400 Message-ID: <4BD6DF99.5090508@lissyara.su> Date: Tue, 27 Apr 2010 16:59:05 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100427123506.GA14350@nagual.pp.ru> <4BD6DE97.8070906@lissyara.su> In-Reply-To: <4BD6DE97.8070906@lissyara.su> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: Something wrong with TCP connections in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 12:59:06 -0000 27.04.2010 16:54, Alex Keda пишет: > 27.04.2010 16:35, Andrey Chernov пишет: >> See subj. >> They appears to work for ~10 minutes then all hangs deadly. No one TCP >> service responds, but ICMP and UDP goes normally. >> The machine is x86 Pentium 4 IPv4-only, IPv6 is turned off in every >> place. >> Last kernel I have that works nice compiled at Mar 19. >> >> Ethernet info: >> fxp0: port 0xc000-0xc03f mem >> 0xed100000-0xed100fff,0xed000000-0xed0fffff irq 11 at device 11.0 on >> pci1 >> miibus0: on fxp0 >> inphy0: PHY 1 on miibus0 >> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> >> This is remote machine, so I don't have console access. >> > I too have it bug > but, time > 2-3 hours. > lissyara$ ifconfig > bge0: flags=8943 > metric 0 mtu 1500 > options=c0098 > ether 00:1c:c4:98:77:a8 > inet 172.17.4.127 netmask 0xffffff00 broadcast 172.17.4.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > nd6 options=21 > tap0: flags=8902 metric 0 mtu 1500 > options=80000 > ether 00:bd:3c:81:00:00 > bridge0: flags=8843 metric 0 > mtu 1500 > ether 42:16:df:e5:3c:68 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 3 priority 128 path cost 2000000 > member: bge0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 55 > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 172.17.4.127 --> 172.29.200.25 > inet 10.10.20.26 --> 10.10.10.16 netmask 0xffffffff > options=1 > lissyara$ > > _______________________________________________ > 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" > forget. if I attempt local login to machine, I can type "root", Enter - and finish - cursor get to line down and nothing. (root without password) From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 13:30: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 B11751065672; Tue, 27 Apr 2010 13:30:54 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7168D8FC32; Tue, 27 Apr 2010 13:30:54 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4C4191FFC51; Tue, 27 Apr 2010 13:30:53 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DF63E84523; Tue, 27 Apr 2010 15:30:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Freddie Cash References: <4BD06BD9.6030401@FreeBSD.org> Date: Tue, 27 Apr 2010 15:30:20 +0200 In-Reply-To: (Freddie Cash's message of "Thu, 22 Apr 2010 08:42:04 -0700") Message-ID: <86sk6h3tw3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 13:30:54 -0000 Freddie Cash writes: > If a lowly user's vote counts for anything, I'd vote for the complete > removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and > zfs (and gvinum for the masochistics). :) We don't need to support any = of > the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it= 's > time for it to be retired. gstripe can't create a bootable striped set; ataraid can. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 13:34: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 987871065670; Tue, 27 Apr 2010 13:34:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5180B8FC0A; Tue, 27 Apr 2010 13:34:48 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 5E6101FFC22; Tue, 27 Apr 2010 13:34:47 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id F1D1984523; Tue, 27 Apr 2010 15:34:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Maxim Sobolev References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> Date: Tue, 27 Apr 2010 15:34:14 +0200 In-Reply-To: <4BD0ACD2.3040805@FreeBSD.org> (Maxim Sobolev's message of "Thu, 22 Apr 2010 13:08:50 -0700") Message-ID: <86och53tpl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 13:34:48 -0000 Maxim Sobolev writes: > Richard Tector writes: > > Could I also add that the removal of ataraid would affect those > > users who dual-boot with Windows and rely on the psuedo-raid > > provided by most Intel chipsets to be able to share the same pair of > > disks. > Well, this won't be a problem if we have GEOM classes that can > understand metadata created by the ATA RAID BIOS(es). Most pseudo-raid kit has nifty features like checksum offloading, composite writes etc. which can improve performance considerably. You can't access those from GEOM. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 13:55:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7595B1065672 for ; Tue, 27 Apr 2010 13:55:26 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0518FC1C for ; Tue, 27 Apr 2010 13:55:25 +0000 (UTC) Received: from [10.170.20.44] (nat-170-142-177-44.tn.gov [170.142.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o3RDtM3S075555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 09:55:23 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BD6ECBA.6010408@FreeBSD.org> Date: Tue, 27 Apr 2010 08:55:06 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Alex Keda References: <4BD6CBE6.9030303@lissyara.su> In-Reply-To: <4BD6CBE6.9030303@lissyara.su> Content-Type: multipart/mixed; boundary="------------050304040205020203020008" X-Spam-Status: No, score=0.9 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: current@freebsd.org Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 13:55:26 -0000 This is a multi-part message in MIME format. --------------050304040205020203020008 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Alex Keda wrote: > Following recent changes in dri, xorg server freezes after 20-30 seconds > of work. mouse works, but the image does not change. > process xorg get 100% cpu > if I delete/rename drm.ko - all OK (but, very slow) > > > vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c chip=0x791e1002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'ATI RADEON X1200 Series (RS690)' > class = display > subclass = VGA > bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, > size 134217728, enabled > bar [18] = type Memory, range 64, base 0xd8500000, size 65536, > enabled > bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled > bar [24] = type Memory, range 32, base 0xd8400000, size 1048576, > enabled > cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 > cap 05[80] = MSI supports 1 message, 64 bit Ok, does this patch help? robert. > _______________________________________________ > 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" --------------050304040205020203020008 Content-Type: text/x-patch; name="ati_pcigart.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ati_pcigart.diff" Index: ati_pcigart.c =================================================================== --- ati_pcigart.c (revision 207069) +++ ati_pcigart.c (working copy) @@ -198,7 +198,7 @@ page_base |= (upper_32_bits(entry_addr) & 0xff) << 4; page_base |= ATI_GART_READ | ATI_GART_WRITE; - page_base |= ATI_GART_NOSNOOP; + //page_base |= ATI_GART_NOSNOOP; break; case DRM_ATI_GART_PCIE: page_base >>= 8; --------------050304040205020203020008-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:00: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 DEE991065672; Tue, 27 Apr 2010 14:00:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id DB02B8FC1D; Tue, 27 Apr 2010 14:00:11 +0000 (UTC) Received: by ewy24 with SMTP id 24so3985066ewy.33 for ; Tue, 27 Apr 2010 07:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6HEfOoOq1/j2SHU/Txa/LgniEPqJi+ozw7civoJuLB4=; b=mGdQpsi/C3CR8J6gfeXpoPQUHT48iVywUbbpPyajcVUMTf4SxydM5ta0DjDWqlMwy/ lF80vebL4OJhR/KYDOCK8nY101BsMuz/JSbLGoINFvIT08LZ7MYVLsJc17Yuq6XbCcb1 Xd/CkjS5gvFZGi/uahhqjbTQ0RrA2l873wZt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ICyjSST0gEYGsRTz11r3iv6dnpEr12ZB3FVnpxbo6Pt/U3L7dqk5PPP6skrM0a7gId mQAZwKqUCXnoDMb/Nf2Ss4u9tCdDp9s3Rm9uhfB+Ej4LvbemGrw+b6IZRigjDKkxzh+S QzYfMNGgkcS2jqFSFnJ3yfwaVJX+VsAQ1X3bI= Received: by 10.103.133.7 with SMTP id k7mr3196523mun.128.1272376805450; Tue, 27 Apr 2010 07:00:05 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j10sm22240921mue.48.2010.04.27.07.00.04 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 07:00:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6EDD6.8010403@FreeBSD.org> Date: Tue, 27 Apr 2010 16:59:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> In-Reply-To: <86och53tpl.fsf@ds4.des.no> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 14:00:16 -0000 Dag-Erling Smørgrav wrote: > Maxim Sobolev writes: >> Richard Tector writes: >>> Could I also add that the removal of ataraid would affect those >>> users who dual-boot with Windows and rely on the psuedo-raid >>> provided by most Intel chipsets to be able to share the same pair of >>> disks. >> Well, this won't be a problem if we have GEOM classes that can >> understand metadata created by the ATA RAID BIOS(es). > > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. which can improve performance considerably. You > can't access those from GEOM. Have you ever seen them documented? Does the need to specifically handle dozens of incompatible implementations with limited resources worth those (probably not major) benefits? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:06:35 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37EBC106566B for ; Tue, 27 Apr 2010 14:06:35 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id E2A6B8FC1C for ; Tue, 27 Apr 2010 14:06:34 +0000 (UTC) Received: from [195.93.240.106] (port=26960 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6lQm-0003B5-KC for current@freebsd.org; Tue, 27 Apr 2010 18:06:32 +0400 Message-ID: <4BD6EF69.6000105@lissyara.su> Date: Tue, 27 Apr 2010 18:06:33 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: current@freebsd.org References: <4BD6CBE6.9030303@lissyara.su> <4BD6ECBA.6010408@FreeBSD.org> In-Reply-To: <4BD6ECBA.6010408@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 14:06:35 -0000 27.04.2010 17:55, Robert Noland ïèøåò: > > > Alex Keda wrote: >> Following recent changes in dri, xorg server freezes after 20-30 >> seconds of work. mouse works, but the image does not change. >> process xorg get 100% cpu >> if I delete/rename drm.ko - all OK (but, very slow) >> >> >> vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c >> chip=0x791e1002 rev=0x00 hdr=0x00 >> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >> device = 'ATI RADEON X1200 Series (RS690)' >> class = display >> subclass = VGA >> bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, >> size 134217728, enabled >> bar [18] = type Memory, range 64, base 0xd8500000, size 65536, >> enabled >> bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled >> bar [24] = type Memory, range 32, base 0xd8400000, size >> 1048576, enabled >> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >> cap 05[80] = MSI supports 1 message, 64 bit > > Ok, does this patch help? yes. I work without freeze more than 3 minutes =)) From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:13:23 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F096D106566B for ; Tue, 27 Apr 2010 14:13:23 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id B00428FC13 for ; Tue, 27 Apr 2010 14:13:23 +0000 (UTC) Received: from [10.170.20.44] (nat-170-142-177-44.tn.gov [170.142.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o3REDLVN075677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 10:13:21 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BD6F0F0.6000204@FreeBSD.org> Date: Tue, 27 Apr 2010 09:13:04 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Alex Keda References: <4BD6CBE6.9030303@lissyara.su> <4BD6ECBA.6010408@FreeBSD.org> <4BD6EF69.6000105@lissyara.su> In-Reply-To: <4BD6EF69.6000105@lissyara.su> Content-Type: multipart/mixed; boundary="------------090901090906020604070806" X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: current@freebsd.org Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 14:13:24 -0000 This is a multi-part message in MIME format. --------------090901090906020604070806 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Alex Keda wrote: > 27.04.2010 17:55, Robert Noland ïèøåò: >> >> >> Alex Keda wrote: >>> Following recent changes in dri, xorg server freezes after 20-30 >>> seconds of work. mouse works, but the image does not change. >>> process xorg get 100% cpu >>> if I delete/rename drm.ko - all OK (but, very slow) >>> >>> >>> vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c >>> chip=0x791e1002 rev=0x00 hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'ATI RADEON X1200 Series (RS690)' >>> class = display >>> subclass = VGA >>> bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, >>> size 134217728, enabled >>> bar [18] = type Memory, range 64, base 0xd8500000, size 65536, >>> enabled >>> bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled >>> bar [24] = type Memory, range 32, base 0xd8400000, size >>> 1048576, enabled >>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>> cap 05[80] = MSI supports 1 message, 64 bit >> >> Ok, does this patch help? > yes. I work without freeze more than 3 minutes =)) How about this one? robert. > _______________________________________________ > 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" --------------090901090906020604070806 Content-Type: text/x-patch; name="ati_pcigart-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ati_pcigart-2.diff" Index: ati_pcigart.c =================================================================== --- ati_pcigart.c (revision 207069) +++ ati_pcigart.c (working copy) @@ -220,6 +220,8 @@ ret = 1; done: + if (gart_info->gart_reg_if == DRM_ATI_GART_IGP) + DRM_MEMORYBARRIER(); gart_info->addr = address; gart_info->bus_addr = bus_address; return ret; --------------090901090906020604070806-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:17: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 1275D106566C; Tue, 27 Apr 2010 14:17:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C34AD8FC0C; Tue, 27 Apr 2010 14:17:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C200D1FFC51; Tue, 27 Apr 2010 14:17:01 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 656DB84523; Tue, 27 Apr 2010 16:16:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Motin References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> Date: Tue, 27 Apr 2010 16:16:29 +0200 In-Reply-To: <4BD6EDD6.8010403@FreeBSD.org> (Alexander Motin's message of "Tue, 27 Apr 2010 16:59:50 +0300") Message-ID: <86fx2h3rr6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 14:17:03 -0000 Alexander Motin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. which can improve performance considerably. You > > can't access those from GEOM. > Have you ever seen them documented? ISTR I got the info from sos@ at some point. I have several Promise cards lying around and was working onm RAID5 offloading, but I stopped when ZFS became usable. > Does the need to specifically handle dozens of incompatible > implementations with limited resources worth those (probably not > major) benefits? The details probably vary from controller to controller, but the capabilities are pretty much the same: perform the same write operation to several disks at once, split a write operation across several disks, compute and write parity. IIRC, composite writes are already supported but not used. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:41: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 D2DC81065672; Tue, 27 Apr 2010 14:41:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC1F8FC19; Tue, 27 Apr 2010 14:41:45 +0000 (UTC) Received: by ewy24 with SMTP id 24so4022603ewy.33 for ; Tue, 27 Apr 2010 07:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CnFhT2EW2zhgVncf+lxqj47R4Wi90gKpDctsVM23k00=; b=HrPE5Jc726ixDcqg1mnLYWhXVGO5vesG5C9IhAa8+kJQdICk3zG7YqXbwYsP6lqvcp DXV8oxfwh1o1SqOcIXXHqSCXgF35TIv7n7c8kQzBQlbwWglSoeXMc97zKoDBOW8xs3Uy LxiCwsU/n1fsprVv19uHfVKXeFc2LdxdxBhRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Lw0hXWLIfD6Y6hNF5RjrdaQ9eq4xdVKSN7+Qcs64mOfy3ANFgOn1Us8YX2CNkLa+SV MA9PqXMy3rKysXhho5xEtDKwzLeXkL1b2FFdpj1V8UZHiBq82V2Wu9ptQhN0jaOvpGDT sn1kbh5iKluGZg7HTVAQDpE3Cm9uo7AS6Sjmk= Received: by 10.102.216.24 with SMTP id o24mr3225033mug.67.1272379301653; Tue, 27 Apr 2010 07:41:41 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e10sm22401360muf.8.2010.04.27.07.41.40 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 07:41:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6F797.5090205@FreeBSD.org> Date: Tue, 27 Apr 2010 17:41:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> <86fx2h3rr6.fsf@ds4.des.no> In-Reply-To: <86fx2h3rr6.fsf@ds4.des.no> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 14:41:47 -0000 Dag-Erling Smørgrav wrote: > Alexander Motin writes: >> Dag-Erling Smørgrav writes: >>> Most pseudo-raid kit has nifty features like checksum offloading, >>> composite writes etc. which can improve performance considerably. You >>> can't access those from GEOM. >> Have you ever seen them documented? > > ISTR I got the info from sos@ at some point. I have several Promise > cards lying around and was working onm RAID5 offloading, but I stopped > when ZFS became usable. Out Promise driver doesn't even have ATAPI support, not speaking about more advanced features. >> Does the need to specifically handle dozens of incompatible >> implementations with limited resources worth those (probably not >> major) benefits? > > The details probably vary from controller to controller, but the > capabilities are pretty much the same: perform the same write operation > to several disks at once, split a write operation across several disks, > compute and write parity. > > IIRC, composite writes are already supported but not used. I haven't dug really deep into current ataraid(4), but AFAIK it is all done in software. At least there is no any offloading support on the controller drivers level. None of ata(4) drivers do anything except executing one ATA command at a time. Looking that most of modern controllers threat every SATA channel independently, with separate request queue, status, interrupts and so on, I can hardly imagine how could they partially accelerate such things. The only alike example I know is a parity calculation accelerator in Marvel ARM SoCs. But it is completely separate device, unrelated to SATA controller. Any URLs? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:49:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4B91065670; Tue, 27 Apr 2010 14:49:35 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D3BEF8FC15; Tue, 27 Apr 2010 14:49:34 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3REnQFU003767; Tue, 27 Apr 2010 08:49:26 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <86och53tpl.fsf@ds4.des.no> Date: Tue, 27 Apr 2010 08:49:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <70151EE0-AD49-4BB3-ADEB-68447A36D88A@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-0.4 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD, URIBL_SBL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 14:49:35 -0000 On Apr 27, 2010, at 7:34 AM, Dag-Erling Sm=F8rgrav wrote: > Maxim Sobolev writes: >> Richard Tector writes: >>> Could I also add that the removal of ataraid would affect those >>> users who dual-boot with Windows and rely on the psuedo-raid >>> provided by most Intel chipsets to be able to share the same pair of >>> disks. >> Well, this won't be a problem if we have GEOM classes that can >> understand metadata created by the ATA RAID BIOS(es). >=20 > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. which can improve performance considerably. You > can't access those from GEOM. If my "most" you mean "a small subset of vendors and products", then = yes, you're correct. For the vast remaining majority, all you get is a = special BIOS that can do striping and mirroring at boot. Sometimes that = special BIOS requires a special hook in the controller chip, which is = why you have ICHxxR vs ICHxx chips, for example. All the 'R' means is = that the silicon supports an external ROM. Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 16:51:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB81A106564A; Tue, 27 Apr 2010 16:51:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 650898FC23; Tue, 27 Apr 2010 16:51:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1925D46B52; Tue, 27 Apr 2010 12:51:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 1C8BE8A026; Tue, 27 Apr 2010 12:51:42 -0400 (EDT) From: John Baldwin To: Maxim Sobolev Date: Tue, 27 Apr 2010 12:04:43 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BCD5A7B.2070505@FreeBSD.org> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> In-Reply-To: <4BD0AC89.5080306@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004271204.43057.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 12:51:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 16:51:43 -0000 On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote: > John Baldwin wrote: > > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: > >> John Baldwin wrote: > >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: > >>>> Maxim Sobolev wrote: > >>>>> There is already a code to detect non-existing AT keyboard and avoid > >>>>> attaching atkbd to it. The code is i386-only at the moment, I am trying > >>>>> to figure out how to modify it so that it works on amd64 as well. > >>>> Looks like this huge delay is caused by the inb() being astonishingly > >>>> slow, which is not factored by the timeout routines. Reading keyboard > >>>> status port once takes about 0.003s! I am not sure if it's common > >>>> behaviour of the platform, or something specific to this particular > >>>> model. Do you know by any chance? > >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so > >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have > >>> any BIOS options related to the USB legacy compat? I know of the Nehalem > >>> systems I've seen they have a separate option for controlling port 60/64 > >>> emulation which we leave disabled by default. > >> That makes sense. Unfortunately I don't have access to the BIOS > >> settings. This is a hosted system, and the provider keeps BIOS password > >> for themselves. > >> > >> I have a patch that fixes that issue by measuring status register > >> reading time first and then factoring it in the calculations of the > >> number of retries: > >> > >> http://sobomax.sippysoft.com/atkbdc.diff > >> > >> It also applies the same logic to detect broken/non-existing keyboard > >> controller to amd64 as we do to the i386. I'd appreciate if you can do a > >> review. > > > > Hmm, not all i386 CPUs that we support have a TSC. Is the change to > > atkbdc_isa.c sufficient to fix the hang? If so, I'd rather just commit that > > bit and leave out the read_delay changes. > > No, it's not sufficient. The problem here is that for some reason that > test passes on that system (probably emulation works) and so that normal > keyboard attach routine is invoked early in boot, when we don't even > have clock initialized. What if I make TSC-related changes amd64? Will > that be OK? Hmm, I think you should definitely commit the atkbdc_isa.c change first of all. I'm still thinking about the other change. I wonder if we can figure out that a keyboard isn't present sooner somehow? Do you know if the keyboard appears to be present but just slow vs if the keyboard is eventually found to not be present? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 19:11: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 81A46106566B; Tue, 27 Apr 2010 19:11:16 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id 148678FC21; Tue, 27 Apr 2010 19:11:15 +0000 (UTC) Received: by gxk3 with SMTP id 3so6506132gxk.13 for ; Tue, 27 Apr 2010 12:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wLIiXEurL8yw2+osM0n1WDNl9puV9hbXmD483far+6g=; b=bvtwVRMnvQgEjWwJx22FMGrOr7aTgIxVYzIxs/JQLlW7IA6y1J4zeTStiKBpz7rrPe 943+T3G/vRU5CA6PTp2idUmNOLS7FK49b0+005k2yk12Io1x/Ca0Q5B2VxBh4UvIVFqT SOLvFw34P4JdgerW+fwje8UZJAnuXKXttUsis= 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=T1jnnnXJ78NymGpqq1POrhJnKTbrq9PXttxw3ipIqF4YGjvVdIh3fds7zGvK5mVb6J +G5KHOsryACtzhyNirosboc6i6IzGaZeB6TnnjJ03XNqjt9WC7ZQQc8x9BgZIiQZ1GCu RlWutYnztmoxDEUSXQ2GTqrgWTBkFIhOaNwlo= MIME-Version: 1.0 Received: by 10.101.116.2 with SMTP id t2mr1551541anm.242.1272395470508; Tue, 27 Apr 2010 12:11:10 -0700 (PDT) Received: by 10.100.194.19 with HTTP; Tue, 27 Apr 2010 12:11:10 -0700 (PDT) In-Reply-To: <201004271204.43057.jhb@freebsd.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> Date: Tue, 27 Apr 2010 15:11:10 -0400 Message-ID: From: Alexander Sack To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 19:11:16 -0000 On Tue, Apr 27, 2010 at 12:04 PM, John Baldwin wrote: > On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote: >> John Baldwin wrote: >> > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: >> >> John Baldwin wrote: >> >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: >> >>>> Maxim Sobolev wrote: >> >>>>> There is already a code to detect non-existing AT keyboard and avo= id >> >>>>> attaching atkbd to it. The code is i386-only at the moment, I am > trying >> >>>>> to figure out how to modify it so that it works on amd64 as well. >> >>>> Looks like this huge delay is caused by the inb() being astonishing= ly >> >>>> slow, which is not factored by the timeout routines. Reading keyboa= rd >> >>>> status port once takes about 0.003s! I am not sure if it's common >> >>>> behaviour of the platform, or something specific to this particular >> >>>> model. Do you know by any chance? >> >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboar= d > ports so >> >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. = =A0Do > you have >> >>> any BIOS options related to the USB legacy compat? =A0I know of the > Nehalem >> >>> systems I've seen they have a separate option for controlling port 6= 0/64 >> >>> emulation which we leave disabled by default. >> >> That makes sense. Unfortunately I don't have access to the BIOS >> >> settings. This is a hosted system, and the provider keeps BIOS passwo= rd >> >> for themselves. >> >> >> >> I have a patch that fixes that issue by measuring status register >> >> reading time first and then factoring it in the calculations of the >> >> number of retries: >> >> >> >> http://sobomax.sippysoft.com/atkbdc.diff >> >> >> >> It also applies the same logic to detect broken/non-existing keyboard >> >> controller to amd64 as we do to the i386. I'd appreciate if you can d= o a >> >> review. >> > >> > Hmm, not all i386 CPUs that we support have a TSC. =A0Is the change to >> > atkbdc_isa.c sufficient to fix the hang? =A0If so, I'd rather just com= mit > that >> > bit and leave out the read_delay changes. >> >> No, it's not sufficient. The problem here is that for some reason that >> test passes on that system (probably emulation works) and so that normal >> keyboard attach routine is invoked early in boot, when we don't even >> have clock initialized. What if I make TSC-related changes amd64? Will >> that be OK? > > Hmm, I think you should definitely commit the atkbdc_isa.c change first o= f > all. =A0I'm still thinking about the other change. =A0I wonder if we can = figure > out that a keyboard isn't present sooner somehow? =A0Do you know if the k= eyboard > appears to be present but just slow vs if the keyboard is eventually foun= d to > not be present? S5520UR, Intel BIOS 48 (last 2 digits), Build 2/27/10. If I disable 60/64 emulation the box refuses to go into the BIOS or boot anything. The BIOS just simply hangs after the Intel logo screen. This just seems like a bug. On the last generation Alcolu based machines, we usually have 60/64h emulation disabled which works just fine (USB Legacy Mode is still enabled so things like the debugger still/kinda/sorta work). I will work through our Intel channels to have them look at this (we already discovered some other bugs with respect to flashing and RMM3). I am looking at the atkbd driver for the first time. It would seem to me at first glance that John makes a very good point: there is already code to deal with a lack of a keyboard in the i386 code. I would *assume* that turning it on for amd64 would be all that is necessar= y? Btw these systems also fail other keyboard related tests. I also see: "atkbd: unable to set the command byte." On all Nehalem systems (this might be less serious given the OS has taken over from the BIOS). I am testing a variant of Maxim's patch right now. Stay tuned, -aps From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 19:11: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 315EA1065677; Tue, 27 Apr 2010 19:11:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E2A698FC1D; Tue, 27 Apr 2010 19:11:27 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3RJBM5T004732; Tue, 27 Apr 2010 13:11:23 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Tue, 27 Apr 2010 13:11:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BD06BD9.6030401@FreeBSD.org> To: Luke Dean X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 19:11:28 -0000 On Apr 26, 2010, at 11:39 PM, Luke Dean wrote: >=20 >=20 > On Thu, 22 Apr 2010, Alexander Motin wrote: >=20 >> So what is the public opinion: Is the lack of ataraid(4) fatal or we = can >> live without it? >=20 > Hardware mirroring is very important to me. It's the only solution = I'm aware of for realtime protection from drive failure in systems that = boot multiple operating systems. ATARAID doesn't do hardware mirroring. If you need that feature, buy an = MPT card or a real RAID controller. Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 19:13: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 D33031065674; Tue, 27 Apr 2010 19:13:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 752A88FC1B; Tue, 27 Apr 2010 19:13:41 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3RJDb8h004747; Tue, 27 Apr 2010 13:13:37 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <1272367989.97887.47.camel@buffy.york.ac.uk> Date: Tue, 27 Apr 2010 13:13:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <31A502A0-DB53-4677-BF92-6DD826ED449C@samsco.org> References: <4BD06BD9.6030401@FreeBSD.org> <20100426.103327.319083499807534535.imp@bsdimp.com> <1272367989.97887.47.camel@buffy.york.ac.uk> To: Gavin Atkinson X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org, "M. Warner Losh" , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 19:13:41 -0000 On Apr 27, 2010, at 5:33 AM, Gavin Atkinson wrote: > On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: >> My opinion for the path forward: >> (1) Send a big heads up about the future of ataraid(5). It will be >> shot in the head soon, to be replaced be a bunch of geom classes >> for each different container format. At least that seems to be >> the rough consensus I've seen so far. We need worker bees to do >> many of these classes, although much can be mined from the ataraid >> code today. >=20 > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror = from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. >=20 > ataraid depends on knowing a lot about the underlying hardware, in = order > to know which format of metadata to use. i.e. it needs to know that = the > disks are attached to (say) a Highpoint controller. This is unfortunately true, especially on older controllers. I think = that there are reasonable ways to address this though, by having CAM SIMs provide a bit more information in their PATH_INQ response. Scott From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 20:26: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 0472E106566B; Tue, 27 Apr 2010 20:26:05 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id A0F2D8FC15; Tue, 27 Apr 2010 20:26:04 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3RKPwpM064698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 13:25:59 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BD74861.30603@FreeBSD.org> Date: Tue, 27 Apr 2010 13:26:09 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Baldwin References: <4BCD5A7B.2070505@FreeBSD.org> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> In-Reply-To: <201004271204.43057.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 20:26:05 -0000 John Baldwin wrote: > Hmm, I think you should definitely commit the atkbdc_isa.c change first of > all. I'm still thinking about the other change. I wonder if we can figure > out that a keyboard isn't present sooner somehow? Do you know if the keyboard > appears to be present but just slow vs if the keyboard is eventually found to > not be present? Our syscons does keyboard probing two times - once early during kernel initialization before most of the subsystems have been initialized yet, and then "real" probing later in boot process. Interesting thing is that initially keyboard looks present. Reading status port in atkbdc_configure() gives value other than 0xff, although reading is thousand times slower than usually. This causes syscons try attaching it. Even though reading status port works, apparently either emulation is not complete or there is some other issue, so that it never responds to some commands. Slow access and lack of response results in wait_for_data() function waiting several minutes instead of 200ms as designed. This what causes that 6-10 minutes delay in boot process. In fact I've also tried sending 0xAA command instead of just checking that value read from the status port is not 0xFF, and it actually completed fine at this point. The controller has returned 0x55 as expected. Therefore, I believe measuring inb() delay is the only reasonable way to avoid that big boot delay at this point. Later on, when we probe/attach keyboard second time (in atkbdc_isa.c) reading status port returns 0xff, so the we can fail attachment process immediately. However, this is not a big issue since at this point reading from status port is as fast as any other ISA inb() operations, so it doesn't cause any noticeable delay. Here is the latest version of the patch: http://sobomax.sippysoft.com/atkbdc.diff -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 20:55: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 CF55B1065670; Tue, 27 Apr 2010 20:55:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB4F8FC15; Tue, 27 Apr 2010 20:55:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 27C0D46B38; Tue, 27 Apr 2010 16:55:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 292EE8A01F; Tue, 27 Apr 2010 16:55:53 -0400 (EDT) From: John Baldwin To: Maxim Sobolev Date: Tue, 27 Apr 2010 16:54:07 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BCD5A7B.2070505@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> <4BD74861.30603@FreeBSD.org> In-Reply-To: <4BD74861.30603@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004271654.07340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 16:55:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 20:55:55 -0000 On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: > John Baldwin wrote: > > Hmm, I think you should definitely commit the atkbdc_isa.c change first of > > all. I'm still thinking about the other change. I wonder if we can figure > > out that a keyboard isn't present sooner somehow? Do you know if the keyboard > > appears to be present but just slow vs if the keyboard is eventually found to > > not be present? > > Our syscons does keyboard probing two times - once early during kernel > initialization before most of the subsystems have been initialized yet, > and then "real" probing later in boot process. Interesting thing is that > initially keyboard looks present. Reading status port in > atkbdc_configure() gives value other than 0xff, although reading is > thousand times slower than usually. This causes syscons try attaching > it. Even though reading status port works, apparently either emulation > is not complete or there is some other issue, so that it never responds > to some commands. Slow access and lack of response results in > wait_for_data() function waiting several minutes instead of 200ms as > designed. This what causes that 6-10 minutes delay in boot process. I believe the USB driver has disabled the keyboard emulation by the time the second probe happens in syscons. Can you try disabling legacy USB support in the BIOS just to make sure that is what causes the delay? > In fact I've also tried sending 0xAA command instead of just checking > that value read from the status port is not 0xFF, and it actually > completed fine at this point. The controller has returned 0x55 as > expected. Therefore, I believe measuring inb() delay is the only > reasonable way to avoid that big boot delay at this point. > > Later on, when we probe/attach keyboard second time (in atkbdc_isa.c) > reading status port returns 0xff, so the we can fail attachment process > immediately. However, this is not a big issue since at this point > reading from status port is as fast as any other ISA inb() operations, > so it doesn't cause any noticeable delay. > > Here is the latest version of the patch: > > http://sobomax.sippysoft.com/atkbdc.diff Hmm, still has the issue that we can't assume a TSC on i386. I would still commit the easy bits to change various '#if defined(__i386__)' to '#if defined(__i386__) || defined(__amd64__)' now. One thing that could make this cleaner would be to have a macro defined something like this in atkbdc.c: /* CPU will stay inside loops for 100msec at most. */ #ifdef __amd64__ #define KBD_RETRY(kbd) (100000 / ((KBDD_DELAYTIME * 2) + kbdc->read_delay)) #else #define KBD_RETRY(kbd) (5000) #endif and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:06: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 D978B106567C; Tue, 27 Apr 2010 21:06:29 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 997E88FC18; Tue, 27 Apr 2010 21:06:29 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3RL6PGR064914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 14:06:26 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BD751DD.80407@FreeBSD.org> Date: Tue, 27 Apr 2010 14:06:37 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Baldwin References: <4BCD5A7B.2070505@FreeBSD.org> <201004271204.43057.jhb@freebsd.org> <4BD74861.30603@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> In-Reply-To: <201004271654.07340.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 21:06:30 -0000 John Baldwin wrote: > On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: >> John Baldwin wrote: >>> Hmm, I think you should definitely commit the atkbdc_isa.c change first of >>> all. I'm still thinking about the other change. I wonder if we can figure >>> out that a keyboard isn't present sooner somehow? Do you know if the keyboard >>> appears to be present but just slow vs if the keyboard is eventually found to >>> not be present? >> Our syscons does keyboard probing two times - once early during kernel >> initialization before most of the subsystems have been initialized yet, >> and then "real" probing later in boot process. Interesting thing is that >> initially keyboard looks present. Reading status port in >> atkbdc_configure() gives value other than 0xff, although reading is >> thousand times slower than usually. This causes syscons try attaching >> it. Even though reading status port works, apparently either emulation >> is not complete or there is some other issue, so that it never responds >> to some commands. Slow access and lack of response results in >> wait_for_data() function waiting several minutes instead of 200ms as >> designed. This what causes that 6-10 minutes delay in boot process. > > I believe the USB driver has disabled the keyboard emulation by the time the > second probe happens in syscons. Can you try disabling legacy USB support in > the BIOS just to make sure that is what causes the delay? Unfortunately it's not possible. Hosting provider doesn't allow me to have access to BIOS settings. >> In fact I've also tried sending 0xAA command instead of just checking >> that value read from the status port is not 0xFF, and it actually >> completed fine at this point. The controller has returned 0x55 as >> expected. Therefore, I believe measuring inb() delay is the only >> reasonable way to avoid that big boot delay at this point. >> >> Later on, when we probe/attach keyboard second time (in atkbdc_isa.c) >> reading status port returns 0xff, so the we can fail attachment process >> immediately. However, this is not a big issue since at this point >> reading from status port is as fast as any other ISA inb() operations, >> so it doesn't cause any noticeable delay. >> >> Here is the latest version of the patch: >> >> http://sobomax.sippysoft.com/atkbdc.diff > > Hmm, still has the issue that we can't assume a TSC on i386. I would still > commit the easy bits to change various '#if defined(__i386__)' to > '#if defined(__i386__) || defined(__amd64__)' now. > > One thing that could make this cleaner would be to have a macro defined > something like this in atkbdc.c: > > /* CPU will stay inside loops for 100msec at most. */ > #ifdef __amd64__ > #define KBD_RETRY(kbd) (100000 / ((KBDD_DELAYTIME * 2) + kbdc->read_delay)) > #else > #define KBD_RETRY(kbd) (5000) > #endif > > and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places. Please take a closer look. Use of rdtsc() in this version is conditonal on __amd64__ only. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:19:02 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 837E0106564A; Tue, 27 Apr 2010 21:19:02 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEFCF8FC1A; Tue, 27 Apr 2010 21:19:01 +0000 (UTC) Received: by wwb17 with SMTP id 17so20911wwb.13 for ; Tue, 27 Apr 2010 14:18: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=s7wj17FtDmJotQf7KyCCUfq9FVGERP0cmUxfM3vh4SA=; b=SZmuPS3A4vmzyxcHXQyVTvbBH2ro1bqjWkar/azKiiLhHZTx/e54/XrFkB5eFavwSu 2to16VSIEpA732JEtYGMugGp0Rzj7LoRaRJkVQLRv1pn6as/Vvl/+8ii9cuDV8dxwpJ8 DHZzckK9tOK/6/z5XEYHeuQSrtkmZXVO4DDQs= 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=qA2TGJLTHNeIHnNvFLTyG7G56aBCQNQst6DirboeKIPf1dtITEMaJahxcSQbPUjN8R lrjsQBa6TbKGtTLpOD7CPbvK8OlBW01qPyAdNhOPE8XqK9evt1LuEb6Yy3GVu12o2zao wUoU8nmrzXe10XmQYqhXllnADt/1McSdhSHQA= MIME-Version: 1.0 Received: by 10.216.87.140 with SMTP id y12mr1734811wee.36.1272403136994; Tue, 27 Apr 2010 14:18:56 -0700 (PDT) Received: by 10.216.49.76 with HTTP; Tue, 27 Apr 2010 14:18:56 -0700 (PDT) In-Reply-To: References: <4BC9E254.9070300@freebsd.org> Date: Tue, 27 Apr 2010 21:18:56 +0000 Message-ID: From: Paul B Mahol To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 21:19:02 -0000 On 4/19/10, Paul B Mahol wrote: > On 4/19/10, Tom Evans wrote: >> On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol wrote: >>> On 4/17/10, Paul B Mahol wrote: >>>> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle >>>> wrote: >>>>> Paul B Mahol wrote: >>>>>> >>>>>> It is apparently not possible to make use of -use-the-force-luke=4gms >>>>>> on FreeBSD when appending new session after 4GB. Mounted disk >>>>>> afterwards show nothing. >>>>>> >>>>>> Should we allow it like linux does? >>>>> >>>>> Are you claiming there is a problem when FreeBSD reads such >>>>> images or a problem with creating such images? What >>>>> programs are you using? >>>> >>>> I burn flac files in multiple sessions, each session have separate >>>> directory, on DVD+R DL MKM/003 >>>> After I used 4gms switch mounted fs shows nothing. (but there is >5GB >>>> of >>>> data) >>>> >>>> According to growisofs source BD (bluray) dont need this switch at all >>>> ... >>>> >>>>> This sounds like a pretty unsurprising 32-bit truncation >>>>> bug: the filesystem structures in ISO9660 are all sector >>>>> numbers so 8TB should be the natural limit (4G sectors >>>>> times 2k bytes/sector). >>>> >>>> I did not tested this on FreeBSD amd64 yet. >>> >>> Update: Linux shows all sessions and Windows 7 shows only first one. >> >> >> From the source code of groisofs.c: >> >> * - DVD+R Double Layer support; >> * - -use-the-force-luke=4gms to allow ISO9660 directory structures >> * to cross 4GB boundary, the option is effective only with DVD+R DL >> * and for data to be accessible under Linux isofs a kernel patch is >> * required; >> >> So I'm guessing it does something non standard, particularly if >> windows also refuses to see the data. > > That is pretty old, from 2.4 era, it was added after it was found that > isofs had bug. Windows at least "try" to show something - only one > session, but fourth and not second session crossed 4GB limit. > > The source also claims that in BD case there is no need for _force_ > switch at all. > Mounting with -norrip shows all sessions. Kernel displays "RRIP without PX field?" if I try to mount "normal" way. From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:27:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA2B106566C; Tue, 27 Apr 2010 21:27:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D09888FC16; Tue, 27 Apr 2010 21:27:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 63DD346B09; Tue, 27 Apr 2010 17:27:54 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 43D338A021; Tue, 27 Apr 2010 17:27:53 -0400 (EDT) From: John Baldwin To: Maxim Sobolev Date: Tue, 27 Apr 2010 17:25:36 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> <4BD751DD.80407@FreeBSD.org> In-Reply-To: <4BD751DD.80407@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004271725.36518.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 27 Apr 2010 17:27:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 21:27:55 -0000 On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote: > John Baldwin wrote: > > On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: > >> John Baldwin wrote: > >>> Hmm, I think you should definitely commit the atkbdc_isa.c change first of > >>> all. I'm still thinking about the other change. I wonder if we can figure > >>> out that a keyboard isn't present sooner somehow? Do you know if the keyboard > >>> appears to be present but just slow vs if the keyboard is eventually found to > >>> not be present? > >> Our syscons does keyboard probing two times - once early during kernel > >> initialization before most of the subsystems have been initialized yet, > >> and then "real" probing later in boot process. Interesting thing is that > >> initially keyboard looks present. Reading status port in > >> atkbdc_configure() gives value other than 0xff, although reading is > >> thousand times slower than usually. This causes syscons try attaching > >> it. Even though reading status port works, apparently either emulation > >> is not complete or there is some other issue, so that it never responds > >> to some commands. Slow access and lack of response results in > >> wait_for_data() function waiting several minutes instead of 200ms as > >> designed. This what causes that 6-10 minutes delay in boot process. > > > > I believe the USB driver has disabled the keyboard emulation by the time the > > second probe happens in syscons. Can you try disabling legacy USB support in > > the BIOS just to make sure that is what causes the delay? > > Unfortunately it's not possible. Hosting provider doesn't allow me to > have access to BIOS settings. Hmm, ok. > >> In fact I've also tried sending 0xAA command instead of just checking > >> that value read from the status port is not 0xFF, and it actually > >> completed fine at this point. The controller has returned 0x55 as > >> expected. Therefore, I believe measuring inb() delay is the only > >> reasonable way to avoid that big boot delay at this point. > >> > >> Later on, when we probe/attach keyboard second time (in atkbdc_isa.c) > >> reading status port returns 0xff, so the we can fail attachment process > >> immediately. However, this is not a big issue since at this point > >> reading from status port is as fast as any other ISA inb() operations, > >> so it doesn't cause any noticeable delay. > >> > >> Here is the latest version of the patch: > >> > >> http://sobomax.sippysoft.com/atkbdc.diff > > > > Hmm, still has the issue that we can't assume a TSC on i386. I would still > > commit the easy bits to change various '#if defined(__i386__)' to > > '#if defined(__i386__) || defined(__amd64__)' now. > > > > One thing that could make this cleaner would be to have a macro defined > > something like this in atkbdc.c: > > > > /* CPU will stay inside loops for 100msec at most. */ > > #ifdef __amd64__ > > #define KBD_RETRY(kbd) (100000 / ((KBDD_DELAYTIME * 2) + kbdc->read_delay)) > > #else > > #define KBD_RETRY(kbd) (5000) > > #endif > > > > and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places. > > Please take a closer look. Use of rdtsc() in this version is conditonal > on __amd64__ only. Ok, that does look a lot better. I don't like having to use rdtsc() to time the delay but I don't have any better suggestions. I think you should add a block comment above the calibration section to explain why you are doing it (i.e. some BIOSes' PS/2 emulation take a really long time to execute). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:37: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 EAE221065670; Tue, 27 Apr 2010 21:37:11 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF9B8FC17; Tue, 27 Apr 2010 21:37:11 +0000 (UTC) Received: by gxk3 with SMTP id 3so6551994gxk.13 for ; Tue, 27 Apr 2010 14:37:05 -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=KZ8mszOcTkhi6IyQjezQX4cpQMm1xd0sKd+ow72ABPM=; b=Cxmr4sJd1YGz+8bfky0ZKDBvnz8GWOb02XgazZZtgDsbGmIQMqVQvFM6A5I/qmvA8U FEMS24cxyGynpsH6oiJ18JSfyXeOQR+d8ES5QbAHfQlj0H2bY2BeCnJLROcBPYvYv0y0 Tr7ubbiRwgQaloWJwcsadxayi89NZ00AUlSNM= 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=xXrLbUBP08IuV+OWFJmDYKBdcRmJ6pkx7ZMl+hsMn9I/TspPKl7k5QMTy+PvolsuCC Me5WXK8YHbD+LEwsIVxYxmDnHQ1PPfyz8XIYlRis4d+l781wKAfGNXXDh437N3IT+XKa DxogtR5GP+q3bvOlQnvuBnxwq4+RQ9o7o6LFM= MIME-Version: 1.0 Received: by 10.101.125.8 with SMTP id c8mr2425880ann.126.1272404224380; Tue, 27 Apr 2010 14:37:04 -0700 (PDT) Received: by 10.100.194.19 with HTTP; Tue, 27 Apr 2010 14:37:04 -0700 (PDT) In-Reply-To: <201004271725.36518.jhb@freebsd.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> <4BD751DD.80407@FreeBSD.org> <201004271725.36518.jhb@freebsd.org> Date: Tue, 27 Apr 2010 17:37:04 -0400 Message-ID: From: Alexander Sack To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 21:37:12 -0000 On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote: > On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote: >> John Baldwin wrote: >> > On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: >> >> John Baldwin wrote: >> >>> Hmm, I think you should definitely commit the atkbdc_isa.c change fi= rst of >> >>> all. =A0I'm still thinking about the other change. =A0I wonder if we= can figure >> >>> out that a keyboard isn't present sooner somehow? =A0Do you know if = the keyboard >> >>> appears to be present but just slow vs if the keyboard is eventually= found to >> >>> not be present? >> >> Our syscons does keyboard probing two times - once early during kerne= l >> >> initialization before most of the subsystems have been initialized ye= t, >> >> and then "real" probing later in boot process. Interesting thing is t= hat >> >> initially keyboard looks present. Reading status port in >> >> atkbdc_configure() gives value other than 0xff, although reading is >> >> thousand times slower than usually. This causes syscons try attaching >> >> it. Even though reading status port works, apparently either emulatio= n >> >> is not complete or there is some other issue, so that it never respon= ds >> >> to some commands. Slow access and lack of response results in >> >> wait_for_data() function waiting several minutes instead of 200ms as >> >> designed. This what causes that 6-10 minutes delay in boot process. >> > >> > I believe the USB driver has disabled the keyboard emulation by the ti= me the >> > second probe happens in syscons. =A0Can you try disabling legacy USB s= upport in >> > the BIOS just to make sure that is what causes the delay? >> >> Unfortunately it's not possible. Hosting provider doesn't allow me to >> have access to BIOS settings. Stunt double: I tried it and it has no effect. The waits in atkdbd kills it with or without USB legacy support on. The wait on this machine is about 1-2 minutes before boot. Just another data point. -aps From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:42: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 A4B451065670 for ; Tue, 27 Apr 2010 21:42:55 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAF08FC14 for ; Tue, 27 Apr 2010 21:42:55 +0000 (UTC) Received: from [77.41.96.17] (port=25617 helo=dc7700p.lissyara.su) by hosting.lissyara.su with esmtpa (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6sYO-000EeG-Pr for current@freebsd.org; Wed, 28 Apr 2010 01:42:52 +0400 Message-ID: <4BD75A5A.7030606@lissyara.su> Date: Wed, 28 Apr 2010 01:42:50 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.9) Gecko/20100403 Thunderbird/3.0.4 MIME-Version: 1.0 References: <4BD6CBE6.9030303@lissyara.su> <4BD6ECBA.6010408@FreeBSD.org> <4BD6EF69.6000105@lissyara.su> <4BD6F0F0.6000204@FreeBSD.org> In-Reply-To: <4BD6F0F0.6000204@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: current@freebsd.org Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 21:42:55 -0000 27.04.2010 18:13, Robert Noland ïèøåò: > > > Alex Keda wrote: >> 27.04.2010 17:55, Robert Noland ïèøåò: >>> >>> >>> Alex Keda wrote: >>>> Following recent changes in dri, xorg server freezes after 20-30 >>>> seconds of work. mouse works, but the image does not change. >>>> process xorg get 100% cpu >>>> if I delete/rename drm.ko - all OK (but, very slow) >>>> >>>> >>>> vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c chip=0x791e1002 >>>> rev=0x00 hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'ATI RADEON X1200 Series (RS690)' >>>> class = display >>>> subclass = VGA >>>> bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, size >>>> 134217728, enabled >>>> bar [18] = type Memory, range 64, base 0xd8500000, size 65536, enabled >>>> bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled >>>> bar [24] = type Memory, range 32, base 0xd8400000, size 1048576, >>>> enabled >>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 05[80] = MSI supports 1 message, 64 bit >>> >>> Ok, does this patch help? >> yes. I work without freeze more than 3 minutes =)) > > How about this one? it use with previous patch, or without it? From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 21:54: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 55B56106566B for ; Tue, 27 Apr 2010 21:54:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 227F98FC0C for ; Tue, 27 Apr 2010 21:54:56 +0000 (UTC) Received: from [10.170.20.44] (nat-170-142-177-44.tn.gov [170.142.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o3RLssGb079876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 17:54:55 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BD75D1D.806@FreeBSD.org> Date: Tue, 27 Apr 2010 16:54:37 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Alex Keda References: <4BD6CBE6.9030303@lissyara.su> <4BD6ECBA.6010408@FreeBSD.org> <4BD6EF69.6000105@lissyara.su> <4BD6F0F0.6000204@FreeBSD.org> <4BD75A5A.7030606@lissyara.su> In-Reply-To: <4BD75A5A.7030606@lissyara.su> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: current@freebsd.org Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 21:54:57 -0000 Alex Keda wrote: > 27.04.2010 18:13, Robert Noland ïèøåò: >> >> >> Alex Keda wrote: >>> 27.04.2010 17:55, Robert Noland ïèøåò: >>>> >>>> >>>> Alex Keda wrote: >>>>> Following recent changes in dri, xorg server freezes after 20-30 >>>>> seconds of work. mouse works, but the image does not change. >>>>> process xorg get 100% cpu >>>>> if I delete/rename drm.ko - all OK (but, very slow) >>>>> >>>>> >>>>> vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c chip=0x791e1002 >>>>> rev=0x00 hdr=0x00 >>>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>>> device = 'ATI RADEON X1200 Series (RS690)' >>>>> class = display >>>>> subclass = VGA >>>>> bar [10] = type Prefetchable Memory, range 64, base 0xd0000000, size >>>>> 134217728, enabled >>>>> bar [18] = type Memory, range 64, base 0xd8500000, size 65536, enabled >>>>> bar [20] = type I/O Port, range 32, base 0x1100, size 256, enabled >>>>> bar [24] = type Memory, range 32, base 0xd8400000, size 1048576, >>>>> enabled >>>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>>> cap 05[80] = MSI supports 1 message, 64 bit >>>> >>>> Ok, does this patch help? >>> yes. I work without freeze more than 3 minutes =)) >> >> How about this one? > it use with previous patch, or without it? Try this one by itself. robert. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 22:59:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD9D106564A; Tue, 27 Apr 2010 22:59:39 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E4A7E8FC1B; Tue, 27 Apr 2010 22:59:38 +0000 (UTC) Received: from park.js.berklix.net (p549A68DA.dip.t-dialin.net [84.154.104.218]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o3RMLWbH093135; Tue, 27 Apr 2010 22:21:32 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o3RMLL66052967; Wed, 28 Apr 2010 00:21:21 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o3RMKhqZ017168; Wed, 28 Apr 2010 00:21:00 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201004272221.o3RMKhqZ017168@fire.js.berklix.net> To: Paul B Mahol From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 27 Apr 2010 21:18:56 -0000." Date: Wed, 28 Apr 2010 00:20:43 +0200 Sender: jhs@berklix.com Cc: Tom Evans , Tim Kientzle , current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 22:59:39 -0000 Hi, Paul B Mahol wrote: > On 4/19/10, Paul B Mahol wrote: > > On 4/19/10, Tom Evans wrote: > >> On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol wrote: > >>> On 4/17/10, Paul B Mahol wrote: > >>>> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle > >>>> wrote: > >>>>> Paul B Mahol wrote: > >>>>>> > >>>>>> It is apparently not possible to make use of -use-the-force-luke=4gms > >>>>>> on FreeBSD when appending new session after 4GB. Mounted disk > >>>>>> afterwards show nothing. > >>>>>> > >>>>>> Should we allow it like linux does? > >>>>> > >>>>> Are you claiming there is a problem when FreeBSD reads such > >>>>> images or a problem with creating such images? What > >>>>> programs are you using? > >>>> > >>>> I burn flac files in multiple sessions, each session have separate > >>>> directory, on DVD+R DL MKM/003 > >>>> After I used 4gms switch mounted fs shows nothing. (but there is >5GB > >>>> of > >>>> data) > >>>> > >>>> According to growisofs source BD (bluray) dont need this switch at all > >>>> ... > >>>> > >>>>> This sounds like a pretty unsurprising 32-bit truncation > >>>>> bug: the filesystem structures in ISO9660 are all sector > >>>>> numbers so 8TB should be the natural limit (4G sectors > >>>>> times 2k bytes/sector). > >>>> > >>>> I did not tested this on FreeBSD amd64 yet. > >>> > >>> Update: Linux shows all sessions and Windows 7 shows only first one. > >> > >> > >> From the source code of groisofs.c: > >> > >> * - DVD+R Double Layer support; > >> * - -use-the-force-luke=4gms to allow ISO9660 directory structures > >> * to cross 4GB boundary, the option is effective only with DVD+R DL > >> * and for data to be accessible under Linux isofs a kernel patch is > >> * required; > >> > >> So I'm guessing it does something non standard, particularly if > >> windows also refuses to see the data. > > > > That is pretty old, from 2.4 era, it was added after it was found that > > isofs had bug. Windows at least "try" to show something - only one > > session, but fourth and not second session crossed 4GB limit. > > > > The source also claims that in BD case there is no need for _force_ > > switch at all. > > > > Mounting with -norrip shows all sessions. > Kernel displays "RRIP without PX field?" if I try to mount "normal" way. Might this help ? Kernel config /sys/conf/NOTES options UDF #Universal Disk Format My config notes /* Allows DVDs with files > 2 Gig, to avoid: * "ls: file_about_2.5gig.ts: * Value too large to be stored in data type" * ports/sysutils/k3b can use it to write eg 4G+ files. */ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 23:06:38 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29ED9106564A; Tue, 27 Apr 2010 23:06:38 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id CB1798FC13; Tue, 27 Apr 2010 23:06:37 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3RN6X7r065752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 16:06:33 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BD76E04.30604@FreeBSD.org> Date: Tue, 27 Apr 2010 16:06:44 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alexander Sack References: <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> <4BD751DD.80407@FreeBSD.org> <201004271725.36518.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, mj@feral.com, John Baldwin Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Apr 2010 23:06:38 -0000 Alexander Sack wrote: > On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote: >> On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote: >>> John Baldwin wrote: >>>> On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: >>>>> John Baldwin wrote: >>>>>> Hmm, I think you should definitely commit the atkbdc_isa.c change first of >>>>>> all. I'm still thinking about the other change. I wonder if we can figure >>>>>> out that a keyboard isn't present sooner somehow? Do you know if the keyboard >>>>>> appears to be present but just slow vs if the keyboard is eventually found to >>>>>> not be present? >>>>> Our syscons does keyboard probing two times - once early during kernel >>>>> initialization before most of the subsystems have been initialized yet, >>>>> and then "real" probing later in boot process. Interesting thing is that >>>>> initially keyboard looks present. Reading status port in >>>>> atkbdc_configure() gives value other than 0xff, although reading is >>>>> thousand times slower than usually. This causes syscons try attaching >>>>> it. Even though reading status port works, apparently either emulation >>>>> is not complete or there is some other issue, so that it never responds >>>>> to some commands. Slow access and lack of response results in >>>>> wait_for_data() function waiting several minutes instead of 200ms as >>>>> designed. This what causes that 6-10 minutes delay in boot process. >>>> I believe the USB driver has disabled the keyboard emulation by the time the >>>> second probe happens in syscons. Can you try disabling legacy USB support in >>>> the BIOS just to make sure that is what causes the delay? >>> Unfortunately it's not possible. Hosting provider doesn't allow me to >>> have access to BIOS settings. > > Stunt double: I tried it and it has no effect. The waits in atkdbd > kills it with or without USB legacy support on. The wait on this > machine is about 1-2 minutes before boot. Just another data point. Have you tried my patch? Does it help? -Maxim From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 06:27: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 EB1131065672 for ; Wed, 28 Apr 2010 06:27:23 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9058FC0A for ; Wed, 28 Apr 2010 06:27:23 +0000 (UTC) Received: from [195.93.240.106] (port=49934 helo=lissyara.moskb.local) by hosting.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O70jx-0001S0-7b for freebsd-current@freebsd.org; Wed, 28 Apr 2010 10:27:21 +0400 Message-ID: <4BD7D549.6090009@lissyara.su> Date: Wed, 28 Apr 2010 10:27:21 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4BD6CBE6.9030303@lissyara.su> <4BD6ECBA.6010408@FreeBSD.org> <4BD6EF69.6000105@lissyara.su> <4BD6F0F0.6000204@FreeBSD.org> In-Reply-To: <4BD6F0F0.6000204@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-White-List: YES X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 06:27:24 -0000 27.04.2010 18:13, Robert Noland ïèøåò: > > > Alex Keda wrote: >> 27.04.2010 17:55, Robert Noland ïèøåò: >>> >>> >>> Alex Keda wrote: >>>> Following recent changes in dri, xorg server freezes after 20-30 >>>> seconds of work. mouse works, but the image does not change. >>>> process xorg get 100% cpu >>>> if I delete/rename drm.ko - all OK (but, very slow) >>>> >>>> >>>> vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c >>>> chip=0x791e1002 rev=0x00 hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, >>>> Inc.' >>>> device = 'ATI RADEON X1200 Series (RS690)' >>>> class = display >>>> subclass = VGA >>>> bar [10] = type Prefetchable Memory, range 64, base >>>> 0xd0000000, size 134217728, enabled >>>> bar [18] = type Memory, range 64, base 0xd8500000, size >>>> 65536, enabled >>>> bar [20] = type I/O Port, range 32, base 0x1100, size 256, >>>> enabled >>>> bar [24] = type Memory, range 32, base 0xd8400000, size >>>> 1048576, enabled >>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >>>> cap 05[80] = MSI supports 1 message, 64 bit >>> >>> Ok, does this patch help? >> yes. I work without freeze more than 3 minutes =)) > > How about this one? I reverse previous and apply it patch working time more than without it (without ~1 minutes, with last patch ~2-3 minutes), but - one final - Xorg get 100% CPU and freeze From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 07:35: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 3350A106566C; Wed, 28 Apr 2010 07:35:52 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E1B248FC15; Wed, 28 Apr 2010 07:35:51 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 279C21FFC53; Wed, 28 Apr 2010 07:35:50 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A9C8E844F3; Wed, 28 Apr 2010 09:35:17 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Motin References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> <86fx2h3rr6.fsf@ds4.des.no> <4BD6F797.5090205@FreeBSD.org> Date: Wed, 28 Apr 2010 09:35:17 +0200 In-Reply-To: <4BD6F797.5090205@FreeBSD.org> (Alexander Motin's message of "Tue, 27 Apr 2010 17:41:27 +0300") Message-ID: <86wrvst4ga.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 07:35:52 -0000 Alexander Motin writes: > I haven't dug really deep into current ataraid(4), but AFAIK it is all > done in software. At least there is no any offloading support on the > controller drivers level. None of ata(4) drivers do anything except > executing one ATA command at a time. Correct. That doesn't mean they *shouldn't* use offloading. Like I said, I started working on checksum offloading for Promise SATA controllers, but ZFS came along and I replaced the controllers because of data corruption issues (which turned out to be either a driver bug or a PCI timing bug which sos@ worked around in the driver, I forget which) > Any URLs? Google "Promise FastTrak SATA RAID" I have two or three of those, including one with on-board SDRAM (but no battery backup) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 09:18:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3386A1065672; Wed, 28 Apr 2010 09:18:34 +0000 (UTC) (envelope-from fluffy@freebsd.org) Received: from ns.ael.RU (ns.ael.ru [62.76.207.226]) by mx1.freebsd.org (Postfix) with ESMTP id 549728FC1C; Wed, 28 Apr 2010 09:18:32 +0000 (UTC) Received: from Fluffy.Khv.RU (85.9.168.188.retail.ttk.ru [188.168.9.85] (may be forged)) by ns.ael.RU (8.14.3/8.14.3/Fluffy/5.3) with ESMTP id o3S97icR083651; Wed, 28 Apr 2010 20:07:45 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: from Fluffy.Khv.RU (fluffy@localhost [127.0.0.1]) by Fluffy.Khv.RU (8.14.4/8.14.4/Fluffy/5.4.1) with ESMTP id o3S97P0w090231; Wed, 28 Apr 2010 20:07:25 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: (from fluffy@localhost) by Fluffy.Khv.RU (8.14.4/8.14.4/Submit) id o3S97PtW090230; Wed, 28 Apr 2010 20:07:25 +1100 (VLAST) (envelope-from fluffy@freebsd.org) From: Dima Panov Organization: The FreeBSD Project To: freebsd-current@freebsd.org Date: Wed, 28 Apr 2010 20:07:24 +1100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-900010-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100416160818.GA69460@freebsd.org> In-Reply-To: <20100416160818.GA69460@freebsd.org> X-Face: "RE-2'yS-N:*/7DHOjQ%Az<.+SG>K7B'k(&; qb0K4]Hv>J}"l9,=:m2_]-3S/}`b\]yA-g !y3en*Zl(i-86iM?Q[w@!=rW&JdT>KHW@dri>+qMcy42O, 5#izEqa-K+=B<@A X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ns.ael.RU [62.76.207.226]); Wed, 28 Apr 2010 20:07:46 +1100 (VLAST) Cc: Roman Divacky , current@freebsd.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 09:18:34 -0000 On Saturday 17 April 2010 03:08:18 Roman Divacky wrote: > Hi, > > ClangBSD is a branch of FreeBSD that aims at integrating clang > (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. > > Recently, we've achieved the state when clang can compile all of FreeBSD > world on i386/amd64 platforms (including all the C++ apps we have and > itself) and a bootable kernel. Thus we feel that the time has come to ask > the FreeBSD community for wider testing on i386/amd64 (you sure can help > with other platforms too :)). > Great works, thanks! But I have a problem with recently-compiled clangbsd (in chroot) while building lang/ruby18: clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c main.c clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -L. - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a -lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) from ./mkconfig.rb:11:in `require' from ./mkconfig.rb:11 *** Error code 1 host system: [root@Fluffy] ~# uname -a FreeBSD Fluffy.Khv.RU 9.0-900010-CURRENT FreeBSD 9.0-900010-CURRENT #0 r207097M: Fri Apr 23 19:20:05 VLAST 2010 root@Fluffy.Khv.RU:/usr/obj/usr/src/sys/Spot amd64 clangbsd: /base/!svn/ver/206467/projects/clangbsd/sys -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 KDE@FreeBSD Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 09:18: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 3386A1065672; Wed, 28 Apr 2010 09:18:34 +0000 (UTC) (envelope-from fluffy@freebsd.org) Received: from ns.ael.RU (ns.ael.ru [62.76.207.226]) by mx1.freebsd.org (Postfix) with ESMTP id 549728FC1C; Wed, 28 Apr 2010 09:18:32 +0000 (UTC) Received: from Fluffy.Khv.RU (85.9.168.188.retail.ttk.ru [188.168.9.85] (may be forged)) by ns.ael.RU (8.14.3/8.14.3/Fluffy/5.3) with ESMTP id o3S97icR083651; Wed, 28 Apr 2010 20:07:45 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: from Fluffy.Khv.RU (fluffy@localhost [127.0.0.1]) by Fluffy.Khv.RU (8.14.4/8.14.4/Fluffy/5.4.1) with ESMTP id o3S97P0w090231; Wed, 28 Apr 2010 20:07:25 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: (from fluffy@localhost) by Fluffy.Khv.RU (8.14.4/8.14.4/Submit) id o3S97PtW090230; Wed, 28 Apr 2010 20:07:25 +1100 (VLAST) (envelope-from fluffy@freebsd.org) From: Dima Panov Organization: The FreeBSD Project To: freebsd-current@freebsd.org Date: Wed, 28 Apr 2010 20:07:24 +1100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-900010-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100416160818.GA69460@freebsd.org> In-Reply-To: <20100416160818.GA69460@freebsd.org> X-Face: "RE-2'yS-N:*/7DHOjQ%Az<.+SG>K7B'k(&; qb0K4]Hv>J}"l9,=:m2_]-3S/}`b\]yA-g !y3en*Zl(i-86iM?Q[w@!=rW&JdT>KHW@dri>+qMcy42O, 5#izEqa-K+=B<@A X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ns.ael.RU [62.76.207.226]); Wed, 28 Apr 2010 20:07:46 +1100 (VLAST) Cc: Roman Divacky , current@freebsd.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 09:18:34 -0000 On Saturday 17 April 2010 03:08:18 Roman Divacky wrote: > Hi, > > ClangBSD is a branch of FreeBSD that aims at integrating clang > (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. > > Recently, we've achieved the state when clang can compile all of FreeBSD > world on i386/amd64 platforms (including all the C++ apps we have and > itself) and a bootable kernel. Thus we feel that the time has come to ask > the FreeBSD community for wider testing on i386/amd64 (you sure can help > with other platforms too :)). > Great works, thanks! But I have a problem with recently-compiled clangbsd (in chroot) while building lang/ruby18: clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c main.c clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -L. - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a -lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) from ./mkconfig.rb:11:in `require' from ./mkconfig.rb:11 *** Error code 1 host system: [root@Fluffy] ~# uname -a FreeBSD Fluffy.Khv.RU 9.0-900010-CURRENT FreeBSD 9.0-900010-CURRENT #0 r207097M: Fri Apr 23 19:20:05 VLAST 2010 root@Fluffy.Khv.RU:/usr/obj/usr/src/sys/Spot amd64 clangbsd: /base/!svn/ver/206467/projects/clangbsd/sys -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 KDE@FreeBSD Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 10:16: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 AB37A1065670 for ; Wed, 28 Apr 2010 10:16:57 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 59B7E8FC1C for ; Wed, 28 Apr 2010 10:16:57 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-198-33.ard.bellsouth.net [72.154.198.33]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o3SAGs9p009082 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 06:16:54 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Keda In-Reply-To: <4BD7D549.6090009@lissyara.su> References: <4BD6CBE6.9030303@lissyara.su> <4BD6ECBA.6010408@FreeBSD.org> <4BD6EF69.6000105@lissyara.su> <4BD6F0F0.6000204@FreeBSD.org> <4BD7D549.6090009@lissyara.su> Content-Type: text/plain; charset="koi8-r" Organization: FreeBSD Date: Wed, 28 Apr 2010 05:16:48 -0500 Message-Id: <1272449808.2452.5.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: xorg hangs after last commits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 10:16:57 -0000 On Wed, 2010-04-28 at 10:27 +0400, Alex Keda wrote: > 27.04.2010 18:13, Robert Noland ÐÉÛÅÔ: > > > > > > Alex Keda wrote: > >> 27.04.2010 17:55, Robert Noland ÐÉÛÅÔ: > >>> > >>> > >>> Alex Keda wrote: > >>>> Following recent changes in dri, xorg server freezes after 20-30 > >>>> seconds of work. mouse works, but the image does not change. > >>>> process xorg get 100% cpu > >>>> if I delete/rename drm.ko - all OK (but, very slow) > >>>> > >>>> > >>>> vgapci0@pci0:1:5:0: class=0x030000 card=0x12ff103c > >>>> chip=0x791e1002 rev=0x00 hdr=0x00 > >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, > >>>> Inc.' > >>>> device = 'ATI RADEON X1200 Series (RS690)' > >>>> class = display > >>>> subclass = VGA > >>>> bar [10] = type Prefetchable Memory, range 64, base > >>>> 0xd0000000, size 134217728, enabled > >>>> bar [18] = type Memory, range 64, base 0xd8500000, size > >>>> 65536, enabled > >>>> bar [20] = type I/O Port, range 32, base 0x1100, size 256, > >>>> enabled > >>>> bar [24] = type Memory, range 32, base 0xd8400000, size > >>>> 1048576, enabled > >>>> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 > >>>> cap 05[80] = MSI supports 1 message, 64 bit > >>> > >>> Ok, does this patch help? > >> yes. I work without freeze more than 3 minutes =)) > > > > How about this one? > I reverse previous and apply it patch > working time more than without it (without ~1 minutes, with last patch > ~2-3 minutes), but - one final - Xorg get 100% CPU and freeze Ok, the IGP chips are strange... Just go with the first patch for now and let it keep snooping... Performance impact shouldn't be substantial. robert. > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 12:16: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 9FB63106566C for ; Wed, 28 Apr 2010 12:16:46 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (unknown [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 50E808FC14 for ; Wed, 28 Apr 2010 12:16:46 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 164AAF91 for ; Wed, 28 Apr 2010 14:16:43 +0200 (CEST) Date: Wed, 28 Apr 2010 14:16:38 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20100428121637.GA61412@roberto-al.eurocontrol.fr> References: <20100416160818.GA69460@freebsd.org> <201004282007.25568.fluffy@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004282007.25568.fluffy@freebsd.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Wed, 28 Apr 2010 14:16:44 +0200 (CEST) Subject: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 12:16:46 -0000 According to Dima Panov: > while building lang/ruby18: Which options to you use? _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 WITHOUT_ONIGURUMA=true WITH_RDOC=true WITHOUT_DEBUG=true I notice your ruby is compiling w/o any -On, try with -O at least? > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include > -c main.c > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -L. - > rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a -lrt > -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > from ./mkconfig.rb:11:in `require' > from ./mkconfig.rb:11 > *** Error code 1 Interesting, using a fairly recent clang snapshot from trunk, I get a sig11 :( -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 12:24: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 9AE28106564A for ; Wed, 28 Apr 2010 12:24:20 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (unknown [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 5022D8FC08 for ; Wed, 28 Apr 2010 12:24:20 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 27E7BFA7 for ; Wed, 28 Apr 2010 14:24:19 +0200 (CEST) Date: Wed, 28 Apr 2010 14:24:17 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20100428122416.GB61412@roberto-al.eurocontrol.fr> References: <20100416160818.GA69460@freebsd.org> <20100422234515.GA6814@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100422234515.GA6814@lor.one-eyed-alien.net> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Wed, 28 Apr 2010 14:24:19 +0200 (CEST) Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 12:24:20 -0000 According to Brooks Davis: > For the foreseeable future, doing anything but using the latest port is a > recipe for problems. The "make BOOTSTRAP=yes makesum" is a wonderful trick, thanks Brooks! -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 12:44: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 7F9B41065670; Wed, 28 Apr 2010 12:44:49 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id DCD988FC17; Wed, 28 Apr 2010 12:44:48 +0000 (UTC) Received: by ewy24 with SMTP id 24so4411411ewy.33 for ; Wed, 28 Apr 2010 05:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=lHKgyG4BAWszoBw84PBhZBbM0Lp8scCDOBLuVTq6aio=; b=WXRLiDPr09iufmg7NmV89yhSHsGp3sNzIU7OUW7/M2wIVtAm+lVMAg2uSQI4by5Bsf ycGVbZ6/qpXYm9Wd3fLFGOMJYgfbbBKBWonFDCQmniafGiGxtpbm1MgV+/sguPqHmqAm fKUDuRNGSC204MDq2e5yu8wsKNLNlKt+xUmJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=PYynWdsx8Eusc9f6YwuKzxvFskE98VN5vr9NjEAP4vLSYL9T0LloR2SOoirvgdzFsh NLurMzGJ9AlFBkv4g2GQ1oMVf/P0lM7kbk7KmiLCL3MhzOhOZbT7ZgBYTFaR/liJuwh8 s8wd+pJFJ7tUHJcNnZNWrCnXUrlf16qgXUeOo= Received: by 10.103.7.28 with SMTP id k28mr4055564mui.25.1272458684174; Wed, 28 Apr 2010 05:44:44 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id s10sm26986527mue.57.2010.04.28.05.44.43 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Apr 2010 05:44:43 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD82DAD.4050804@FreeBSD.org> Date: Wed, 28 Apr 2010 15:44:29 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: FreeBSD-Current , freebsd-arm@FreeBSD.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: New Marvell SATA driver for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 12:44:49 -0000 Hi. I'm glad to present new driver (mvs) for several series of Marvell SATA controllers (PCI-X, PCIe and SoC-integrated), to work with CAM ATA infrastructure. Driver supports following Marvell chips: Gen-I (SATA 1.5Gbps): 88SX5040, 88SX5041, 88SX5080, 88SX5081 Gen-II (SATA 3Gbps, NCQ, PMP): 88SX6040 ,88SX6041 (including Adaptec 1420SA), 88SX6080, 88SX6081 Gen-IIe (SATA 3Gbps, NCQ, PMP with FBS): 88SX6042, 88SX7042 (including Adaptec 1430SA); 88F5182, 88F6281, MV78100 SoCs. , same as atamarvell + ataadaptec + atamvsata legacy ata(4) drivers together. Driver supports most of hardware features, including command queues, NCQ, Port Multipliers, hot-swap, SATA power management, Command Completion Coalescing, Asynchronous Notifications and MSI. Driver also supports ATAPI devices, though it may be not very reliable due to strange ATA shadow registers behavior in these chips. I've successfully tested it with Supermicro SAT2-MV8 (88SX6081) on i386 and sparc64, Adaptec 1430SA (88SX7042) on i386, and SheevaPlug (88F6281) on arm. I haven't tested it on Gen-I chips due to lack of such hardware. Complete fresh patch for HEAD can be found here: http://people.freebsd.org/~mav/mvs.20100328.patch (make sure to run patch with -p to create directories). Testing results, comments and feedback welcome. Special thanks to iXsystems, Inc. for supporting this work. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 15:35: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 0CA95106566B for ; Wed, 28 Apr 2010 15:35:41 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 95B608FC14 for ; Wed, 28 Apr 2010 15:35:40 +0000 (UTC) Received: by ewy24 with SMTP id 24so4522390ewy.33 for ; Wed, 28 Apr 2010 08:35:31 -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=RGRD9zJth2VzaV42GwxPOV5PaMtdPbyR12APgdFzjBs=; b=XH0SYE2Xrc6E6apnUJ4l/Olzu69LCo7BjLYnC24YzDkReKKpJv2YRrhHOS8seMPjdZ BtZXX5E+qZpTdvDECxVdJ8ei/j1X3XP+eZTqWtj/8fjM3+F0rJY/oP/5KetjNPbt3hmO FA7B7bvv2v2OgTWgdN2aPhrI6hw4i7ALHOSuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XUv6SR3xWyb5MXDpoAlI8JqjZV71PFAS78eUbH2I++XD5rwB00aAkKIPluUguCdD5t 7boH2BW5wFAYhH0/WYG9qM8q8FuOLC1aVn+FqKTLXaTsD8jRhNglfUySGR7K0RR0cuia cbp3TRWkw8hskHPzZrAe+M9lkTC/Wd9g5svls= MIME-Version: 1.0 Received: by 10.213.65.74 with SMTP id h10mr1012994ebi.60.1272467241146; Wed, 28 Apr 2010 08:07:21 -0700 (PDT) Received: by 10.213.8.133 with HTTP; Wed, 28 Apr 2010 08:07:21 -0700 (PDT) Date: Wed, 28 Apr 2010 19:07:21 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 15:35:41 -0000 Hello! I have a trouble with my FreeBSD-CURRENT virtual machine running on VmWare ESX server. uname -a prints: FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 04:15:07 UTC 2010 root@host:/usr/obj/usr/src/sys/GENERIC amd64 The problem lies in that FreeBSD hangs after "reboot" command. I see the following on console: http://www.freeimagehosting.net/image.php?8885b3c6ea.png Is it a known problem? Are there any solutions? Thanks in advance! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 15:41: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 EF956106566B for ; Wed, 28 Apr 2010 15:41:05 +0000 (UTC) (envelope-from fluffy@freebsd.org) Received: from ns.ael.RU (ns.ael.ru [62.76.207.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2E12C8FC19 for ; Wed, 28 Apr 2010 15:41:04 +0000 (UTC) Received: from Fluffy.Khv.RU (85.9.168.188.retail.ttk.ru [188.168.9.85] (may be forged)) by ns.ael.RU (8.14.3/8.14.3/Fluffy/5.3) with ESMTP id o3SFexsC099962 for ; Thu, 29 Apr 2010 02:41:01 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: from Fluffy.Khv.RU (fluffy@localhost [127.0.0.1]) by Fluffy.Khv.RU (8.14.4/8.14.4/Fluffy/5.4.1) with ESMTP id o3SFeRX4018063 for ; Thu, 29 Apr 2010 02:40:27 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: (from fluffy@localhost) by Fluffy.Khv.RU (8.14.4/8.14.4/Submit) id o3SFeRaE018062 for freebsd-current@freebsd.org; Thu, 29 Apr 2010 02:40:27 +1100 (VLAST) (envelope-from fluffy@freebsd.org) From: Dima Panov Organization: The FreeBSD Project To: freebsd-current@freebsd.org Date: Thu, 29 Apr 2010 02:40:24 +1100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-900010-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100416160818.GA69460@freebsd.org> <201004282007.25568.fluffy@freebsd.org> <20100428121637.GA61412@roberto-al.eurocontrol.fr> In-Reply-To: <20100428121637.GA61412@roberto-al.eurocontrol.fr> X-Face: "RE-2'yS-N:*/7DHOjQ%Az<.+SG>K7B'k(&; qb0K4]Hv>J}"l9,=:m2_]-3S/}`b\]yA-g !y3en*Zl(i-86iM?Q[w@!=rW&JdT>KHW@dri>+qMcy42O, 5#izEqa-K+=B<@A X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ns.ael.RU [62.76.207.226]); Thu, 29 Apr 2010 02:41:01 +1100 (VLAST) Subject: Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 15:41:06 -0000 On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > According to Dima Panov: > > while building lang/ruby18: > Which options to you use? > > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 > WITHOUT_ONIGURUMA=true > WITH_RDOC=true > WITHOUT_DEBUG=true > > I notice your ruby is compiling w/o any -On, try with -O at least? same here. also on 1.8.7.249 snapshot. ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o dmyext.o clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c main.c clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC -DRUBY_EXPORT -L. -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a - lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] *** Signal 6 Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. *** Error code 1 _OPTIONS_READ=ruby-1.8.7.249,1 WITHOUT_ONIGURUMA=true WITH_RDOC=true WITHOUT_DEBUG=true > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -I. > > -I. -I/usr/include -c main.c > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -L. > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > > from ./mkconfig.rb:11:in `require' > > from ./mkconfig.rb:11 > > > > *** Error code 1 > > Interesting, using a fairly recent clang snapshot from trunk, I get a sig11 > :( Ruby is bad? -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 KDE@FreeBSD Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 17:18:40 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1C0106566B for ; Wed, 28 Apr 2010 17:18:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9FBA98FC19 for ; Wed, 28 Apr 2010 17:18:40 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 5855A1A3DBB; Wed, 28 Apr 2010 10:18:40 -0700 (PDT) Date: Wed, 28 Apr 2010 10:18:40 -0700 From: Alfred Perlstein To: current@freebsd.org Message-ID: <20100428171840.GS35381@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: fixes for enhanced coredump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 17:18:40 -0000 I was recently working on the enhanced coredumps internal to Juniper and realized that there were some defects in the code I pushed (mostly due to mismerge), can someone please review? 1) don't allocate hostname[] on the stack 2) don't leak the temp buffer in imgact_elf_coredump. thank you, -Alfred Index: kern/kern_sig.c =================================================================== --- kern/kern_sig.c (revision 207329) +++ kern/kern_sig.c (working copy) @@ -3004,8 +3004,9 @@ char *temp; size_t i; int indexpos; - char hostname[MAXHOSTNAMELEN]; + char *hostname; + hostname = NULL; format = corefilename; temp = malloc(MAXPATHLEN, M_TEMP, M_NOWAIT | M_ZERO); if (temp == NULL) @@ -3021,6 +3022,19 @@ sbuf_putc(&sb, '%'); break; case 'H': /* hostname */ + if (hostname == NULL) { + hostname = malloc(MAXHOSTNAMELEN, + M_TEMP, M_NOWAIT); + if (hostname == NULL) { + log(LOG_ERR, + "pid %ld (%s), uid (%lu): " + "unable to alloc memory " + "for corefile hostname\n", + (long)pid, name, + (u_long)uid); + goto nomem; + } + } getcredhostname(td->td_ucred, hostname, sizeof(hostname)); sbuf_printf(&sb, "%s", hostname); @@ -3054,9 +3068,10 @@ } #endif if (sbuf_overflowed(&sb)) { - sbuf_delete(&sb); log(LOG_ERR, "pid %ld (%s), uid (%lu): corename is too " "long\n", (long)pid, name, (u_long)uid); +nomem: + sbuf_delete(&sb); free(temp, M_TEMP); return (NULL); } Index: kern/imgact_elf.c =================================================================== --- kern/imgact_elf.c (revision 207329) +++ kern/imgact_elf.c (working copy) @@ -1088,8 +1088,10 @@ hdrsize = 0; __elfN(puthdr)(td, (void *)NULL, &hdrsize, seginfo.count); - if (hdrsize + seginfo.size >= limit) - return (EFAULT); + if (hdrsize + seginfo.size >= limit) { + error = EFAULT; + goto done; + } /* * Allocate memory for building the header, fill it up, @@ -1097,7 +1099,8 @@ */ hdr = malloc(hdrsize, M_TEMP, M_WAITOK); if (hdr == NULL) { - return (EINVAL); + error = EINVAL; + goto done; } error = __elfN(corehdr)(td, vp, cred, seginfo.count, hdr, hdrsize, gzfile); @@ -1125,8 +1128,8 @@ curproc->p_comm, error); } +done: #ifdef COMPRESS_USER_CORES -done: if (core_buf) free(core_buf, M_TEMP); if (gzfile) -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 17:25: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 68F791065670; Wed, 28 Apr 2010 17:25:05 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by mx1.freebsd.org (Postfix) with ESMTP id C7FD48FC13; Wed, 28 Apr 2010 17:25:04 +0000 (UTC) Received: by ywh31 with SMTP id 31so6999903ywh.3 for ; Wed, 28 Apr 2010 10:24:59 -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=ix+N+ZkFCvCs4Fz0wgGbCuhW1CMTylDbPZMBLhrxB1M=; b=jBEc8hfioP/of8zdKX2uI1bkdVVtiRgHVHIEkoo31918OguJhU26a1g09njMqXkJeV gbib/e9z1gCa2/vbDtAJu7S9r7x8YB+WIUg3wP0cbzSHByMtmgBxPGtj50xPpvULC/oE C9b9aSrpBSNKVOuSF4wWT+pehDe9kROe6riJ8= 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=pI6OtLl8ZsgY0duFBJDxU651Qtp7LS5Wv0maLHCyW22GGN3KWq1iqVNU1JJ/zHxKdi vIPFXk/Rgu+IVj1PuJf+tXS+e74vQOPPE7gnZZx/4nPJP1vVZ0PJaS7OFEQCkcGGyqjE UptWeW3Eb5Z8rhvD8Qsrz/zkrl9NA3NjiJlX4= MIME-Version: 1.0 Received: by 10.101.102.9 with SMTP id e9mr2926076anm.86.1272475496709; Wed, 28 Apr 2010 10:24:56 -0700 (PDT) Received: by 10.100.194.19 with HTTP; Wed, 28 Apr 2010 10:24:55 -0700 (PDT) In-Reply-To: <4BD76E04.30604@FreeBSD.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org> <4BD751DD.80407@FreeBSD.org> <201004271725.36518.jhb@freebsd.org> <4BD76E04.30604@FreeBSD.org> Date: Wed, 28 Apr 2010 13:24:55 -0400 Message-ID: From: Alexander Sack To: Maxim Sobolev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, mj@feral.com Subject: Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 17:25:05 -0000 On Tue, Apr 27, 2010 at 7:06 PM, Maxim Sobolev wrote: > Alexander Sack wrote: >> >> On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote: >>> >>> On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote: >>>> >>>> John Baldwin wrote: >>>>> >>>>> On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote: >>>>>> >>>>>> John Baldwin wrote: >>>>>>> >>>>>>> Hmm, I think you should definitely commit the atkbdc_isa.c change >>>>>>> first of >>>>>>> all. =A0I'm still thinking about the other change. =A0I wonder if w= e can >>>>>>> figure >>>>>>> out that a keyboard isn't present sooner somehow? =A0Do you know if= the >>>>>>> keyboard >>>>>>> appears to be present but just slow vs if the keyboard is eventuall= y >>>>>>> found to >>>>>>> not be present? >>>>>> >>>>>> Our syscons does keyboard probing two times - once early during kern= el >>>>>> initialization before most of the subsystems have been initialized >>>>>> yet, >>>>>> and then "real" probing later in boot process. Interesting thing is >>>>>> that >>>>>> initially keyboard looks present. Reading status port in >>>>>> atkbdc_configure() gives value other than 0xff, although reading is >>>>>> thousand times slower than usually. This causes syscons try attachin= g >>>>>> it. Even though reading status port works, apparently either emulati= on >>>>>> is not complete or there is some other issue, so that it never >>>>>> responds >>>>>> to some commands. Slow access and lack of response results in >>>>>> wait_for_data() function waiting several minutes instead of 200ms as >>>>>> designed. This what causes that 6-10 minutes delay in boot process. >>>>> >>>>> I believe the USB driver has disabled the keyboard emulation by the >>>>> time the >>>>> second probe happens in syscons. =A0Can you try disabling legacy USB >>>>> support in >>>>> the BIOS just to make sure that is what causes the delay? >>>> >>>> Unfortunately it's not possible. Hosting provider doesn't allow me to >>>> have access to BIOS settings. >> >> Stunt double: =A0I tried it and it has no effect. =A0The waits in atkdbd >> kills it with or without USB legacy support on. =A0The wait on this >> machine is about 1-2 minutes before boot. =A0Just another data point. > > Have you tried my patch? Does it help? Maxim, yes I have. Works much better. Wait time is nominal. I would definitely document the time delay code as its non-intuitive looking at it. -aps From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 17:34: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 395AC1065672 for ; Wed, 28 Apr 2010 17:34:17 +0000 (UTC) (envelope-from kama@pvp.se) Received: from ms1.as.pvp.se (mail.pvp.se [213.64.187.227]) by mx1.freebsd.org (Postfix) with ESMTP id EEAD08FC1A for ; Wed, 28 Apr 2010 17:34:16 +0000 (UTC) Received: by ms1.as.pvp.se (Postfix, from userid 1001) id 376D17B; Wed, 28 Apr 2010 19:01:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ms1.as.pvp.se (Postfix) with ESMTP id 35B8F7A for ; Wed, 28 Apr 2010 19:01:42 +0200 (CEST) Date: Wed, 28 Apr 2010 19:01:42 +0200 (CEST) From: kama X-X-Sender: kama@ns1.as.pvp.se To: freebsd-current@freebsd.org In-Reply-To: Message-ID: <20100428185223.P4522@ns1.as.pvp.se> References: <4BCFF81A.6050006@lissyara.su> <4BCFFBC1.2080703@lissyara.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: newsyslog patch implementing file includes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 17:34:18 -0000 On Thu, 22 Apr 2010, krad wrote: > On 22 April 2010 08:33, Alex Keda wrote: > > > 22.04.2010 11:29, Gordon Tetlow ?????: > > > >> On Thu, Apr 22, 2010 at 12:17 AM, Alex Keda >> admin@lissyara.su>> wrote: > >> > >> It's need feature. I test patch - it work for me (CURRENT, amd64) > >> Can I use some as: > >> /path/to/dir/*.conf > >> ? > >> and can I create recursive include? > >> > >> > >> Yes, wildcards and recursive includes are supported. > >> > > great job! > > Thanks! > > > > > > _______________________________________________ > > 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" > > > > > i would be real nice is newsyslog also supported a date based file renaming > shceme rather than the cyclic 0,1,2,3, much like the datext option in > logrotate. eg > > messages > messages.20100422 > messages.20100421 > messages.20100420 > ... > > The cyclic renaming is a pain for incremental backups as all the log files > are backed up every time as their contents changes compared to their > filename Even nicer if it could use the strftime() syntax format. ie: %Y%m%d to get the date. This way it could also be named in week number. /Bjorn From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 18: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 1F9B6106564A; Wed, 28 Apr 2010 18:20:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id C78428FC15; Wed, 28 Apr 2010 18:20:50 +0000 (UTC) Received: from desktop.home.serebryakov.spb.ru (85-142-52-164.well-com.net [85.142.52.164]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3501C13DF46; Wed, 28 Apr 2010 22:20:42 +0400 (MSD) Date: Wed, 28 Apr 2010 22:20:39 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1239259726.20100428222039@serebryakov.spb.ru> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86och53tpl.fsf@ds4.des.no> References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 18:20:51 -0000 Hello, Dag-Erling. You wrote 27 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2010 =D0=B3., 17:34:14: > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. Why are they called ``PSEUDO-raids'' then? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 18:32: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 097711065672; Wed, 28 Apr 2010 18:32:54 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B44A78FC1C; Wed, 28 Apr 2010 18:32:53 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DE6DB1FFC22; Wed, 28 Apr 2010 18:32:52 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 5BEC2844A8; Wed, 28 Apr 2010 20:32:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: lev@FreeBSD.org References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <1239259726.20100428222039@serebryakov.spb.ru> Date: Wed, 28 Apr 2010 20:32:20 +0200 In-Reply-To: <1239259726.20100428222039@serebryakov.spb.ru> (Lev Serebryakov's message of "Wed, 28 Apr 2010 22:20:39 +0400") Message-ID: <86633bv363.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Maxim Sobolev , Alexander Motin , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 18:32:54 -0000 Lev Serebryakov writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. > Why are they called ``PSEUDO-raids'' then? Several reasons - they don't present the array to the OS as a single device, they don't handle failover, etc. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 20:32:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C60701065670 for ; Wed, 28 Apr 2010 20:32:44 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5924F8FC08 for ; Wed, 28 Apr 2010 20:32:44 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id EC0AC5AE57; Wed, 28 Apr 2010 22:32:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E92435AE45; Wed, 28 Apr 2010 22:32:42 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C84C95D076; Wed, 28 Apr 2010 22:32:42 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.1FP2) with ESMTP id 2010042822324095-96702 ; Wed, 28 Apr 2010 22:32:40 +0200 Received: by wep4035 (sSMTP sendmail emulation); Wed, 28 Apr 2010 22:32:41 +0200 Date: Wed, 28 Apr 2010 22:32:41 +0200 From: Alexey Shuvaev To: Dima Panov Message-ID: <20100428203241.GA38859@wep4035.physik.uni-wuerzburg.de> References: <20100416160818.GA69460@freebsd.org> <201004282007.25568.fluffy@freebsd.org> <20100428121637.GA61412@roberto-al.eurocontrol.fr> <201004290240.26848.fluffy@freebsd.org> MIME-Version: 1.0 In-Reply-To: <201004290240.26848.fluffy@freebsd.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.20 (2009-06-14) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.1FP2|March 17, 2010) at 04/28/2010 10:32:41 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.1FP2|March 17, 2010) at 04/28/2010 10:32:41 PM, Serialize complete at 04/28/2010 10:32:41 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Roman Divacky , freebsd-current@freebsd.org Subject: Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 20:32:44 -0000 On Thu, Apr 29, 2010 at 02:40:24AM +1100, Dima Panov wrote: > On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > > According to Dima Panov: > > > while building lang/ruby18: > > Which options to you use? > > > > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 > > WITHOUT_ONIGURUMA=true > > WITH_RDOC=true > > WITHOUT_DEBUG=true > > > > I notice your ruby is compiling w/o any -On, try with -O at least? > > same here. also on 1.8.7.249 snapshot. > > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o enum.o > enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o > numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o > ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o > version.o dmyext.o > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC -DRUBY_EXPORT -I. > -I. -I/usr/include -c main.c > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC -DRUBY_EXPORT -L. > -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a - > lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment > ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] > > *** Signal 6 > > Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. > *** Error code 1 > > > _OPTIONS_READ=ruby-1.8.7.249,1 > WITHOUT_ONIGURUMA=true > WITH_RDOC=true > WITHOUT_DEBUG=true > > > > > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -I. > > > -I. -I/usr/include -c main.c > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -L. > > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > > > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > > > > from ./mkconfig.rb:11:in `require' > > > from ./mkconfig.rb:11 > > > > > > *** Error code 1 > > > > Interesting, using a fairly recent clang snapshot from trunk, I get a sig11 > > :( > > > Ruby is bad? > For the record, ruby compilation also fails with base gcc inside i386 ports tinderbox on amd64-CURRENT host: [snip] cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c variable.c cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c version.c In file included from version.c:14: version.h:29:41: warning: no newline at end of file cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c dmyext.c ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dln.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o dmyext.o cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT -I. -I. -I/usr/include -c main.c cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT -L. -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o libruby18-static.a -lrt -lcrypt -lm -L/usr/lib -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby ./lib/fileutils.rb:1030: retry outside of rescue clause rbconfig.rb updated *** Error code 1 Stop in /work/a/ports/lang/ruby18/work/ruby-1.8.7-p248. *** Error code 1 Stop in /a/ports/lang/ruby18. ================================================================ build of /usr/ports/lang/ruby18 ended at Sat Apr 24 04:57:59 UTC 2010 I don't know why it is failing in the same file (is it just included first or is it really troublesome?), but it looks quite suspicious. I am nowhere the ruby expert but it may be that the problem is in ruby itself. Note, that I have successfully built quite a lot of packages inside this i386 tinderbox on amd64 host including full kde4, openoffice3, jdk16, virtualbox-ose, mplayer, ... On the topic, if I understand it correctly, one can build clandbsd branch with normal gcc from base, so it is "backward compatible". What are the general showstoppers then to merge to HEAD the part of clangbsd that allows building HEAD with llvm from ports? I think this will significantly increase the number of testers... Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 21:03: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 B5827106566C; Wed, 28 Apr 2010 21:03:52 +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 F1E208FC1C; Wed, 28 Apr 2010 21:03:51 +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 o3SL3lLk013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Apr 2010 00:03:47 +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 o3SL3lXk014224; Thu, 29 Apr 2010 00:03:47 +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 o3SL3liG014223; Thu, 29 Apr 2010 00:03:47 +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: Thu, 29 Apr 2010 00:03:47 +0300 From: Kostik Belousov To: Alexey Shuvaev Message-ID: <20100428210347.GD2391@deviant.kiev.zoral.com.ua> References: <20100416160818.GA69460@freebsd.org> <201004282007.25568.fluffy@freebsd.org> <20100428121637.GA61412@roberto-al.eurocontrol.fr> <201004290240.26848.fluffy@freebsd.org> <20100428203241.GA38859@wep4035.physik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HWvPVVuAAfuRc6SZ" Content-Disposition: inline In-Reply-To: <20100428203241.GA38859@wep4035.physik.uni-wuerzburg.de> 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.5 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: Roman Divacky , freebsd-current@freebsd.org, Dima Panov Subject: Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Apr 2010 21:03:52 -0000 --HWvPVVuAAfuRc6SZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 28, 2010 at 10:32:41PM +0200, Alexey Shuvaev wrote: > On Thu, Apr 29, 2010 at 02:40:24AM +1100, Dima Panov wrote: > > On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > > > According to Dima Panov: > > > > while building lang/ruby18: > > > Which options to you use? > > >=20 > > > _OPTIONS_READ=3Druby+oniguruma-1.8.7.248_1,1 > > > WITHOUT_ONIGURUMA=3Dtrue > > > WITH_RDOC=3Dtrue > > > WITHOUT_DEBUG=3Dtrue > > >=20 > > > I notice your ruby is compiling w/o any -On, try with -O at least? > >=20 > > same here. also on 1.8.7.249 snapshot. > >=20 > > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o = dln.o enum.o =20 > > enumerator.o error.o eval.o file.o gc.o hash.o inits.o io.o mar= shal.o math.o =20 > > numeric.o object.o pack.o parse.o process.o prec.o random.o rang= e.o re.o regex.o =20 > > ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o = variable.o =20 > > version.o dmyext.o > > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=3Dgnu89 -fPIC= -DRUBY_EXPORT -I.=20 > > -I. -I/usr/include -c main.c > > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=3Dgnu89 -fPIC= -DRUBY_EXPORT -L. =20 > > -rpath=3D/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o l= ibruby18-static.a - > > lrt -lcrypt -lm -L/usr/lib -rpath=3D/usr/lib:/usr/local/lib -pthread = -o miniruby > > ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment > > ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] > >=20 > > *** Signal 6 > >=20 > > Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. > > *** Error code 1 > >=20 > >=20 > > _OPTIONS_READ=3Druby-1.8.7.249,1 > > WITHOUT_ONIGURUMA=3Dtrue > > WITH_RDOC=3Dtrue > > WITHOUT_DEBUG=3Dtrue > >=20 > >=20 > > >=20 > > > > clang -I/usr/include -pipe -g -g -std=3Dgnu89 -fPIC -DRUBY_EXPO= RT -I. > > > > -I. -I/usr/include -c main.c > > > > clang -I/usr/include -pipe -g -g -std=3Dgnu89 -fPIC -DRUBY_EXPO= RT -L.=20 > > > > - rpath=3D/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main= .o=20 > > > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib=20 > > > > -rpath=3D/usr/lib:/usr/local/lib -pthread -o miniruby > > > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > >=20 > > > > from ./mkconfig.rb:11:in `require' > > > > from ./mkconfig.rb:11 > > > >=20 > > > > *** Error code 1 > > >=20 > > > Interesting, using a fairly recent clang snapshot from trunk, I get a= sig11 > > > :( > >=20 > >=20 > > Ruby is bad? > >=20 > For the record, ruby compilation also fails with base gcc inside > i386 ports tinderbox on amd64-CURRENT host: >=20 > [snip] > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT = -I. -I. -I/usr/include -c variable.c > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT = -I. -I. -I/usr/include -c version.c > In file included from version.c:14: > version.h:29:41: warning: no newline at end of file > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT = -I. -I. -I/usr/include -c dmyext.c > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o dl= n.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o = io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o p= rec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o = string.o struct.o time.o util.o variable.o version.o dmyext.o > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT = -I. -I. -I/usr/include -c main.c > cc -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -DRUBY_EXPORT = -L. -rpath=3D/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o = libruby18-static.a -lrt -lcrypt -lm -L/usr/lib -rpath=3D/usr/lib:/usr/loca= l/lib -pthread -o miniruby > ./lib/fileutils.rb:1030: retry outside of rescue clause > rbconfig.rb updated > *** Error code 1 >=20 > Stop in /work/a/ports/lang/ruby18/work/ruby-1.8.7-p248. > *** Error code 1 >=20 > Stop in /a/ports/lang/ruby18. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > build of /usr/ports/lang/ruby18 ended at Sat Apr 24 04:57:59 UTC 2010 >=20 > I don't know why it is failing in the same file (is it just included first > or is it really troublesome?), but it looks quite suspicious. > I am nowhere the ruby expert but it may be that the problem is in ruby it= self. > Note, that I have successfully built quite a lot of packages inside > this i386 tinderbox on amd64 host including full kde4, openoffice3, jdk16, > virtualbox-ose, mplayer, ... This should be fixed by r206992 on HEAD, and by r207271 on stable/8. >=20 > On the topic, if I understand it correctly, one can build clandbsd branch > with normal gcc from base, so it is "backward compatible". > What are the general showstoppers then to merge to HEAD > the part of clangbsd that allows building HEAD with llvm from ports? > I think this will significantly increase the number of testers... >=20 > Alexey. > _______________________________________________ > 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" --HWvPVVuAAfuRc6SZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvYorIACgkQC3+MBN1Mb4gNRwCgiwEA7eAP8uEuoFECQwbtpiNF uYkAoJft9HzUIA7N9D/INut8y0RUkw/p =ySoh -----END PGP SIGNATURE----- --HWvPVVuAAfuRc6SZ-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 00:00:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D19A71065670 for ; Thu, 29 Apr 2010 00:00:00 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id AF3C28FC17 for ; Wed, 28 Apr 2010 23:59:58 +0000 (UTC) x-mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: Ayrt A/c0 BFP3 BH1e Bq0o BrnT Dexf FN40 GltG G5mJ HP5F ImHR Iqoh It+9 IvGQ Iwby; 1; ZgByAGUAZQBiAHMAZAAtAGMAdQByAHIAZQBuAHQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {9DF9F10B-1901-4C9D-A53C-7D50EB92009B}; bQBhAHQAdABoAGUAdwAuAGYAbABlAG0AaQBuAGcAQABpAHMAaQBsAG8AbgAuAGMAbwBtAA==; Wed, 28 Apr 2010 23:59:58 GMT; cwBsAGUAZQBwACAAYgB1AGcAIABpAG4AIAB0AGEAcwBrAHEAdQBlAHUAZQAoADkAKQA= x-cr-puzzleid: {9DF9F10B-1901-4C9D-A53C-7D50EB92009B} Content-class: urn:content-classes:message Date: Wed, 28 Apr 2010 16:59:58 -0700 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sleep bug in taskqueue(9) Thread-Index: AcrnLugjIb9k3BJXRcO0WnukadoAGg== From: "Matthew Fleming" To: X-Mailman-Approved-At: Thu, 29 Apr 2010 02:04:52 +0000 Subject: sleep bug in taskqueue(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 00:00:01 -0000 It looks to me like taskqueue_drain(taskqueue_thread, foo) will not correctly detect whether or not a task is currently running. The check is against a field in the taskqueue struct, but for the taskqueue_thread queue with more than one thread, multiple threads can simultaneously be running a task, thus stomping over the tq_running field. I have not seen any problem with the code as-is in actual use, so this is purely an inspection bug. The following patch should fix the problem. Because it changes the size of struct task I'm not sure if it would be suitable for MFC. Thanks, matthew diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c index 8405b3d..3b18269 100644 --- a/sys/kern/subr_taskqueue.c +++ b/sys/kern/subr_taskqueue.c @@ -51,7 +51,6 @@ __FBSDID("$FreeBSD$"); const char *tq_name; taskqueue_enqueue_fn tq_enqueue; void *tq_context; - struct task *tq_running; struct mtx tq_mutex; struct thread **tq_threads; int tq_tcount; @@ -233,13 +232,13 @@ taskqueue_run(struct taskqueue *queue) STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); pending =3D task->ta_pending; task->ta_pending =3D 0; - queue->tq_running =3D task; + task->ta_flags |=3D TA_FLAGS_RUNNING; TQ_UNLOCK(queue); =20 task->ta_func(task->ta_context, pending); =20 TQ_LOCK(queue); - queue->tq_running =3D NULL; + task->ta_flags &=3D ~TA_FLAGS_RUNNING; wakeup(task); } =20 @@ -256,14 +255,16 @@ taskqueue_drain(struct taskqueue *queue, struct task *task) { if (queue->tq_spin) { /* XXX */ mtx_lock_spin(&queue->tq_mutex); - while (task->ta_pending !=3D 0 || task =3D=3D queue->tq_running) + while (task->ta_pending !=3D 0 || + (task->ta_flags & TA_FLAGS_RUNNING) !=3D 0) msleep_spin(task, &queue->tq_mutex, "-", 0); mtx_unlock_spin(&queue->tq_mutex); } else { WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__); =20 mtx_lock(&queue->tq_mutex); - while (task->ta_pending !=3D 0 || task =3D=3D queue->tq_running) + while (task->ta_pending !=3D 0 || + (task->ta_flags & TA_FLAGS_RUNNING) !=3D 0) msleep(task, &queue->tq_mutex, PWAIT, "-", 0); mtx_unlock(&queue->tq_mutex); } diff --git a/sys/sys/_task.h b/sys/sys/_task.h index 2a51e1b..c57bdd5 100644 --- a/sys/sys/_task.h +++ b/sys/sys/_task.h @@ -36,15 +36,21 @@ * taskqueue_run(). The first argument is taken from the 'ta_context' * field of struct task and the second argument is a count of how many * times the task was enqueued before the call to taskqueue_run(). + * + * List of locks + * (c) const after init + * (q) taskqueue lock */ typedef void task_fn_t(void *context, int pending); =20 struct task { - STAILQ_ENTRY(task) ta_link; /* link for queue */ - u_short ta_pending; /* count times queued */ - u_short ta_priority; /* Priority */ - task_fn_t *ta_func; /* task handler */ - void *ta_context; /* argument for handler */ + STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ + u_char ta_flags; /* (q) state of this task */ +#define TA_FLAGS_RUNNING 0x01 + u_short ta_pending; /* (q) count times queued */ + u_short ta_priority; /* (c) Priority */ + task_fn_t *ta_func; /* (c) task handler */ + void *ta_context; /* (c) argument for handler */ From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 03:07: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 891FC106564A for ; Thu, 29 Apr 2010 03:07:40 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC0C8FC14 for ; Thu, 29 Apr 2010 03:07:40 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o3T37c7q004673 for ; Wed, 28 Apr 2010 22:07:38 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=eR4vwShGM0lZOfPUwrsJGQ1kDUq62fsaDvYOz5ijRjqZOI9vLgaJJb7uWeczQTXBw RcGwM98mGTH15GbxGAWcQ009Ie2rPndxByk8K5ZG3mCnC3AY3TaUPbNOricVHBNWy8x jUSZRSb/M3JdxuAXDpbKNAlPgcCeLKRHcJuD1Ys= Message-ID: <4BD8F7FA.2080103@jrv.org> Date: Wed, 28 Apr 2010 22:07:38 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 03:07:40 -0000 FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: Mon Apr 26 01:13:00 CDT 2010 root@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 svn 206111 is April 2 system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. The system was running this in the clang build area: while true do make -j7 buildworld done The panic happened during the 27th iteration. panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 04:17: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 3D718106566B for ; Thu, 29 Apr 2010 04:17:44 +0000 (UTC) (envelope-from artemb@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 987018FC08 for ; Thu, 29 Apr 2010 04:17:43 +0000 (UTC) Received: by pwi9 with SMTP id 9so11066431pwi.13 for ; Wed, 28 Apr 2010 21:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Rducf4AF+VUyHDlMT52wlkMboqm9EU3ypyryauhw/ow=; b=TNGBvO0OKnwPb31mD/QQ4eOGXC9qP3pG0exSv/0jPLCsJ5ze2gZ5OL1OWBMH7pJwdp baHref1a1eicm4LReaWSjh1uD6rymxt2WrSLVmtOV5ny5XGkc7huJ3tbzDCs6dr++6YJ E1OPPTLyqgyBprzt7ik5JA5ZC8sDmWBGpuE3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=REKT2qtj93oEYxnE+2ow1S1EsMQs/5NxHLhC81lPf26f3S9gtbpoX/NTW4h1O6/vvK O7SDra3pjizweVQJa/ugknjiYAPA3qHVJlafW6wo8hcaDw1W9t9M1TRv/o9vfZzFb5kT 98jy9Dy5F4lp450mB75ixSnCeB9mt3Scy0FxY= MIME-Version: 1.0 Received: by 10.141.108.17 with SMTP id k17mr9080603rvm.38.1272514654304; Wed, 28 Apr 2010 21:17:34 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.29.10 with HTTP; Wed, 28 Apr 2010 21:17:34 -0700 (PDT) In-Reply-To: <4BD8F7FA.2080103@jrv.org> References: <4BD8F7FA.2080103@jrv.org> Date: Wed, 28 Apr 2010 21:17:34 -0700 X-Google-Sender-Auth: fbe77cdbebf25acd Message-ID: From: Artem Belevich To: "James R. Van Artsdalen" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 04:17:44 -0000 Do you have vm.kmem_size set in /boot/loader.conf? If not, do set it to about double of your physical RAM size. Defaults are way too conservative for use with large amounts of memory and ZFS. --Artem On Wed, Apr 28, 2010 at 8:07 PM, James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: > Mon Apr 26 01:13:00 CDT 2010 > root@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC =A0amd64 > > svn 206111 is April 2 > > system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 > GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. > > The system was running this in the clang build area: > > while true > do > =A0make -j7 buildworld > done > > The panic happened during the 27th iteration. > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocate= d > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 06:57:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14F951065677 for ; Thu, 29 Apr 2010 06:57:46 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f249.mail.ru (f249.mail.ru [217.69.128.174]) by mx1.freebsd.org (Postfix) with ESMTP id C1F8D8FC15 for ; Thu, 29 Apr 2010 06:57:45 +0000 (UTC) Received: from mail by f249.mail.ru with local id 1O7Ngq-0000ZL-00; Thu, 29 Apr 2010 10:57:40 +0400 Received: from [77.45.202.112] by win.mail.ru with HTTP; Thu, 29 Apr 2010 10:57:40 +0400 From: =?koi8-r?Q?=E1=CE=C4=D2=C5=CA_=F3=CD=C1=C7=C9=CE?= To: Artem Belevich Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [77.45.202.112] Date: Thu, 29 Apr 2010 10:57:40 +0400 References: In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: FreeBSD Current , "James R. Van Artsdalen" Subject: Re[2]: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?Q?=E1=CE=C4=D2=C5=CA_=F3=CD=C1=C7=C9=CE?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 06:57:46 -0000 On Wed, Apr 28, 2010 at 8:07 PM, James R. Van Artsdalen wrote: > FreeBSD bigback.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206111: > Mon Apr 26 01:13:00 CDT 2010 > root@bigback.housenet.jrv:/usr/obj/usr/src/sys/GENERIC ?amd64 > > svn 206111 is April 2 > > system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 > GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. > > The system was running this in the clang build area: > > while true > do > ?make -j7 buildworld > done > > The panic happened during the 27th iteration. > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated > I open PR amd64/145654 with problem like it. Have you increasing Wired memory at buildworld ? From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 09:55: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 213DE106566C for ; Thu, 29 Apr 2010 09:55:26 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB4D8FC22 for ; Thu, 29 Apr 2010 09:55:25 +0000 (UTC) Received: by ewy24 with SMTP id 24so4828763ewy.33 for ; Thu, 29 Apr 2010 02:55: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:date:message-id :subject:from:to:content-type; bh=A30QYoqcsnudE8QjrkkfGvm6XkY+JVEaczOVIEZfLHk=; b=BwQnZK5Hv9bTQxqfTcqeIuS6pyZVxEjo+2yxYCBYWkaHbP6XNOfFu24kjIAbjwu6rh rNvBgL/nDj0nM1zyMiWnJGfRjs1AFiRnuR5E1oRL58EZdYwezCao4nNQFodasj/hDqZC ja77FEjc1Z62c5atKiRP8+4gbhpfu0JQDtlvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bufL39lWgoEIc9AL70WNrfMPrHz1Kz67yn4q8M37yXGoUewx667A1XZ8TKVv9O0RSs xwBhgZ3c8J+FzOL6uNn4+UjhDpbqClVsNsdTguc/AJlBl7pSzfwpU9u2ySpefVt7M8zg d+t27cALI9ZSI8YvjrYBjeP1nY7Du0wtbP8mE= MIME-Version: 1.0 Received: by 10.213.67.207 with SMTP id s15mr1433045ebi.76.1272534915907; Thu, 29 Apr 2010 02:55:15 -0700 (PDT) Received: by 10.213.8.133 with HTTP; Thu, 29 Apr 2010 02:55:15 -0700 (PDT) Date: Thu, 29 Apr 2010 13:55:15 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Failed assertion: "(run->regs_mask[elm] & (1U << bit)) == 0" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 09:55:26 -0000 Hello Hackers! I have a problem with FreeBSD-CURRENT system: FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 04:15:07 UTC 2010 root@host:/usr/obj/usr/src/sys/GENERIC amd64 Perl aborts with the following error on exiting cpan shell: cpan[2]> q Lockfile removed. perl: (malloc) /usr/src/lib/libc/stdlib/malloc.c:2628: Failed assertion: "(run->regs_mask[elm] & (1U << bit)) == 0" Abort trap: 6 (core dumped) Below is a backtrace: 3 RSYSCALL(kill) [New Thread 8014071c0 (LWP 100083)] (gdb) bt #0 0x0000000800f0c38c in kill () at kill.S:3 #1 0x0000000800ca5363 in _raise (sig=6) at /usr/src/lib/libthr/thread/thr_sig.c:185 #2 0x0000000800f0a953 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #3 0x0000000800e589b6 in arena_run_reg_dalloc (run=0x801609000, bin=0x5016b8, ptr=0x801609a40, size=1) at /usr/src/lib/libc/stdlib/malloc.c:2628 #4 0x0000000800e5e29c in arena_dalloc_bin (arena=0x501430, chunk=0x801400000, ptr=0x801609a40, mapelm=0x801403100) at /usr/src/lib/libc/stdlib/malloc.c:3870 #5 0x0000000800e5fcef in arena_dalloc (arena=0x501430, chunk=0x801400000, ptr=0x801609a40) at /usr/src/lib/libc/stdlib/malloc.c:4302 #6 0x0000000800e5ffbb in idalloc (ptr=0x801609a40) at /usr/src/lib/libc/stdlib/malloc.c:4344 #7 0x0000000800e65730 in free (ptr=0x801609a40) at /usr/src/lib/libc/stdlib/malloc.c:6132 #8 0x0000000800f03a6d in __clean_env (freeVars=true) at /usr/src/lib/libc/stdlib/getenv.c:236 #9 0x0000000800f042de in __clean_env_destructor () at /usr/src/lib/libc/stdlib/getenv.c:407 #10 0x0000000800de4829 in ?? () from /lib/libc.so.7 #11 0x0000000800f0fb01 in _fini () from /lib/libc.so.7 #12 0x00007fffffffeac0 in ?? () #13 0x0000000800508450 in objlist_call_fini (list=0x800643030, force=1 '\001', lockstate=0x7fffffffeadc) at /usr/src/libexec/rtld-elf/rtld.c:1638 #14 0x0000000800508aaf in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:1832 #15 0x0000000800eddfd6 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:180 #16 0x0000000800e65ec2 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:67 #17 0x0000000000400cc3 in main (argc=Could not find the frame base for "main". ) at perlmain.c:130 Current language: auto; currently asm (gdb) Thanks! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 10:25: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 F14DD106566B for ; Thu, 29 Apr 2010 10:25:29 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 872428FC1F for ; Thu, 29 Apr 2010 10:25:29 +0000 (UTC) Received: by wwb13 with SMTP id 13so359035wwb.13 for ; Thu, 29 Apr 2010 03:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=5aXWnBvuLkfDhTXpvDVrETB3yygVdsLMHqZ1k5HThlw=; b=A01vIE7g1x9gV6votMX0hZniHsnd7pUThIuJRUvz9tuuggzRzKSsTBk9XucX2+Zkog 0MFrEdVlfvXwce8xFejSvZmkJAVtviU+o/8K9wkL8LnemIvjz7xtOa5W0Chh9dIli2SF eSZlTRNFJpvaloB5pIwUDeClMMetHZVBLtpTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ukGcbXtcg7hrqX8cQIteG+td8BAevexiEKW9Y0f0y1sN872T1rRdlUb+7iyqDCqUXX /09bHM0t4ZWFCJ4sVuQKr/dZjw/paqoKoE5MMrgAFE55nwS064Gu0hOOadDNthHBuQoE tSSHWMoNwvCSOoM4ShSPNUbqN//rr5HeC6G6Q= MIME-Version: 1.0 Received: by 10.216.90.20 with SMTP id d20mr6694729wef.29.1272536725750; Thu, 29 Apr 2010 03:25:25 -0700 (PDT) Received: by 10.216.180.10 with HTTP; Thu, 29 Apr 2010 03:25:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 12:25:25 +0200 Message-ID: From: Lucius Windschuh To: Dmitry Krivenok Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Failed assertion: "(run->regs_mask[elm] & (1U << bit)) == 0" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 10:25:30 -0000 Hi Dmitry. 2010/4/29 Dmitry Krivenok : > Hello Hackers! > > I have a problem with FreeBSD-CURRENT system: > FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 > 04:15:07 UTC 2010 =A0 =A0 root@host:/usr/obj/usr/src/sys/GENERIC =A0amd64 > > Perl aborts with the following error on exiting cpan shell: > > cpan[2]> q > Lockfile removed. > perl: (malloc) /usr/src/lib/libc/stdlib/malloc.c:2628: Failed assertion: > "(run->regs_mask[elm] & (1U << bit)) =3D=3D 0" > Abort trap: 6 (core dumped) Can you determine if the CPAN shell is using Term::ReadLine and you have devel/p5-ReadLine-Gnu installed? If this is the case, you probably ran into this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D131664 Replacing p5-ReadLine-Gnu with p5-ReadLine-Perl should avoid this problem. I was still unable to track this futher bug down and this port is broken for a while. :-/ Regards, Lucius From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 11:05: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 E164A1065670 for ; Thu, 29 Apr 2010 11:05:58 +0000 (UTC) (envelope-from fluffy@freebsd.org) Received: from ns.ael.RU (ns.ael.ru [62.76.207.226]) by mx1.freebsd.org (Postfix) with ESMTP id CF1178FC0A for ; Thu, 29 Apr 2010 11:05:57 +0000 (UTC) Received: from Fluffy.Khv.RU (85.9.168.188.retail.ttk.ru [188.168.9.85] (may be forged)) by ns.ael.RU (8.14.3/8.14.3/Fluffy/5.3) with ESMTP id o3TB5oTS099673 for ; Thu, 29 Apr 2010 22:05:51 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: from Fluffy.Khv.RU (fluffy@localhost [127.0.0.1]) by Fluffy.Khv.RU (8.14.4/8.14.4/Fluffy/5.4.1) with ESMTP id o3TB5UG9024529 for ; Thu, 29 Apr 2010 22:05:31 +1100 (VLAST) (envelope-from fluffy@freebsd.org) Received: (from fluffy@localhost) by Fluffy.Khv.RU (8.14.4/8.14.4/Submit) id o3TB5T4p024364 for freebsd-current@freebsd.org; Thu, 29 Apr 2010 22:05:29 +1100 (VLAST) (envelope-from fluffy@freebsd.org) From: Dima Panov Organization: The FreeBSD Project To: freebsd-current@freebsd.org Date: Thu, 29 Apr 2010 22:05:25 +1100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-900010-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100416160818.GA69460@freebsd.org> <20100428121637.GA61412@roberto-al.eurocontrol.fr> <201004290240.26848.fluffy@freebsd.org> In-Reply-To: <201004290240.26848.fluffy@freebsd.org> X-Face: "RE-2'yS-N:*/7DHOjQ%Az<.+SG>K7B'k(&; qb0K4]Hv>J}"l9,=:m2_]-3S/}`b\]yA-g !y3en*Zl(i-86iM?Q[w@!=rW&JdT>KHW@dri>+qMcy42O, 5#izEqa-K+=B<@A X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ns.ael.RU [62.76.207.226]); Thu, 29 Apr 2010 22:05:53 +1100 (VLAST) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 11:05:59 -0000 On Thursday 29 April 2010 02:40:24 Dima Panov wrote: > On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote: > > According to Dima Panov: > > > while building lang/ruby18: > > Which options to you use? > > > > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1 > > WITHOUT_ONIGURUMA=true > > WITH_RDOC=true > > WITHOUT_DEBUG=true > > > > I notice your ruby is compiling w/o any -On, try with -O at least? > > same here. also on 1.8.7.249 snapshot. > > ar rcu libruby18-static.a array.o bignum.o class.o compar.o dir.o > dln.o enum.o enumerator.o error.o eval.o file.o gc.o hash.o inits.o > io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o > prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o > string.o struct.o time.o util.o variable.o version.o dmyext.o > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC > -DRUBY_EXPORT -I. -I. -I/usr/include -c main.c > clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89 -fPIC > -DRUBY_EXPORT -L. -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic > -pthread main.o libruby18-static.a - lrt -lcrypt -lm -L/usr/lib > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment ruby > 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9] > > *** Signal 6 > > Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249. > *** Error code 1 > > > _OPTIONS_READ=ruby-1.8.7.249,1 > WITHOUT_ONIGURUMA=true > WITH_RDOC=true > WITHOUT_DEBUG=true > > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -I. > > > -I. -I/usr/include -c main.c > > > clang -I/usr/include -pipe -g -g -std=gnu89 -fPIC -DRUBY_EXPORT -L. > > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic -pthread main.o > > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib > > > -rpath=/usr/lib:/usr/local/lib -pthread -o miniruby > > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError) > > > > > > from ./mkconfig.rb:11:in `require' > > > from ./mkconfig.rb:11 > > > > > > *** Error code 1 > > > > Interesting, using a fairly recent clang snapshot from trunk, I get a > > sig11 > > > > :( > > Ruby is bad? clangbsd errors in my blog: http://dimapanov.wordpress.com/2010/04/29/clangbsd/ at this moment unbuildable some critical ports: devel/binutils devel/icu[4] devel/pcre lang/ruby1[89] -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 KDE@FreeBSD Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 11:32:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E37E1065673 for ; Thu, 29 Apr 2010 11:32:07 +0000 (UTC) (envelope-from hinokind@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 9B7FE8FC2C for ; Thu, 29 Apr 2010 11:32:05 +0000 (UTC) Received: by fxm15 with SMTP id 15so1013977fxm.13 for ; Thu, 29 Apr 2010 04:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:subject :references:date:mime-version:content-transfer-encoding:from :message-id:in-reply-to:user-agent; bh=ZKQCf8sgYcHwry3tuwVg4DREOUUi3OLcoD8GEOkOOIk=; b=Ayc05gSyjN4I4o0c0oi/kgd78kM6fn3up36z4AszSlxWSrFcSTX6/Xu4P8lHNfERTt 2WxmUX2yMOxHCMaxC5IJOxFmLfeFr/Y7FYZEQGivEd8KyApF9rcoZYNO2nuv8mhwHoyg QWVJgphUGp05+dvod7RbsOObns2eNdpR1bMQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; b=Ag2bw9rHQ+4ZZM375tKwm9MLd8cpS2Bs7yozvuPHd/9eXrbDZJ372oGTSwv0U9XYKf x+Qqa7PrA/COTqug5ojwHhbTNDzbDi0I3K/RlPnKhPyx/OdRQpa5gvaxzrow6nGNHLV2 ZlJXWNq5Hg2B7PgLBIZ5eZmsrtE14YF7KaiJ0= Received: by 10.103.80.8 with SMTP id h8mr20530mul.90.1272540721069; Thu, 29 Apr 2010 04:32:01 -0700 (PDT) Received: from klevas (hst-17-80.splius.lt [77.79.17.80]) by mx.google.com with ESMTPS id i5sm3674462mue.19.2010.04.29.04.31.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 04:32:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Dima Panov" , freebsd-current@freebsd.org References: <20100416160818.GA69460@freebsd.org> <20100428121637.GA61412@roberto-al.eurocontrol.fr> <201004290240.26848.fluffy@freebsd.org> <201004292205.26216.fluffy@freebsd.org> Date: Thu, 29 Apr 2010 14:31:57 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: =?utf-8?B?QW5kcml1cyBNb3JrxatuYXM=?= Message-ID: In-Reply-To: <201004292205.26216.fluffy@freebsd.org> User-Agent: Opera Mail/10.10 (FreeBSD) Cc: Subject: Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 11:32:07 -0000 On Thu, 29 Apr 2010 14:05:25 +0300, Dima Panov wrote: > Ruby is bad? More like clang is bad, it's a known issue. > clangbsd errors in my blog: > > http://dimapanov.wordpress.com/2010/04/29/clangbsd/ > > at this moment unbuildable some critical ports: > > devel/binutils > devel/icu[4] > devel/pcre > lang/ruby1[89] I could give you a much longer list. Using clang for ports right now is not a good idea, a lot of things won't compile, some will be miscompiled or whatever, some ports rely on gcc specific/undefined behaviour, etc... We're [slowly] working on it, but for now you should probably stick with gcc for ports. Reporting broken ports won't really help too much, since we know what's broken ourselves. What could help is tracking miscompilations (it was explained earlier how to do it), but even for that we're waiting for sound related bug to be fixed on llvm end, to see how does that affect other broken ports. -- Andrius From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 12:46: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 289C31065670; Thu, 29 Apr 2010 12:46:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DBBA48FC16; Thu, 29 Apr 2010 12:46:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 63F3F46B29; Thu, 29 Apr 2010 08:46:17 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 087F08A021; Thu, 29 Apr 2010 08:46:05 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 29 Apr 2010 07:40:43 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100428171840.GS35381@elvis.mu.org> In-Reply-To: <20100428171840.GS35381@elvis.mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004290740.43355.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 29 Apr 2010 08:46:05 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alfred Perlstein Subject: Re: fixes for enhanced coredump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 12:46:18 -0000 On Wednesday 28 April 2010 1:18:40 pm Alfred Perlstein wrote: > I was recently working on the enhanced coredumps > internal to Juniper and realized that there were > some defects in the code I pushed (mostly due to > mismerge), can someone please review? > > 1) don't allocate hostname[] on the stack > 2) don't leak the temp buffer in imgact_elf_coredump. Doesn't this leak hostname? I don't see it being free'd anywhere. > thank you, > -Alfred > > > Index: kern/kern_sig.c > =================================================================== > --- kern/kern_sig.c (revision 207329) > +++ kern/kern_sig.c (working copy) > @@ -3004,8 +3004,9 @@ > char *temp; > size_t i; > int indexpos; > - char hostname[MAXHOSTNAMELEN]; > + char *hostname; > > + hostname = NULL; > format = corefilename; > temp = malloc(MAXPATHLEN, M_TEMP, M_NOWAIT | M_ZERO); > if (temp == NULL) > @@ -3021,6 +3022,19 @@ > sbuf_putc(&sb, '%'); > break; > case 'H': /* hostname */ > + if (hostname == NULL) { > + hostname = malloc(MAXHOSTNAMELEN, > + M_TEMP, M_NOWAIT); > + if (hostname == NULL) { > + log(LOG_ERR, > + "pid %ld (%s), uid (%lu): " > + "unable to alloc memory " > + "for corefile hostname\n", > + (long)pid, name, > + (u_long)uid); > + goto nomem; > + } > + } > getcredhostname(td->td_ucred, hostname, > sizeof(hostname)); > sbuf_printf(&sb, "%s", hostname); > @@ -3054,9 +3068,10 @@ > } > #endif > if (sbuf_overflowed(&sb)) { > - sbuf_delete(&sb); > log(LOG_ERR, "pid %ld (%s), uid (%lu): corename is too " > "long\n", (long)pid, name, (u_long)uid); > +nomem: > + sbuf_delete(&sb); > free(temp, M_TEMP); > return (NULL); > } > Index: kern/imgact_elf.c > =================================================================== > --- kern/imgact_elf.c (revision 207329) > +++ kern/imgact_elf.c (working copy) > @@ -1088,8 +1088,10 @@ > hdrsize = 0; > __elfN(puthdr)(td, (void *)NULL, &hdrsize, seginfo.count); > > - if (hdrsize + seginfo.size >= limit) > - return (EFAULT); > + if (hdrsize + seginfo.size >= limit) { > + error = EFAULT; > + goto done; > + } > > /* > * Allocate memory for building the header, fill it up, > @@ -1097,7 +1099,8 @@ > */ > hdr = malloc(hdrsize, M_TEMP, M_WAITOK); > if (hdr == NULL) { > - return (EINVAL); > + error = EINVAL; > + goto done; > } > error = __elfN(corehdr)(td, vp, cred, seginfo.count, hdr, hdrsize, > gzfile); > @@ -1125,8 +1128,8 @@ > curproc->p_comm, error); > } > > +done: > #ifdef COMPRESS_USER_CORES > -done: > if (core_buf) > free(core_buf, M_TEMP); > if (gzfile) > -- > - Alfred Perlstein > .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > .- FreeBSD committer > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 12:46:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0B9106564A for ; Thu, 29 Apr 2010 12:46:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE9A8FC1B for ; Thu, 29 Apr 2010 12:46:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id ECF3D46B09; Thu, 29 Apr 2010 08:46:23 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2FFB08A026; Thu, 29 Apr 2010 08:46:18 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 29 Apr 2010 07:44:35 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E039E389A@seaxch09.desktop.isilon.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004290744.35090.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 29 Apr 2010 08:46:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Matthew Fleming Subject: Re: sleep bug in taskqueue(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 12:46:24 -0000 On Wednesday 28 April 2010 7:59:58 pm Matthew Fleming wrote: > It looks to me like taskqueue_drain(taskqueue_thread, foo) will not > correctly detect whether or not a task is currently running. The check > is against a field in the taskqueue struct, but for the taskqueue_thread > queue with more than one thread, multiple threads can simultaneously be > running a task, thus stomping over the tq_running field. That sounds right. > I have not seen any problem with the code as-is in actual use, so this > is purely an inspection bug. > > The following patch should fix the problem. Because it changes the size > of struct task I'm not sure if it would be suitable for MFC. For HEAD I would maybe pad the flags field out to an int? The compiler is going to make it an int anyway. For the purposes of MFC'ing there are a couple of options. The simplest might be to reuse the high bit of the 'pending' count as a running flag. Breaking the ABI of struct task would prohibit an MFC otherwise. > Thanks, > matthew > > diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c > index 8405b3d..3b18269 100644 > --- a/sys/kern/subr_taskqueue.c > +++ b/sys/kern/subr_taskqueue.c > @@ -51,7 +51,6 @@ __FBSDID("$FreeBSD$"); > const char *tq_name; > taskqueue_enqueue_fn tq_enqueue; > void *tq_context; > - struct task *tq_running; > struct mtx tq_mutex; > struct thread **tq_threads; > int tq_tcount; > @@ -233,13 +232,13 @@ taskqueue_run(struct taskqueue *queue) > STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); > pending = task->ta_pending; > task->ta_pending = 0; > - queue->tq_running = task; > + task->ta_flags |= TA_FLAGS_RUNNING; > TQ_UNLOCK(queue); > > task->ta_func(task->ta_context, pending); > > TQ_LOCK(queue); > - queue->tq_running = NULL; > + task->ta_flags &= ~TA_FLAGS_RUNNING; > wakeup(task); > } > > > @@ -256,14 +255,16 @@ taskqueue_drain(struct taskqueue *queue, struct > task *task) > { > if (queue->tq_spin) { /* XXX */ > mtx_lock_spin(&queue->tq_mutex); > - while (task->ta_pending != 0 || task == > queue->tq_running) > + while (task->ta_pending != 0 || > + (task->ta_flags & TA_FLAGS_RUNNING) != 0) > msleep_spin(task, &queue->tq_mutex, "-", 0); > mtx_unlock_spin(&queue->tq_mutex); > } else { > WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, > __func__); > > mtx_lock(&queue->tq_mutex); > - while (task->ta_pending != 0 || task == > queue->tq_running) > + while (task->ta_pending != 0 || > + (task->ta_flags & TA_FLAGS_RUNNING) != 0) > msleep(task, &queue->tq_mutex, PWAIT, "-", 0); > mtx_unlock(&queue->tq_mutex); > } > diff --git a/sys/sys/_task.h b/sys/sys/_task.h > index 2a51e1b..c57bdd5 100644 > --- a/sys/sys/_task.h > +++ b/sys/sys/_task.h > @@ -36,15 +36,21 @@ > * taskqueue_run(). The first argument is taken from the 'ta_context' > * field of struct task and the second argument is a count of how many > * times the task was enqueued before the call to taskqueue_run(). > + * > + * List of locks > + * (c) const after init > + * (q) taskqueue lock > */ > typedef void task_fn_t(void *context, int pending); > > struct task { > - STAILQ_ENTRY(task) ta_link; /* link for queue */ > - u_short ta_pending; /* count times queued */ > - u_short ta_priority; /* Priority */ > - task_fn_t *ta_func; /* task handler */ > - void *ta_context; /* argument for handler */ > + STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ > + u_char ta_flags; /* (q) state of this task */ > +#define TA_FLAGS_RUNNING 0x01 > + u_short ta_pending; /* (q) count times queued */ > + u_short ta_priority; /* (c) Priority */ > + task_fn_t *ta_func; /* (c) task handler */ > + void *ta_context; /* (c) argument for handler */ > _______________________________________________ > 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" > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 14:36: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 58BF11065672 for ; Thu, 29 Apr 2010 14:36:25 +0000 (UTC) (envelope-from jasonjwwilliams@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 32DD38FC19 for ; Thu, 29 Apr 2010 14:36:24 +0000 (UTC) Received: by pvh1 with SMTP id 1so21800pvh.13 for ; Thu, 29 Apr 2010 07:36:24 -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=IqniAL/ucJ1+2tvWFvgPS5QQcxMsHsgS5h9e6Tyoaa0=; b=Z3uxcagGG/cdDtY3GHCDJHOMR1fO4APGTAXAZWcWU2Bs9WgbpU0aXgqV8mIYNfPI1d jeCuEJ5PZxB8SarDW+ZTBXF7iuum6JpU0gzAYxQHddqopic/Im12Ph0UZ15GT/zpwb/C VjMzDmZbaXHi3Du7mkl15ooYuFBDy7feObnPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qlYldcI9x2TLw2KqFlhcNhdL8pUhYcTp60UKHXG88PIEg+EpiEBZzudJQt7+1IdsLJ yfFAgJkCLNEyLRWTBDIgsT394IHA8GX2iz7vo8OTZlgaooA4rzBTPPRHb4EaN0vnBIqu hAjb3WNNr2WHIdYIFoYQHZs4JT4UwnrHA2wJo= MIME-Version: 1.0 Received: by 10.141.214.35 with SMTP id r35mr3290847rvq.264.1272551473166; Thu, 29 Apr 2010 07:31:13 -0700 (PDT) Received: by 10.141.27.20 with HTTP; Thu, 29 Apr 2010 07:31:12 -0700 (PDT) Date: Thu, 29 Apr 2010 08:31:12 -0600 Message-ID: From: "Jason J. W. Williams" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 14:36:25 -0000 Hi Y'all, I've written before that we're considering moving to FreeBSD 8 from OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs ZFS implementation for a high reliability environment like a database? If so, what are your experiences? Basically, I'm curious how stable the implementation is and whether it's ready for a critical production environment. Also, any gotchas particularly with running it with MySQL or anything else that utilizes a lot of memory. On Solaris, we cap the max ARC size to keep it from grabbing all the system RAM and competing with MySQL. Any thoughts or comments are greatly appreciated. -J From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 14:48: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 44757106566B for ; Thu, 29 Apr 2010 14:48:17 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D80708FC0C for ; Thu, 29 Apr 2010 14:48:16 +0000 (UTC) Received: by fxm15 with SMTP id 15so1158711fxm.13 for ; Thu, 29 Apr 2010 07:48:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.182.193 with SMTP id r1mr846160hbg.210.1272552489332; Thu, 29 Apr 2010 07:48:09 -0700 (PDT) Received: by 10.239.149.141 with HTTP; Thu, 29 Apr 2010 07:48:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 16:48:09 +0200 Message-ID: From: Olivier Smedts To: "Jason J. W. Williams" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 14:48:17 -0000 2010/4/29 Jason J. W. Williams : > Hi Y'all, > > I've written before that we're considering moving to FreeBSD 8 from > OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs > ZFS implementation for a high reliability environment like a database? > If so, what are your experiences? > > Basically, I'm curious how stable the implementation is and whether > it's ready for a critical production environment. Also, any gotchas > particularly with running it with MySQL or anything else that utilizes > a lot of memory. On Solaris, we cap the max ARC size to keep it from > grabbing all the system RAM and competing with MySQL. > > Any thoughts or comments are greatly appreciated. No experience with databases on ZFS but I think you should set the recordsize property to a proper (I mean, for your MySQL setup) value on the FS that will hold the data. Have a look at : http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases Cheers > > -J > _______________________________________________ > 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" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 14:53: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 CF378106566C for ; Thu, 29 Apr 2010 14:53:41 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (unknown [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 865478FC0A for ; Thu, 29 Apr 2010 14:53:41 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 5BE757121 for ; Thu, 29 Apr 2010 16:53:39 +0200 (CEST) Date: Thu, 29 Apr 2010 16:53:35 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20100429145334.GB62822@roberto-al.eurocontrol.fr> References: <4BD8F7FA.2080103@jrv.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD8F7FA.2080103@jrv.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 29 Apr 2010 16:53:39 +0200 (CEST) Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 14:53:41 -0000 According to James R. Van Artsdalen: > system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 > GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated Apart from the fact that you must at least set vm.kmem_size to something like 2x your RAM, one rule of thumb I've seen discussed for ZFS is that you will need approximatively 1 GB of RAM per TB of data so you may be a bit short here to get optimal perfs. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 15:19:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D25491065676; Thu, 29 Apr 2010 15:19:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B36148FC23; Thu, 29 Apr 2010 15:19:38 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 7E9191A3FBC; Thu, 29 Apr 2010 08:19:33 -0700 (PDT) Date: Thu, 29 Apr 2010 08:19:33 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20100429151933.GI36233@elvis.mu.org> References: <20100428171840.GS35381@elvis.mu.org> <201004290740.43355.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004290740.43355.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: fixes for enhanced coredump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 15:19:39 -0000 * John Baldwin [100429 05:46] wrote: > On Wednesday 28 April 2010 1:18:40 pm Alfred Perlstein wrote: > > I was recently working on the enhanced coredumps > > internal to Juniper and realized that there were > > some defects in the code I pushed (mostly due to > > mismerge), can someone please review? > > > > 1) don't allocate hostname[] on the stack > > 2) don't leak the temp buffer in imgact_elf_coredump. > > Doesn't this leak hostname? I don't see it being free'd anywhere. Thank you, I missed bringing that line over from JUNOS. -Alfred > > > thank you, > > -Alfred > > > > > > Index: kern/kern_sig.c > > =================================================================== > > --- kern/kern_sig.c (revision 207329) > > +++ kern/kern_sig.c (working copy) > > @@ -3004,8 +3004,9 @@ > > char *temp; > > size_t i; > > int indexpos; > > - char hostname[MAXHOSTNAMELEN]; > > + char *hostname; > > > > + hostname = NULL; > > format = corefilename; > > temp = malloc(MAXPATHLEN, M_TEMP, M_NOWAIT | M_ZERO); > > if (temp == NULL) > > @@ -3021,6 +3022,19 @@ > > sbuf_putc(&sb, '%'); > > break; > > case 'H': /* hostname */ > > + if (hostname == NULL) { > > + hostname = malloc(MAXHOSTNAMELEN, > > + M_TEMP, M_NOWAIT); > > + if (hostname == NULL) { > > + log(LOG_ERR, > > + "pid %ld (%s), uid (%lu): " > > + "unable to alloc memory " > > + "for corefile hostname\n", > > + (long)pid, name, > > + (u_long)uid); > > + goto nomem; > > + } > > + } > > getcredhostname(td->td_ucred, hostname, > > sizeof(hostname)); > > sbuf_printf(&sb, "%s", hostname); > > @@ -3054,9 +3068,10 @@ > > } > > #endif > > if (sbuf_overflowed(&sb)) { > > - sbuf_delete(&sb); > > log(LOG_ERR, "pid %ld (%s), uid (%lu): corename is too " > > "long\n", (long)pid, name, (u_long)uid); > > +nomem: > > + sbuf_delete(&sb); > > free(temp, M_TEMP); > > return (NULL); > > } > > Index: kern/imgact_elf.c > > =================================================================== > > --- kern/imgact_elf.c (revision 207329) > > +++ kern/imgact_elf.c (working copy) > > @@ -1088,8 +1088,10 @@ > > hdrsize = 0; > > __elfN(puthdr)(td, (void *)NULL, &hdrsize, seginfo.count); > > > > - if (hdrsize + seginfo.size >= limit) > > - return (EFAULT); > > + if (hdrsize + seginfo.size >= limit) { > > + error = EFAULT; > > + goto done; > > + } > > > > /* > > * Allocate memory for building the header, fill it up, > > @@ -1097,7 +1099,8 @@ > > */ > > hdr = malloc(hdrsize, M_TEMP, M_WAITOK); > > if (hdr == NULL) { > > - return (EINVAL); > > + error = EINVAL; > > + goto done; > > } > > error = __elfN(corehdr)(td, vp, cred, seginfo.count, hdr, hdrsize, > > gzfile); > > @@ -1125,8 +1128,8 @@ > > curproc->p_comm, error); > > } > > > > +done: > > #ifdef COMPRESS_USER_CORES > > -done: > > if (core_buf) > > free(core_buf, M_TEMP); > > if (gzfile) > > -- > > - Alfred Perlstein > > .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 > > .- FreeBSD committer > > _______________________________________________ > > 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" > > > > -- > John Baldwin -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 15:31: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 5A0CF106566C for ; Thu, 29 Apr 2010 15:31:57 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id BF8BB8FC1C for ; Thu, 29 Apr 2010 15:31:56 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id AF9571CC6E; Thu, 29 Apr 2010 17:31:54 +0200 (CEST) Date: Thu, 29 Apr 2010 17:31:54 +0200 From: Michael Moll To: freebsd-current@freebsd.org Message-ID: <20100429153154.GA70173@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 15:31:57 -0000 Hi All, after upgrading a FreeBSD/sparc64 machine from CURRENT sources of 3rd March to ones of 28th April config(8) doesn't work correctly anymore: server01# config -x /boot/kernel/kernel options CONFIG_AUTOGENERATED ident GENERIC machine sparc64 cpu SUN4U [...] device fwe device fwip device dcons device dcons_crom Assertion failed: (r != '\0' && ("Char present in the configuration " "string mustn't be equal to 0")), function kernconfdump, file /usr/src/usr.sbin/config/main.c, line 721. Abort (core dumped) A backtrace does not bring up anything useful: (gdb) bt #0 0x0000000040580668 in kill () from /lib/libc.so.7 #1 0x00000000404b6be0 in abort () from /lib/libc.so.7 #2 0x000000004056848c in __assert () from /lib/libc.so.7 #3 0x0000000000104064 in ?? () Previous frame identical to this frame (corrupt stack?) (gdb) Any ideas on this? Kind Regards -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 15:44: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 C8F84106564A for ; Thu, 29 Apr 2010 15:44:20 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB398FC08 for ; Thu, 29 Apr 2010 15:44:20 +0000 (UTC) Received: by ewy24 with SMTP id 24so4965899ewy.33 for ; Thu, 29 Apr 2010 08:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=knyeFTuw41DEfHdNMKJFRuHCkkH7sX0+fKFOaBtJLa8=; b=xz6bh/ReuDCZRRRseOSYgs5GsCcySLv5HAWu3LPLu1bWmOLp1jMP2N1OIxjVJlnpml +xmW5QZlPKWu/PFXv+eDMeQrcMqaAbvBh2RoUcnshu9m+GNNOXxPziSO+Kf1Eu3iYW4+ PLQb7kPWNg2NUaGRsl9BoZybvdvyCHlhHrGLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a5WZ8rOS1K9IhVwBgURAqzyziV7Lx5USKNludPvjz55cSlRQuRFJy2Ds2Cu0V3Qe2n Lac1iHDZGqT9AZZxGYzyOjUa+WfBUDCeNqXibKUo8M7SRCCAyIfSOcMzfCwBVVGE5Nz4 DGt8SP/31lhJVdHISI8ufaD7VRQIXAn6nqUyo= MIME-Version: 1.0 Received: by 10.213.53.70 with SMTP id l6mr3563014ebg.45.1272555856650; Thu, 29 Apr 2010 08:44:16 -0700 (PDT) Received: by 10.213.33.2 with HTTP; Thu, 29 Apr 2010 08:44:16 -0700 (PDT) In-Reply-To: <20100429145334.GB62822@roberto-al.eurocontrol.fr> References: <4BD8F7FA.2080103@jrv.org> <20100429145334.GB62822@roberto-al.eurocontrol.fr> Date: Thu, 29 Apr 2010 16:44:16 +0100 Message-ID: From: Tom Evans To: Ollivier Robert Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 15:44:20 -0000 On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert wrote: > According to James R. Van Artsdalen: >> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12 >> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. > >> panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated > > Apart from the fact that you must at least set vm.kmem_size to something like 2x your RAM, one rule of thumb I've seen discussed for ZFS is that you will need approximatively 1 GB of RAM per TB of data so you may be a bit short here to get optimal perfs. > Citation needed? I have a file server running amd64 8-STABLE with 4GB of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems with memory usage. Are you saying that after my next update, adding another 6 x 1.5 TB drives, it will start being flaky and/or panicing with kmem_map too small errors? Cheers Tom From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 16:08: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 4C9A9106564A for ; Thu, 29 Apr 2010 16:08:17 +0000 (UTC) (envelope-from jasonjwwilliams@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2538FC16 for ; Thu, 29 Apr 2010 16:08:17 +0000 (UTC) Received: by pvg3 with SMTP id 3so16071pvg.13 for ; Thu, 29 Apr 2010 09:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KADctowvXKJUJ7HdiB/bm8wAOLsLucGljemzJUPqBIw=; b=C5NKqNAA4v5KdIj4/A8zdGfrKX9QtUWpDhaDCLCQ/Z5GY4g8MnEGPKDWwEGgo1mjfY ruD8Or3HNptAJvzHJ3baPpkEAFgWZNedwErrn2yIaNMeOcLAydyBi3fBFZ2jBM4H+jBK 4XZ6s8S0Qnu1gUaWOhIorAcsl8W+R2DyatuNU= 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=OKkK8+4utt//kAPWn+0QMjJ0568V+HrtAcsl02+cPC/XSp9MjXGtnvuPBBNTJ1Jirg nXaqKc73L8vDHXk4tSFAqEXqQ17z0LtbxMvMgO+8RSlDsNXRxVFkh7HJUBskNnKQt4az tryr9lt71EVhQaJCyGMwJ5F9de1yCX0a8NldA= MIME-Version: 1.0 Received: by 10.140.251.19 with SMTP id y19mr1550383rvh.161.1272557290997; Thu, 29 Apr 2010 09:08:10 -0700 (PDT) Received: by 10.141.27.20 with HTTP; Thu, 29 Apr 2010 09:08:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 10:08:10 -0600 Message-ID: From: "Jason J. W. Williams" To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 16:08:17 -0000 Hi Olivier, We've actually been running MySQL on ZFS on Solaris for quite some time. :) We're very comfortable with that setup. My question is more specific to live experience with doing the same thing on FreeBSD. We know where the sabots are on MySQL/ZFS/Solaris. Would like to find out where the landmines are when you swap Solaris for FreeBSD in that equation. Thank you again. -J On Thu, Apr 29, 2010 at 8:48 AM, Olivier Smedts wrote: > 2010/4/29 Jason J. W. Williams : >> Hi Y'all, >> >> I've written before that we're considering moving to FreeBSD 8 from >> OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs >> ZFS implementation for a high reliability environment like a database? >> If so, what are your experiences? >> >> Basically, I'm curious how stable the implementation is and whether >> it's ready for a critical production environment. Also, any gotchas >> particularly with running it with MySQL or anything else that utilizes >> a lot of memory. On Solaris, we cap the max ARC size to keep it from >> grabbing all the system RAM and competing with MySQL. >> >> Any thoughts or comments are greatly appreciated. > > No experience with databases on ZFS but I think you should set the > recordsize property to a proper (I mean, for your MySQL setup) value > on the FS that will hold the data. > > Have a look at : > http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases > > Cheers > >> >> -J >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > > > > -- > Olivier Smedts =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org =A0 =A0 =A0 =A0- against HTML email & vCards =A0= X > www: http://www.gid0.org =A0 =A0- against proprietary attachments / \ > > =A0"Il y a seulement 10 sortes de gens dans le monde : > =A0ceux qui comprennent le binaire, > =A0et ceux qui ne le comprennent pas." > From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 16:50: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 51642106566B for ; Thu, 29 Apr 2010 16:50:18 +0000 (UTC) (envelope-from mickael.maillot@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 A43258FC12 for ; Thu, 29 Apr 2010 16:50:17 +0000 (UTC) Received: by wyb36 with SMTP id 36so464432wyb.13 for ; Thu, 29 Apr 2010 09:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GWTv7A6hN67RExsJ6cW2QuMuYlMBPN0W4ayvr6E+zF0=; b=kXkLo3WxHWE/SKHIVZyijIE+XM0syEYUf60uDxuB30PuoRDnKSfNlAZ17paLzb6odv oTobi7fh78HGJdCwIUrfYskPunog026DRmWyCsLi/rovFLev6Rf1ZbW1dgv1ytvRAsLZ FAmeu+SX5IHd6jLfSPbkbKMRTARZ2kShSuPWc= 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=ICFqkaIW6+dPQKBpT/zuVzpkyU2Pm2WxUvrSEWRZ1W+BB/KlUxdn0ZlrMuIA7GU20J DD8E37K8MxpURwgrj5ykxetzmMY2nL+tg2qeGZjxZUxKE0/zmhPNT6Chw80YE9/ThS0z iOFKHREnZVbv0pqxh/q8MBBRUHHmHKWzP3gYM= MIME-Version: 1.0 Received: by 10.216.154.145 with SMTP id h17mr517490wek.103.1272559809813; Thu, 29 Apr 2010 09:50:09 -0700 (PDT) Received: by 10.216.51.12 with HTTP; Thu, 29 Apr 2010 09:50:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 18:50:09 +0200 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: "Jason J. W. Williams" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 16:50:18 -0000 i have two freebsd running MySQL 5.1 on ZFS: - first: a 7-STABLE build (7.2, 2 month after zfs v13 import) the machine crash recently after a 130 day uptime beceause i dont limit arc size (so 4Gb by default) and i think they run oom. even with vfs.zfs.cache_flush_disable=3D1, no data loose, innodb redo the log and the mysql is fine. - second: a 8-STABLE FreeBSD db4.security-mail.net 8.0-STABLE FreeBSD 8.0-STABLE #2: Mon Apr 19 12:48:20 CEST 2010 root@db4.security-mail.net:/usr/obj/usr/src/sys/GENERIC amd64) updated recently, no problem at all. i follow all opensolaris databases recommendation but there is some diff between freebsd and osol. like primarycache=3Dmetadata we have a realy big table (~ 1,5 To) in innodb split with mysql partition (compress ration ~ x2) and it's works pretty well. i would recommend you to wait 8.1 to have all recent zfs enhancement for prod unless you follow all mailing list and commit. 2010/4/29 Jason J. W. Williams : > Hi Olivier, > > We've actually been running MySQL on ZFS on Solaris for quite some > time. :) We're very comfortable with that setup. > > My question is more specific to live experience with doing the same > thing on FreeBSD. We know where the sabots are on MySQL/ZFS/Solaris. > Would like to find out where the landmines are when you swap Solaris > for FreeBSD in that equation. > > Thank you again. > > -J > > On Thu, Apr 29, 2010 at 8:48 AM, Olivier Smedts wrote: >> 2010/4/29 Jason J. W. Williams : >>> Hi Y'all, >>> >>> I've written before that we're considering moving to FreeBSD 8 from >>> OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs >>> ZFS implementation for a high reliability environment like a database? >>> If so, what are your experiences? >>> >>> Basically, I'm curious how stable the implementation is and whether >>> it's ready for a critical production environment. Also, any gotchas >>> particularly with running it with MySQL or anything else that utilizes >>> a lot of memory. On Solaris, we cap the max ARC size to keep it from >>> grabbing all the system RAM and competing with MySQL. >>> >>> Any thoughts or comments are greatly appreciated. >> >> No experience with databases on ZFS but I think you should set the >> recordsize property to a proper (I mean, for your MySQL setup) value >> on the FS that will hold the data. >> >> Have a look at : >> http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases >> >> Cheers >> >>> >>> -J >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >>> >> >> >> >> -- >> Olivier Smedts =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0ASCII ribbon campaign ( ) >> e-mail: olivier@gid0.org =A0 =A0 =A0 =A0- against HTML email & vCards = =A0X >> www: http://www.gid0.org =A0 =A0- against proprietary attachments / \ >> >> =A0"Il y a seulement 10 sortes de gens dans le monde : >> =A0ceux qui comprennent le binaire, >> =A0et ceux qui ne le comprennent pas." >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 16:56:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 284391065670 for ; Thu, 29 Apr 2010 16:56:35 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1708FC14 for ; Thu, 29 Apr 2010 16:56:34 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.3/8.14.3) with ESMTP id o3TGuVKM016004; Thu, 29 Apr 2010 10:56:31 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Thu, 29 Apr 2010 10:56:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BD8F7FA.2080103@jrv.org> <20100429145334.GB62822@roberto-al.eurocontrol.fr> To: Tom Evans X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Ollivier Robert , freebsd-current@freebsd.org Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 16:56:35 -0000 On Apr 29, 2010, at 9:44 AM, Tom Evans wrote: > On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert > wrote: >> According to James R. Van Artsdalen: >>> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) = with 12 >>> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. >>=20 >>> panic: kmem_malloc(131072): kmem_map too small: 3832475648 total = allocated >>=20 >> Apart from the fact that you must at least set vm.kmem_size to = something like 2x your RAM, one rule of thumb I've seen discussed for = ZFS is that you will need approximatively 1 GB of RAM per TB of data so = you may be a bit short here to get optimal perfs. >>=20 >=20 > Citation needed? I have a file server running amd64 8-STABLE with 4GB > of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems > with memory usage. Are you saying that after my next update, adding > another 6 x 1.5 TB drives, it will start being flaky and/or panicing > with kmem_map too small errors? >=20 I'm sorry, but I find it absolutely absurd that any filesystem has to = wire down 2GB of RAM, and that the solution to panics is buy more RAM. Scott From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 17:03: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 55362106566C for ; Thu, 29 Apr 2010 17:03:47 +0000 (UTC) (envelope-from jasonjwwilliams@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 050688FC1A for ; Thu, 29 Apr 2010 17:03:46 +0000 (UTC) Received: by vws4 with SMTP id 4so876276vws.13 for ; Thu, 29 Apr 2010 10:03:39 -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=L8qkFjGFdhHmhJ8vX/RvebVvQdeMhIqsX+ueCPEBaNA=; b=lm6WeNYxAPBda+uie61zU+DorJHOkFb3uHPqSRvfwzqpPZnJAb/ljAv/EgsrIn31eE GacWSZOXamFY5SY+MZy3HkLxMcbUDi+yRxbzSq2Cj3ltRWpSUo/Jb2/POiwtajhgCD19 wuoyHZ1CB6IrHdaW4/1h9XCsJJxxw0Cp1FUB4= 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=XG1lxsbxP6unysj5oCZcU/N+TObdgtuDmGyRPIFd3XBTY0ClPtZLZ0swkj9W7JodTX rtFzZOVlz4+SGwQAZ6tmksRQJRPQt97Q5Qm6KuJncNOkqzO4M4DZPhZIoxruYNy/1GgN xzFd+NOX/cuQSklcsCy6Wdi89R4J1CAEr/zqM= MIME-Version: 1.0 Received: by 10.224.17.149 with SMTP id s21mr2912163qaa.46.1272560618940; Thu, 29 Apr 2010 10:03:38 -0700 (PDT) Received: by 10.224.28.138 with HTTP; Thu, 29 Apr 2010 10:03:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Apr 2010 11:03:38 -0600 Message-ID: From: "Jason J. W. Williams" To: =?ISO-8859-1?Q?Micka=EBl_Maillot?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Olivier Smedts , freebsd-current@freebsd.org Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 17:03:47 -0000 Hi Mickael, Thank you for the detailed response! By "wait 8.1 to have all recent zfs enhancement for prod" are you referring to the ZFS enhancements they've made over the past year in that regard, or enhancements the FreeBSD committers are making to make ZFS on FreeBSD work better? I've got to stand up some additional infrastructure within a short time commitment, so I might not be able to wait for 8.1. (I assume it's not due in the next 30 days.) -J On Thu, Apr 29, 2010 at 10:50 AM, Micka=EBl Maillot wrote: > i have two freebsd running MySQL 5.1 on ZFS: > - first: a 7-STABLE build (7.2, 2 month after zfs v13 import) > the machine crash recently after a 130 day uptime beceause i dont > limit arc size (so 4Gb by default) and i think they run oom. > even with vfs.zfs.cache_flush_disable=3D1, no data loose, innodb redo > the log and the mysql is fine. > - second: a 8-STABLE > FreeBSD db4.security-mail.net 8.0-STABLE FreeBSD 8.0-STABLE #2: Mon > Apr 19 12:48:20 CEST 2010 > root@db4.security-mail.net:/usr/obj/usr/src/sys/GENERIC =A0amd64) > updated recently, no problem at all. > > i follow all opensolaris databases recommendation but there is some > diff between freebsd and osol. > like primarycache=3Dmetadata > > we have a realy big table (~ 1,5 To) in innodb split with mysql > partition (compress ration ~ x2) and it's works pretty well. > > i would recommend you to wait 8.1 to have all recent zfs enhancement > for prod unless you follow all mailing list and commit. > > > 2010/4/29 Jason J. W. Williams : >> Hi Olivier, >> >> We've actually been running MySQL on ZFS on Solaris for quite some >> time. :) We're very comfortable with that setup. >> >> My question is more specific to live experience with doing the same >> thing on FreeBSD. We know where the sabots are on MySQL/ZFS/Solaris. >> Would like to find out where the landmines are when you swap Solaris >> for FreeBSD in that equation. >> >> Thank you again. >> >> -J >> >> On Thu, Apr 29, 2010 at 8:48 AM, Olivier Smedts wrote= : >>> 2010/4/29 Jason J. W. Williams : >>>> Hi Y'all, >>>> >>>> I've written before that we're considering moving to FreeBSD 8 from >>>> OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs >>>> ZFS implementation for a high reliability environment like a database? >>>> If so, what are your experiences? >>>> >>>> Basically, I'm curious how stable the implementation is and whether >>>> it's ready for a critical production environment. Also, any gotchas >>>> particularly with running it with MySQL or anything else that utilizes >>>> a lot of memory. On Solaris, we cap the max ARC size to keep it from >>>> grabbing all the system RAM and competing with MySQL. >>>> >>>> Any thoughts or comments are greatly appreciated. >>> >>> No experience with databases on ZFS but I think you should set the >>> recordsize property to a proper (I mean, for your MySQL setup) value >>> on the FS that will hold the data. >>> >>> Have a look at : >>> http://www.solarisinternals.com/wiki/index.php/ZFS_for_Databases >>> >>> Cheers >>> >>>> >>>> -J >>>> _______________________________________________ >>>> 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" >>>> >>> >>> >>> >>> -- >>> Olivier Smedts =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0ASCII ribbon campaign ( ) >>> e-mail: olivier@gid0.org =A0 =A0 =A0 =A0- against HTML email & vCards = =A0X >>> www: http://www.gid0.org =A0 =A0- against proprietary attachments / \ >>> >>> =A0"Il y a seulement 10 sortes de gens dans le monde : >>> =A0ceux qui comprennent le binaire, >>> =A0et ceux qui ne le comprennent pas." >>> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 18:25:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B69C6106566B for ; Thu, 29 Apr 2010 18:25:55 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8537A8FC08 for ; Thu, 29 Apr 2010 18:25:55 +0000 (UTC) Received: by pzk39 with SMTP id 39so3122807pzk.7 for ; Thu, 29 Apr 2010 11:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lC1IfH+hLAZW8Ifn7G7LAsGxq4D8vQmM+DbAPGMSq2s=; b=ThsdU+m44EqIK7JY0ej/ExX4Jnn2pY4Ix3qDbMIQurO1mMY56Ye7y+1oRAnzw2KOIC lbYqoxlSrX4lHOIzr+Y0eJNvUZLkr+1TW1pPhZAADnBC0xg1b6Ccmac0Lhka42sSMbop SHImqD68wk7hyY9H4d0uHhfvCBuzBiUteiGgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QlVal1bVO3gLC2BJg8NTk7gKsPbOF9ToHAnZi27x18zRN/RGVaWOI/fJJi2TXXg2Ik pJ741CV/kpiJ5T1HaTZ0PFF7nP4j+iVzdaIisaXV6AgD7DRDnyiR9BTjKXznbqNM0oND DzWBSIS0i1i1C9OFzNTk8Ssy+9s+NKN/GrC70= MIME-Version: 1.0 Received: by 10.140.248.18 with SMTP id v18mr5588775rvh.295.1272565547320; Thu, 29 Apr 2010 11:25:47 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.141.29.10 with HTTP; Thu, 29 Apr 2010 11:25:46 -0700 (PDT) In-Reply-To: References: <4BD8F7FA.2080103@jrv.org> <20100429145334.GB62822@roberto-al.eurocontrol.fr> Date: Thu, 29 Apr 2010 11:25:46 -0700 X-Google-Sender-Auth: 8b304f03eebd6b5b Message-ID: From: Artem Belevich To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Tom Evans , Ollivier Robert , freebsd-current@freebsd.org Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 18:25:55 -0000 If I understand it correctly, the problem in this case is that even when you do have more than enough RAM, kernel just does not provide enough space in kmem_map to map that physical memory into. Unless you want to have dedupe turned on large filesystem (and FreeBSD does not have this feature yet), you don't really *need* all that much RAM. "kmem_map too small" comes up as an issue way more often than lack of physical memory. --Artem On Thu, Apr 29, 2010 at 9:56 AM, Scott Long wrote: > On Apr 29, 2010, at 9:44 AM, Tom Evans wrote: >> On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert >> wrote: >>> According to James R. Van Artsdalen: >>>> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with = 12 >>>> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB. >>> >>>> panic: kmem_malloc(131072): kmem_map too small: 3832475648 total alloc= ated >>> >>> Apart from the fact that you must at least set vm.kmem_size to somethin= g like 2x your RAM, one rule of thumb I've seen discussed for ZFS is that y= ou will need approximatively 1 GB of RAM per TB of data so you may be a bit= short here to get optimal perfs. >>> >> >> Citation needed? I have a file server running amd64 8-STABLE with 4GB >> of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems >> with memory usage. Are you saying that after my next update, adding >> another 6 x 1.5 TB drives, it will start being flaky and/or panicing >> with kmem_map too small errors? >> > > I'm sorry, but I find it absolutely absurd that any filesystem has to wir= e down 2GB of RAM, and that the solution to panics is buy more RAM. > > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 20:33:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F1121065674 for ; Thu, 29 Apr 2010 20:33:36 +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 49F608FC24 for ; Thu, 29 Apr 2010 20:33:35 +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 XAA17602; Thu, 29 Apr 2010 23:33:31 +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 1O7aQN-0009fO-Hi; Thu, 29 Apr 2010 23:33:31 +0300 Message-ID: <4BD9ED1A.3050100@icyb.net.ua> Date: Thu, 29 Apr 2010 23:33:30 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Michael Moll References: <20100429153154.GA70173@darkthrone.kvedulv.de> In-Reply-To: <20100429153154.GA70173@darkthrone.kvedulv.de> 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: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 20:33:36 -0000 on 29/04/2010 18:31 Michael Moll said the following: [snip] > Assertion failed: (r != '\0' && ("Char present in the configuration " "string > mustn't be equal to 0")), function kernconfdump, file > /usr/src/usr.sbin/config/main.c, line 721. [snip] > Any ideas on this? Yes, one idea - to verify what the message above says. You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within your kernel config file. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 21:19:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6887D106564A for ; Thu, 29 Apr 2010 21:19:49 +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 AB1F88FC0A for ; Thu, 29 Apr 2010 21:19:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA18333; Fri, 30 Apr 2010 00:19: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 1O7b97-0009jt-Me; Fri, 30 Apr 2010 00:19:45 +0300 Message-ID: <4BD9F7F1.7020607@icyb.net.ua> Date: Fri, 30 Apr 2010 00:19:45 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Michael Moll References: <20100429153154.GA70173@darkthrone.kvedulv.de> <4BD9ED1A.3050100@icyb.net.ua> <20100429211256.GA73377@darkthrone.kvedulv.de> In-Reply-To: <20100429211256.GA73377@darkthrone.kvedulv.de> 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: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 21:19:49 -0000 on 30/04/2010 00:12 Michael Moll said the following: > Hi, > > On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: >> on 29/04/2010 18:31 Michael Moll said the following: >> You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within >> your kernel config file. > > Thanks, I checked this and there are no 0x00s in the config file itself, Then that assert message is strange. Or there is something else to this situation. > but a hd to /boot/kernel/kernel reveals: > > 09 66 77 69 70 0a 64 65 76 69 63 65 09 64 63 6f |.fwip.device.dco| > 6e 73 0a 64 65 76 69 63 65 09 64 63 6f 6e 73 5f |ns.device.dcons_| > 63 72 6f 6d 0a 00 00 00 00 00 00 00 00 00 00 00 |crom............| > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > > This also explains why a recent config-binary worked against the old > kernel... The were some commits to /src/usr.sbin/config/* in the last > weeks, maybe one of them broke this. Actually I think that this doesn't mean anything. /boot/kernel/kernel is a binary, an executable, it is expected to have a fair amount of 0x00 in it. That assert was specifically about kernel _config_ file. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 21:20:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FE97106574E for ; Thu, 29 Apr 2010 21:20:36 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 0D99B8FC2D for ; Thu, 29 Apr 2010 21:20:35 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o3TLKWV1062657; Thu, 29 Apr 2010 16:20:33 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=dKXKyYSa2MFsurQCPvXGWc7OubL9JL0NSVeIoG4xC4cU42zUTH2tLSPgUwq1Z0yuK aRaClxe/6hL6SVAmMpaFVu/UP05dhBoZICflq/iIwF/2dtHl0RKnwqbXC2Nnk1GCgGt MaWwl2R8WCNV1BNFgs/hg9cOGHoyuKbJh8ztlII= Message-ID: <4BD9F820.5060606@jrv.org> Date: Thu, 29 Apr 2010 16:20:32 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=F3=CD=C1=C7=C9=CE?= References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Artem Belevich Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 21:20:36 -0000 =E1=CE=C4=D2=C5=CA =F3=CD=C1=C7=C9=CE wrote: > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total all= ocated > > > I open PR amd64/145654 with problem like it. Have you increasing Wired = memory at buildworld ? > =20 No. This # while true > do > sysctl -A | grep wired > make -j8 buildworld > done is getting: vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 vm.max_wired: 997427 Is that the right variable to look at? A friend of mine can duplicate your PR too. From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 21:30:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CB53106566B for ; Thu, 29 Apr 2010 21:30:39 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [194.126.158.19]) by mx1.freebsd.org (Postfix) with ESMTP id C8A7C8FC13 for ; Thu, 29 Apr 2010 21:30:38 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id D19721CC6E; Thu, 29 Apr 2010 23:12:56 +0200 (CEST) Date: Thu, 29 Apr 2010 23:12:56 +0200 From: Michael Moll To: Andriy Gapon Message-ID: <20100429211256.GA73377@darkthrone.kvedulv.de> References: <20100429153154.GA70173@darkthrone.kvedulv.de> <4BD9ED1A.3050100@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD9ED1A.3050100@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 21:30:39 -0000 Hi, On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: > on 29/04/2010 18:31 Michael Moll said the following: > You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within > your kernel config file. Thanks, I checked this and there are no 0x00s in the config file itself, but a hd to /boot/kernel/kernel reveals: 09 66 77 69 70 0a 64 65 76 69 63 65 09 64 63 6f |.fwip.device.dco| 6e 73 0a 64 65 76 69 63 65 09 64 63 6f 6e 73 5f |ns.device.dcons_| 63 72 6f 6d 0a 00 00 00 00 00 00 00 00 00 00 00 |crom............| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| This also explains why a recent config-binary worked against the old kernel... The were some commits to /src/usr.sbin/config/* in the last weeks, maybe one of them broke this. Kind Regards -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 21:41:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D65F106566C for ; Thu, 29 Apr 2010 21:41:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [109.74.192.160]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7C58FC0C for ; Thu, 29 Apr 2010 21:41:46 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id CA0CBC400D; Thu, 29 Apr 2010 21:41:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 29 Apr 2010 21:41:44 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Thu, 29 Apr 2010 22:41:30 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100429153154.GA70173@darkthrone.kvedulv.de> <20100429211256.GA73377@darkthrone.kvedulv.de> <4BD9F7F1.7020607@icyb.net.ua> In-Reply-To: <4BD9F7F1.7020607@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004292241.30915.bruce@cran.org.uk> Cc: Michael Moll , Andriy Gapon Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 21:41:46 -0000 On Thursday 29 April 2010 22:19:45 Andriy Gapon wrote: > on 30/04/2010 00:12 Michael Moll said the following: > > Hi, > > > > On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: > >> on 29/04/2010 18:31 Michael Moll said the following: > >> You can use hd to see if you indeed have '\0' (0x00) symbol somewhere > >> within your kernel config file. > > > > Thanks, I checked this and there are no 0x00s in the config file itself, > > Then that assert message is strange. > Or there is something else to this situation. > > > but a hd to /boot/kernel/kernel reveals: > > > > 09 66 77 69 70 0a 64 65 76 69 63 65 09 64 63 6f |.fwip.device.dco| > > 6e 73 0a 64 65 76 69 63 65 09 64 63 6f 6e 73 5f |ns.device.dcons_| > > 63 72 6f 6d 0a 00 00 00 00 00 00 00 00 00 00 00 |crom............| > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > > > > This also explains why a recent config-binary worked against the old > > kernel... The were some commits to /src/usr.sbin/config/* in the last > > weeks, maybe one of them broke this. > > Actually I think that this doesn't mean anything. > /boot/kernel/kernel is a binary, an executable, it is expected to have a > fair amount of 0x00 in it. > That assert was specifically about kernel _config_ file. It's expected to have some 0x00s, but hopefully not in the middle of the embedded kernel configuration file that has recently been added to GENERIC :) -- Bruce From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 21:46:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 536E3106566B for ; Thu, 29 Apr 2010 21:46:33 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 252018FC0A for ; Thu, 29 Apr 2010 21:46:32 +0000 (UTC) Received: by pvg3 with SMTP id 3so218646pvg.13 for ; Thu, 29 Apr 2010 14:46:30 -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=0aaEHz68IF3EfWcXWwHWJdalg1d9y+kcNuZJOoUfVcE=; b=UfMvN3+ZmMDB8L/Onb7tH3NdlzV2SP1UzopwAxlisIOMHA7kWo9BC6k24Sd4/jOMou KwYnH6xycKOj8qUig0UhBswceC4Y1khOMAr19q2NG3d2JtFnE+im/mleT8KZt0E9DCY+ Ro3sLfS6L82tLjvVddvGnf4SqoT786cjRbC80= 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=OFeqLUnfVQMoilBkJUbyjHHZW+UpWpaKQFWlpKj0w6tLwe4FtpCW4xLKgeRZ5WlHQd DSmUFop+43/6NZbXEqp5UfjFXTlDogUz+MHW3rq0ZzSkg7p1eb3cNgQyBarvau5ie9nz WD5YNd8g+qvc9dVKYyAhuZdOKrcnJdNv8K3rA= MIME-Version: 1.0 Received: by 10.142.201.17 with SMTP id y17mr1479389wff.283.1272577590095; Thu, 29 Apr 2010 14:46:30 -0700 (PDT) Received: by 10.142.69.2 with HTTP; Thu, 29 Apr 2010 14:46:29 -0700 (PDT) In-Reply-To: <201004292241.30915.bruce@cran.org.uk> References: <20100429153154.GA70173@darkthrone.kvedulv.de> <20100429211256.GA73377@darkthrone.kvedulv.de> <4BD9F7F1.7020607@icyb.net.ua> <201004292241.30915.bruce@cran.org.uk> Date: Thu, 29 Apr 2010 14:46:29 -0700 Message-ID: From: Garrett Cooper To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michael Moll , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 21:46:33 -0000 On Thu, Apr 29, 2010 at 2:41 PM, Bruce Cran wrote: > On Thursday 29 April 2010 22:19:45 Andriy Gapon wrote: >> on 30/04/2010 00:12 Michael Moll said the following: >> > Hi, >> > >> > On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote: >> >> on 29/04/2010 18:31 Michael Moll said the following: >> >> You can use hd to see if you indeed have '\0' (0x00) symbol somewhere >> >> within your kernel config file. >> > >> > Thanks, I checked this and there are no 0x00s in the config file itsel= f, >> >> Then that assert message is strange. >> Or there is something else to this situation. >> >> > but a hd to /boot/kernel/kernel reveals: >> > >> > 09 66 77 69 70 0a 64 65 =A076 69 63 65 09 64 63 6f |.fwip.device.dco| >> > 6e 73 0a 64 65 76 69 63 =A065 09 64 63 6f 6e 73 5f |ns.device.dcons_| >> > 63 72 6f 6d 0a 00 00 00 =A000 00 00 00 00 00 00 00 |crom............| >> > 00 00 00 00 00 00 00 00 =A000 00 00 00 00 00 00 00 |................| >> > >> > This also explains why a recent config-binary worked against the old >> > kernel... The were some commits to /src/usr.sbin/config/* in the last >> > weeks, maybe one of them broke this. >> >> Actually I think that this doesn't mean anything. >> /boot/kernel/kernel is a binary, an executable, it is expected to have a >> fair amount of 0x00 in it. >> That assert was specifically about kernel _config_ file. > > It's expected to have some 0x00s, but hopefully not in the middle of the > embedded kernel configuration file that has recently been added to GENERI= C :) Michael, Does a version prior to last week work, and could you please attach your kernel configuration file(s) for analysis? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 22:18:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1960106564A for ; Thu, 29 Apr 2010 22:18:41 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5D42D8FC18 for ; Thu, 29 Apr 2010 22:18:41 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id o3TMIcfO063911; Thu, 29 Apr 2010 17:18:38 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=JeH51lHKELin1IvTWWrsG36ZXFXyaTylglvNfiTKG2UFAmg2hV5e6oX2cKMvgm6WC hnC2GX+XQZAoIW2YoiuQ4Z6/bvb+8WC/ljBm5gJPLaADfsFqBvZhRbijKct3rn6TIpL tPSuLE5OZvEq7t1/7djxnvsh5qknR+MEK2PJIkY= Message-ID: <4BDA05BE.8090807@jrv.org> Date: Thu, 29 Apr 2010 17:18:38 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Scott Long References: <4BD8F7FA.2080103@jrv.org> <20100429145334.GB62822@roberto-al.eurocontrol.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Evans , Ollivier Robert , freebsd-current@freebsd.org Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 22:18:41 -0000 Scott Long wrote: > > I'm sorry, but I find it absolutely absurd that any filesystem has to wire down 2GB of RAM, and that the solution to panics is buy more The only thing buying more RAM is likely to do is make the memory leak behind this harder to reproduce. Likewise increasing kernel tunables. It may only be a short-term leak, i.e. something that would be recovered normally. Does FreeBSD have a kernel debug facility for this? Is there a way to look at a kernel dump file and identify by caller who allocated space? From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 22:30:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 970011065677 for ; Thu, 29 Apr 2010 22:30:24 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [109.74.192.160]) by mx1.freebsd.org (Postfix) with ESMTP id 57C6E8FC08 for ; Thu, 29 Apr 2010 22:30:24 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3BE2BC400D; Thu, 29 Apr 2010 22:30:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.3 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 29 Apr 2010 22:30:23 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Thu, 29 Apr 2010 23:30:06 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100429153154.GA70173@darkthrone.kvedulv.de> <201004292241.30915.bruce@cran.org.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004292330.06455.bruce@cran.org.uk> Cc: Garrett Cooper , Andriy Gapon , Michael Moll Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 22:30:24 -0000 On Thursday 29 April 2010 22:46:29 Garrett Cooper wrote: > Does a version prior to last week work, and could you please > attach your kernel configuration file(s) for analysis? I remember coming across the same error during buildkernel last week, but can't remember how, or how I resolved it. I've just built GENERIC from recent sources and can get the assert to occur by running "config -x /boot/kernel/kernel". It looks like it thinks there's more data available than there is. config/main.c gets the size of the configuration by running elfdump: > elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' ' -f 2 | paste - - - 10053368 2656 The first column is the offset, and the second is the number of bytes, but the embedded configuration only has 2649 bytes. Some of the output from config: > config -x /boot/kernel/kernel options CONFIG_AUTOGENERATED ident GENERIC machine sparc64 cpu SUN4U makeoptions DEBUG=-g options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE [...] device uath device ural device zyd device firewire device sbp device fwe device fwip device dcons device dcons_crom Assertion failed: (r != '\0' && ("Char present in the configuration " "string mustn't be equal to 0")), function kernconfdump, file /usr/src/usr.sbin/config/main.c, line 719. Abort (core dumped) -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 22:49:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C4BA1065673 for ; Thu, 29 Apr 2010 22:49:40 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [194.126.158.19]) by mx1.freebsd.org (Postfix) with ESMTP id C4CF88FC0A for ; Thu, 29 Apr 2010 22:49:39 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id BF93C1CC6E; Fri, 30 Apr 2010 00:49:38 +0200 (CEST) Date: Fri, 30 Apr 2010 00:49:38 +0200 From: Michael Moll To: Bruce Cran Message-ID: <20100429224938.GI90938@darkthrone.kvedulv.de> References: <20100429153154.GA70173@darkthrone.kvedulv.de> <201004292241.30915.bruce@cran.org.uk> <201004292330.06455.bruce@cran.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004292330.06455.bruce@cran.org.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, imp@freebsd.org Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 22:49:40 -0000 Hi, On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: > /boot/kernel/kernel". It looks like it thinks there's more data available > than there is. > > config/main.c gets the size of the configuration by running elfdump: > > > elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' ' > -f 2 | paste - - - > > 10053368 2656 > > The first column is the offset, and the second is the number of bytes, but the > embedded configuration only has 2649 bytes. OK, that explains that with all the related commits backup out (207265-206664) the resulting config-binary still fails. I don't have time today to build the kernel with the different revisions to hunt the problem down to one commit... imp@: The last commits to usr.sbin/config/* might have raised this problem, could you have a look at it? Kind Regards -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 23:10:56 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E14C106564A for ; Thu, 29 Apr 2010 23:10:56 +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 F1D7D8FC16 for ; Thu, 29 Apr 2010 23:10:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3TN6lcY013041; Thu, 29 Apr 2010 17:06:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 29 Apr 2010 17:07:00 -0600 (MDT) Message-Id: <20100429.170700.752311254921725854.imp@bsdimp.com> To: kvedulv@kvedulv.de From: "M. Warner Losh" In-Reply-To: <20100429224938.GI90938@darkthrone.kvedulv.de> References: <201004292330.06455.bruce@cran.org.uk> <20100429224938.GI90938@darkthrone.kvedulv.de> 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: bruce@cran.org.uk, freebsd-current@FreeBSD.org Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 23:10:56 -0000 In message: <20100429224938.GI90938@darkthrone.kvedulv.de> Michael Moll writes: : Hi, : : On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: : > /boot/kernel/kernel". It looks like it thinks there's more data available : > than there is. : > : > config/main.c gets the size of the configuration by running elfdump: : > : > > elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' ' : > -f 2 | paste - - - : > : > 10053368 2656 : > : > The first column is the offset, and the second is the number of bytes, but the : > embedded configuration only has 2649 bytes. : : OK, that explains that with all the related commits backup out : (207265-206664) the resulting config-binary still fails. I don't have : time today to build the kernel with the different revisions to hunt the : problem down to one commit... : : imp@: The last commits to usr.sbin/config/* might have raised this : problem, could you have a look at it? Do you have a small, reproducible sequence of events that will recreate this problem? I've seen no problems at all in my testing. I assume this is in -current? Warner From owner-freebsd-current@FreeBSD.ORG Thu Apr 29 21:43:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC4C41065674 for ; Thu, 29 Apr 2010 21:43:34 +0000 (UTC) (envelope-from roberto@keltia.net) Received: from keltia.net (fbx.keltia.net [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 4FABA8FC0C for ; Thu, 29 Apr 2010 21:43:34 +0000 (UTC) Received: from lonrach.keltia.net (lonrach.keltia.net [193.56.58.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 25CA87528 for ; Thu, 29 Apr 2010 23:23:59 +0200 (CEST) Date: Thu, 29 Apr 2010 23:23:46 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org Message-ID: <20100429212345.GA2215@lonrach.keltia.net> References: <4BD8F7FA.2080103@jrv.org> <20100429145334.GB62822@roberto-al.eurocontrol.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Thu, 29 Apr 2010 23:23:59 +0200 (CEST) X-Mailman-Approved-At: Thu, 29 Apr 2010 23:29:26 +0000 Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Apr 2010 21:43:34 -0000 According to Tom Evans: > Citation needed? I have a file server running amd64 8-STABLE with 4GB > of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems > with memory usage. Are you saying that after my next update, adding > another 6 x 1.5 TB drives, it will start being flaky and/or panicing > with kmem_map too small errors? I don't have the citation handy but it was on the opensolaris forum in the zfs community. I understand that this is FreeBSD we're speaking about but the figure comes from the fact that ZFS (and particularly the ARC cache) does take a lot of memory. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 00:00:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E5F1065670 for ; Fri, 30 Apr 2010 00:00:18 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [194.126.158.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6F98FC12 for ; Fri, 30 Apr 2010 00:00:18 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id 1B8C71CC6E; Fri, 30 Apr 2010 02:00:17 +0200 (CEST) Date: Fri, 30 Apr 2010 02:00:16 +0200 From: Michael Moll To: "M. Warner Losh" Message-ID: <20100430000016.GA90776@darkthrone.kvedulv.de> References: <201004292330.06455.bruce@cran.org.uk> <20100429224938.GI90938@darkthrone.kvedulv.de> <20100429.170700.752311254921725854.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100429.170700.752311254921725854.imp@bsdimp.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: bruce@cran.org.uk, freebsd-current@FreeBSD.org Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 00:00:18 -0000 On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: > Do you have a small, reproducible sequence of events that will > recreate this problem? I've seen no problems at all in my testing. > I assume this is in -current? Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on other archs) and run config -x on the resulting file. Kind Regards -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 00:36:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D866C1065673 for ; Fri, 30 Apr 2010 00:36:15 +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 804A68FC1D for ; Fri, 30 Apr 2010 00:36:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3U0U8Oj013803; Thu, 29 Apr 2010 18:30:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 29 Apr 2010 18:30:20 -0600 (MDT) Message-Id: <20100429.183020.769051483995706188.imp@bsdimp.com> To: kvedulv@kvedulv.de From: "M. Warner Losh" In-Reply-To: <20100430000016.GA90776@darkthrone.kvedulv.de> References: <20100429224938.GI90938@darkthrone.kvedulv.de> <20100429.170700.752311254921725854.imp@bsdimp.com> <20100430000016.GA90776@darkthrone.kvedulv.de> 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: bruce@cran.org.uk, freebsd-current@freebsd.org Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 00:36:15 -0000 In message: <20100430000016.GA90776@darkthrone.kvedulv.de> Michael Moll writes: : On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: : > Do you have a small, reproducible sequence of events that will : > recreate this problem? I've seen no problems at all in my testing. : > I assume this is in -current? : : Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on other : archs) and run config -x on the resulting file. Can you please enclose the exact config file that you are using? Thanks. Warner From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 01:53:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A2A5106564A; Fri, 30 Apr 2010 01:53:25 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [109.74.192.160]) by mx1.freebsd.org (Postfix) with ESMTP id BE8108FC0C; Fri, 30 Apr 2010 01:53:24 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id DFE46C400D; Fri, 30 Apr 2010 01:53:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon.cran.org.uk X-Spam-Level: X-Spam-Status: No, score=-2.2 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from core.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Fri, 30 Apr 2010 01:53:23 +0000 (UTC) From: Bruce Cran To: freebsd-current@freebsd.org Date: Fri, 30 Apr 2010 02:53:10 +0100 User-Agent: KMail/1.13.2 (FreeBSD/9.0-CURRENT; KDE/4.4.2; amd64; ; ) References: <20100429153154.GA70173@darkthrone.kvedulv.de> <201004292330.06455.bruce@cran.org.uk> <20100429224938.GI90938@darkthrone.kvedulv.de> In-Reply-To: <20100429224938.GI90938@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004300253.10461.bruce@cran.org.uk> Cc: Michael Moll , imp@freebsd.org Subject: Re: config(8) dumps core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 01:53:25 -0000 On Thursday 29 April 2010 23:49:38 Michael Moll wrote: > OK, that explains that with all the related commits backup out > (207265-206664) the resulting config-binary still fails. I don't have > time today to build the kernel with the different revisions to hunt the > problem down to one commit... > > imp@: The last commits to usr.sbin/config/* might have raised this > problem, could you have a look at it? It appears it was r188214 that caused the breakage: in versions prior to that, it outputs 6 trailing NULs and exits normally on a modern kernel. If it only broke recently then I guess it was kernel, not changes to the config app, that broke it. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 02:53:40 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3F4D106566C for ; Fri, 30 Apr 2010 02:53:40 +0000 (UTC) (envelope-from super_bisquit@yahoo.com) Received: from n8.bullet.mail.ac4.yahoo.com (n8.bullet.mail.ac4.yahoo.com [76.13.13.236]) by mx1.freebsd.org (Postfix) with SMTP id 65DC88FC13 for ; Fri, 30 Apr 2010 02:53:40 +0000 (UTC) Received: from [76.13.13.26] by n8.bullet.mail.ac4.yahoo.com with NNFMP; 30 Apr 2010 02:40:32 -0000 Received: from [68.142.194.243] by t3.bullet.mail.ac4.yahoo.com with NNFMP; 30 Apr 2010 02:40:32 -0000 Received: from [67.195.9.82] by t1.bullet.mud.yahoo.com with NNFMP; 30 Apr 2010 02:40:32 -0000 Received: from [98.137.27.214] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 30 Apr 2010 02:40:31 -0000 Received: from [127.0.0.1] by omp124.mail.gq1.yahoo.com with NNFMP; 30 Apr 2010 02:40:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 975395.23602.bm@omp124.mail.gq1.yahoo.com Received: (qmail 17490 invoked by uid 60001); 30 Apr 2010 02:40:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1272595231; bh=PDVQCG8rKcJDYVrS1zA4MMNafkZv1bBzwelCs83fS78=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Oeqndb0yd8stHUww4brz79t1PxCo7s8N0ri1i/sC6jevBYthqDLBwG8VIl74ZfG7dKpzA2dFkugWuLcehOhlcQNhlYZZvpO9hGXvGPDneqlJPdycYfr3PpgEE3poqIk6w8iq9zfJaFOZ5j17ryr7SnVavWUzgYVDkA6IvVCwjdU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=aJavRsnuZe6eU66JdOV20oO5g7mdSS/kOP/8iIuYcCpa/df4Z8nLYYzUJXkTRYF8JpbCQMGL364JHvlAoE5IEhPEYKF5I85+QyLbr+gHXJmpcFE93FMy8duXrHzY+geHm1z0TuK4W0ijB0fq64Pw2yujycMXY1sZc7Orv8nWNA4=; Message-ID: <854597.16742.qm@web110102.mail.gq1.yahoo.com> X-YMail-OSG: 8ZhMiC0VM1ksynwa_o4OM3DI_z9JfqvdMwmxVZZh__BOnAj t8s5DoJMFLdJTQSHg.WWZHFGlUpBVDdTHgMbLJc0loArTKJ2lmHbPW17UuzD PWaQauTadH1NZBXAgkXY6h4sIhqZal6X4lekBTKwdBsYFSfS1wfVGCQlx6T3 5iO2V0.Hb1nXKysPtgBqzRS7iC275sfFjOBFqK90.aic3AOm8J5Z26XoZa6i v0WckF0dZ7Cu2Ase68C.9ZaAnDF1gelY- Received: from [71.200.56.84] by web110102.mail.gq1.yahoo.com via HTTP; Thu, 29 Apr 2010 19:40:31 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Thu, 29 Apr 2010 19:40:31 -0700 (PDT) From: Super Biscuit To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LOR on secondary machine. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 02:53:40 -0000 =A0I won't be able to give all of the information because the machine in qu= estion does not have a graphical environment. Here is what I can give. PowerMac G3=20 Motorola 750 400mHz revision 2.2 Open Firmware 3.0 FreeBSD 9.0 SNAPSHOT lock order reversal: 1st 0xd47cc118 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0x177c200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: 0xdafa9760: at kdb_backtrace+0x4c 0xdafa9870: at_witness_debugger+0x3c 0xdafa97a0:at witness_checkorder+0x8d0 0xdafa9800: at _sx_xcloxk+0x90 0xdafa9830: at ufsdirhash_acquire+0x40 0xdafa9850: at ufsdirhash_remove+0x2c 0xdafa98c0: at ufs_remove+0x8c 0xdafa9900: at VOP_REMOVE_APV+0xe0 0xdafa9920: at kern_unlinkat+0x22c 0xdafa9a60: at kern_unlink+0x28 0xdafa9a80: at unlink+0x1c 0xdafa9aa0: at trap+0x37c 0xdafa9b60: at powerpc_interrupt+0x100 0xdafa9b90: user SC trap by 0x41957238:srr1=3D0xd032 r1=3D0x7fffc4e0 cr=3D0x20000042 xer=3D0 ctr=3D0x41957230 =0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 04:31:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AF89106566B for ; Fri, 30 Apr 2010 04:31:13 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f206.mail.ru (f206.mail.ru [217.69.128.145]) by mx1.freebsd.org (Postfix) with ESMTP id 060758FC12 for ; Fri, 30 Apr 2010 04:31:12 +0000 (UTC) Received: from mail by f206.mail.ru with local id 1O7hrp-0001DP-00; Fri, 30 Apr 2010 08:30:21 +0400 Received: from [91.202.27.126] by win.mail.ru with HTTP; Fri, 30 Apr 2010 08:30:21 +0400 From: Andrey Smagin To: James R. Van Artsdalen Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: 172.17.1.151 via proxy [91.202.27.126] Date: Fri, 30 Apr 2010 08:30:21 +0400 References: <4BD9F820.5060606@jrv.org> In-Reply-To: <4BD9F820.5060606@jrv.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: FreeBSD Current , Artem Belevich Subject: Re[2]: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 04:31:13 -0000 Thu, 29 Apr 2010 16:20:32 -0500 ÐÉÓØÍÏ ÏÔ "James R. Van Artsdalen" : > áÎÄÒÅÊ óÍÁÇÉÎ wrote: > > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated > > > > > I open PR amd64/145654 with problem like it. Have you increasing Wired memory at buildworld ? > > > > No. This > > # while true > > do > > sysctl -A | grep wired > > make -j8 buildworld > > done > > is getting: > > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > vm.max_wired: 997427 > > Is that the right variable to look at? strange - by "top" Wired memory now about 1.2Gbyte, but vm.max_wired: 330338 Also my system crashed after 3-5 buildworld's and kernels. usr/obj+usr/src - ~2GB size, 4GB of RAM - twice more than need to have all data for compilation in memory. > A friend of mine can duplicate your PR too. From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 04:37:07 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A078106564A for ; Fri, 30 Apr 2010 04:37:07 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5EBB88FC0A for ; Fri, 30 Apr 2010 04:37:06 +0000 (UTC) Received: by vws4 with SMTP id 4so1335455vws.13 for ; Thu, 29 Apr 2010 21:37:01 -0700 (PDT) Received: by 10.220.63.143 with SMTP id b15mr6333055vci.3.1272602221224; Thu, 29 Apr 2010 21:37:01 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id z22sm7267139vco.10.2010.04.29.21.36.59 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Apr 2010 21:37:00 -0700 (PDT) Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 04:37:07 -0000 Hello, I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct boot into single user but there were problems with tunefs that could lead to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain types of activity. I have only had this reported twice and I am not able to reproduce no matter how much load I throw at the machine. If you reproduce this please try to get a coredump or minidump. Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 03:42:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9A72106564A for ; Fri, 30 Apr 2010 03:42:33 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id A97148FC08 for ; Fri, 30 Apr 2010 03:42:33 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id DD20D153494; Fri, 30 Apr 2010 04:35:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejAEE8XAJohY; Fri, 30 Apr 2010 04:35:29 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 83A3C153441; Fri, 30 Apr 2010 00:27:03 +0200 (CEST) Message-ID: <4BDA07B4.40506@digiware.nl> Date: Fri, 30 Apr 2010 00:27:00 +0200 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Artem Belevich References: <4BD8F7FA.2080103@jrv.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 30 Apr 2010 04:46:14 +0000 Cc: FreeBSD Current , "James R. Van Artsdalen" Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 03:42:34 -0000 On 29-4-2010 6:17, Artem Belevich wrote: > Do you have vm.kmem_size set in /boot/loader.conf? > > If not, do set it to about double of your physical RAM size. Defaults > are way too conservative for use with large amounts of memory and ZFS. As per this suggestion I set this value to 2*8G: vm.kmem_size="17179869184" And bfore the kernel boots this value is set in the loader. Tested it by goinginto the loader and show the value. But once booted I still get: [/boot] wjw@zfs.digiware.nl> sysctl vm.kmem_size vm.kmem_size: 3718209536 So who is resetting this value??? Thanx, -WjW From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 08:05:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E073106566C for ; Fri, 30 Apr 2010 08:05:31 +0000 (UTC) (envelope-from p.massat@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 C95438FC0A for ; Fri, 30 Apr 2010 08:05:30 +0000 (UTC) Received: by vws4 with SMTP id 4so1433258vws.13 for ; Fri, 30 Apr 2010 01:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=ASPsBki6/62Q+bH0tXy7zkLISIcR+CrgV0zGGScvp/k=; b=mBNyzePABjzp8DeSeaaadDqWTeiKMTo9Z8enHkaEbVsBN46wxld69Jm1HU+JDFUze1 uborIgr0Y+cXCVwzkfI9cU19CCIw5059uz6Rlkg+C6rqMELpaM0QUlgzLkOGLDOzLAcq GptDunr1DJIn+UHoJOhRiTbl4UB7Zl8FV8N+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=p/0bvgZybam0C9opnbd5a/NlmYiUC9go9iPh4vdJ2O1FQGUee3W7P38APJ4ZYhvR6j tjtMCl62S1nsOgGHkLCmOKyY0o9AkeKoJs3NZYM9aB4sSQmRdbHGsnSgE/2cQTE6jd+P Z/MNPe3RztWTGGYqX9Vn39mMEFmInIj8j+oYU= Received: by 10.150.119.37 with SMTP id r37mr1463804ybc.341.1272614719437; Fri, 30 Apr 2010 01:05:19 -0700 (PDT) MIME-Version: 1.0 Sender: p.massat@gmail.com Received: by 10.100.165.19 with HTTP; Fri, 30 Apr 2010 01:04:59 -0700 (PDT) In-Reply-To: References: From: Pierre Massat Date: Fri, 30 Apr 2010 10:04:59 +0200 X-Google-Sender-Auth: 66891277d03fef40 Message-ID: To: "Jason J. W. Williams" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 08:05:31 -0000 Hi everybody, On Thu, Apr 29, 2010 at 4:31 PM, Jason J. W. Williams wrote: > I've written before that we're considering moving to FreeBSD 8 from > OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs > ZFS implementation for a high reliability environment like a database? > If so, what are your experiences? I'm running MySQL 5.5 (Server version: 5.5.1-m2-log FreeBSD port: mysql-server-5.5.1) on FreeBSD 8.0 with a quite recent kernel (FreeBSD 8.0-STABLE (GENERIC) #0: Tue Feb 23 12:38:58 UTC 2010). I've done some tweaks to ZFS, like limiting ARC size, followed advices like recordsize matching InnoDB page size (i'm using InnoDB on my 4Go database). We have 11% of reads and 89% of writes and we make around 300 queries per second. The thing is it runs well except that once, I had a very big slowdown on MySQL : UPDATE queries were taking 30 seconds (which is actually the timeout in my.cnf) to complete. I can't tell if it was a MySQL problem (as i'm using something which is not release yet i think) or if it's due to ZFS. However, after a restart, everything was back to normal and things are running well. We have a lot of memory, 32 Go (yes, the box is actually oversize for what we're doing right now), and we don't stress the server so much (it has 2x XeonQuand X55xx), and that might be a reason why it runs well (we don't push ZFS and the server to the limits). I hope it's useful for you. If you need anything more, please ask. -- Pierre Massat From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 08:12:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4EA61065A64 for ; Fri, 30 Apr 2010 08:11:59 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFB18FC12 for ; Fri, 30 Apr 2010 08:11:58 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so3547165fge.13 for ; Fri, 30 Apr 2010 01:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=ehZWC7rCvtikDJcflPGMO2OExioEt2dxp1ryvqBrqFM=; b=iDhg+x0bb4kjZSRqGTt6kkCbpaWCg1LGfD/1ef/RxufxSqMXtxlmnyebG1ZM9Ynt/v mPIwY/4F1pqk2BwM6hUdQFgLf7TZ0zgUqoY4BQFBGaaPHW0Lw67ql0MxS2J0ukEj6984 qw08AAgllFghKRJ4SrxiXX9UE4CBbbOf0PcGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=BajbJLStVK5ZZK+jZOQ8ewAF/558O7vH/gF38MNR6JdzPZD8pDk2QqQY6ZEHoKiMWx xsG/50yzChHB66rmQR0iuDxRJ8GS7cvJKWT4RT0uoWZ0z87Uxdp+dPOmZYLcHEfoUweP a0DwewMmi37A7UQXilvPpM1Z4l2UTJNN4aYpw= Received: by 10.103.141.3 with SMTP id t3mr6008129mun.48.1272615111567; Fri, 30 Apr 2010 01:11:51 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE0288.dip0.t-ipconnect.de [87.174.2.136]) by mx.google.com with ESMTPS id w5sm7736145mue.24.2010.04.30.01.11.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Apr 2010 01:11:50 -0700 (PDT) Date: Fri, 30 Apr 2010 10:11:49 +0200 From: Gary Jennejohn To: Willem Jan Withagen Message-ID: <20100430101149.35d50368@ernst.jennejohn.org> In-Reply-To: <4BDA07B4.40506@digiware.nl> References: <4BD8F7FA.2080103@jrv.org> <4BDA07B4.40506@digiware.nl> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Artem Belevich , "James R. Van Artsdalen" Subject: Re: kmem_map too small: 3832475648 total allocated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 08:12:01 -0000 On Fri, 30 Apr 2010 00:27:00 +0200 Willem Jan Withagen wrote: > On 29-4-2010 6:17, Artem Belevich wrote: > > Do you have vm.kmem_size set in /boot/loader.conf? > > > > If not, do set it to about double of your physical RAM size. Defaults > > are way too conservative for use with large amounts of memory and ZFS. > > As per this suggestion I set this value to 2*8G: > vm.kmem_size="17179869184" > > And bfore the kernel boots this value is set in the loader. > Tested it by goinginto the loader and show the value. > > But once booted I still get: > [/boot] wjw@zfs.digiware.nl> sysctl vm.kmem_size > vm.kmem_size: 3718209536 > > So who is resetting this value??? > A number of variables go into calculating vm.kmem_size (see kmeminit() in kern_malloc.c). In the end, the kernel won't allocate more than twice the physical memory size _which it has discovered_. The question is, how much of your physical memory does the kernel actually see? -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 09:36:16 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86CAF106566B for ; Fri, 30 Apr 2010 09:36:16 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id F3DB58FC12 for ; Fri, 30 Apr 2010 09:36:15 +0000 (UTC) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o3U9aBWE030606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 13:36:13 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7mdn-0002fQ-8B; Fri, 30 Apr 2010 13:36:11 +0400 From: Vladimir Grebenschikov To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2010 13:36:10 +0400 Message-ID: <1272620170.9401.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.0.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 09:36:16 -0000 Hi=20 1) now works for me (no panics so far)=20 -----Original Message----- From: Jeff Roberson To: current@freebsd.org Subject: SUJ update Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) Hello, I fixed a few SUJ bugs. If those of you who reported one of the following= =20 bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct=20 boot into single user but there were problems with tunefs that could lead= =20 to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain=20 types of activity. I have only had this reported twice and I am not able= =20 to reproduce no matter how much load I throw at the machine. If you=20 reproduce this please try to get a coredump or minidump. Thanks, Jeff _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 10:43:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE64C106566B for ; Fri, 30 Apr 2010 10:43:56 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1D25B8FC19 for ; Fri, 30 Apr 2010 10:43:55 +0000 (UTC) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o3UAhp6c004670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 14:43:52 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7nhG-0000bF-5y; Fri, 30 Apr 2010 14:43:50 +0400 From: Vladimir Grebenschikov To: Jeff Roberson In-Reply-To: <1272620170.9401.14.camel@localhost> References: <1272620170.9401.14.camel@localhost> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2010 14:43:49 +0400 Message-ID: <1272624229.2142.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.0.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 10:43:56 -0000 Hi Ehh, looks like fresh kernel is not too stable, it holds after some time of activity. DDB may be activated, but even 'call cpu_reset' does nothing here. Looks like it is not related to SUJ, it happens even with SUJ disabled. -----Original Message----- From: Vladimir Grebenschikov Reply-to: vova@fbsd.ru To: Jeff Roberson Cc: current@freebsd.org Subject: Re: SUJ update Date: Fri, 30 Apr 2010 13:36:10 +0400 Hi=20 1) now works for me (no panics so far)=20 -----Original Message----- From: Jeff Roberson To: current@freebsd.org Subject: SUJ update Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) Hello, I fixed a few SUJ bugs. If those of you who reported one of the following= =20 bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct=20 boot into single user but there were problems with tunefs that could lead= =20 to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain=20 types of activity. I have only had this reported twice and I am not able= =20 to reproduce no matter how much load I throw at the machine. If you=20 reproduce this please try to get a coredump or minidump. Thanks, Jeff _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 10:49:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D759106566C for ; Fri, 30 Apr 2010 10:49:46 +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 D6E4A8FC16 for ; Fri, 30 Apr 2010 10:49:45 +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 o3UAnYPT086280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 13:49:34 +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 o3UAnYrP030965; Fri, 30 Apr 2010 13:49:34 +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 o3UAnYUK030964; Fri, 30 Apr 2010 13:49:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Apr 2010 13:49:34 +0300 From: Kostik Belousov To: Vladimir Grebenschikov Message-ID: <20100430104934.GL2391@deviant.kiev.zoral.com.ua> References: <1272620170.9401.14.camel@localhost> <1272624229.2142.8.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9JSHP372f+2dzJ8X" Content-Disposition: inline In-Reply-To: <1272624229.2142.8.camel@localhost> 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=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, 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: Jeff Roberson , current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 10:49:46 -0000 --9JSHP372f+2dzJ8X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 30, 2010 at 02:43:49PM +0400, Vladimir Grebenschikov wrote: > Hi >=20 > Ehh, looks like fresh kernel is not too stable, it holds after some time > of activity. >=20 > DDB may be activated, but even 'call cpu_reset' does nothing here. >=20 > Looks like it is not related to SUJ, it happens even with SUJ disabled. Does reverting r207410 + r207412 help ? >=20 >=20 > -----Original Message----- > From: Vladimir Grebenschikov > Reply-to: vova@fbsd.ru > To: Jeff Roberson > Cc: current@freebsd.org > Subject: Re: SUJ update > Date: Fri, 30 Apr 2010 13:36:10 +0400 >=20 > Hi=20 >=20 > 1) now works for me (no panics so far)=20 >=20 > -----Original Message----- > From: Jeff Roberson > To: current@freebsd.org > Subject: SUJ update > Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) >=20 > Hello, >=20 > I fixed a few SUJ bugs. If those of you who reported one of the followin= g=20 > bugs could re-test I would greatly appreciate it. >=20 > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct= =20 > boot into single user but there were problems with tunefs that could lead= =20 > to the kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. >=20 > I have had some reports of a hang waiting on journal space with certain= =20 > types of activity. I have only had this reported twice and I am not able= =20 > to reproduce no matter how much load I throw at the machine. If you=20 > reproduce this please try to get a coredump or minidump. >=20 > Thanks, > Jeff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Vladimir B. Grebenschikov > vova@fbsd.ru > _______________________________________________ > 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" --9JSHP372f+2dzJ8X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvatb0ACgkQC3+MBN1Mb4gl/ACcCph7krKBkX9P/D7tB+Jtl1eR YhAAoL5sSTK2Zmh7JOvNMMZ1YQu5z8KE =XF3U -----END PGP SIGNATURE----- --9JSHP372f+2dzJ8X-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 12:36:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AECC106564A for ; Fri, 30 Apr 2010 12:36:48 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA468FC0C for ; Fri, 30 Apr 2010 12:36:47 +0000 (UTC) Received: by bwz8 with SMTP id 8so102153bwz.3 for ; Fri, 30 Apr 2010 05:36:38 -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=7PGjXrpwQlFQi/3eyAT/N2nGvvnguPBEql3dDbxC1P4=; b=uK8vkixyeZs+KI2DqGobU/t2fKfCE3QJfYp4Yaf6B+spzNuN55jYQZazIUieA0c6Qs jggQrE/ZYiUz/9vAP+9G1S6fPOW1tF964QfIcOdRhCUWLWwsXMx+NHPKAsq6bgH8emhQ Aj9VKZSrdlaQcIWPYHbZR/MuLkknsT5mi9EJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QK2Wlq2zRHgIlGH7sJ2tpTEoDwiICllYhTZ+piv8x08GLhUd36uqZ+BehbE7YNVw40 n6G2n9DUS+3XwqrK2keC5YqkGTJ9DCJD5TQ7XcRIZn7lhvr50wi7hkLjMqj68SebTiZ6 CDzD9n5c3g5OqiTnsTCKi8XgGS6W7lGj+6ap4= MIME-Version: 1.0 Received: by 10.204.8.205 with SMTP id i13mr7046898bki.109.1272630997423; Fri, 30 Apr 2010 05:36:37 -0700 (PDT) Received: by 10.204.79.3 with HTTP; Fri, 30 Apr 2010 05:36:37 -0700 (PDT) Date: Fri, 30 Apr 2010 16:36:37 +0400 Message-ID: From: pluknet To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 12:36:48 -0000 Hi, what do you think of adding this handler (based on old bz@ patch)? It's quite annoying to see the meaningless messages like "mpt0: Unhandled Event Notify Frame. Event 0x14 (ACK not required)." each 1% change in logical array rebuild progress. --- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c 2010-03-02 15:38:13.000000000 +0300 +++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c 2010-04-21 19:31:00.000000000 +0400 @@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req CAMLOCK_2_MPTLOCK(mpt); break; } + case MPI_EVENT_IR_RESYNC_UPDATE: + { + uint8_t resync = (data0 >> 16) & 0xff; + mpt_prt(mpt, "IR resync update %d completed\n", resync); + break; + } case MPI_EVENT_EVENT_CHANGE: case MPI_EVENT_INTEGRATED_RAID: case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: Another way - just hide such event since mptutil displays rebuild progress. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 13:14:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B554C106566C for ; Fri, 30 Apr 2010 13:14:42 +0000 (UTC) (envelope-from jasonjwwilliams@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 84B5E8FC12 for ; Fri, 30 Apr 2010 13:14:42 +0000 (UTC) Received: by pwi9 with SMTP id 9so106661pwi.13 for ; Fri, 30 Apr 2010 06:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=0344Gq++/RziXzdpnT9DOK/86TI3dyzMRwWPkoFbJMo=; b=TKdh6IwUpLu1Ium3cmbVlyGhy9vnRWU9RCcEml9weX0fU6gZOoKZE0yodbuIvz1A/9 NxoBB5rAvcuek011eoiBtK1Q+oLbO4FsMyLNX9I5CDisEXW2XoK3OcMMxFZoVrbiBpEJ 2BHY04D2fQ7tS/czZ7zyGCHrT+Sagu93rrRx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=rFLeQwP9Wc6NqH7Rao2DYQ/vc9LUq2ZHLZiDs9x3Td0ro2m7/BSoDlI4qLj44qA3P0 /S2IJwjMp+5azGAgd+PsG3w9wS7ydXhi+kdUeXS9fSIux9ds0zqe6IXIGpkXuTqXAopZ FjgQwsnUA/ceYULAbvE+D7XRb/cwRjirhYm/k= Received: by 10.142.149.36 with SMTP id w36mr899812wfd.228.1272633274365; Fri, 30 Apr 2010 06:14:34 -0700 (PDT) Received: from [192.168.100.56] (71-209-52-18.bois.qwest.net [71.209.52.18]) by mx.google.com with ESMTPS id 23sm1865000pzk.10.2010.04.30.06.14.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Apr 2010 06:14:29 -0700 (PDT) References: Message-Id: <80219502-EDAD-4745-A89B-813601D1C15E@gmail.com> From: "Jason J. W. Williams" To: Pierre Massat In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 30 Apr 2010 07:14:26 -0600 Cc: "freebsd-current@freebsd.org" Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 13:14:42 -0000 Hi Pierre, What was the iowait when the update hangs occurred? Also, what was the box's uptime approx when it happened? Have you surpassed that amount of uptime since? Were you able to DTrace MySQL to see what func was hanging? Thank you so much! -J Sent via iPhone Is your e-mail Premiere? On Apr 30, 2010, at 2:04, Pierre Massat wrote: > Hi everybody, > > On Thu, Apr 29, 2010 at 4:31 PM, Jason J. W. Williams > wrote: >> I've written before that we're considering moving to FreeBSD 8 from >> OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs >> ZFS implementation for a high reliability environment like a >> database? >> If so, what are your experiences? > > I'm running MySQL 5.5 (Server version: 5.5.1-m2-log FreeBSD port: > mysql-server-5.5.1) on FreeBSD 8.0 with a quite recent kernel (FreeBSD > 8.0-STABLE (GENERIC) #0: Tue Feb 23 12:38:58 UTC 2010). I've done some > tweaks to ZFS, like limiting ARC size, followed advices like > recordsize matching InnoDB page size (i'm using InnoDB on my 4Go > database). We have 11% of reads and 89% of writes and we make around > 300 queries per second. > > The thing is it runs well except that once, I had a very big slowdown > on MySQL : UPDATE queries were taking 30 seconds (which is actually > the timeout in my.cnf) to complete. I can't tell if it was a MySQL > problem (as i'm using something which is not release yet i think) or > if it's due to ZFS. However, after a restart, everything was back to > normal and things are running well. We have a lot of memory, 32 Go > (yes, the box is actually oversize for what we're doing right now), > and we don't stress the server so much (it has 2x XeonQuand X55xx), > and that might be a reason why it runs well (we don't push ZFS and the > server to the limits). > > I hope it's useful for you. If you need anything more, please ask. > > -- > Pierre Massat From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 14:19:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78B261065672 for ; Fri, 30 Apr 2010 14:19:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 09D688FC28 for ; Fri, 30 Apr 2010 14:19:30 +0000 (UTC) Received: by bwz8 with SMTP id 8so165264bwz.3 for ; Fri, 30 Apr 2010 07:19:23 -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=aTqBGaOxrtEXsv13yso0IcVuBt2CFTJm8YXHgIVt+e8=; b=LenHk7Xpe1+mb5EcAfDDWms9MxdZdE4iJLGLODlV2AGyHQxtUBUy2o+D+r5dwzLLrd FFrj0ql2+GNbK0qK2o0o7nYaqxZVDr3luxM3B85jIwNbcDvXVnayVD4YFJWZdTluRwLM kHQbd6h58eI+vvSqUlg5OtmpXsHlx0R4/L3js= 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=a9HdojvQWrhdUrz/TYDPeisn9v9K2iM1Jfda+S3mDjtpbv94qyhe9+EztdxCZIJrsr yYZAG3td774mGWq8TkgYkJz1cnRjZDGO5XYIbCIU7YOlnqRb+/jelZCNCAjbJXj7upIa 5yGGD+JKsGcam2Ew0yLFy0Y3eGduCSd2pTdLE= MIME-Version: 1.0 Received: by 10.204.5.87 with SMTP id 23mr7083272bku.206.1272637163606; Fri, 30 Apr 2010 07:19:23 -0700 (PDT) Received: by 10.204.79.3 with HTTP; Fri, 30 Apr 2010 07:19:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Apr 2010 18:19:23 +0400 Message-ID: From: pluknet To: Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 14:19:31 -0000 On 30 April 2010 08:37, Jeff Roberson wrote: > Hello, > > I fixed a few SUJ bugs. =A0If those of you who reported one of the follow= ing > bugs could re-test I would greatly appreciate it. > > 1) =A0panic on gnome start via softdep_cancel_link(). > 2) =A0Difficulty setting flags on /. =A0This can only be done from a dire= ct boot > into single user but there were problems with tunefs that could lead to t= he > kernel and disk becoming out of sync with filesystem state. > 3) =A0Kernel compiles without SOFTUPDATES defined in the config now work. Just finished make universe. Everything is fine (c). Thanks. > > I have had some reports of a hang waiting on journal space with certain > types of activity. =A0I have only had this reported twice and I am not ab= le to > reproduce no matter how much load I throw at the machine. =A0If you repro= duce > this please try to get a coredump or minidump. > > Thanks, > Jeff --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 14:22:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E33D106564A for ; Fri, 30 Apr 2010 14:22:56 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3D81A8FC08 for ; Fri, 30 Apr 2010 14:22:56 +0000 (UTC) Received: from [172.16.135.100] (lportal.in1.lcl [172.16.1.9]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o3UEMtS2060950; Fri, 30 Apr 2010 07:22:55 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BDAE7BD.4000503@feral.com> Date: Fri, 30 Apr 2010 07:22:53 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pluknet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Fri, 30 Apr 2010 07:22:55 -0700 (PDT) Cc: FreeBSD Current Subject: Re: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 14:22:56 -0000 pluknet wrote: Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll put it in > --- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c 2010-03-02 > 15:38:13.000000000 +0300 > +++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c 2010-04-21 > 19:31:00.000000000 +0400 > @@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req > CAMLOCK_2_MPTLOCK(mpt); > break; > } > + case MPI_EVENT_IR_RESYNC_UPDATE: > + { > + uint8_t resync = (data0 >> 16) & 0xff; > + mpt_prt(mpt, "IR resync update %d completed\n", resync); > + break; > + } > case MPI_EVENT_EVENT_CHANGE: > case MPI_EVENT_INTEGRATED_RAID: > case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: > > Another way - just hide such event since mptutil displays rebuild progress. > > From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 14:28:48 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA662106566B for ; Fri, 30 Apr 2010 14:28:48 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id EEDE08FC1D for ; Fri, 30 Apr 2010 14:28:47 +0000 (UTC) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o3UEShYU004321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 18:28:44 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7rCs-0000mU-Ms; Fri, 30 Apr 2010 18:28:42 +0400 From: Vladimir Grebenschikov To: Kostik Belousov In-Reply-To: <20100430104934.GL2391@deviant.kiev.zoral.com.ua> References: <1272620170.9401.14.camel@localhost> <1272624229.2142.8.camel@localhost> <20100430104934.GL2391@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Apr 2010 18:28:42 +0400 Message-ID: <1272637722.2233.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.0.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Jeff Roberson , current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 14:28:48 -0000 Hi=20 1h - flight ok -----Original Message----- From: Kostik Belousov To: Vladimir Grebenschikov Cc: Jeff Roberson , current@freebsd.org Subject: Re: SUJ update Date: Fri, 30 Apr 2010 13:49:34 +0300 On Fri, Apr 30, 2010 at 02:43:49PM +0400, Vladimir Grebenschikov wrote: > Hi >=20 > Ehh, looks like fresh kernel is not too stable, it holds after some time > of activity. >=20 > DDB may be activated, but even 'call cpu_reset' does nothing here. >=20 > Looks like it is not related to SUJ, it happens even with SUJ disabled. Does reverting r207410 + r207412 help ? >=20 >=20 > -----Original Message----- > From: Vladimir Grebenschikov > Reply-to: vova@fbsd.ru > To: Jeff Roberson > Cc: current@freebsd.org > Subject: Re: SUJ update > Date: Fri, 30 Apr 2010 13:36:10 +0400 >=20 > Hi=20 >=20 > 1) now works for me (no panics so far)=20 >=20 > -----Original Message----- > From: Jeff Roberson > To: current@freebsd.org > Subject: SUJ update > Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) >=20 > Hello, >=20 > I fixed a few SUJ bugs. If those of you who reported one of the followin= g=20 > bugs could re-test I would greatly appreciate it. >=20 > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct= =20 > boot into single user but there were problems with tunefs that could lead= =20 > to the kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. >=20 > I have had some reports of a hang waiting on journal space with certain= =20 > types of activity. I have only had this reported twice and I am not able= =20 > to reproduce no matter how much load I throw at the machine. If you=20 > reproduce this please try to get a coredump or minidump. >=20 > Thanks, > Jeff > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >=20 >=20 > --=20 > Vladimir B. Grebenschikov > vova@fbsd.ru > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 14:48:35 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D697106564A for ; Fri, 30 Apr 2010 14:48:35 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (fbx.keltia.net [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id DB4C88FC13 for ; Fri, 30 Apr 2010 14:48:34 +0000 (UTC) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 6DDFC7E0F for ; Fri, 30 Apr 2010 16:33:21 +0200 (CEST) Date: Fri, 30 Apr 2010 16:33:16 +0200 From: Ollivier Robert To: FreeBSD Current Users' list Message-ID: <20100430143316.GA475@roberto-al.eurocontrol.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (keltia.net); Fri, 30 Apr 2010 16:33:21 +0200 (CEST) Cc: Subject: rsync locks for very long periods (indefinitely?) when using suj over raid5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 14:48:35 -0000 9.0-CURRENT as of two hours ago (with latest SUJ fixes then) running on a bi-Xeon @2.8 GHz (5 year old) w/ HT, 32-bit mode (no LM). 4 GB, no PAE 4 72 GB disks in a raid5 with gvinum, block size: 128 KB UFS2 + SUJ, mounted async. 420 [15:40] root@vcs:/data# gvinum list 4 drives: D gvinumdrive0 State: up /dev/da2 A: 6/69459 MB (0%) D gvinumdrive3 State: up /dev/da5 A: 6/69459 MB (0%) D gvinumdrive2 State: up /dev/da4 A: 6/69459 MB (0%) D gvinumdrive1 State: up /dev/da3 A: 0/69452 MB (0%) 1 volume: V data0 State: up Plexes: 1 Size: 203 GB 1 plex: P data0.p0 R5 State: up Subdisks: 4 Size: 203 GB 4 subdisks: S data0.p0.s3 State: up D: gvinumdrive3 Size: 67 GB S data0.p0.s2 State: up D: gvinumdrive2 Size: 67 GB S data0.p0.s1 State: up D: gvinumdrive1 Size: 67 GB S data0.p0.s0 State: up D: gvinumdrive0 Size: 67 GB rsync from / (plain UFS2) to /data (UFS2+SUJ over raid5) locks in a matter of seconds. Stay in "getblk" state. ps / show pcpu / show alllocks / show threads / show lockedvnods http://sparc64.pastebin.com/NBNQJJXs bt on rsync http://sparc64.pastebin.com/cCZx0FU7 Kernel compiled with INVARIANTS INVARIANT_SUPPORT WITNESS WITNESS_SKIPSPIN Anything else? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 14:50:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EA3E106567E; Fri, 30 Apr 2010 14:50:36 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id E4BB58FC2A; Fri, 30 Apr 2010 14:50:35 +0000 (UTC) Received: by bwz8 with SMTP id 8so188844bwz.3 for ; Fri, 30 Apr 2010 07:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OMLN8EXpO7o5R+dLLld1mQ1KxLyIDhy0WMrwfmMTb78=; b=CQ5NLeKvoKwDm9vsYY3Jo7Tfsg69qszE+rzN1Tn0Fa9oGEVLiV03wHQXsU3TT2wzG9 6zNQ4HKd5t3ekE8IacP31WhdxdIa441asdr8OkILVDjjW3fXdf7VtW86Og90swtUGOkR AHSVl8PUGZflfqu6vKB9kSHM9jRmdu9K7W+1I= 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=BjFDvQ9yjqvZd13y0pW36OOTVu9vj2S11OcrPcnSIwBxG1X/NeylbYoP2Nk0fu+qle xJBr34qabFjCtcrGXdm6mtMNNXXxUB1omUnQ3Y+f7pJNRGYrlzN1MCK/zWBsy+zoF41Y E+/f1f1T8mB84knKNum/bR4QqlfNIxVKVbMMM= MIME-Version: 1.0 Received: by 10.204.7.201 with SMTP id e9mr104429bke.122.1272639027080; Fri, 30 Apr 2010 07:50:27 -0700 (PDT) Received: by 10.204.79.3 with HTTP; Fri, 30 Apr 2010 07:50:26 -0700 (PDT) In-Reply-To: <4BDAE7BD.4000503@feral.com> References: <4BDAE7BD.4000503@feral.com> Date: Fri, 30 Apr 2010 18:50:26 +0400 Message-ID: From: pluknet To: Matthew Jacob Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi , FreeBSD Current Subject: Re: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 14:50:36 -0000 On 30 April 2010 18:22, Matthew Jacob wrote: > pluknet wrote: > Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll = put > it in Err.. I thought that list is dedicated for cam related stuff. [cc'ing scsi@ for better coverage. Sorry for cross-posting :/ ] > >> --- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c =A0 =A0 =A0 =A02010-03-02 >> 15:38:13.000000000 +0300 >> +++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c =A0 2010-04-21 >> 19:31:00.000000000 +0400 >> @@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CAMLOCK_2_MPTLOCK(mpt); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >> =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 case MPI_EVENT_IR_RESYNC_UPDATE: >> + =A0 =A0 =A0 { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint8_t resync =3D (data0 >> 16) & 0xff; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpt_prt(mpt, "IR resync update %d complete= d\n", resync); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; >> + =A0 =A0 =A0 } >> =A0 =A0 =A0 =A0case MPI_EVENT_EVENT_CHANGE: >> =A0 =A0 =A0 =A0case MPI_EVENT_INTEGRATED_RAID: >> =A0 =A0 =A0 =A0case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: >> >> Another way - just hide such event since mptutil displays rebuild >> progress. >> >> --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 15:28:46 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9375E106566B for ; Fri, 30 Apr 2010 15:28:46 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB8E8FC20 for ; Fri, 30 Apr 2010 15:28:46 +0000 (UTC) Received: by pzk39 with SMTP id 39so196986pzk.7 for ; Fri, 30 Apr 2010 08:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GQGhFMtbqiKkywMipZDu42ad30LhAeHyJgkH/DqdkT4=; b=xDd9Rfm3Cy6fM7ZFgn6u8H+nBAsPzFER9Z9P8txxBUp1DoN5pJbVKSgVEkvBRWjBxt Y6zyYqQSDMDAQWPqJfwsmqQ+cbeKCrgKgpuc68FdM+zJzhjMIeFCCnK8gsELfrVBuVEg jDtsigb7REnrUrj30LXF0kL4w4WDSrCSeL3jw= 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=AUqVMy5uB9tKTUTsfFMMBw6o5mce4W+tnOz3xvK55FafYnbcsXxcHT8Go7PvNf20To jx2LXY4jqBo687/QJAxRnqrfCcyH0SWoQ7md/tNXpYW2gpFsAk/h0+L7R9ascG2OK5lQ uPAM2VsgpLwctziF2yhTu2jfy4SP9IauvCOF0= MIME-Version: 1.0 Received: by 10.142.247.21 with SMTP id u21mr6684335wfh.115.1272641323204; Fri, 30 Apr 2010 08:28:43 -0700 (PDT) Received: by 10.142.70.5 with HTTP; Fri, 30 Apr 2010 08:28:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Apr 2010 23:28:43 +0800 Message-ID: From: Buganini To: Jeff Roberson Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 15:28:46 -0000 just a little request # tunefs usage: tunefs [-A] [-a enable | disable] [-e maxbpg] [-f avgfilesize] [-J enable | disable ] [-L volname] [-l enable | disable] [-m minfree] [-N enable | disable] [-n enable | disable] [-o space | time] [-p] [-s avgfpdir] special | filesystem -j is not showing --Buganini From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 16:20:26 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED8E61065679 for ; Fri, 30 Apr 2010 16:20:26 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id AF6148FC13 for ; Fri, 30 Apr 2010 16:20:25 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o3UGKBjg037171 for ; Fri, 30 Apr 2010 09:20:11 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o3UGJr5a037167 for current@freebsd.org; Fri, 30 Apr 2010 09:19:53 -0700 (PDT) (envelope-from david) Date: Fri, 30 Apr 2010 09:19:53 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20100430161953.GW96847@bunrab.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="cwgtkLz7OrNqz/qA" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 16:20:27 -0000 --cwgtkLz7OrNqz/qA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This was during the single- to multi-user transition on boot; I was going to skip the output from the LORs, but I suspect that some of them might be relevant; see below. I can leave the system in this state for a whle, but I normally power it off (to reduce heat, noise, and electricity consumption in a room my spouse uses). Please note that this is using a GENERIC kernel. Here's a cut/paste from the serial console: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 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 #144 r207433: Fri Apr 30 07:13:53 PDT 2010 root@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3614.55-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 Stepp= ing =3D 1 Features=3D0xbfebfbff Features2=3D0x659d AMD Features=3D0x20100000 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2086129664 (1989 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard =2E.. aacd0: on aac0 aacd0: 34970MB (71619584 sectors) aacd1: on aac0 aacd1: 69974MB (143307008 sectors) uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ses0 at aacp0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Uninstalled SCSI-2 device=20 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device pass0 at aacp0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Uninstalled SCSI-3 device=20 pass0: 3.300MB/s transfers pass1 at aacp0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Uninstalled SCSI-3 device=20 pass1: 3.300MB/s transfers pass2 at aacp0 bus 0 scbus0 target 2 lun 0 pass2: Fixed Uninstalled SCSI-3 device=20 pass2: 3.300MB/s transfers pass3 at aacp0 bus 0 scbus0 target 3 lun 0 pass3: Fixed Uninstalled SCSI-3 device=20 pass3: 3.300MB/s transfers SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/aacd0s4a Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a. Setting hostid: 0xc74551dd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/aacd0s4a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4a: clean, 499913 free (1473 frags, 62305 blocks, 0.2% fragmenta= tion) /dev/aacd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1a: clean, 424969 free (1913 frags, 52882 blocks, 0.3% fragmenta= tion) /dev/aacd1s1e: clean, 4818032 free (263136 frags, 569362 blocks, 2.0% fragm= entation) /dev/aacd0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s1d: clean, 1031838 free (4190 frags, 128456 blocks, 0.2% fragmen= tation) /dev/aWARNING: TMPFS is considered to be a highly experimental feature in F= reeBSD. acd1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd1s1d: clean, 11736234 free (197738 frags, 1442312 blocks, 1.2% fra= gmentation) /dev/aacd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2a: clean, 596278 free (1118 frags, 74395 blocks, 0.2% fragmenta= tion) /dev/aacd0s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s2d: clean, 1109224 free (22320 frags, 135863 blocks, 1.2% fragme= ntation) /dev/aacd0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3a: clean, 578047 free (1031 frags, 72127 blocks, 0.1% fragmenta= tion) /dev/aacd0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s3d: clean, 1071557 free (38805 frags, 129094 blocks, 2.2% fragme= ntation) /dev/aacd0s4d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4d: clean, 1078573 free (59909 frags, 127333 blocks, 3.3% fragme= ntation) /dev/aacd0s4f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/aacd0s4f: clean, 2106253 free (349 frags, 263238 blocks, 0.0% fragment= ation) Mounting local file systems:. Setting hostname: freebeast.catwhisker.org. lock order reversal: 1st 0xc64c85a8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502 2nd 0xd94ff1a0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11362 3rd 0xc64e69e8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2091 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebdd2300,c08e8615,c08d898b,c0cc700a,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08d898b,c0cc700a,c553d030,c5540568,ebdd235c,...) at kdb_back= trace+0x29 _witness_debugger(c0cc700a,c64e69e8,c0cb932f,c5540568,c0cce101,...) at _wit= ness_debugger+0x25 witness_checkorder(c64e69e8,9,c0cce101,82b,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c64e69e8,80100,c64e6a08,0,0,...) at __lockmgr_args+0x7f9 ffs_lock(ebdd2480,c08e83bb,c0ccd5a6,80100,c64e6990,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0dd1b20,ebdd2480,c5eee764,c0dec560,c64e6990,...) at VOP_LOCK= 1_APV+0xb5 _vn_lock(c64e6990,80100,c0cce101,82b,4,...) at _vn_lock+0x5e vget(c64e6990,80100,c5eee6c0,50,0,...) at vget+0xb9 vfs_hash_get(c64bf798,78c12,80000,c5eee6c0,ebdd25d0,...) at vfs_hash_get+0x= e6 ffs_vgetf(c64bf798,78c12,80000,ebdd25d0,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c64c8550,0,c0cea2f8,147,0,...) at softdep_sync_metada= ta+0xc92 ffs_syncvnode(c64c8550,1,c5eee6c0,ebdd2690,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c64c8550,200,0,880,c5585380,...) at ffs_truncate+0x862 ufs_direnter(c64c8550,c64e6990,ebdd2944,ebdd2bd4,0,...) at ufs_direnter+0x8= d4 ufs_makeinode(ebdd2bd4,0,ebdd2b30,ebdd2a8c,c0c002d5,...) at ufs_makeinode+0= x557 ufs_create(ebdd2b30,ebdd2b48,0,0,ebdd2ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0dd1b20,ebdd2b30,ebdd2bd4,ebdd2ac8,0,...) at VOP_CREATE_APV= +0xa5 vn_open_cred(ebdd2ba8,ebdd2c5c,1a4,0,c5585380,...) at vn_open_cred+0x215 vn_open(ebdd2ba8,ebdd2c5c,1a4,c5f54038,0,...) at vn_open+0x3b kern_openat(c5eee6c0,ffffff9c,804c5e8,0,602,...) at kern_openat+0x125 kern_open(c5eee6c0,804c5e8,0,601,21b6,...) at kern_open+0x35 open(c5eee6c0,ebdd2cf8,c0cfcac4,c0ca746c,c5f692a8,...) at open+0x30 syscall(ebdd2d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x281743c3, esp =3D 0xbfbfec4= c, ebp =3D 0xbfbfecb8 --- Starting Network: lo0 em0 em1. 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%lo0 prefixlen 64 scopeid 0x3=20 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6a inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255 inet6 fe80::230:48ff:fe2d:326a%em0 prefixlen 64 tentative scopeid 0= x1=20 nd6 options=3D29 media: Ethernet autoselect status: no carrier em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier Starting devd. Starting Network: em1. em1: flags=3D8802 metric 0 mtu 1500 options=3D389b ether 00:30:48:2d:32:6b media: Ethernet autoselect status: no carrier add net default: gateway 172.16.8.1 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 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/compat a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Starting rpcbind. NFS access cache time=3D60 Setting NIS domain: lmdhw.com. Startlock order reversal: ing ypbind. Sta 1st 0xc5f89990 vm object (standard object) @ /usr/src/sys/vm/vm_fault.c= :1280 rting amd. 2nd 0xc0f9b180 page lock (page lock) @ /usr/src/sys/vm/vm_fault.c:1299 3rd 0xc668cbb0 vm object (standard object) @ /usr/src/sys/vm/vm_fault.c:12= 49 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bad0,c08e8615,c08d898b,c0cc700a,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08d898b,c0cc700a,c553a2b0,c553d648,ebe0bb2c,...) at kdb_back= trace+0x29 _witness_debugger(c0cc700a,c668cbb0,c0cc720f,c553d648,c0cec528,...) at _wit= ness_debugger+0x25 witness_checkorder(c668cbb0,9,c0cec528,4e1,0,...) at witness_checkorder+0x8= 39 _mtx_lock_flags(c668cbb0,0,c0cec528,4e1,5,...) at _mtx_lock_flags+0xc4 vm_fault_copy_entry(c64f34b0,c5586c30,c5faae58,c5faaca8,ebe0bc48,...) at vm= _fault_copy_entry+0x228 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 75 (0xc0f9b180) locked @ = /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5faae58,c5faaca8,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 75 (0xc0f9b180) locked @ = /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,1,0,517,5,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5faa1f8,c5f5fc18,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 77 (0xc0f9b180) locked @ = /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5faa1f8,c5f5fc18,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 77 (0xc0f9b180) locked @ = /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,391,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5f5f7e0,c5f50480,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 333 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5f5f7e0,c5f50480,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 333 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,30,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c15a93a8,c5f50b88,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 429 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c15a93a8,c5f50b88,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 429 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,2,0,517,5,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5faaa68,c5f50ca8,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 433 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5faaa68,c5f50ca8,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 433 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,13,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5f50cf0,c5faa360,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 471 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5f50cf0,c5faa360,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 471 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,7,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c15a9558,c5faa0d8,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 485 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c15a9558,c5faa0d8,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 485 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,1,0,517,5,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5fba8b8,c5f50900,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 487 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5fba8b8,c5f50900,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 487 (0xc0f9ae00) locked @= /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,103,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5fba2d0,c5f5fdc8,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 1005 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5fba2d0,c5f5fdc8,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 1005 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,6,0,517,5,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5f50630,c5faa9d8,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 1017 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5f50630,c5faa9d8,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 1017 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,17,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5f5f678,c5faae10,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 1063 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5f5f678,c5faae10,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 1063 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,400,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c5f5fe10,c65b5090,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "MAP ENTRY" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 2047 (0xc0f9a780) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1063 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb14,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb4c,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb60,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0cecea9,c0cec528,...) at witness_warn+0x1fd uma_zalloc_arg(c15b7700,0,2,ebe0bc00,c0b1250a,...) at uma_zalloc_arg+0x34 vm_map_entry_create(c64f34b0,c5586c30,c5f5fe10,c65b5090,ebe0bc48,...) at vm= _map_entry_create+0x4d vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x2ba fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "VM OBJECT" with the following non-sleepable locks hel= d: exclusive sleep mutex page lock (page lock) r =3D 2047 (0xc0f9a780) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1063 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0baa4,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0badc,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0baf0,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0ced87f,c553a790,...) at witness_warn+0x1fd uma_zalloc_arg(c15b8a80,0,2,c15b7778,ebe0bc48,...) at uma_zalloc_arg+0x34 vm_object_allocate(0,20,0,517,3,...) at vm_object_allocate+0x2d vm_fault_copy_entry(c64f34b0,c5586c30,c65b5750,c5f50510,ebe0bc48,...) at vm= _fault_copy_entry+0x62 vmspace_fork(c5586c30,ebe0bc48,2,0,0,...) at vmspace_fork+0x57b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x27b fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- lock order reversal: 1st 0xc0f9a780 page lock (page lock) @ /usr/src/sys/vm/vm_fault.c:1299 2nd 0xc5f8d330 process lock (process lock) @ /usr/src/sys/vm/swap_pager.c:= 208 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb40,c08e8615,c08d898b,c0cc6ff1,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08d898b,c0cc6ff1,c553a2b0,c5539340,ebe0bb9c,...) at kdb_back= trace+0x29 _witness_debugger(c0cc6ff1,c5f8d330,c0cbf526,c5539340,c0ceb66c,...) at _wit= ness_debugger+0x25 witness_checkorder(c5f8d330,9,c0ceb66c,d0,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c5f8d330,0,c0ceb66c,d0,c5586c30,...) at _mtx_lock_flags+0xc4 swap_reserve_by_uid(945000,0,c5567400,ebe0bc60,c0878318,...) at swap_reserv= e_by_uid+0x12e swap_reserve(945000,0,2,0,0,...) at swap_reserve+0x2b fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x298 fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- lock order reversal: (sleepable after non-sleepable) 1st 0xc0f9a780 page lock (page lock) @ /usr/src/sys/vm/vm_fault.c:1299 2nd 0xc0e214f0 proctree (proctree) @ /usr/src/sys/kern/kern_fork.c:329 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb7c,c08e8615,c08d898b,c0cc6ff1,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08d898b,c0cc6ff1,c553a2b0,c5539068,ebe0bbd8,...) at kdb_back= trace+0x29 _witness_debugger(c0cc6ff1,c0e214f0,c0cbfd3f,c5539068,c0cbbe2a,...) at _wit= ness_debugger+0x25 witness_checkorder(c0e214f0,1,c0cbbe2a,149,0,...) at witness_checkorder+0x8= 39 _sx_slock(c0e214f0,0,c0cbbe2a,149,0,...) at _sx_slock+0x85 fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x320 fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "4096" with the following non-sleepable locks held: exclusive sleep mutex page lock (page lock) r =3D 2047 (0xc0f9a780) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1127 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb30,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb68,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb7c,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0c5929c,c0cbbe2a,...) at witness_warn+0x1fd uma_zalloc_arg(c15b0700,0,102,2,37d,...) at uma_zalloc_arg+0x34 malloc(abc,c0db7000,102,1869f,37d,...) at malloc+0xe4 sigacts_alloc(c5f8d880,0,c0cbbe2a,1de,0,...) at sigacts_alloc+0x23 fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x858 fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- uma_zalloc_arg: zone "256" with the following non-sleepable locks held: exclusive sleep mutex page lock (page lock) r =3D 2047 (0xc0f9a780) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1127 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb00,c08e8615,c0cec528,513,...) at db_tr= ace_self_wrapper+0x26 kdb_backtrace(c0cec528,513,ffffffff,c0f61214,ebe0bb38,...) at kdb_backtrace= +0x29 _witness_debugger(c0cc659d,ebe0bb4c,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0cec231,c0c56d98,109,...) at witness_warn+0x1fd uma_zalloc_arg(c15b1700,0,102,2,37d,...) at uma_zalloc_arg+0x34 malloc(b8,c0db2b84,102,c08923ea,37d,...) at malloc+0xe4 fdinit(c65aa200,ebe0bc00,c08a2e55,c6675aa8,c0cc0bde,...) at fdinit+0x28 fdcopy(c65aa200,0,c0cbbe2a,1de,0,...) at fdcopy+0x21 fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x893 fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- lock order reversal: (sleepable after non-sleepable) 1st 0xc0f9a780 page lock (page lock) @ /usr/src/sys/vm/vm_fault.c:1299 2nd 0xc65aa22c filedesc structure (filedesc structure) @ /usr/src/sys/kern= /kern_descrip.c:1580 KDB: stack backtrace: db_trace_self_wrapper(c0cc4017,ebe0bb30,c08e8615,c08d898b,c0cc6ff1,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c08d898b,c0cc6ff1,c553a2b0,c553d308,ebe0bb8c,...) at kdb_back= trace+0x29 _witness_debugger(c0cc6ff1,c65aa22c,c0cbb557,c553d308,c0cbb30f,...) at _wit= ness_debugger+0x25 witness_checkorder(c65aa22c,9,c0cbb30f,62c,0,...) at witness_checkorder+0x8= 39 _sx_xlock(c65aa22c,0,c0cbb30f,62c,37d,...) at _sx_xlock+0x85 fdinit(c65aa200,ebe0bc00,c08a2e55,c6675aa8,c0cc0bde,...) at fdinit+0x6c fdcopy(c65aa200,0,c0cbbe2a,1de,0,...) at fdcopy+0x21 fork1(c5f92000,14,0,ebe0bc78,c5f92000,...) at fork1+0x893 fork(c5f92000,ebe0bcf8,c0cfcac4,c0cc7889,c5f8d2a8,...) at fork+0x29 syscall(ebe0bd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (2, FreeBSD ELF32, fork), eip =3D 0x2811d37b, esp =3D 0xbfbfe9c= c, ebp =3D 0xbfbfe9d8 --- System call fork returning with the following locks held: exclusive sleep mutex page lock (page lock) r =3D 2047 (0xc0f9a780) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1127 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 panic: witness_warn cpuid =3D 1 KDB: enter: panic [ thread pid 892 tid 100089 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 892 tid 100089 td 0xc5f92000 kdb_enter(c0cc0b06,c0cc0b06,c0c68e9c,ebe0bc54,1,...) at kdb_enter+0x3a panic(c0c68e9c,c0c434fd,0,0,0,...) at panic+0x136 witness_warn(2,0,c0cfcac4,c0cbbefd,c5f8d2a8,...) at witness_warn+0x1e9 syscall(ebe0bd38) at syscall+0x2d8 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (893), eip =3D 0x2811d37b, esp =3D 0xbfbfe9cc, ebp =3D 0xbfbfe9= d8 --- db> show locks exclusive sleep mutex page lock (page lock) r =3D 2047 (0xc0f9a780) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1127 (0xc0f9ae00) locked = @ /usr/src/sys/vm/vm_fault.c:1299 exclusive sleep mutex page lock (page lock) r =3D 1569 (0xc0f9b180) locked = @ /usr/src/sys/vm/vm_fault.c:1299 db>=20 Please let me know if additional information might be useful. I should be able to try various experiments & patches. As I type, I'm still building the kernel for CURRENT as of r207433 on my laptop; I should be able to report whether or not it exhibits similar behavior. 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. --cwgtkLz7OrNqz/qA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvbAygACgkQmprOCmdXAD3JtwCggXy8jPmMILiZ6n4GkYwz4ndE T4gAn2stbeP/dbgHORLPAGCRPygrlT9i =y0nR -----END PGP SIGNATURE----- --cwgtkLz7OrNqz/qA-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 16:27:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 276181065670 for ; Fri, 30 Apr 2010 16:27:43 +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 967B38FC16 for ; Fri, 30 Apr 2010 16:27:42 +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 o3UGRWtj013547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 19:27:32 +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 o3UGRWMZ044738; Fri, 30 Apr 2010 19:27:32 +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 o3UGRWLW044737; Fri, 30 Apr 2010 19:27:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Apr 2010 19:27:32 +0300 From: Kostik Belousov To: David Wolfskill , current@freebsd.org Message-ID: <20100430162732.GP2391@deviant.kiev.zoral.com.ua> References: <20100430161953.GW96847@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qSHHer9gQ0dtepKr" Content-Disposition: inline In-Reply-To: <20100430161953.GW96847@bunrab.catwhisker.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=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 16:27:43 -0000 --qSHHer9gQ0dtepKr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 30, 2010 at 09:19:53AM -0700, David Wolfskill wrote: > This was during the single- to multi-user transition on boot; I was > going to skip the output from the LORs, but I suspect that some of > them might be relevant; see below. >=20 > I can leave the system in this state for a whle, but I normally power it > off (to reduce heat, noise, and electricity consumption in a room my > spouse uses). >=20 > Please note that this is using a GENERIC kernel. Please try r207438. --qSHHer9gQ0dtepKr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvbBPQACgkQC3+MBN1Mb4g+UgCfaxm/2erKKJx3cvXoA/EgA0+E KsMAoMQhKJAMfvgYf579/ogxk3ac7JiO =nU2i -----END PGP SIGNATURE----- --qSHHer9gQ0dtepKr-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 17:06:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C082106566C for ; Fri, 30 Apr 2010 17:06:06 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6238FC16 for ; Fri, 30 Apr 2010 17:06:05 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o3UH5qsZ037600; Fri, 30 Apr 2010 10:05:52 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o3UH5p0R037599; Fri, 30 Apr 2010 10:05:51 -0700 (PDT) (envelope-from david) Date: Fri, 30 Apr 2010 10:05:51 -0700 From: David Wolfskill To: Kostik Belousov Message-ID: <20100430170551.GA96847@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Kostik Belousov , current@freebsd.org References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vAlDtAs5WEb1aNYe" Content-Disposition: inline In-Reply-To: <20100430162732.GP2391@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 17:06:06 -0000 --vAlDtAs5WEb1aNYe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 30, 2010 at 07:27:32PM +0300, Kostik Belousov wrote: > ... > Please try r207438. OK; that worked -- thanks! I actually merely hand-edited the one file & rebuilt the kernel; boot to multi-user mode was uneventful, and: FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #145 r2074= 33M: Fri Apr 30 09:54:26 PDT 2010 root@freebeast.catwhisker.org:/usr/ob= j/usr/src/sys/GENERIC i386 I also completed the CURRENT build on my laptop, and despite what happened with the build machine, I tried booting r207433 ... and it came up just fine. Biggest salient difference that occurs to me is that the laptop is a single core, while the build machine is a pair of CPUs (with a single core each): FreeBSD d254.dwolf.juniper.net. 9.0-CURRENT FreeBSD 9.0-CURRENT #144 r20743= 3: Fri Apr 30 09:06:04 PDT 2010 root@g1-190.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 Thanks again for the timely fix! 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. --vAlDtAs5WEb1aNYe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvbDe4ACgkQmprOCmdXAD27iACeMEnbJSzx7V3Lma9yoSHmIkQl FmYAn29qsXFyrT54XP6zwY2UOKTamSzU =zCPV -----END PGP SIGNATURE----- --vAlDtAs5WEb1aNYe-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 18:10:32 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D1F81065679 for ; Fri, 30 Apr 2010 18:10:32 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2FC8FC1A for ; Fri, 30 Apr 2010 18:10:30 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 245E76107; Fri, 30 Apr 2010 13:50:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1272649842; bh=2ISyWF6a0Ki9qpASnqLPdGtP5oyrXULkZ54xbFOYIp8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=h8EYiiWbRb+myDft3YdMmOfzfS8ohV0l7fnotuq8EMtMJYg5qCMzlUVQ4C6/Cwyxb UmU23AWHBSSb3iOETudBxmyXXIrbDdp1SOjzki6XzGJmRYlOXtwNmjs7dLymlRw DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type; b=aDmPXzVjfwmsyXMVEB3m9MeygqPUGUiCkwkxKjjkBwwUQbHkk0WHCvEyNLuVmtqsu +Tk7Ujq6e9S3uAOaKJ/cFM7BwAo5jYqyo5tEs+GPflw81uoYAMqqElbo32NyOQX Message-ID: <4BDB186E.4070309@protected-networks.net> Date: Fri, 30 Apr 2010 13:50:38 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100422 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kostik Belousov References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> In-Reply-To: <20100430162732.GP2391@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------000402090607000902040502" Cc: current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 18:10:32 -0000 This is a multi-part message in MIME format. --------------000402090607000902040502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/30/10 12:27, Kostik Belousov wrote: > On Fri, Apr 30, 2010 at 09:19:53AM -0700, David Wolfskill wrote: >> This was during the single- to multi-user transition on boot; I was >> going to skip the output from the LORs, but I suspect that some of >> them might be relevant; see below. >> >> I can leave the system in this state for a whle, but I normally power it >> off (to reduce heat, noise, and electricity consumption in a room my >> spouse uses). >> >> Please note that this is using a GENERIC kernel. > > Please try r207438. Sadly, it doesn't do it for me .. lockd start-up causes a panic on a "sleeping thread". Do I need to do a buildworld as well as kernel? imb --------------000402090607000902040502 Content-Type: text/plain; name="core.txt.0" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="core.txt.0" toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 Fri Apr 30 13:31:47 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r207439M: Fri Apr 30 13:12:37 EDT 2010 root@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: sleeping thread GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Sleeping thread (tid 100093, pid 1247) owns a non-sleepable lock sched_switch(c6bce480,0,104,eccc5318,12,...) at sched_switch+0xb1 mi_switch(104,0) at mi_switch+0xd6 sleepq_switch(c6bce480,0,c0a42263,260,0,...) at sleepq_switch+0xab sleepq_wait(da11f1e8,4c,c0a454b0,0,0,...) at sleepq_wait+0x3f _sleep(da11f1e8,c616b254,4c,c0a454b0,0,...) at _sleep+0x32a bwait(da11f1e8,4c,c0a454b0,da11f1e8,e8d6c744,...) at bwait+0x66 bufwait(da11f1e8,da11f1e8,da11f1e8,100,0,...) at bufwait+0x28 bufwrite(da11f1e8,0,e8d6c8c0,100,c619f380,...) at bufwrite+0x134 ffs_write(e8d6c8e0,c09afb7e,c396c520,0,0,...) at ffs_write+0x495 VOP_WRITE_APV(c0aeed00,e8d6c8e0,0,0,0,...) at VOP_WRITE_APV+0x96 vnode_pager_generic_putpages(c6dcf330,e8d6c9f0,1000,0,e8d6c990,...) at vnode_pager_generic_putpages+0x16c vop_stdputpages(e8d6c948,e8d6c948,28484000,0,2,...) at vop_stdputpages+0x30 vnode_pager_putpages(c6d86088,e8d6c9f0,1000,5,e8d6c990,...) at vnode_pager_putpages+0x92 vm_pageout_flush(e8d6c9f0,1,5,e8d6ca00,c06c1444,...) at vm_pageout_flush+0x1c0 vm_object_page_collect_flush(5,0,0,0,0,...) at vm_object_page_collect_flush+0x67a vm_object_page_clean(c6d86088,0,0,10000,0,...) at vm_object_page_clean+0x7dc vm_object_sync(c6d86088,0,0,10000000,1,...) at vm_object_sync+0x2aa vm_map_sync(c61a0960,28800000,28800000,1,0,...) at vm_map_sync+0x175 msync(c6bce480,e8d6ccf8,c6cbdb40,e8d6cd38,c,...) at msync+0x6a syscall(e8d6cd38) at syscall+0x1aa Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (65, FreeBSD ELF32, msync), eip = 0x280e987f, esp = 0xbfbfe67c, ebp = 0xbfbfe698 --- panic: sleeping thread cpuid = 1 KDB: enter: panic panic: from debugger cpuid = 1 KDB: stack backtrace: Physical memory: 3049 MB Dumping 99 MB: 84 68 52 36 20 4 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04b4054 in db_fncall (dummy1=-388417476, dummy2=0, dummy3=4, dummy4=0xe8d9382c "©ÏNÀ\001") at /usr/home/imb/svn/head/sys/ddb/db_command.c:548 #2 0xc04b43bf in db_command (last_cmdp=0xc0b0f05c, cmd_table=0x0, dopager=1) at /usr/home/imb/svn/head/sys/ddb/db_command.c:445 #3 0xc04b462f in db_command_loop () at /usr/home/imb/svn/head/sys/ddb/db_command.c:498 #4 0xc04b63e5 in db_trap (type=3, code=0) at /usr/home/imb/svn/head/sys/ddb/db_main.c:229 #5 0xc06b6f7e in kdb_trap (type=3, code=0, tf=0xe8d939d0) at /usr/home/imb/svn/head/sys/kern/subr_kdb.c:535 #6 0xc09b4a50 in trap (frame=0xe8d939d0) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:694 #7 0xc099785b in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:165 #8 0xc06b7101 in kdb_enter (why=0xc0a3f01a "panic", msg=0xc0a3f01a "panic") at cpufunc.h:71 #9 0xc068627f in panic (fmt=0xc0a42826 "sleeping thread") at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:573 #10 0xc06c5255 in propagate_priority (td=Variable "td" is not available. ) at /usr/home/imb/svn/head/sys/kern/subr_turnstile.c:222 #11 0xc06c5e48 in turnstile_wait (ts=0xc6b21900, owner=0xc6bce480, queue=Variable "queue" is not available. ) at /usr/home/imb/svn/head/sys/kern/subr_turnstile.c:739 #12 0xc0676ec7 in _mtx_lock_sleep (m=0xc0b48e00, tid=3335246976, opts=0, file=0x0, line=0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c:447 #13 0xc0932403 in vm_fault (map=0xc6bcb5a0, vaddr=675311616, fault_type=2 '\002', fault_flags=0) at /usr/home/imb/svn/head/sys/vm/vm_fault.c:313 #14 0xc09b3ffa in trap_pfault (frame=0xe8d93d38, usermode=1, eva=675311616) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:832 #15 0xc09b4bdd in trap (frame=0xe8d93d38) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:401 #16 0xc099785b in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:165 #17 0x08056ef9 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -68 0 0 0 - DLs ?? 273919:50.00 [kernel] 0 1 0 0 44 0 8032 0 wait DLs ?? 135937:10.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? 223028:10.00 [g_event] 0 3 0 0 -8 0 0 0 - RL ?? 337087:40.00 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 444150:00.00 [g_down] 0 5 0 0 -16 0 0 0 crypto DL ?? 0:00.00 [crypto] 0 6 0 0 -16 0 0 0 crypto DL ?? 0:00.00 [crypto r 0 7 0 0 -16 0 0 0 c62a13bc DL ?? 0:00.00 [cbb0 eve 0 8 0 0 -16 0 0 0 - DL ?? 0:00.00 [fw0_prob 0 9 0 0 44 0 0 0 ccb_sc DL ?? 4093:40.00 [xpt_thrd 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 171 0 0 0 - RL ?? 29156939:06.00 [idle] 0 12 0 0 -60 0 0 0 - WL ?? 1288425:00.00 [intr] 0 13 0 0 -16 0 0 0 sleep DL ?? 0:00.00 [ng_queue 0 14 0 0 -16 0 0 0 - DL ?? 125917:10.00 [yarrow] 0 15 0 0 -64 0 0 0 - DL ?? 421942:30.00 [usb] 0 16 0 0 -16 0 0 0 tzpoll DL ?? 31386:40.00 [acpi_the 0 17 0 0 -20 0 0 0 IPRT E DL ?? 0:00.00 [TIMER] 0 18 0 0 76 0 0 0 r DL ?? 338:00.00 [g_journa 0 19 0 0 -32 0 0 0 psleep DL ?? 3006:50.00 [pagedaem 0 20 0 0 -32 0 0 0 psleep DL ?? 51:00.00 [vmdaemon 0 21 0 0 76 0 0 0 pgzero DL ?? 116:40.00 [pagezero 0 22 0 0 -32 0 0 0 psleep DL ?? 2222:40.00 [bufdaemo 0 23 0 0 -32 0 0 0 syncer DL ?? 2435:30.00 [syncer] 0 24 0 0 -32 0 0 0 vlruwt DL ?? 1768:30.00 [vnlru] 0 25 0 0 -32 0 0 0 sdflus DL ?? 16804:40.00 [softdepf 0 26 0 0 -32 0 0 0 flowcl DL ?? 12912:30.00 [flowclea 0 27 1 0 76 0 9800 0 wait Ds+ ?? 1019922:40.00 [sh] 0 190 1 0 76 0 1572 0 pause Ds ?? 10457:50.00 [adjkernt 0 790 1 0 76 0 9464 0 select Ds ?? 22304:40.00 [dhclient 65 806 1 0 47 0 9464 0 select Ds ?? 9031:50.00 [dhclient 0 807 1 0 76 0 8032 0 select Ds ?? 2964:30.00 [devd] 0 1043 1 0 47 0 9520 0 select Ds ?? 532783:50.00 [syslogd] 53 1132 1 0 48 0 36000 0 kqread Ds ?? 3240219:20.00 [named] 0 1149 1 0 76 0 9548 0 select Ds ?? 162435:00.00 [rpcbind] 0 1247 1 0 76 0 271640 0 biowr Ds ?? 9837:40.00 [rpc.stat 0 1254 1 0 76 0 9552 0 nlmrcv Ds ?? 0:00.00 [rpc.lock 0 1255 27 0 96 0 9800 0 vm pag LL+ ?? 0:00.00 [sh] ------------------------------------------------------------------------ vmstat -s 53922 cpu context switches 1877 device interrupts 5254 software interrupts 86621 traps 177061 system calls 26 kernel threads created 1227 fork() calls 2 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 265 vnode pager pageins 1821 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 99 pages reactivated 33645 copy-on-write faults 48 copy-on-write optimized faults 26046 zero fill pages zeroed 1535 zero fill pages prezeroed 4 intransit blocking page faults 83753 total VM faults taken 0 pages affected by kernel thread creation 1171166 pages affected by fork() 1960 pages affected by vfork() 0 pages affected by rfork() 136 pages cached 68352 pages freed 0 pages freed by daemon 48490 pages freed by exiting processes 4401 pages active 1502 pages inactive 33 pages in VM cache 7187 pages wired down 753697 pages free 4096 bytes per page 18513 total name lookups cache hits (88% pos + 4% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) GEOM 112 22K - 512 16,32,64,128,512,1024 CAM dev queue 5 1K - 5 128 CAM queue 18 1K - 116 16,32,128 CAM SIM 5 1K - 5 128 scsi_da 0 0K - 16 16 CAM periph 6 1K - 25 16,32,64,128 isadev 11 1K - 11 64 entropy 1024 64K - 1024 64 drm_ctxbitmap 1 4K - 1 4096 hdac 10 28K - 10 64,128,512,1024,2048 cdev 10 2K - 10 128 drm_agplists 1 1K - 1 64 sigio 1 1K - 1 32 filedesc 46 26K - 1268 16,32,64,128,256,512,1024,2048,4096 kenv 85 8K - 90 16,32,64,128,4096 kqueue 2 5K - 15 128,1024,4096 proc-args 11 1K - 415 32,64,128,256 ithread 73 6K - 73 16,64,128 KTRACE 100 13K - 100 128 linker 120 46K - 204 16,32,64,512,1024,2048,4096 lockf 11 1K - 23 32,64 feeder 13 1K - 15 16,64 ip6ndp 7 1K - 9 64,128 ip6opt 0 0K - 29 128 temp 209 245K - 8275 16,32,64,128,256,512,1024,2048,4096 devbuf 3820 4019K - 3997 16,32,64,128,256,512,1024,2048,4096 module 277 18K - 277 64,128 mtx_pool 3 9K - 3 1024,4096 drm_maps 1 1K - 1 64 osd 2 1K - 2 16,32 subproc 111 171K - 1330 256,4096 proc 2 8K - 2 4096 session 11 1K - 11 64 pgrp 11 1K - 11 64 cred 22 3K - 3418 64,128 uidinfo 4 2K - 4 64,1024 plimit 3 1K - 20 256 sysctltmp 0 0K - 272 16,32,64,128,256,4096 sysctloid 4160 128K - 4266 16,32,64,128 sysctl 0 0K - 593 16,32,64 callout 1 256K - 1 umtx 280 27K - 280 64,128 p1003.1b 1 1K - 1 16 SWAP 2 277K - 2 64 drm_driver 4 5K - 8 16,64,256,4096 bus-sc 89 173K - 1899 16,32,64,128,256,512,1024,2048,4096 bus 899 48K - 4696 16,32,64,128,256,512,1024 devstat 6 13K - 6 16,4096 eventhandler 96 5K - 96 32,64,128 mixer 1 4K - 1 4096 kobj 170 340K - 208 2048 Per-cpu 1 1K - 1 16 drm_sarea 1 1K - 1 16 drm_dma 1 1K - 1 16 rman 175 11K - 587 16,32,64 fw_xfer 0 0K - 1 128 sbuf 0 0K - 582 16,32,64,128,256,512,1024,2048,4096 firewire 11 23K - 14 32,64,512,1024,2048,4096 stack 0 0K - 2 128 taskqueue 15 1K - 15 16,64 Unitno 15 1K - 19 16,64 iov 0 0K - 1926 16,64,128,256 select 11 1K - 11 64 ioctlops 0 0K - 797 16,32,64,128,256,512,1024 msg 4 25K - 4 1024,4096 sem 4 6K - 4 256,512,1024,4096 shm 1 12K - 1 tty 19 10K - 21 512,1024 mbuf_tag 0 0K - 23 32,64 ksem 1 4K - 1 4096 shmfd 1 4K - 1 4096 pcb 30 79K - 191 16,64,512,1024,2048,4096 soname 6 1K - 1052 16,32,128 biobuf 4 8K - 6 2048 vfscache 1 512K - 1 cl_savebuf 0 0K - 6 32,64 vfs_hash 1 256K - 1 vnodes 2 1K - 2 128 acpidev 113 4K - 113 32 vnodemarker 0 0K - 13 512 mount 82 3K - 126 16,32,64,128,256 BPF 9 9K - 9 64,128,256,4096 ether_multi 50 2K - 64 16,32,64 ifaddr 44 11K - 45 16,32,64,128,256,512,2048 ifnet 5 5K - 5 64,1024 clone 8 32K - 8 4096 arpcom 3 1K - 3 16 lltable 18 4K - 19 128,256 sbp 104 9K - 104 32,128 tap 1 1K - 1 128 ddb_capture 1 48K - 1 acpica 2758 141K - 104956 16,32,64,128,256,512,1024,2048 pci_link 16 2K - 16 64,128 acpitask 1 1K - 1 1024 USBdev 31 7K - 31 32,128,256,1024 USB 53 43K - 59 16,32,64,128,1024,2048,4096 routetbl 78 4109K - 205 16,32,64,128,256 netgraph_btsocks_hci_raw 1 8K - 1 acpi_perf 2 1K - 2 128 CAM XPT 71 78K - 174 16,32,64,256,1024,2048 acpipwr 3 1K - 3 32,64 netgraph_node 7 1K - 7 128 netgraph 3 1K - 3 32 igmp 4 1K - 4 128 ipid 2 24K - 2 pmc 35 70K - 35 16,32,64,128,256,1024,4096 acpivideo 3 1K - 3 64 agp 1 1K - 1 16 in_multi 3 1K - 4 128 sctp_iter 0 0K - 4 128 sctp_ifn 3 1K - 3 128 sctp_ifa 7 1K - 7 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 4 16 hostcache 1 16K - 1 syncache 1 72K - 1 acpisem 62 8K - 62 64,128 ip6_moptions 2 1K - 2 32,128 in6_multi 27 3K - 27 16,256 in6_mfilter 1 1K - 1 512 kbdmux 6 18K - 6 16,256,1024,2048 mld 4 1K - 4 128 NLM 0 0K - 1 16 crypto 1 1K - 1 512 rpc 52 5K - 181 16,32,64,128,256,512,1024 audit_evclass 172 3K - 211 16 savedino 0 0K - 15 256 freework 0 0K - 17 64 newdirblk 4 1K - 6 32 dirrem 5 1K - 37 64 mkdir 4 1K - 12 64 diradd 19 2K - 30 64 freefile 0 0K - 29 32 freeblks 0 0K - 17 64 freefrag 2 1K - 28 64 newblk 15 66K - 89 128 bmsafemap 5 5K - 18 128,4096 inodedep 28 263K - 74 256 pagedep 11 66K - 20 128 ufs_dirhash 54 11K - 54 16,32,64,128,256,512 ufs_mount 3 27K - 3 256,2048 UMAHash 1 1K - 1 256 DEVFS1 111 28K - 113 256 DEVFS3 263 33K - 265 128 vm_pgdata 2 65K - 2 64 DEVFS2 111 2K - 111 16 atkbddev 2 1K - 2 32 DEVFS_RULE 53 13K - 53 32,256 DEVFS 36 1K - 37 16,64 DEVFSP 1 1K - 1 32 cpuctl 1 1K - 1 16 apmdev 1 1K - 1 64 ntfs_nthash 1 256K - 1 io_apic 1 1K - 1 1024 memdesc 1 4K - 1 4096 msi 1 1K - 1 64 nexusdev 6 1K - 6 16 linux 14 1K - 14 32,64 pfs_nodes 169 22K - 169 128 pfs_vncache 3 1K - 3 32 iprtheap 21 3K - 21 32,64,128,256,1024 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 104, 16, 104, 0 UMA Zones: 888, 0, 104, 0, 104, 0 UMA Slabs: 284, 0, 729, 13, 930, 0 UMA RCntSlabs: 544, 0, 137, 3, 137, 0 UMA Hash: 128, 0, 4, 26, 5, 0 16 Bucket: 76, 0, 47, 3, 69, 0 32 Bucket: 140, 0, 45, 11, 66, 0 64 Bucket: 268, 0, 46, 10, 92, 123 128 Bucket: 524, 0, 47, 2, 953, 112 VM OBJECT: 136, 0, 703, 109, 14508, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 72, 57505, 47, 218, 2984, 0 MAP ENTRY: 72, 0, 153, 165, 27228, 0 DP fakepg: 72, 0, 0, 0, 0, 0 SG fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 335, 0, 335, 0 16: 16, 0, 3717, 343, 55573, 0 32: 32, 0, 3164, 113, 56920, 0 64: 64, 0, 5026, 166, 8358, 0 128: 128, 0, 3016, 164, 10145, 0 256: 256, 0, 684, 96, 2635, 0 512: 512, 0, 91, 45, 2085, 0 1024: 1024, 0, 68, 212, 2303, 0 2048: 2048, 0, 237, 33, 427, 0 4096: 4096, 0, 343, 36, 7415, 0 Files: 56, 0, 69, 199, 5337, 0 TURNSTILE: 72, 0, 141, 39, 141, 0 umtx pi: 52, 0, 0, 0, 0, 0 MAC labels: 20, 0, 0, 0, 0, 0 PROC: 680, 0, 37, 35, 1255, 0 THREAD: 568, 0, 120, 20, 120, 0 SLEEPQUEUE: 44, 0, 141, 95, 141, 0 VMSPACE: 240, 0, 12, 68, 1231, 0 cpuset: 40, 0, 2, 182, 2, 0 audit_record: 816, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 64, 197, 242, 0 mbuf: 256, 0, 4, 385, 959, 0 mbuf_cluster: 2048, 25600, 257, 17, 290, 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 NetGraph items: 36, 4130, 0, 0, 0, 0 NetGraph data items: 36, 531, 0, 0, 0, 0 g_bio: 140, 0, 0, 364, 5015, 0 ttyinq: 152, 0, 15, 37, 15, 0 ttyoutq: 256, 0, 8, 22, 8, 0 ata_request: 212, 0, 0, 0, 0, 0 ata_composite: 180, 0, 0, 0, 0, 0 cryptop: 60, 0, 0, 0, 0, 0 cryptodesc: 56, 0, 0, 0, 0, 0 VNODE: 272, 0, 545, 15, 575, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0 S VFS Cache: 72, 0, 541, 95, 1242, 0 L VFS Cache: 292, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 36, 7952, 0 NFSMOUNT: 524, 0, 0, 0, 0, 0 NFSNODE: 468, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 120, 8, 120, 0 mqnode: 344, 0, 3, 19, 3, 0 mqueue: 132, 0, 0, 0, 0, 0 mvdata: 36, 0, 0, 0, 0, 0 mqnotifier: 136, 0, 0, 0, 0, 0 UDF translation buffer, zone: 510, 0, 0, 0, 0, 0 UDF Node zone: 20, 0, 0, 0, 0, 0 UDF Dirstream zone: 48, 0, 0, 0, 0, 0 pipe: 392, 0, 2, 38, 782, 0 AIO: 124, 0, 0, 0, 0, 0 AIOP: 16, 0, 0, 0, 0, 0 AIOCB: 296, 0, 0, 0, 0, 0 AIOL: 64, 0, 0, 0, 0, 0 AIOLIO: 168, 0, 0, 0, 0, 0 ksiginfo: 80, 0, 55, 1001, 56, 0 itimer: 220, 0, 0, 36, 1, 0 KNOTE: 72, 0, 10, 202, 1065, 0 socket: 412, 25605, 36, 63, 538, 0 unpcb: 172, 25622, 9, 83, 124, 0 ipq: 32, 904, 0, 0, 0, 0 udp_inpcb: 220, 25614, 14, 94, 384, 0 udpcb: 8, 25781, 14, 392, 384, 0 tcp_inpcb: 220, 25614, 14, 40, 19, 0 tcpcb: 632, 25602, 11, 13, 19, 0 tcptw: 52, 5184, 3, 141, 3, 0 syncache: 112, 15365, 0, 0, 0, 0 hostcache: 76, 15400, 0, 0, 0, 0 tcpreass: 20, 1690, 0, 0, 0, 0 sackhole: 20, 0, 0, 0, 0, 0 sctp_ep: 860, 25600, 0, 0, 0, 0 sctp_asoc: 1484, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 290, 6, 0 sctp_raddr: 432, 80001, 0, 0, 0, 0 sctp_chunk: 92, 400008, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 220, 25614, 1, 35, 1, 0 rtentry: 108, 0, 22, 86, 23, 0 selfd: 28, 0, 28, 353, 2043, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0 ip4flow: 40, 50232, 87, 189, 87, 0 ip6flow: 64, 50228, 0, 0, 0, 0 Mountpoints: 648, 0, 6, 12, 6, 0 FFS inode: 116, 0, 522, 72, 551, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 522, 48, 551, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 8 0 irq9: acpi0 63 0 irq17: fwohci0 1 0 irq18: cbb0 uhci2+ 19 0 irq19: uhci1 ahci0+ 1235 5 irq20: fxp0 168 0 irq23: uhci0 ehci0 370 1 cpu0: timer 49272 201 irq256: hdac0 13 0 cpu1: timer 39171 159 Total 90320 368 ------------------------------------------------------------------------ pstat -T 69/12328 files 0M/2047M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ntfs/SQ004033P03 4194048 0 4194048 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 ada0 da0 pass0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 13.12 5 0.06 1.55 0 0.00 0.00 0 0.00 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ 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: 33554432 (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: 8192 (max amount of shared memory in pages) seminfo: semmap: 30 (# of entries in semaphore map) semmni: 10 (# of semaphore identifiers) semmns: 60 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 136 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: kvm_nlist: can't get names ------------------------------------------------------------------------ netstat -s tcp: 16 packets sent 3 data packets (126 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 7 ack-only packets (0 delayed) 0 URG only packets 0 window probe packets 0 window update packets 6 control packets 13 packets received 9 acks (for 129 bytes) 3 duplicate acks 0 acks for unsent data 7 packets (2199 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 3 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 3 connections established (including accepts) 5 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 9 segments updated rtt (of 9 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 1 correct data packet header prediction 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: 156 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 156 delivered 187 datagrams output 0 times multicast source filter matched ip: 167 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 166 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 1 packet not forwardable 0 packets received for unknown multicast group 0 redirects sent 171 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: 5 ARP requests sent 0 ARP replies sent 2 ARP requests received 3 ARP replies received 6 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 4 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 3 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 44 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 Input histogram: UDP: 3 ICMP6: 1 Mbuf statistics: 1 one mbuf two or more mbuf: lo0= 3 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: 29 first candidate 4 same address 29 appropriate scope icmp6: 1 call to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: unreach: 1 neighbor solicitation: 8 MLDv2 listener report: 3 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: unreach: 1 Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 1 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 68/582/650 mbufs in use (current/cache/total) 60/214/274/25600 mbuf clusters in use (current/cache/total/max) 64/197 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) 137K/573K/710K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop fxp0 1500 00:a0:d1:3f:7d:47 141 0 0 146 0 0 0 fxp0 1500 auburn-net toshi 154 - - 159 - - - lo0 16384 15 0 0 15 0 0 0 lo0 16384 local-net localhost 12 - - 12 - - - lo0 16384 localhost ::1 0 - - 4 - - - lo0 16384 fe80:2::1 fe80:2::1 0 - - 0 - - - vboxn 1500 0a:00:27:00:00:00 0 0 0 0 0 0 0 tap0 1500 00:a0:d1:3f:7d:48 1 0 0 1 26 0 0 tap0 1500 toshi.auburn. 2001:470:1f07:4e1 0 - - 36 - - - tap0 1500 fe80:4::2a0:d fe80:4::2a0:d1ff: 0 - - 1 - - - tap0 1500 vpn-net/28 toshi 0 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 83 151 fxp0 127.0.0.1 link#2 UH 0 12 lo0 192.168.1.0/24 link#1 U 4 8 fxp0 192.168.1.10 link#1 UHS 0 0 lo0 202.12.127.80/28 link#4 U 0 0 tap0 202.12.127.84 link#4 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2001:470:1f07:4e1::1 UGS tap0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:470:1f07:4e1::/64 link#4 U tap0 2001:470:1f07:4e1::4 link#4 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#2 U lo0 fe80::1%lo0 link#2 UHS lo0 fe80::%tap0/64 link#4 U tap0 fe80::2a0:d1ff:fe3f:7d48%tap0 link#4 UHS lo0 ff01:2::/32 ::1 U lo0 ff01:4::/32 2001:470:1f07:4e1::4 U tap0 ff02::/16 ::1 UGRS lo0 ff02::%lo0/32 ::1 U lo0 ff02::%tap0/32 2001:470:1f07:4e1::4 U tap0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) c6df2c58 tcp4 0 0 *.845 *.* LISTEN c6db1c58 tcp6 0 0 *.1019 *.* LISTEN c6db2000 tcp4 0 0 *.729 *.* LISTEN c6dec278 tcp6 0 0 *.729 *.* LISTEN c6dec4f0 tcp4 0 0 *.111 *.* LISTEN c6dec000 tcp6 0 0 *.111 *.* LISTEN c6dede38 tcp4 0 0 192.168.1.10.46067 199.19.57.1.53 TIME_WAIT c6dee000 tcp4 0 0 192.168.1.10.62580 199.19.54.1.53 TIME_WAIT c6dede6c tcp4 0 0 192.168.1.10.24314 199.19.54.1.53 TIME_WAIT c6db19e0 tcp6 0 0 ::1.953 *.* LISTEN c6db1000 tcp4 0 0 127.0.0.1.953 *.* LISTEN c6db1278 tcp4 0 0 202.12.127.84.53 *.* LISTEN c6db14f0 tcp4 0 0 127.0.0.1.53 *.* LISTEN c6db1768 tcp4 0 0 192.168.1.10.53 *.* LISTEN c6ddfe9c udp4 0 0 *.663 *.* c6cdc1b8 udp6 0 0 *.685 *.* c6de5ce4 udp6 0 0 *.698 *.* c6de5dc0 udp4 0 0 *.* *.* c6ddfdc0 udp4 0 0 *.729 *.* c6de5000 udp6 0 0 *.729 *.* c6dea294 udp6 0 0 *.* *.* c6de50dc udp4 0 0 *.948 *.* c6ddf974 udp4 0 0 *.111 *.* c6ddf7bc udp6 0 0 *.847 *.* c6cf8000 udp6 0 0 *.111 *.* c6cdb370 udp4 0 0 202.12.127.84.53 *.* c6cdb44c udp4 0 0 127.0.0.1.53 *.* c6cdb294 udp4 0 0 192.168.1.10.53 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c6cfb560 stream 0 0 c6dcf660 0 0 0 /var/run/rpcbind.sock c6cfd0ac stream 0 0 c6ccf990 0 0 0 /var/run/devd.pipe c6cfa000 dgram 0 0 0 c6cfb8bc 0 c6cfa0ac c6cfa0ac dgram 0 0 0 c6cfb8bc 0 c6cfb6b8 c6cfb6b8 dgram 0 0 0 c6cfb8bc 0 0 c6cfb764 dgram 0 0 c6d81660 0 0 0 /var/named/var/run/log c6cfb810 dgram 0 0 c6d81770 0 0 0 /var/run/log c6cfb8bc dgram 0 0 c6d81880 0 c6cfa000 0 /var/run/logpriv c6cfa158 dgram 0 0 c6cc1440 0 0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.845 tcp6 0/0/128 *.1019 tcp4 0/0/128 *.netviewdm1 tcp6 0/0/128 *.netviewdm1 tcp4 0/0/128 *.sunrpc tcp6 0/0/128 *.sunrpc tcp6 0/0/128 localhost.rndc tcp4 0/0/128 localhost.rndc tcp4 0/0/3 toshi.domain tcp4 0/0/3 localhost.domain tcp4 0/0/3 toshi.domain 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 sh 1255 root / 2 drwxr-xr-x 512 r root sh 1255 wd / 2 drwxr-xr-x 512 r root sh 1255 text / 9609750 -r-xr-xr-x 116732 r root sh 1255 0 /dev 4 crw------- console rw root sh 1255 1 /dev 4 crw------- console rw root sh 1255 2 /dev 4 crw------- console rw root sh 1255 10 / 11611662 -r-xr-xr-x 586 r root sh 1255 11 / 11611366 -rw-r--r-- 39057 r root rpc.lockd 1254 root / 2 drwxr-xr-x 512 r root rpc.lockd 1254 wd / 2 drwxr-xr-x 512 r root rpc.lockd 1254 text / 4335227 -r-xr-xr-x 47848 r root rpc.lockd 1254 0 /dev 12 crw-rw-rw- null rw root rpc.lockd 1254 1 /dev 12 crw-rw-rw- null rw root rpc.lockd 1254 2 /dev 12 crw-rw-rw- null rw root rpc.lockd 1254 3* local dgram c6cfa000 <-> c6cfb8bc root rpc.statd 1247 root / 2 drwxr-xr-x 512 r root rpc.statd 1247 wd / 2 drwxr-xr-x 512 r root rpc.statd 1247 text / 4335236 -r-xr-xr-x 17264 r root rpc.statd 1247 0 /dev 12 crw-rw-rw- null rw root rpc.statd 1247 1 /dev 12 crw-rw-rw- null rw root rpc.statd 1247 2 /dev 12 crw-rw-rw- null rw root rpc.statd 1247 3 / 16557729 -rw-r--r-- 256 rw root rpc.statd 1247 4* internet6 dgram udp c6de5000 root rpc.statd 1247 5* internet6 stream tcp c6dec278 root rpc.statd 1247 6* internet dgram udp c6ddfdc0 root rpc.statd 1247 7* internet stream tcp c6db2000 root rpc.statd 1247 8* local dgram c6cfa0ac <-> c6cfb8bc root rpcbind 1149 root / 2 drwxr-xr-x 512 r root rpcbind 1149 wd / 2 drwxr-xr-x 512 r root rpcbind 1149 text / 4333899 -r-xr-xr-x 39468 r root rpcbind 1149 0 /dev 12 crw-rw-rw- null rw root rpcbind 1149 1 /dev 12 crw-rw-rw- null rw root rpcbind 1149 2 /dev 12 crw-rw-rw- null rw root rpcbind 1149 3 / 2755657 -r--r--r-- 0 r root rpcbind 1149 4* internet6 dgram udp c6dea294 root rpcbind 1149 5* local stream c6cfb560 root rpcbind 1149 6* internet6 dgram udp c6cf8000 root rpcbind 1149 7* internet6 dgram udp c6ddf7bc root rpcbind 1149 8* internet6 stream tcp c6dec000 root rpcbind 1149 9* internet dgram udp c6ddf974 root rpcbind 1149 10* internet dgram udp c6de50dc root rpcbind 1149 11* internet stream tcp c6dec4f0 bind named 1132 root / 2590933 drwxr-xr-x 512 r bind named 1132 wd / 2638028 drwxr-xr-x 512 r bind named 1132 jail / 2590933 drwxr-xr-x 512 r bind named 1132 text / 4335127 -r-xr-xr-x 1897100 r bind named 1132 0 /dev 12 crw-rw-rw- null rw bind named 1132 1 /dev 12 crw-rw-rw- null rw bind named 1132 2 /dev 12 crw-rw-rw- null rw bind named 1132 3* local dgram c6cfb6b8 <-> c6cfb8bc bind named 1132 4 /dev 12 crw-rw-rw- null rw bind named 1132 6* pipe c6c0b310 <-> c6c0b3c8 0 rw bind named 1132 8* pipe c6c0b3c8 <-> c6c0b310 0 rw bind named 1132 10 /var/named/dev 16 crw-rw-rw- random r bind named 1132 20* internet stream tcp c6db1768 bind named 1132 21* internet stream tcp c6db14f0 bind named 1132 22* internet stream tcp c6db1278 bind named 1132 23* internet stream tcp c6db1000 bind named 1132 24* internet6 stream tcp c6db19e0 bind named 1132 512* internet dgram udp c6cdb294 bind named 1132 513* internet dgram udp c6cdb44c bind named 1132 514* internet dgram udp c6cdb370 root syslogd 1043 root / 2 drwxr-xr-x 512 r root syslogd 1043 wd / 2 drwxr-xr-x 512 r root syslogd 1043 text / 4335232 -r-xr-xr-x 35860 r root syslogd 1043 0 /dev 12 crw-rw-rw- null rw root syslogd 1043 1 /dev 12 crw-rw-rw- null rw root syslogd 1043 2 /dev 12 crw-rw-rw- null rw root syslogd 1043 3 / 2755885 -rw------- 4 w root syslogd 1043 4* local dgram c6cfa158 root syslogd 1043 5* local dgram c6cfb8bc root syslogd 1043 6* local dgram c6cfb810 root syslogd 1043 7* local dgram c6cfb764 root syslogd 1043 8 /dev 18 crw------- klog r root syslogd 1043 10 /dev 4 crw------- console w root syslogd 1043 11 / 2496644 -rw-r--r-- 107051 w root syslogd 1043 12 / 2496826 -rw------- 60 w root syslogd 1043 13 / 2496646 -rw------- 71874 w root syslogd 1043 14 / 2496529 -rw-r----- 1829 w root syslogd 1043 15 / 2496823 -rw-r--r-- 19247 w root syslogd 1043 16 / 2496828 -rw------- 740 w root syslogd 1043 17 / 2496630 -rw------- 70226 w root syslogd 1043 18 / 2496790 -rw------- 29840 w root syslogd 1043 19 / 2496825 -rw-r----- 64521 w root syslogd 1043 20 / 2496665 -rw-rw-r-- 107 w root devd 807 root / 2 drwxr-xr-x 512 r root devd 807 wd / 2 drwxr-xr-x 512 r root devd 807 text / 683853 -r-xr-xr-x 388696 r root devd 807 0 /dev 12 crw-rw-rw- null rw root devd 807 1 /dev 12 crw-rw-rw- null rw root devd 807 2 /dev 12 crw-rw-rw- null rw root devd 807 3 / 11611162 drwxr-xr-x 512 r root devd 807 4 / 1885333 drwxr-xr-x 512 r root devd 807 5 /dev 6 crw------- devctl r root devd 807 6* local stream c6cfd0ac root devd 807 7 / 2755660 -rw------- 3 w _dhcp dhclient 806 root / 16510165 dr-xr-xr-x 512 r _dhcp dhclient 806 wd / 16510165 dr-xr-xr-x 512 r _dhcp dhclient 806 jail / 16510165 dr-xr-xr-x 512 r _dhcp dhclient 806 text / 683860 -r-xr-xr-x 74204 r _dhcp dhclient 806 0 /dev 12 crw-rw-rw- null rw _dhcp dhclient 806 1 /dev 12 crw-rw-rw- null rw _dhcp dhclient 806 2 /dev 12 crw-rw-rw- null rw _dhcp dhclient 806 4* route raw 0 c6cda338 _dhcp dhclient 806 5* pipe c6be39e8 <-> c6be3930 0 rw _dhcp dhclient 806 6* local stream c6cfd0ac _dhcp dhclient 806 7 / 16557724 ---------- 864 w _dhcp dhclient 806 8 /dev 8 crw------- bpf rw _dhcp dhclient 806 9* internet raw ip c6d6d000 root dhclient 790 root / 2 drwxr-xr-x 512 r root dhclient 790 wd / 2 drwxr-xr-x 512 r root dhclient 790 text / 683860 -r-xr-xr-x 74204 r root dhclient 790 0 /dev 12 crw-rw-rw- null rw root dhclient 790 1 /dev 12 crw-rw-rw- null rw root dhclient 790 2 /dev 12 crw-rw-rw- null rw root dhclient 790 4* pipe c6be3930 <-> c6be39e8 0 rw root dhclient 790 6* local stream c6cfd0ac root adjkerntz 190 root / 2 drwxr-xr-x 512 r root adjkerntz 190 wd / 2 drwxr-xr-x 512 r root adjkerntz 190 text / 683758 -r-xr-xr-x 7260 r root adjkerntz 190 0 /dev 12 crw-rw-rw- null rw root adjkerntz 190 1 /dev 12 crw-rw-rw- null rw root adjkerntz 190 2 /dev 12 crw-rw-rw- null rw root sh 27 root / 2 drwxr-xr-x 512 r root sh 27 wd / 2 drwxr-xr-x 512 r root sh 27 text / 9609750 -r-xr-xr-x 116732 r root sh 27 0 /dev 4 crw------- console rw root sh 27 1 /dev 4 crw------- console rw root sh 27 2 /dev 4 crw------- console rw root sh 27 10 / 11611483 -rw-r--r-- 3713 r root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 683818 -r-xr-xr-x 661524 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 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 #1 r207439M: Fri Apr 30 13:12:37 EDT 2010 root@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0cf6000. Preloaded elf module "/boot/modules/vboxdrv.ko" at 0xc0cf6234. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1662512030 Hz CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Family = 6 Model = e Stepping = 8 Features=0xbfe9fbff Features2=0xc1a9 TSC: P-state invariant Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 2048 kbytes, 8-way associative, 64 bytes/line real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001026000 - 0x00000000bc03afff, 3137425408 bytes (765973 pages) avail memory = 3135778816 (2990 MB) Table 'FACP' at 0xbf681bf8 Table 'APIC' at 0xbf681cec APIC: Found table at 0xbf681cec MP Configuration Table version 1.4 found at 0xc009fd71 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x000000-0x0004ff at 0xc0000000 x86bios: SSEG 0x010000-0x01ffff at 0xc5fce000 x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000 x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000 bios32: Found BIOS32 Service Directory header at 0xc00f69c0 bios32: Entry = 0xfd63d (c00fd63d) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd5c0+0x44 pnpbios: Found PnP BIOS data at 0xc00f6a30 pnpbios: Entry = f0000:bd02 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf6960 00024 (v2 TOSINV) ACPI: XSDT 0xbf678478 0008C (v1 TOSINV TOSINV00 06040000 INV 00000000) ACPI: FACP 0xbf681bf8 000F4 (v3 TOSINV TOSINV00 06040000 ALAN 00000001) ACPI: DSDT 0xbf67a1cf 079B5 (v2 TOSINV CALISTGA 06040000 INTL 20050624) ACPI: FACS 0xbf682fc0 00040 ACPI: APIC 0xbf681cec 00068 (v1 INTEL CALISTGA 06040000 LOHR 0000005A) ACPI: HPET 0xbf681d54 00038 (v1 INTEL CALISTGA 06040000 LOHR 0000005A) ACPI: MCFG 0xbf681d8c 0003C (v1 INTEL CALISTGA 06040000 LOHR 0000005A) ACPI: TCPA 0xbf681dc8 00032 (v1 PTLTD CALISTGA 06040000 PTL 00000001) ACPI: APIC 0xbf681dfa 00068 (v1 TOSINV APIC 06040000 INV 00000000) ACPI: SLIC 0xbf681e62 00176 (v1 TOSINV TOSINV00 06040000 INV 00000000) ACPI: BOOT 0xbf681fd8 00028 (v1 PTLTD $SBFTBL$ 06040000 LTP 00000001) ACPI: SSDT 0xbf679b80 0064F (v1 SataRe SataPri 00001000 INTL 20050624) ACPI: SSDT 0xbf6794ee 00692 (v1 SataRe SataSec 00001000 INTL 20050624) ACPI: SSDT 0xbf678a90 0025F (v1 PmRef Cpu0Tst 00003000 INTL 20050624) ACPI: SSDT 0xbf6789ea 000A6 (v1 PmRef Cpu1Tst 00003000 INTL 20050624) ACPI: SSDT 0xbf678504 004E6 (v1 PmRef CpuPm 00003000 INTL 20050624) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> firmware: 'wpifw' version 2144: 149652 bytes loaded at 0xc0a9f9e4 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 nfslock: pseudo-device crypto: null: random: cpuctl: access to MSR registers/cpuid info. VESA: information block 0000 56 45 53 41 00 03 00 01 00 9e 01 00 00 00 40 00 0010 00 9e 7b 00 00 01 43 01 00 9e 55 01 00 9e 89 01 0020 00 9e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 60 01 61 01 62 01 63 01 64 01 65 01 66 01 67 01 0050 68 01 69 01 6a 01 6b 01 6c 01 6d 01 6e 01 6f 01 0060 70 01 71 01 3c 01 4d 01 5c 01 3a 01 4b 01 5a 01 0070 07 01 1a 01 1b 01 05 01 17 01 18 01 12 01 14 01 0080 15 01 01 01 03 01 11 01 ff ff 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 49 6e 74 65 6c 28 72 29 20 38 32 39 34 35 47 4d 0110 20 43 68 69 70 73 65 74 20 46 61 6d 69 6c 79 20 0120 47 72 61 70 68 69 63 73 20 43 68 69 70 20 41 63 0130 63 65 6c 65 72 61 74 65 64 20 56 47 41 20 42 49 0140 4f 53 00 49 6e 74 65 6c 20 43 6f 72 70 6f 72 61 0150 74 69 6f 6e 00 49 6e 74 65 6c 28 72 29 20 38 32 0160 39 34 35 47 4d 20 43 68 69 70 73 65 74 20 46 61 0170 6d 69 6c 79 20 47 72 61 70 68 69 63 73 20 43 6f 0180 6e 74 72 6f 6c 6c 65 72 00 48 61 72 64 77 61 72 0190 65 20 56 65 72 73 69 6f 6e 20 30 2e 30 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 15 mode(s) found VESA: v3.0, 7872k memory, flags:0x1, mode table:0xc5ffe040 (9e000040) VESA: Intel(r) 82945GM Chipset Family Graphics Chip Accelerated VGA BIOS VESA: Intel Corporation Intel(r) 82945GM Chipset Family Graphics Controller Hardware Version 0.0 io: full: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled npx0: INT 16 interface smbios0: at iomem 0xf69a0-0xf69be on motherboard smbios0: Version: 2.4 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 2.10 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc5fc8000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/2 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 ACPI: SSDT 0xbf679236 001FB (v1 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 001FB (v1 PmRef Cpu0Ist 00003000 INTL 20050624) ACPI: SSDT 0xbf678cef 004C2 (v1 PmRef Cpu0Cst 00003001 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 004C2 (v1 PmRef Cpu0Cst 00003001 INTL 20050624) cpu1: on acpi0 ACPI: SSDT 0xbf679431 000BD (v1 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 000BD (v1 PmRef Cpu1Ist 00003000 INTL 20050624) ACPI: SSDT 0xbf6791b1 00085 (v1 PmRef Cpu1Cst 00003000 INTL 20050624) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00085 (v1 PmRef Cpu1Cst 00003000 INTL 20050624) acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 10 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 acpi_lid0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x27a0, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27a2, revid=0x03 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xf0a00000, size 19, enabled map[14]: type I/O Port, range 32, base 0x1800, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xf0b00000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, revid=0x03 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf0a80000, size 19, enabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf0b40000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x27d0, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27d2, revid=0x02 domain=0, bus=0, slot=28, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d4, revid=0x02 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27c8, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x02 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf0d44000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27c4, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x18b0, size 4, enabled found-> vendor=0x8086, dev=0x27da, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 vgapci0: port 0x1800-0x1807 mem 0xf0a00000-0xf0a7ffff,0xd0000000-0xdfffffff,0xf0b00000-0xf0b3ffff irq 16 at device 2.0 on pci0 acpi_video0: on vgapci0 found VGA CRT or VESA Compatible Analog Monitor(100), idx#0, port#0, detectable by BIOS, head #0 found TV/HDTV or Analog-Video Monitor(200), idx#0, port#0, detectable by BIOS, head #0 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, detectable by BIOS, head #0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7932k stolen memory drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: mem 0xf0a80000-0xf0afffff at device 2.1 on pci0 hdac0: mem 0xf0b40000-0xf0b43fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 hdac0: using IRQ 256 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 17 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci2: on pcib1 pci2: domain=0, physical bus=2 pcib2: irq 16 at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 3 pcib2: subordinate bus 4 pcib2: I/O decode 0x2000-0x2fff pcib2: memory decode 0xf0700000-0xf07fffff pcib2: prefetched decode 0xf0200000-0xf03fffff pci3: on pcib2 pci3: domain=0, physical bus=3 pcib3: irq 18 at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 5 pcib3: subordinate bus 6 pcib3: I/O decode 0x3000-0x3fff pcib3: memory decode 0xf0800000-0xf08fffff pcib3: prefetched decode 0xf0400000-0xf05fffff pci5: on pcib3 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x4222, revid=0x02 domain=0, bus=5, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf0800000, size 12, enabled pcib3: requested memory range 0xf0800000-0xf0800fff: good pcib3: matched entry for 5.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 pci5: at device 0.0 (no driver attached) uhci0: port 0x1820-0x183f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 50 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 51 uhci1: [MPSAFE] uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1860-0x187f irq 18 at device 29.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 52 uhci2: [MPSAFE] uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x1880-0x189f irq 16 at device 29.3 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 53 uhci3: [MPSAFE] uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xf0d44000-0xf0d443ff irq 23 at device 29.7 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 7 pcib4: subordinate bus 7 pcib4: I/O decode 0x4000-0x4fff pcib4: memory decode 0xf0900000-0xf09fffff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci7: on pcib4 pci7: domain=0, physical bus=7 found-> vendor=0x104c, dev=0x8039, revid=0x00 domain=0, bus=7, slot=6, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, memory disabled found-> vendor=0x104c, dev=0x803a, revid=0x00 domain=0, bus=7, slot=6, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0906000, size 11, enabled pcib4: requested memory range 0xf0906000-0xf09067ff: good map[14]: type Memory, range 32, base 0xf0900000, size 14, enabled pcib4: requested memory range 0xf0900000-0xf0903fff: good pcib4: matched entry for 7.6.INTB pcib4: slot 6 INTB hardwired to IRQ 17 found-> vendor=0x104c, dev=0x803b, revid=0x00 domain=0, bus=7, slot=6, func=2 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0904000, size 12, enabled pcib4: requested memory range 0xf0904000-0xf0904fff: good pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 found-> vendor=0x104c, dev=0x803c, revid=0x00 domain=0, bus=7, slot=6, func=3 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=4 (dwords) lattimer=0x80 (3840 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0906800, size 8, enabled pcib4: requested memory range 0xf0906800-0xf09068ff: good pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1092, revid=0x02 domain=0, bus=7, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf0905000, size 12, enabled pcib4: requested memory range 0xf0905000-0xf0905fff: good map[14]: type I/O Port, range 32, base 0x4000, size 6, enabled pcib4: requested I/O range 0x4000-0x403f: in range pcib4: matched entry for 7.8.INTA pcib4: slot 8 INTA hardwired to IRQ 20 cbb0: at device 6.0 on pci7 pcib4: cbb0 requested memory range 0x0-0xffffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xbf670000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib4: matched entry for 7.6.INTA pcib4: slot 6 INTA hardwired to IRQ 18 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0x8039104c 0x02100007 0x06070000 0x00824000 0x10: 0xbf670000 0x020000a0 0x20090807 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400112 0x40: 0xff101179 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x48409060 0x02830019 0x000f0000 0x01a01b22 0x90: 0x606600c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x44072b31 0x8d019449 0x00000000 0x00000000 fwohci0: vendor=104c, dev=803a fwohci0: vendor=104c, dev=803a fwohci0: <1394 Open Host Controller Interface> mem 0xf0906000-0xf09067ff,0xf0900000-0xf0903fff irq 17 at device 6.1 on pci7 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 54 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:08:0d:a0:d1:3f:7d:47 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1090000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode pci7: at device 6.2 (no driver attached) sdhci0: mem 0xf0906800-0xf09068ff irq 18 at device 6.3 on pci7 sdhci0-slot0: 48MHz 4bits 3.3V DMA sdhci0-slot0: ============== REGISTER DUMP ============== sdhci0-slot0: Sys addr: 0x00000000 | Version: 0x00008900 sdhci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci0-slot0: Present: 0x000a0000 | Host ctl: 0x00000000 sdhci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci0-slot0: Caps: 0x01c030b0 | Max curr: 0x00000000 sdhci0-slot0: =========================================== sdhci0: 1 slot(s) allocated sdhci0: [MPSAFE] sdhci0: [ITHREAD] fxp0: port 0x4000-0x403f mem 0xf0905000-0xf0905fff irq 20 at device 8.0 on pci7 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1092 1179 ff10 0002 fxp0: Dynamic Standby mode is enabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:a0:d1:3f:7d:47 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 55 fxp0: [MPSAFE] fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf at device 31.2 on pci0 pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 1.5Gbps PM PMD SSC PSC 32cmd 4ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: ahcich1: at channel 2 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich1: Caps: ichsmb0: port 0x18c0-0x18df irq 19 at device 31.3 on pci0 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 57 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Synaptics Touchpad, device ID 0-00, 3 buttons psm0: config:00006000, flags:00000008, packet size:6 psm0: syncmask:c0, syncbits:00 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 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) ichwd0: timer disabled pmtimer0 on isa0 atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcf000-0xd07ff,0xdf000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 failed to probe at port 0x1f0 irq 14 on isa0 ata1 failed to probe at port 0x170 irq 15 on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 Device configuration finished. Reducing kern.maxvnodes 197888 -> 100000 procfs registered linprocfs registered linsysfs registered lapic: Divisor 2, Frequency 83125615 Hz Timecounter "TSC" frequency 1662512030 Hz quality -100 Timecounters tick every 1.000 msec splash: image decoder found: blank_saver vlan: initialized, using hash tables with chaining vboxdrv: fAsync=0 offMin=0x564 offMax=0x7ee Linux ELF exec handler installed lo0: bpf attached firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hdac0: Probing codec #0... hdac0: HDA Codec #0: Realtek ALC861 hdac0: HDA Codec ID: 0x10ec0861 hdac0: Vendor: 0x10ec hdac0: Device: 0x0861 hdac0: Revision: 0x03 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0xff101179 hdac0: Found audio FG nid=1 startnode=3 endnode=36 total=33 hdac0: Probing codec #1... hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) hdac0: HDA Codec ID: 0x11c13026 hdac0: Vendor: 0x11c1 hdac0: Device: 0x3026 hdac0: Revision: 0x07 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0xff101179 hdac0: Found modem FG nid=1 startnode=2 endnode=40 total=38 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x00000000 NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdac0: nid 11 0x01014110 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 1 hdac0: nid 12 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 13 0x01a19920 as 2 seq 0 Mic Jack jack 1 loc 1 color Pink misc 9 hdac0: nid 14 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 15 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 16 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 17 0x9933012e as 2 seq 14 CD Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 18 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 31 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: nid 32 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 hdac0: Patched pins configuration: hdac0: nid 11 0x01014110 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 1 hdac0: nid 12 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 13 0x01a19920 as 2 seq 0 Mic Jack jack 1 loc 1 color Pink misc 9 hdac0: nid 14 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 15 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 16 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 17 0x9933012e as 2 seq 14 CD Fixed jack 3 loc 25 color Unknown misc 1 hdac0: nid 18 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 31 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: nid 32 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1 [DISABLED] hdac0: 2 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=11 seq=0 hdac0: Association 1 (2) in: hdac0: Pin nid=13 seq=0 hdac0: Pin nid=17 seq=14 hdac0: Tracing association 0 (1) hdac0: Pin 11 traced to DAC 3 hdac0: Association 0 (1) trace succeeded hdac0: Tracing association 1 (2) hdac0: Pin 13 traced to ADC 8 hdac0: Pin 17 traced to ADC 8 hdac0: Association 1 (2) trace succeeded hdac0: Tracing input monitor hdac0: Tracing nid 20 to out hdac0: Tracing nid 21 to out hdac0: nid 21 is input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 13 to out hdac0: Tracing nid 17 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0140 hdac0: 16 20 24 bits, 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x80000000 hdac0: hdac0: nid: 3 hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0140 hdac0: 16 20 24 bits, 48 96 KHz hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: hdac0: nid: 4 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0140 hdac0: 16 20 24 bits, 48 96 KHz hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: hdac0: nid: 5 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0140 hdac0: 16 20 24 bits, 48 96 KHz hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: hdac0: nid: 6 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000405 hdac0: PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0140 hdac0: 16 20 24 bits, 48 96 KHz hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: hdac0: nid: 7 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000605 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0140 hdac0: 16 20 24 bits, 48 96 KHz hdac0: Output amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: hdac0: nid: 8 hdac0: Name: audio input hdac0: Widget cap: 0x0010051b hdac0: PWR STEREO hdac0: Association: 1 (0x00004001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00020140 hdac0: 16 bits, 48 96 KHz hdac0: Input amp: 0x800b0d02 hdac0: mute=1 step=13 size=11 offset=2 hdac0: connections: 6 hdac0: | hdac0: + <- nid=13 [pin: Mic (Pink Jack)] (selected) hdac0: + [DISABLED] <- nid=12 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=15 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=16 [pin: Speaker (None)] [DISABLED] hdac0: + <- nid=17 [pin: CD (Fixed)] hdac0: + <- nid=21 [audio mixer] hdac0: hdac0: nid: 9 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 10 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 11 hdac0: Name: pin: Line-out (Green Jack) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000001f hdac0: ISC TRQD PDC HP OUT hdac0: Pin config: 0x01014110 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 1 hdac0: | hdac0: + <- nid=22 [audio mixer] hdac0: hdac0: nid: 12 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000037 hdac0: ISC TRQD PDC OUT IN hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=25 [audio mixer] [DISABLED] hdac0: hdac0: nid: 13 hdac0: Name: pin: Mic (Pink Jack) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00000337 hdac0: ISC TRQD PDC OUT IN VREF[ 50 HIZ ] hdac0: Pin config: 0x01a19920 hdac0: Pin control: 0x00000021 IN VREFs hdac0: connections: 1 hdac0: | hdac0: + [DISABLED] <- nid=24 [audio mixer] [DISABLED] hdac0: hdac0: nid: 14 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000017 hdac0: ISC TRQD PDC OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=25 [audio mixer] [DISABLED] hdac0: hdac0: nid: 15 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0000033f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=26 [audio mixer] [DISABLED] hdac0: hdac0: nid: 16 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x0000033f hdac0: ISC TRQD PDC HP OUT IN VREF[ 50 HIZ ] hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=27 [audio mixer] [DISABLED] hdac0: hdac0: nid: 17 hdac0: Name: pin: CD (Fixed) hdac0: Widget cap: 0x00400001 hdac0: STEREO hdac0: Association: 1 (0x00004000) hdac0: OSS: cd (cd) hdac0: Pin cap: 0x00000063 hdac0: ISC TRQD IN BAL hdac0: Pin config: 0x9933012e hdac0: Pin control: 0x00000020 IN hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400301 hdac0: DIGITAL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=7 [audio output] [DISABLED] hdac0: hdac0: nid: 19 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 20 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=13 [pin: Mic (Pink Jack)] hdac0: + [DISABLED] <- nid=16 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 21 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020050f hdac0: PWR STEREO hdac0: Association: 1 (0x00004001) hdac0: OSS: mix (mix) hdac0: Output amp: 0x800b0c0c hdac0: mute=1 step=12 size=11 offset=12 hdac0: Input amp: 0x800b170c hdac0: mute=1 step=23 size=11 offset=12 hdac0: connections: 3 hdac0: | hdac0: + <- nid=17 [pin: CD (Fixed)] hdac0: + <- nid=20 [audio mixer] hdac0: + [DISABLED] <- nid=28 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm, mix hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + <- nid=3 [audio output] hdac0: + <- nid=21 [audio mixer] hdac0: hdac0: nid: 23 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=21 [audio mixer] hdac0: hdac0: nid: 24 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=5 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=21 [audio mixer] hdac0: hdac0: nid: 25 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=6 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=21 [audio mixer] hdac0: hdac0: nid: 26 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=6 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=21 [audio mixer] hdac0: + [DISABLED] <- nid=3 [audio output] hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=4 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=6 [audio output] [DISABLED] hdac0: + [DISABLED] <- nid=21 [audio mixer] hdac0: + [DISABLED] <- nid=3 [audio output] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020010b hdac0: STEREO hdac0: Input amp: 0x80000000 hdac0: mute=1 step=0 size=0 offset=0 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=12 [pin: Speaker (None)] [DISABLED] hdac0: + [DISABLED] <- nid=15 [pin: Speaker (None)] [DISABLED] hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 31 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000017 hdac0: ISC TRQD PDC OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=24 [audio mixer] [DISABLED] hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: pin: Speaker (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000017 hdac0: ISC TRQD PDC OUT hdac0: Pin config: 0x411111f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=23 [audio mixer] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: hdac0: nid: 35 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x800b0f0f hdac0: mute=1 step=15 size=11 offset=15 hdac0: hdac0: Processing modem FG cad=1 nid=1... hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0140 pcm0: 16 20 24 bits, 48 96 KHz pcm0: DAC: 3 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x00020140 pcm0: 16 bits, 48 96 KHz pcm0: ADC: 8 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=11 [pin: Line-out (Green Jack)] pcm0: | pcm0: + <- nid=22 [audio mixer] [src: pcm, mix] pcm0: | pcm0: + <- nid=3 [audio output] [src: pcm] pcm0: + <- nid=21 [audio mixer] [src: mix] pcm0: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + <- nid=13 [pin: Mic (Pink Jack)] [src: mic] pcm0: + <- nid=17 [pin: CD (Fixed)] [src: cd] pcm0: + <- nid=21 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=21 [audio mixer] pcm0: | pcm0: + <- nid=17 [pin: CD (Fixed)] [src: cd] pcm0: + <- nid=20 [audio mixer] [src: mic] pcm0: | pcm0: + <- nid=13 [pin: Mic (Pink Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 3 out): mute pcm0: +- ctl 13 (nid 22 in 0): mute pcm0: +- ctl 14 (nid 22 in 1): mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 3 out): mute pcm0: +- ctl 13 (nid 22 in 0): mute pcm0: pcm0: CD Volume (OSS: cd) pcm0: | pcm0: +- ctl 10 (nid 21 in 0): -36/33dB (24 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 6 (nid 8 in 0): -6/33dB (14 steps) + mute pcm0: +- ctl 7 (nid 20 in 0): mute pcm0: +- ctl 11 (nid 21 in 1): -36/33dB (24 steps) + mute pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 31 (nid 35 out): -45/0dB (16 steps) + mute pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 6 (nid 8 in 0): -6/33dB (14 steps) + mute pcm0: pcm0: Input Mix Level (OSS: mix) pcm0: | pcm0: +- ctl 9 (nid 21 out): -36/0dB (13 steps) + mute pcm0: +- ctl 14 (nid 22 in 1): mute pcm0: pcm0: Input Monitoring Level (OSS: igain) pcm0: | pcm0: +- ctl 14 (nid 22 in 1): mute pcm0: pcm0: Enabling Soft PCM volume pcm0: Mixer "vol": pcm0: Mixer "bass": pcm0: Mixer "treble": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "mix": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Soft PCM mixer ENABLED pcm0: EQ Treble/Bass ENABLED pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 1340000, 4000; 0xe6ae1000 -> 1340000 pcm0: sndbuf_setmap 1350000, 4000; 0xe6af1000 -> 1350000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 cbb0: Unsupported card type detected acpi_tz1: _AC0: temperature 72.0 >= setpoint 0.0 acpi_tz1: switched from NONE to _AC0: 72.0C ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ahcich0: SATA connect time=0ms status=00000113 ahcich0: ready wait time=0ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:15:0): SIGNATURE: 0000 (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 battery0: battery initialization start acpi_acad0: acline initialization start ahcich1: AHCI reset... battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ahcich1: SATA offline status=00000004 ahcich1: AHCI reset done: phy reset found no device uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered (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 (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 (probe3:sbp0:0:3:0): Error 22, Unretryable error ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number K82BT89256VD ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus1 target 0 lun 0 pass0: ATA-8 SATA 2.x device pass0: Serial Number K82BT89256VD pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) pass0: Command Queueing enabled GEOM: new disk ada0 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010200 err: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 50 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 msi: Assigning MSI IRQ 256 to local APIC 1 vector 52 hwpmc: TSC/1/64/0x20 IAP/2/40/0x3ff GEOM: ada0s2: geometry does not match label (255h,63s != 16h,63s). Root mount waiting for: usbus4 ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 umass0:3:0:-1: Attached to scbus3 pass1 at umass-sim0 bus 0 scbus3 target 0 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number FUJITSU MH NW98T64278AB pass1: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number FUJITSU MH NW98T64278AB da0: 40.000MB/s transfers da0: 95396MB (195371568 512 byte sectors: 255H 63S/T 12161C) Root mount waiting for: usbus4 Trying to mount root from ufs:/dev/ada0s2a ct_to_ts([2010-04-30 13:24:37]) = 1272633877.000000000 start_init: trying /sbin/init Setting hostuuid: fff00ba0-e13c-11da-a70e-00a0d13f7d47. Setting hostid: 0xea9e3fa3. Entropy harvesting: interrupts ethernet point_to_point ugen2.2: at usbus2 ums0: on usbus2 ums0: 3 buttons and [XYZ] coordinates ID=0 kickstart . Starting file system checks: /dev/ada0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s2a: clean, 56994151 free (350767 frags, 7080423 blocks, 0.3% fragmentation) Mounting local file systems: . Setting hostname: toshi.auburn.protected-networks.net . module_register: module ng_ether already exists! Module ng_ether failed to register: 17 vboxnet0: bpf attached vboxnet0: Ethernet address: 0a:00:27:00:00:00 tap0: bpf attached tap0: Ethernet address: 00:bd:ea:2d:00:00 Starting Network: lo0 fxp0 vboxnet0 tap0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=21 fxp0: flags=8843 metric 0 mtu 1500 options=2009 ether 00:a0:d1:3f:7d:47 media: Ethernet autoselect (100baseTX ) status: active vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 tap0: flags=8843 metric 0 mtu 1500 options=80000 ether 00:a0:d1:3f:7d:48 inet6 2001:470:1f07:4e1::4 prefixlen 64 inet6 fe80::2a0:d1ff:fe3f:7d48%tap0 prefixlen 64 scopeid 0x4 inet 202.12.127.84 netmask 0xfffffff0 broadcast 202.12.127.95 nd6 options=21 Starting devd. Starting Network: vboxnet0. vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 DHCPREQUEST on fxp0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.12 bound to 192.168.1.10 -- renewal in 43200 seconds. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net default: gateway 2001:470:1f07:4e1::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/kde4/lib /usr/local/lib/compat/pkg /usr/local/lib/gcc44 /usr/local/lib/gegl-0.1 /usr/local/lib/graphviz /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 . Starting syslogd. No core dumps found. Additional ABI support: linux . Starting named. Setting date via ntp. ts_to_ct(1272633894.815324675) = [2010-04-30 13:24:54] 30 Apr 13:24:54 ntpdate[1141]: step time server 64.46.156.146 offset 1.042192 sec Starting rpcbind. NFS access cache time=60 Starting statd. Starting lockd. Sleeping thread (tid 100093, pid 1247) owns a non-sleepable lock sched_switch(c6bce480,0,104,eccc5318,12,...) at sched_switch+0xb1 mi_switch(104,0) at mi_switch+0xd6 sleepq_switch(c6bce480,0,c0a42263,260,0,...) at sleepq_switch+0xab sleepq_wait(da11f1e8,4c,c0a454b0,0,0,...) at sleepq_wait+0x3f _sleep(da11f1e8,c616b254,4c,c0a454b0,0,...) at _sleep+0x32a bwait(da11f1e8,4c,c0a454b0,da11f1e8,e8d6c744,...) at bwait+0x66 bufwait(da11f1e8,da11f1e8,da11f1e8,100,0,...) at bufwait+0x28 bufwrite(da11f1e8,0,e8d6c8c0,100,c619f380,...) at bufwrite+0x134 ffs_write(e8d6c8e0,c09afb7e,c396c520,0,0,...) at ffs_write+0x495 VOP_WRITE_APV(c0aeed00,e8d6c8e0,0,0,0,...) at VOP_WRITE_APV+0x96 vnode_pager_generic_putpages(c6dcf330,e8d6c9f0,1000,0,e8d6c990,...) at vnode_pager_generic_putpages+0x16c vop_stdputpages(e8d6c948,e8d6c948,28484000,0,2,...) at vop_stdputpages+0x30 vnode_pager_putpages(c6d86088,e8d6c9f0,1000,5,e8d6c990,...) at vnode_pager_putpages+0x92 vm_pageout_flush(e8d6c9f0,1,5,e8d6ca00,c06c1444,...) at vm_pageout_flush+0x1c0 vm_object_page_collect_flush(5,0,0,0,0,...) at vm_object_page_collect_flush+0x67a vm_object_page_clean(c6d86088,0,0,10000,0,...) at vm_object_page_clean+0x7dc vm_object_sync(c6d86088,0,0,10000000,1,...) at vm_object_sync+0x2aa vm_map_sync(c61a0960,28800000,28800000,1,0,...) at vm_map_sync+0x175 msync(c6bce480,e8d6ccf8,c6cbdb40,e8d6cd38,c,...) at msync+0x6a syscall(e8d6cd38) at syscall+0x1aa Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (65, FreeBSD ELF32, msync), eip = 0x280e987f, esp = 0xbfbfe67c, ebp = 0xbfbfe698 --- panic: sleeping thread cpuid = 1 KDB: enter: panic panic: from debugger cpuid = 1 KDB: stack backtrace: Physical memory: 3049 MB Dumping 99 MB: 84 68 52 36 20 4 ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident TOSHI-SMP machine i386 cpu I686_CPU makeoptions DEBUG=-g options ATA_CAM options GEOM_JOURNAL options P1003_1B_MQUEUE options X86BIOS options VFS_AIO options UDF_ICONV options NTFS_ICONV options MSDOSFS_ICONV options CD9660_ICONV options LIBICONV options LIBMCHAIN options NETSMB options SMBFS options UDF options NTFS options LINSYSFS options LINPROCFS options COMPAT_LINUX options NETGRAPH_SOCKET options NETGRAPH_ETHER options NETGRAPH_BLUETOOTH_UBT options NETGRAPH_BLUETOOTH_SOCKET options NETGRAPH_BLUETOOTH_L2CAP options NETGRAPH_BLUETOOTH_HCI options NETGRAPH_BLUETOOTH options NETGRAPH options ENABLE_ALART options VESA options USB_DEBUG options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options ATA_STATIC_ID options SMP 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=128 options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFSLOCKD options NFSCLIENT 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 pci device atadisk device atapicd device hptiop device scbus device da device cd device pass 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 miibus device fxp device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr 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 umass device ums device uslcom device firewire device sbp device dcons device dcons_crom device atapicam device atacore device atapci device ahci device ada device udbp device smbus device ichsmb device smb device acpi_video device ichwd device drm device i915drm device smbios device blank_saver device lindev device snd_hda device sound device crypto device tap device coretemp device wpifw device mmc device mmcsd device sdhci device hwpmc device cpuctl device nvram device dpms ------------------------------------------------------------------------ ddb capture buffer --------------000402090607000902040502-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 19:38:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D7DA1065672 for ; Fri, 30 Apr 2010 19:38:19 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD918FC30 for ; Fri, 30 Apr 2010 19:38:18 +0000 (UTC) Received: by pxi17 with SMTP id 17so368478pxi.13 for ; Fri, 30 Apr 2010 12:38:13 -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=zG6Adw0S2rXRq2AetfTyo6Eeo3v04sfIKi7jmvHfMng=; b=CNm3EKFbHItbjUOk2LRly/oHTtUd1SaIlsJRlUtb3WMlfXAWp2bK4qhzfpMngjJogz 4NsirchYIxnP6YZx6qtpkxqlE+GLpFP24P2LaolEfsCMzZi2yR4OXCa8OPpcwcfJGkoO jjaM5gZ1drWxd4LN04giqG1mTNsQWBtF1tuwE= 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=Zs4x0oZ58p855yK7Lpz6t5vaSIBFqil8A6sNUfHnljyey1GnsIlRjX6xJEKWuY7ojM Hhmw9fnebh1XiAgCvn8WvPnYPsi8QnBjl6ivsAzAZpiVLjuGn+ErlhaHkkHlB2Ut44Lj +2CXXeur3ZGHsPuvmMuV35Od1+z2eatCn9eI8= MIME-Version: 1.0 Received: by 10.141.188.8 with SMTP id q8mr1311054rvp.140.1272656293309; Fri, 30 Apr 2010 12:38:13 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.141.45.11 with HTTP; Fri, 30 Apr 2010 12:38:13 -0700 (PDT) In-Reply-To: <4BDB186E.4070309@protected-networks.net> References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> <4BDB186E.4070309@protected-networks.net> Date: Fri, 30 Apr 2010 12:38:13 -0700 X-Google-Sender-Auth: fd2026d844558d20 Message-ID: From: "K. Macy" To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 19:38:19 -0000 > Sadly, it doesn't do it for me .. lockd start-up causes a panic on a > "sleeping thread". Do I need to do a buildworld as well as kernel? > We're calling vm_pageout_flush with the page queue lock held in vm_object_page_collect_flush. I'll have a fix in soon. Thanks, Kip From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 20:22:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14FBE106564A for ; Fri, 30 Apr 2010 20:22:22 +0000 (UTC) (envelope-from p.massat@gmail.com) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by mx1.freebsd.org (Postfix) with ESMTP id B8ABD8FC14 for ; Fri, 30 Apr 2010 20:22:21 +0000 (UTC) Received: by ywh13 with SMTP id 13so274234ywh.8 for ; Fri, 30 Apr 2010 13:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=T5MOWrtkqTYJkKNzGLgijyrivw43iVbvDg2aEl3xL6Q=; b=sTgqE36GIiSTCM1MUmRJsFLAm4u2MINqLlNvuOJB04rpoMAkQM+yqqZB1PIia8shDV a2Jp/QoG6B70SDGi9hpalI9cLm0WnWp4eNtWpI/8qu/ZBneSbB8+mSu1BUIRz8q2Sw9s bCpIc+HqZtHFHj6mqn7LB1iDhYa7vfI3dCnKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=gaEQh+zvwBvKQETYm5kI9UFWtHL4T8SQv8RHGzZNpsr7JYOf7WCVh4krcY3uz1FWgG tSjoWPBI4YhciVP6qoKb1YdwuowwkWmHrr7bSKVV1Uwcpb+nCmExcKP6KQIDuiW8aSN5 OLIiHJRRyqJ6+jYw21ySKFj+2Vfi87FAI0fKc= Received: by 10.91.168.7 with SMTP id v7mr694657ago.87.1272658935210; Fri, 30 Apr 2010 13:22:15 -0700 (PDT) MIME-Version: 1.0 Sender: p.massat@gmail.com Received: by 10.100.165.19 with HTTP; Fri, 30 Apr 2010 13:21:53 -0700 (PDT) In-Reply-To: <80219502-EDAD-4745-A89B-813601D1C15E@gmail.com> References: <80219502-EDAD-4745-A89B-813601D1C15E@gmail.com> From: Pierre Massat Date: Fri, 30 Apr 2010 22:21:53 +0200 X-Google-Sender-Auth: 93cbf7636f6f70e8 Message-ID: To: "Jason J. W. Williams" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-current@freebsd.org" Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 20:22:22 -0000 On Fri, Apr 30, 2010 at 3:14 PM, Jason J. W. Williams wrote: > What was the iowait when the update hangs occurred? Also, what was the box's > uptime approx when it happened? Have you surpassed that amount of uptime > since? Were you able to DTrace MySQL to see what func was hanging? The iowait was 0.0% when the hangs occurred and the uptime of the box was something around 120 days and it's currently 166 days (I only stopped MySQL daemon which was around 60 days of uptime and now 46 days). Unfortunately, I wasn't able to dtrace MySQL. -- Pierre Massat From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 20:23:03 2010 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B81F11065673 for ; Fri, 30 Apr 2010 20:23:03 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 696C38FC21 for ; Fri, 30 Apr 2010 20:23:03 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3UKN1gC093955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 13:23:02 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <4BDB3C31.4050709@sippysoft.com> Date: Fri, 30 Apr 2010 13:23:13 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "current@freebsd.org" , freebsd-net@FreeBSD.ORG Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 30 Apr 2010 21:05:29 +0000 Cc: Subject: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 20:23:03 -0000 Hi, Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to set length of the outgoing packets queue. The default value for that parameter is only 50, which is pretty low especially for the cases when the system handles lot of small packets and can cause ENOBUFS in applications under the load. The following patch makes IFQ_MAXLEN a tunable. I am also tempted to bump the default value for IFQ_MAXLEN 10-fold, but would like to hear what do people think about it first. http://sobomax.sippysoft.com/IFQ_MAXLEN.diff -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 21:21:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 387D1106564A for ; Fri, 30 Apr 2010 21:21:47 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by mx1.freebsd.org (Postfix) with ESMTP id E24008FC08 for ; Fri, 30 Apr 2010 21:21:46 +0000 (UTC) Received: by gxk26 with SMTP id 26so96139gxk.13 for ; Fri, 30 Apr 2010 14:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=E2cCXcqeBQTS1Pv2bkNyCgUdgBMvC5Bco5yYX0V7Hyc=; b=odkT2i2vgEulbYWccoddB4BGxGDnSz39TWwYnFYJWSNYBPdc7GKRAr0Ayb82S9h7T1 4hqumGRiHMtxs/LLWyfgf4ToYsT4QVCgpB+O7HQuSF4nRObeoD0ZEoTS7zf08ruVV8yk CDjNrYMln/W4MQwEBH+DHPfXLHX2p6yDZ6T/g= 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 :content-transfer-encoding; b=MOBi7bdDLpCOoBPvIUc6/9bvS1x5E2Tqfa4YnYQ9Bnk9kZB0HnRdVgtw6TN12Dpcoz pek2TIW+bAad/GmH/u9ZVNzRlJTNJkYMW3xkbIF1FI2ydQncHdmLsFtKJsM8OOvvADrt pdz18Dcfiwkik8UHef0VAgY2zAA/J+Fxabf5U= MIME-Version: 1.0 Received: by 10.229.212.133 with SMTP id gs5mr549008qcb.89.1272662500760; Fri, 30 Apr 2010 14:21:40 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.231.18 with HTTP; Fri, 30 Apr 2010 14:21:40 -0700 (PDT) In-Reply-To: References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> <4BDB186E.4070309@protected-networks.net> Date: Fri, 30 Apr 2010 14:21:40 -0700 X-Google-Sender-Auth: 3419358eeac558e1 Message-ID: From: "K. Macy" To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 21:21:47 -0000 On Fri, Apr 30, 2010 at 12:38 PM, K. Macy wrote: >> Sadly, it doesn't do it for me .. lockd start-up causes a panic on a >> "sleeping thread". Do I need to do a buildworld as well as kernel? >> > > We're calling vm_pageout_flush with the page queue lock held in > vm_object_page_collect_flush. =A0I'll have a fix in soon. Please try updating to 207451 Thanks, Kip From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 21:33:45 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 496321065674; Fri, 30 Apr 2010 21:33:45 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 113E18FC0C; Fri, 30 Apr 2010 21:33:44 +0000 (UTC) Received: by pvg3 with SMTP id 3so417528pvg.13 for ; Fri, 30 Apr 2010 14:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ihlNvhArHWH9lY2wHe8Ivv7flaRg2pdDQR+vEmsurOs=; b=rKSq8PeJD18CwauT1ZqNr1IKPEWM5PIvPEMKcd2eH+fTxKwDWsMQzMjt/6WSKBkQ5k yNt+1GIKeEDoB3ctV93DiCVYn4kGZi0m9LqT4sklPDM+Y50iXdzUV6H8P6XEOpaCoOwl 1Ku653lqHESVxXK6DGum6hhKGH29g++s5LeUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MxSuilOClrKTODpjkieHsthwy6BqT6aWWqBZf1v1lEt4G3b+PPxuKX/7ywhsFdaZHf kNz1rRuCYu5997xB2Kz8Iw6GNvxE247g5C1jBthqgMLh/oVwCj+pscp4SdZHq1Kd0m5r /zFLLdldJbWvve11RdDubxnTmiYC0TXX2gj94= Received: by 10.114.164.39 with SMTP id m39mr12425772wae.56.1272663222057; Fri, 30 Apr 2010 14:33:42 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id c14sm10627441waa.13.2010.04.30.14.33.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Apr 2010 14:33:41 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BDB4CAE.20006@elischer.org> Date: Fri, 30 Apr 2010 14:33:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Maxim Sobolev References: <4BDB3C31.4050709@sippysoft.com> In-Reply-To: <4BDB3C31.4050709@sippysoft.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.ORG, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 21:33:45 -0000 On 4/30/10 1:23 PM, Maxim Sobolev wrote: > Hi, > > Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > set length of the outgoing packets queue. The default value for that > parameter is only 50, which is pretty low especially for the cases when > the system handles lot of small packets and can cause ENOBUFS in > applications under the load. The following patch makes IFQ_MAXLEN a > tunable. I am also tempted to bump the default value for IFQ_MAXLEN > 10-fold, but would like to hear what do people think about it first. > > http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > > -Maxim > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" so just tunable? not a sysctl :-) patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen (do different vimages want a different value?) From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 21:39:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAB62106566C for ; Fri, 30 Apr 2010 21:39:45 +0000 (UTC) (envelope-from jasonjwwilliams@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDF6A8FC0A for ; Fri, 30 Apr 2010 21:39:45 +0000 (UTC) Received: by pxi17 with SMTP id 17so424331pxi.13 for ; Fri, 30 Apr 2010 14:39:40 -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=gbpjNpjXQWJ3SQTMTFNGJ2FaPCvS34HVmENgKhzfdVs=; b=GN5NNFjwmwwEDAj4H71Ni8Qrh4KHVPj0dzHTS1pNXFZyOtMmOwyyHzs00+fS+AIEbA 3OU2oEYf6z52GJGrWFZP6HjglnraI9Ko840/D0sPhCRQnFe1XTOL17vawnP9/exA9YGk keMdaNpWpfBsTO2CqRHeE2ytfat2alh0RsXaI= 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=w6Vk7Eq/fsVEbQWC2aecCRBVYXf/Ww0a21PuPAs7ocOztQZJuR9DJdlFAEtf94cCyw ORkTMSxjukJuclksV216NrimcQxRvpbIu8C+oHu7Wy19Cl1VULYa6rfXp2DKOMvMCk77 uthIrCPT9xMU14wK/UOmMDNlM8stphiP1Twbc= MIME-Version: 1.0 Received: by 10.141.107.15 with SMTP id j15mr1345197rvm.288.1272663580552; Fri, 30 Apr 2010 14:39:40 -0700 (PDT) Received: by 10.141.27.20 with HTTP; Fri, 30 Apr 2010 14:39:40 -0700 (PDT) In-Reply-To: References: <80219502-EDAD-4745-A89B-813601D1C15E@gmail.com> Date: Fri, 30 Apr 2010 15:39:40 -0600 Message-ID: From: "Jason J. W. Williams" To: Pierre Massat Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current@freebsd.org" Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 21:39:46 -0000 Hi Pierre, By chance did you attempt to write a test file to the ZFS filesystem holding the database and logs? Just curious if ZFS was hung since a MySQL restart corrected it. Thank you for your help. -J On Fri, Apr 30, 2010 at 2:21 PM, Pierre Massat wrote: > On Fri, Apr 30, 2010 at 3:14 PM, Jason J. W. Williams > wrote: >> What was the iowait when the update hangs occurred? Also, what was the box's >> uptime approx when it happened? Have you surpassed that amount of uptime >> since? Were you able to DTrace MySQL to see what func was hanging? > > The iowait was 0.0% when the hangs occurred and the uptime of the box > was something around 120 days and it's currently 166 days (I only > stopped MySQL daemon which was around 60 days of uptime and now 46 > days). > > Unfortunately, I wasn't able to dtrace MySQL. > > -- > Pierre Massat > From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 21:42:36 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 925D41065672 for ; Fri, 30 Apr 2010 21:42:36 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE2B8FC19 for ; Fri, 30 Apr 2010 21:42:36 +0000 (UTC) Received: from T61p.pozo.com (t41p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.4/8.14.4) with ESMTP id o3ULgKV0002085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Apr 2010 14:42:20 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201004302142.o3ULgKV0002085@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Apr 2010 14:42:14 -0700 To: kmacy@freebsd.org, Michael Butler From: Manfred Antar In-Reply-To: References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> <4BDB186E.4070309@protected-networks.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-100.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, USER_IN_WHITELIST autolearn=no version=3.3.1, No X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: o3ULgKV0002085 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: Kostik Belousov , current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 21:42:36 -0000 At 02:21 PM 4/30/2010, K. Macy wrote: >On Fri, Apr 30, 2010 at 12:38 PM, K. Macy wrote: >>> Sadly, it doesn't do it for me .. lockd start-up causes a panic on a >>> "sleeping thread". Do I need to do a buildworld as well as kernel? >>> >> >> We're calling vm_pageout_flush with the page queue lock held in >> vm_object_page_collect_flush. I'll have a fix in soon. > >Please try updating to 207451 > >Thanks, >Kip >_______________________________________________ >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" > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. I'm getting this from just rebuilt kernel: Starting dbus. Starting hald. Configuring syscons: blanktime. Starting clamav_clamd. Starting clamav_freshclam. Waiting for clamd socket.. Starting clamav_milter. Waiting for clamav-milter socket.. 60.. Starting denyhosts. Sleeping thread (tid 100058, pid 19) owns a non-sleepable lock sched_switch(c7174d80,0,104,a3b9b2bc,5b,...) at sched_switch+0x1df mi_switch(104,0,c7174d80,0,db35b4f4,...) at mi_switch+0x12a sleepq_switch(c7174d80,0,c0b157ee,260,0,...) at sleepq_switch+0xcb sleepq_wait(db317b94,4c,c0b18293,0,0,...) at sleepq_wait+0x39 _sleep(db317b94,c70066dc,4c,c0b18293,0,...) at _sleep+0x2a2 bwait(db317b94,4c,c0b18293,db317b94,db35b5a0,...) at bwait+0x8f bufwait(db317b94,0,0,0,0,...) at bufwait+0x28 breadn(c7836220,1,0,4000,0,...) at breadn+0xf3 bread(c7836220,1,0,4000,0,...) at bread+0x4c ffs_balloc_ufs2(c7836220,6000,0,1000,c700bc00,...) at ffs_balloc_ufs2+0xe71 ffs_write(db35b930,c0bbb1ec,0,0,db35b874,...) at ffs_write+0x3f5 VOP_WRITE_APV(c0b87ae0,db35b930,0,0,2000,...) at VOP_WRITE_APV+0xa6 vnode_pager_generic_putpages(c7836220,db35ba40,1000,c,db35b9f0,...) at vnode_pager_generic_putpages+0x300 vop_stdputpages(db35b9a0,db35b9cc,c08e75e9,c0b87ae0,db35b9a0,...) at vop_stdputpages+0x30 VOP_PUTPAGES_APV(c0b87ae0,db35b9a0,c066dc10,c7261c5c,c0b9ce00,...) at VOP_PUTPAGES_APV+0x47 vnode_pager_putpages(c7835c38,db35ba40,1,c,db35b9f0,...) at vnode_pager_putpages+0xa9 vm_pageout_flush(db35ba40,1,c,c08dd65c,0,...) at vm_pageout_flush+0x1c7 vm_object_page_collect_flush(c,6,0,82b,c7836220,...) at vm_object_page_collect_flush+0x5f3 vm_object_page_clean(c7835c38,0,0,0,0,...) at vm_object_page_clean+0x2ef vfs_msync(c7414ca8,2,2,c0b9cca0,c7489550,...) at vfs_msync+0x21a sync_fsync(db35bc74,db35bc94,c071062d,c0b76640,db35bc74,...) at sync_fsync+0x22a VOP_FSYNC_APV(c0b76640,db35bc74,c0b19a0d,6a5,c063e92e,...) at VOP_FSYNC_APV+0x42 sync_vnode(c0bbe4b4,c0bbe4a0,3e8,c73f8550,4e20,...) at sync_vnode+0x1bd sched_sync(0,db35bd38,fffa7f7f,ffffffff,d6fbf6ad,...) at sched_sync+0x2c2 fork_exit(c0710760,0,db35bd38) at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xdb35bd70, ebp = 0 --- panic: sleeping thread KDB: enter: panic [ thread pid 1789 tid 100114 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> ================================== || null@pozo.com || || Ph. (415) 681-6235 || ================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 22:00:12 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE913106566B; Fri, 30 Apr 2010 22:00:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id A90028FC15; Fri, 30 Apr 2010 22:00:11 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3UM08Ib094512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 15:00:09 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BDB52F4.2010100@FreeBSD.org> Date: Fri, 30 Apr 2010 15:00:20 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Julian Elischer References: <4BDB3C31.4050709@sippysoft.com> <4BDB4CAE.20006@elischer.org> In-Reply-To: <4BDB4CAE.20006@elischer.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 22:00:12 -0000 Julian Elischer wrote: > On 4/30/10 1:23 PM, Maxim Sobolev wrote: >> Hi, >> >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to >> set length of the outgoing packets queue. The default value for that >> parameter is only 50, which is pretty low especially for the cases when >> the system handles lot of small packets and can cause ENOBUFS in >> applications under the load. The following patch makes IFQ_MAXLEN a >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN >> 10-fold, but would like to hear what do people think about it first. >> >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > > so just tunable? not a sysctl :-) The sysctl would require much bigger rewrite. As long as I understand the value is now cached in many instances of the ifnet structure, and some drivers even use their own queue length instead of IFQ_MAXLEN. Therefore, even if I make this parameter a sysctl one would have to destroy interface and create it again in order for the change to have an effect. Therefore, keeping it tunable would be less confusing. > patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen > (do different vimages want a different value?) I am not quite sure about that. AFAIK vimage is more high-level thing, while this parameter controls queue length between kernel and hardware interface driver. vimage lies above that. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 22:34:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 226B4106566B for ; Fri, 30 Apr 2010 22:34:01 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id C7B1E8FC1A for ; Fri, 30 Apr 2010 22:34:00 +0000 (UTC) Received: by qyk11 with SMTP id 11so794509qyk.13 for ; Fri, 30 Apr 2010 15:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gWugYZUsIHZSxoJBvMxCjWxX/N57Vp7wQuCc6878yok=; b=Bm6vICJuSvx/AiEoLBalLMgQvBVF4EsGm2FK0LSEH8h1cLltdnX/oiL6x9O1DONYgw qcCwHNK3oAcgHSH2HC1zcn3LZoiB7k3yWcpf/wt3ZBgsAefMPBgnxjWuDQUOMX0ZZ6Y9 fplfNPeiGE3WBeMRIlpdW93DbSgCv2dQBWNeA= 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 :content-transfer-encoding; b=KwNdFnREfJV2hnNy4jj6pTCD4w1Jrz2Q7eG9MT8r8+Lm5uUqojs4/7lwDvkdyYKJ+x dtYVKwCOjySJHdfCDR4SXXKBGWsWinENvhxWCVgn7CHKzmz1uS41+U6vgQ5hpmAZpTri L5a/SON3pHMiKNt7KMGf7UvFpJkQvardRVsrg= MIME-Version: 1.0 Received: by 10.229.223.140 with SMTP id ik12mr619677qcb.98.1272666837624; Fri, 30 Apr 2010 15:33:57 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.231.18 with HTTP; Fri, 30 Apr 2010 15:33:57 -0700 (PDT) In-Reply-To: <201004302142.o3ULgKV0002085@pozo.com> References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> <4BDB186E.4070309@protected-networks.net> <201004302142.o3ULgKV0002085@pozo.com> Date: Fri, 30 Apr 2010 15:33:57 -0700 X-Google-Sender-Auth: 4efa5da110bec2a5 Message-ID: From: "K. Macy" To: Manfred Antar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Michael Butler , current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 22:34:01 -0000 How much memory do you have? I haven't been checking code in without testing it, but clearly my system behaves a bit differently. Please try 207452. Thanks, Kip On Fri, Apr 30, 2010 at 2:42 PM, Manfred Antar wrote: > At 02:21 PM 4/30/2010, K. Macy wrote: >>On Fri, Apr 30, 2010 at 12:38 PM, K. Macy wrote: >>>> Sadly, it doesn't do it for me .. lockd start-up causes a panic on a >>>> "sleeping thread". Do I need to do a buildworld as well as kernel? >>>> >>> >>> We're calling vm_pageout_flush with the page queue lock held in >>> vm_object_page_collect_flush. =A0I'll have a fix in soon. >> >>Please try updating to 207451 >> >>Thanks, >>Kip >>_______________________________________________ >>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= " >> >>-- >>This message has been scanned for viruses and >>dangerous content by MailScanner, and is >>believed to be clean. > > I'm getting this from just rebuilt kernel: > > Starting dbus. > Starting hald. > Configuring syscons: blanktime. > Starting clamav_clamd. > Starting clamav_freshclam. > Waiting for clamd socket.. > Starting clamav_milter. > Waiting for clamav-milter socket.. 60.. > Starting denyhosts. > Sleeping thread (tid 100058, pid 19) owns a non-sleepable lock > sched_switch(c7174d80,0,104,a3b9b2bc,5b,...) at sched_switch+0x1df > mi_switch(104,0,c7174d80,0,db35b4f4,...) at mi_switch+0x12a > sleepq_switch(c7174d80,0,c0b157ee,260,0,...) at sleepq_switch+0xcb > sleepq_wait(db317b94,4c,c0b18293,0,0,...) at sleepq_wait+0x39 > _sleep(db317b94,c70066dc,4c,c0b18293,0,...) at _sleep+0x2a2 > bwait(db317b94,4c,c0b18293,db317b94,db35b5a0,...) at bwait+0x8f > bufwait(db317b94,0,0,0,0,...) at bufwait+0x28 > breadn(c7836220,1,0,4000,0,...) at breadn+0xf3 > bread(c7836220,1,0,4000,0,...) at bread+0x4c > ffs_balloc_ufs2(c7836220,6000,0,1000,c700bc00,...) at ffs_balloc_ufs2+0xe= 71 > ffs_write(db35b930,c0bbb1ec,0,0,db35b874,...) at ffs_write+0x3f5 > VOP_WRITE_APV(c0b87ae0,db35b930,0,0,2000,...) at VOP_WRITE_APV+0xa6 > vnode_pager_generic_putpages(c7836220,db35ba40,1000,c,db35b9f0,...) at vn= ode_pager_generic_putpages+0x300 > vop_stdputpages(db35b9a0,db35b9cc,c08e75e9,c0b87ae0,db35b9a0,...) at vop_= stdputpages+0x30 > VOP_PUTPAGES_APV(c0b87ae0,db35b9a0,c066dc10,c7261c5c,c0b9ce00,...) at VOP= _PUTPAGES_APV+0x47 > vnode_pager_putpages(c7835c38,db35ba40,1,c,db35b9f0,...) at vnode_pager_p= utpages+0xa9 > vm_pageout_flush(db35ba40,1,c,c08dd65c,0,...) at vm_pageout_flush+0x1c7 > vm_object_page_collect_flush(c,6,0,82b,c7836220,...) at vm_object_page_co= llect_flush+0x5f3 > vm_object_page_clean(c7835c38,0,0,0,0,...) at vm_object_page_clean+0x2ef > vfs_msync(c7414ca8,2,2,c0b9cca0,c7489550,...) at vfs_msync+0x21a > sync_fsync(db35bc74,db35bc94,c071062d,c0b76640,db35bc74,...) at sync_fsyn= c+0x22a > VOP_FSYNC_APV(c0b76640,db35bc74,c0b19a0d,6a5,c063e92e,...) at VOP_FSYNC_A= PV+0x42 > sync_vnode(c0bbe4b4,c0bbe4a0,3e8,c73f8550,4e20,...) at sync_vnode+0x1bd > sched_sync(0,db35bd38,fffa7f7f,ffffffff,d6fbf6ad,...) at sched_sync+0x2c2 > fork_exit(c0710760,0,db35bd38) at fork_exit+0x90 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xdb35bd70, ebp =3D 0 --- > panic: sleeping thread > KDB: enter: panic > [ thread pid 1789 tid 100114 ] > Stopped at =A0 =A0 =A0kdb_enter+0x3a: movl =A0 =A0$0,kdb_why > db> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > || =A0 =A0 =A0null@pozo.com =A0 =A0 =A0 =A0 =A0 || > || =A0 =A0 =A0Ph. (415) 681-6235 =A0 =A0 =A0|| > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 22:52:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C8A8106566B for ; Fri, 30 Apr 2010 22:52:14 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id E9BE78FC0C for ; Fri, 30 Apr 2010 22:52:13 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 9D8D06107; Fri, 30 Apr 2010 18:52:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1272667932; bh=GKJn8/S82FNoFFFgf0b3oeb67ZgCeOyjo80n1naSr4Q=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=o86TOXTzQi1bKP6a2oULqGe3fvVTs1bUFRfHZk9KMqxeqwwUrZYSgTd3NRL4CdT+C x+PS1Kcxcku0oR5q5NLlbCt2wtcf9u/lSRMeA0kA16JlmSsemjlwhf3EmX3TR3d DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=hRlk99puykU3yYfiT9OcSg777rIPLdSGib/HuIEtt/ptbSUR77g88Cc7Sjzxc1OgO zBiLaVpsRzIZ5uHp5M1s7+FImPRRUjRhaVj4NhxiaCO4mFm0613Eex9ZnGhkLDV Message-ID: <4BDB5F10.8030105@protected-networks.net> Date: Fri, 30 Apr 2010 18:52:00 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100422 Thunderbird/3.0.4 MIME-Version: 1.0 To: kmacy@freebsd.org References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430162732.GP2391@deviant.kiev.zoral.com.ua> <4BDB186E.4070309@protected-networks.net> <201004302142.o3ULgKV0002085@pozo.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 22:52:14 -0000 On 04/30/10 18:33, K. Macy wrote: > How much memory do you have? I haven't been checking code in without > testing it, but clearly my system behaves a bit differently. > > Please try 207452. Building this now although .. > On Fri, Apr 30, 2010 at 2:42 PM, Manfred Antar wrote: >> At 02:21 PM 4/30/2010, K. Macy wrote: >>> On Fri, Apr 30, 2010 at 12:38 PM, K. Macy wrote: >>>>> Sadly, it doesn't do it for me .. lockd start-up causes a panic on a >>>>> "sleeping thread". Do I need to do a buildworld as well as kernel? >>>>> >>>> >>>> We're calling vm_pageout_flush with the page queue lock held in >>>> vm_object_page_collect_flush. I'll have a fix in soon. >>> >>> Please try updating to 207451 .. mine worked with this in place. For reference, 4GB RAM of which only 2990MB is usable on a Toshiba A105 laptop :-( imb From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 23:12:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90CFF106564A for ; Fri, 30 Apr 2010 23:12:43 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id 28FC38FC08 for ; Fri, 30 Apr 2010 23:12:42 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20100430231241.ZQKK25277.nskntmtas04p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Fri, 30 Apr 2010 23:12:41 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100430231241.YWMA1978.nskntotgx03p.mx.bigpond.com@duncan.reilly.home>; Fri, 30 Apr 2010 23:12:41 +0000 Date: Sat, 1 May 2010 09:12:41 +1000 From: Andrew Reilly To: David Wolfskill , current@freebsd.org Message-ID: <20100430231240.GA28805@duncan.reilly.home> References: <20100430161953.GW96847@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100430161953.GW96847@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Fri, 30 Apr 2010 23:12:41 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4BDB63E9.0095,ss=1,fgs=0 X-SIH-MSG-ID: rRgzEtX7TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rVMfpRsM6kxD1MJhiGNGAiaajlTY3Rs9mK Cc: Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Apr 2010 23:12:43 -0000 Hi all, I'm not sure if it's related (I get my src via csup, so I don't have svn reveision numbers), but I upgraded about 16 hours ago again a few hours after that, and my two-core AMD64 system has been (seemingly) quite unstable. I've had a few boot cycles that have failed and dumped me out into kdb, rebooting through single-user (to check file systems) seems to get me "up", but my logs are completely full of: Calling uiomove() with the following non-sleepable locks held: exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xffffffff80e60a00) locked @ /nb/src/sys/vm/vm_pageout.c:452 exclusive sleep mutex page lock (page lock) r = 0 (0xffffffff80e59e00) locked @ /nb/src/sys/vm/vm_pageout.c:451 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c2 uiomove() at uiomove+0x52 ffs_write() at ffs_write+0x32d VOP_WRITE_APV() at VOP_WRITE_APV+0x103 vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5 vnode_pager_putpages() at vnode_pager_putpages+0x97 vm_pageout_flush() at vm_pageout_flush+0x1ad vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470 vm_object_page_clean() at vm_object_page_clean+0x408 vfs_msync() at vfs_msync+0xef sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803ebbad30, rbp = 0 --- or this slightly different version: uma_zalloc_arg: zone "g_bio" with the following non-sleepable locks held: exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xffffffff80e60a00) locked @ /nb/src/sys/kern/vfs_bio.c:3571 exclusive sleep mutex page lock (page lock) r = 0 (0xffffffff80e5fb80) locked @ /nb/src/sys/vm/vm_pageout.c:451 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_warn() at witness_warn+0x2c2 uma_zalloc_arg() at uma_zalloc_arg+0x335 g_vfs_strategy() at g_vfs_strategy+0x28 ufs_strategy() at ufs_strategy+0x45 bufstrategy() at bufstrategy+0x43 bufwrite() at bufwrite+0x108 cluster_wbuild() at cluster_wbuild+0x1cd cluster_write() at cluster_write+0x2f5 ffs_write() at ffs_write+0x66b VOP_WRITE_APV() at VOP_WRITE_APV+0x103 vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5 vnode_pager_putpages() at vnode_pager_putpages+0x97 vm_pageout_flush() at vm_pageout_flush+0x1ad vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470 vm_object_page_clean() at vm_object_page_clean+0x19d vfs_msync() at vfs_msync+0xef sync_fsync() at sync_fsync+0x12a sync_vnode() at sync_vnode+0x157 sched_sync() at sched_sync+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803ebbad30, rbp = 0 --- I'll be doing another csup/rebuild ASAP, in the hope of picking up the fixes mentioned here. Just thought I'd add another "me too" and a bit of data. Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Fri Apr 30 23:42:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3222E106564A for ; Fri, 30 Apr 2010 23:42:18 +0000 (UTC) (envelope-from kmatthew.macy@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id DC0DD8FC13 for ; Fri, 30 Apr 2010 23:42:17 +0000 (UTC) Received: by qyk11 with SMTP id 11so865420qyk.13 for ; Fri, 30 Apr 2010 16:42:13 -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:content-transfer-encoding; bh=hnUWI2hnKny0CD0pEbGc1tY6+1W5StzMdIzaxnF2O6E=; b=Qw7cYqj7hZaLnWLDShEfFa9eMHk+RF4+Lfnm4wvW5CGtEpPNL7yrVqIGmge3xnFMJQ h9Z/HW6+JXPI0msJzPDi6V2VA1hTPpI6gOJ6I1679+CjoYc2J5W/3M8gPxRK6/4hPPoY SNPk7ar0JpRt7HBgZUv3xRoDd4yZ/CHmwkmUE= 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 :content-transfer-encoding; b=CpnhB8oCf1P3FZHQvyQQkyhYtd8JQJT5uTIqkATz6R3r/98kvzaKPFSzfHguM1XeNa hJiemujTJsQHveTRpfUnGIEk080SbRJ0PIN8EF7m2kvaos6IwtYfqGJJ1hy27xffNgHW IIfXIkaGIBr08jTEJshyuzhoRYM9+Xb2t260k= MIME-Version: 1.0 Received: by 10.229.223.140 with SMTP id ik12mr647544qcb.98.1272670932851; Fri, 30 Apr 2010 16:42:12 -0700 (PDT) Sender: kmatthew.macy@gmail.com Received: by 10.229.231.18 with HTTP; Fri, 30 Apr 2010 16:42:12 -0700 (PDT) In-Reply-To: <20100430231240.GA28805@duncan.reilly.home> References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430231240.GA28805@duncan.reilly.home> Date: Fri, 30 Apr 2010 16:42:12 -0700 X-Google-Sender-Auth: ce6f6de7cac3c02d Message-ID: From: "K. Macy" To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 23:42:18 -0000 Hi Andrew, Does FBSDID get expanded when checking out with csup? You should see: __FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30 22:31:37Z kmacy $"); line 451 is part of a KASSERT on this version. Cheers, Kip On Fri, Apr 30, 2010 at 4:12 PM, Andrew Reilly wro= te: > Hi all, > > I'm not sure if it's related (I get my src via csup, so I don't > have svn reveision numbers), but I upgraded about 16 hours ago > again a few hours after that, and my two-core AMD64 system has > been (seemingly) quite unstable. =A0I've had a few boot cycles > that have failed and dumped me out into kdb, rebooting through > single-user (to check file systems) seems to get me "up", but my > logs are completely full of: > > Calling uiomove() with the following non-sleepable locks held: > exclusive sleep mutex vm page queue mutex (vm page queue mutex) r =3D 0 (= 0xffffffff80e60a00) locked @ /nb/src/sys/vm/vm_pageout.c:452 > exclusive sleep mutex page lock (page lock) r =3D 0 (0xffffffff80e59e00) = locked @ /nb/src/sys/vm/vm_pageout.c:451 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_warn() at witness_warn+0x2c2 > uiomove() at uiomove+0x52 > ffs_write() at ffs_write+0x32d > VOP_WRITE_APV() at VOP_WRITE_APV+0x103 > vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5 > vnode_pager_putpages() at vnode_pager_putpages+0x97 > vm_pageout_flush() at vm_pageout_flush+0x1ad > vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470 > vm_object_page_clean() at vm_object_page_clean+0x408 > vfs_msync() at vfs_msync+0xef > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff803ebbad30, rbp =3D 0 --- > > or this slightly different version: > > uma_zalloc_arg: zone "g_bio" with the following non-sleepable locks held: > exclusive sleep mutex vm page queue mutex (vm page queue mutex) r =3D 0 (= 0xffffffff80e60a00) locked @ /nb/src/sys/kern/vfs_bio.c:3571 > exclusive sleep mutex page lock (page lock) r =3D 0 (0xffffffff80e5fb80) = locked @ /nb/src/sys/vm/vm_pageout.c:451 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_warn() at witness_warn+0x2c2 > uma_zalloc_arg() at uma_zalloc_arg+0x335 > g_vfs_strategy() at g_vfs_strategy+0x28 > ufs_strategy() at ufs_strategy+0x45 > bufstrategy() at bufstrategy+0x43 > bufwrite() at bufwrite+0x108 > cluster_wbuild() at cluster_wbuild+0x1cd > cluster_write() at cluster_write+0x2f5 > ffs_write() at ffs_write+0x66b > VOP_WRITE_APV() at VOP_WRITE_APV+0x103 > vnode_pager_generic_putpages() at vnode_pager_generic_putpages+0x1c5 > vnode_pager_putpages() at vnode_pager_putpages+0x97 > vm_pageout_flush() at vm_pageout_flush+0x1ad > vm_object_page_collect_flush() at vm_object_page_collect_flush+0x470 > vm_object_page_clean() at vm_object_page_clean+0x19d > vfs_msync() at vfs_msync+0xef > sync_fsync() at sync_fsync+0x12a > sync_vnode() at sync_vnode+0x157 > sched_sync() at sched_sync+0x1d1 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff803ebbad30, rbp =3D 0 --- > > I'll be doing another csup/rebuild ASAP, in the hope of picking > up the fixes mentioned here. =A0Just thought I'd add another "me > too" and a bit of data. > > Cheers, > > -- > Andrew > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sat May 1 00:29:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3239E1065672; Sat, 1 May 2010 00:29:33 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id AFA158FC08; Sat, 1 May 2010 00:29:32 +0000 (UTC) Received: by qyk11 with SMTP id 11so907155qyk.13 for ; Fri, 30 Apr 2010 17:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5sjtGZJYmKSeo6vYTw8GELTf375l2zhVvhZmTmSZulc=; b=faeBzWOVKv5QK7RsaExKnNNRwKg7JemZSy58eZsS44FeQWqJedbttNPSI/eO7Rm0d+ cVkbRnlrE0TKZgoBT3pDnAv4Y03h3Pb0drGcIy8VCeqqQgSB0/y253ECN2tYhVhIK29t lYqkvG88lHWXLi8v8MbV5V6Gz3prEG0J3m2rk= 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=ZVfjppUZ6zIy48oqMv6qu79me8z/jjl8It9KOjUmqHt3AjzE6Wk+94By9Ws26q9Ylc d3UoQUNLbmN4suDpSh34w4cgVswzo6CvIjOZl6rhK8qd9pjAQoGF2VG97THnoL7spGAD w6H2Zm4lzlb6ZomOMwA71VUUd44WlZHXbPRsE= MIME-Version: 1.0 Received: by 10.229.242.74 with SMTP id lh10mr658682qcb.61.1272673767052; Fri, 30 Apr 2010 17:29:27 -0700 (PDT) Received: by 10.229.49.212 with HTTP; Fri, 30 Apr 2010 17:29:26 -0700 (PDT) In-Reply-To: <4BC0CC6F.7010009@freebsd.org> References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> <4BC0CC6F.7010009@freebsd.org> Date: Sat, 1 May 2010 12:29:26 +1200 Message-ID: From: James Butler To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ports@freebsd.org" , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 00:29:33 -0000 On Sunday, April 11, 2010, Tim Kientzle wrote: > Garrett Cooper wrote: > > If I'm understanding you correctly you're saying it's an issue when I do: > > pkg_add A B C > > # 1 year passes > > pkg_add D > > # D depends on A, B, C, of different revisions. pkg_add barfs because > it can't find the applications, etc. > > This is something that's been hashed over a number of times (a few of > which I've participated in in #bsdports). There needs to be a simple > update command which will handle the action of upgrading packages, > because there isn't a proper command that will do so today. > > > I'm not convinced that the "simple update command" you > mention is actually feasible, much less desirable. > (If I want to try out the new Firefox, why does that > imply that my year-old Gimp has to be upgraded?) > > As for feasibility, here's the easy problem: > =C2=A0 A2.7 requires B3.6 > =C2=A0 =C2=A0 ... one year passes ... > =C2=A0 A4.8 now requires B7.2 > But A4.8 is incompatible with B3.6 and A2.7 is > incompatible with B7.2. =C2=A0So neither A nor B > can be updated separately without breaking the system. > > Here's the hard problem: > =C2=A0 A2.7 requires B3.6 > =C2=A0 =C2=A0 ... one year passes ... > =C2=A0 I want to install C1.0 which requires B7.2 > =C2=A0 but there hasn't been a new release of A that > =C2=A0 works with B7.2. > So I now simply cannot have both C1.0 and A2.7 > installed at the same time because they require > different versions of B. > > PBI avoids both of these problems. =C2=A0It may > be unsuitable for embedded systems[1], but > I see no reason we should not extend the existing > ports/packages system with additional tools that > target certain use cases, and PBI seems a good > fit for the desktop case. > > Tim Genuine (possibly stupid) question -in PBI land, what happens if package B is, say, CUPS? Does one need versioned rc.d scripts to start one or the other? Which one gets to claim port 631? -James Butler > > [1] Actually, PBI might work just fine even for > embedded if we address the disk bloat issue. =C2=A0One > approach would be to make > =C2=A0 /Package/Bar/libfoo-2.8.7.so > a symlink or hardlink to > =C2=A0 /Package/Shared/libfoo-2.8.7.so- > This gives easy sharing of identical files. > It's even easy to handle at install time: > =C2=A0* Installer writes libfoo-2.8.7.so to > =C2=A0 =C2=A0 /Package/Shared/libfoo-2.8.7.so-temp- > =C2=A0* Installer computes hash of file as it's written > =C2=A0* Installer renames file (delete if rename fails with EEXIST) > =C2=A0* Installer writes symlink or hardlink into /Package/Bar > > _______________________________________________ > freebsd-current@freebsd.org=C2=A0mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Sat May 1 08:28:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA5CF106566C for ; Sat, 1 May 2010 08:28:11 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (7c2945a0.i-revonet.jp [124.41.69.160]) by mx1.freebsd.org (Postfix) with ESMTP id 878208FC1B for ; Sat, 1 May 2010 08:28:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 85F9B10749; Sat, 1 May 2010 17:12:54 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by localhost (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otfaQkoNBYe5; Sat, 1 May 2010 17:12:52 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Sat, 1 May 2010 17:12:52 +0900 (JST) Date: Sat, 1 May 2010 17:12:52 +0900 From: Taku YAMAMOTO To: Jack Vogel Message-Id: <20100501171252.e05f257f.taku@tackymt.homeip.net> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.16.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: if_em.c prevents the 2nd time resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 08:28:11 -0000 Greetings, I found a bug in if_em.c which triggers a panic when resuming from the 2nd suspend. (sleep, wakeup, sleep and wakeup will result to a panic) It seems it has got introduced by r206001 (head) or r206211 (stable/8). I guess the following change mistakenly slipped into em_resume() which is completely bogus (suppose these lines should go into em_detach()?): @@ -769,6 +774,9 @@ struct adapter *adapter = device_get_softc(dev); struct ifnet *ifp = adapter->ifp; + if (adapter->led_dev != NULL) + led_destroy(adapter->led_dev); + EM_CORE_LOCK(adapter); em_init_locked(adapter); em_init_manageability(adapter); Should I file a PR? Virtually yours, -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-current@FreeBSD.ORG Sat May 1 09:10:55 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59BF6106564A; Sat, 1 May 2010 09:10:55 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC148FC13; Sat, 1 May 2010 09:10:54 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o419Aq0T097389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 May 2010 02:10:53 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BDBF028.5040505@FreeBSD.org> Date: Sat, 01 May 2010 02:11:04 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: gljennjohn@googlemail.com References: <4BDB3C31.4050709@sippysoft.com> <20100501105823.28ac1756@ernst.jennejohn.org> In-Reply-To: <20100501105823.28ac1756@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 09:10:55 -0000 Gary Jennejohn wrote: > On Fri, 30 Apr 2010 13:23:13 -0700 > Maxim Sobolev wrote: > >> Hi, >> >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to >> set length of the outgoing packets queue. The default value for that >> parameter is only 50, which is pretty low especially for the cases when >> the system handles lot of small packets and can cause ENOBUFS in >> applications under the load. The following patch makes IFQ_MAXLEN a >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN >> 10-fold, but would like to hear what do people think about it first. >> >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff >> > > Seems like a good idea, although I don't see where ifqmaxlen is being > initialized. sys/net/if.c -Maxim From owner-freebsd-current@FreeBSD.ORG Sat May 1 09:20:08 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34ED6106564A; Sat, 1 May 2010 09:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D86038FC0C; Sat, 1 May 2010 09:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6268241C6A3; Sat, 1 May 2010 11:20:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id efeOcqrf7+pF; Sat, 1 May 2010 11:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D3F8841C67B; Sat, 1 May 2010 11:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id F347D4448EC; Sat, 1 May 2010 09:17:05 +0000 (UTC) Date: Sat, 1 May 2010 09:17:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Maxim Sobolev In-Reply-To: <4BDB52F4.2010100@FreeBSD.org> Message-ID: <20100501091158.B23815@maildrop.int.zabbadoz.net> References: <4BDB3C31.4050709@sippysoft.com> <4BDB4CAE.20006@elischer.org> <4BDB52F4.2010100@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, Julian Elischer , "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 09:20:08 -0000 On Fri, 30 Apr 2010, Maxim Sobolev wrote: Hi, > Julian Elischer wrote: >> On 4/30/10 1:23 PM, Maxim Sobolev wrote: >>> Hi, >>> >>> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to >>> set length of the outgoing packets queue. The default value for that >>> parameter is only 50, which is pretty low especially for the cases when >>> the system handles lot of small packets and can cause ENOBUFS in >>> applications under the load. The following patch makes IFQ_MAXLEN a >>> tunable. I am also tempted to bump the default value for IFQ_MAXLEN >>> 10-fold, but would like to hear what do people think about it first. >>> >>> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff >> >> so just tunable? not a sysctl :-) > > The sysctl would require much bigger rewrite. As long as I understand the > value is now cached in many instances of the ifnet structure, and some > drivers even use their own queue length instead of IFQ_MAXLEN. Therefore, > even if I make this parameter a sysctl one would have to destroy interface > and create it again in order for the change to have an effect. Therefore, > keeping it tunable would be less confusing. > >> patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen >> (do different vimages want a different value?) > > I am not quite sure about that. AFAIK vimage is more high-level thing, while > this parameter controls queue length between kernel and hardware interface > driver. vimage lies above that. My leaning goes that it should be a global system boottime configuration and neither a sysctl nor a value per virtual network stack. If we'd want it to be anything else, like making a sysctl I'd prefer to have it global rather than having someone inside a virtual network stack as it basically restricts the usage of global resources (mbufs). If we can get it a sysctl and will have resources limits it will be easily converted into a per-vnet configuration. /bz -- Bjoern A. Zeeb See you when I see you. From owner-freebsd-current@FreeBSD.ORG Sat May 1 09:25:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B556106564A; Sat, 1 May 2010 09:25:31 +0000 (UTC) (envelope-from gljennjohn@googlemail.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 F36518FC1F; Sat, 1 May 2010 09:25:30 +0000 (UTC) Received: by fxm15 with SMTP id 15so960311fxm.13 for ; Sat, 01 May 2010 02:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=YEmA4/lN/sEcNOOqlhiJPoX8QBPfaiaoMggK8MfDUm4=; b=LH1SfxPj761T3/hNiqTHtofebL2NXMEnY2OisnzHOtXENwB9Fko5dNPn2SXVyZx6o9 hF4a5ixuT4PzIs1Tud4QV1D0DJfiUYKyFFGEd38DROobft93ZoFP3S4nDul3zyeHScQv vJxcMLYV95wJ3gEnlyz9pfGdkq+7jE60IvrnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=eVJVOUJWDaxn4nRxr4InpIapgxinCg+FScET9LClhsWQuN752dD6gcAWd8Pj0Ntd9v jSUEHti3R9g502uPtdO20MwlrBi6I3AzxGY45E4qfZYpBVu6PfQeSfqAl03MUU/i4Fov J7zgcovtOWyKbSOkqGQB/gbXKCCSdi4t50WTU= Received: by 10.223.143.67 with SMTP id t3mr1954782fau.16.1272705926907; Sat, 01 May 2010 02:25:26 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE08B7.dip0.t-ipconnect.de [87.174.8.183]) by mx.google.com with ESMTPS id z15sm4650298fkz.21.2010.05.01.02.25.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 May 2010 02:25:26 -0700 (PDT) Date: Sat, 1 May 2010 11:25:24 +0200 From: Gary Jennejohn To: Maxim Sobolev Message-ID: <20100501112524.26c2fe5c@ernst.jennejohn.org> In-Reply-To: <4BDBF028.5040505@FreeBSD.org> References: <4BDB3C31.4050709@sippysoft.com> <20100501105823.28ac1756@ernst.jennejohn.org> <4BDBF028.5040505@FreeBSD.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:25:31 -0000 On Sat, 01 May 2010 02:11:04 -0700 Maxim Sobolev wrote: > Gary Jennejohn wrote: > > On Fri, 30 Apr 2010 13:23:13 -0700 > > Maxim Sobolev wrote: > > > >> Hi, > >> > >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > >> set length of the outgoing packets queue. The default value for that > >> parameter is only 50, which is pretty low especially for the cases when > >> the system handles lot of small packets and can cause ENOBUFS in > >> applications under the load. The following patch makes IFQ_MAXLEN a > >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN > >> 10-fold, but would like to hear what do people think about it first. > >> > >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > >> > > > > Seems like a good idea, although I don't see where ifqmaxlen is being > > initialized. > > sys/net/if.c > Shame on me for not looking at the file itself! I only looked at the patch. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat May 1 09:28:10 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED18106566B; Sat, 1 May 2010 09:28:10 +0000 (UTC) (envelope-from gljennjohn@googlemail.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 153508FC13; Sat, 1 May 2010 09:28:09 +0000 (UTC) Received: by fxm15 with SMTP id 15so961498fxm.13 for ; Sat, 01 May 2010 02:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=DEz01Ue3ca19vyyQpkXi9wC8ivXFLfDFMEQ3awPD+ts=; b=E8T+0FHN+/dHOwgnEifqg/+d6MdC2TR37x+O2g7wDypuWsIaxOQTB/+YjbM3jrIBZv WAi3ythaBeWINy7xe2wi/I3mmBCD5pbx+2p4AJQ2327F31ajRuBz0EJ0MWDAsWXmcztR /kS4+GR4JG73/r3yCPH1IVRcSJIHeo1fW+1EY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=WmXoTVWLR93rY2rQdwFlLqKIAaJqx3Jhxh9RmtBIsHotJmMC24QjtsRPkzDxgMbz7U RfYLlsujr8o6v7EuTJvo2ggNq6Q/NqEAPcSYvf7tYs1yGnznk5SSvgbeoycTK4P5qcSy sMzHNmLmwTvC2CJMM5du65wQs7e1c2zbyLVbU= Received: by 10.223.16.84 with SMTP id n20mr1955905faa.94.1272704305623; Sat, 01 May 2010 01:58:25 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE08B7.dip0.t-ipconnect.de [87.174.8.183]) by mx.google.com with ESMTPS id 35sm4614435fkt.37.2010.05.01.01.58.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 May 2010 01:58:24 -0700 (PDT) Date: Sat, 1 May 2010 10:58:23 +0200 From: Gary Jennejohn To: Maxim Sobolev Message-ID: <20100501105823.28ac1756@ernst.jennejohn.org> In-Reply-To: <4BDB3C31.4050709@sippysoft.com> References: <4BDB3C31.4050709@sippysoft.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.ORG, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:28:10 -0000 On Fri, 30 Apr 2010 13:23:13 -0700 Maxim Sobolev wrote: > Hi, > > Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > set length of the outgoing packets queue. The default value for that > parameter is only 50, which is pretty low especially for the cases when > the system handles lot of small packets and can cause ENOBUFS in > applications under the load. The following patch makes IFQ_MAXLEN a > tunable. I am also tempted to bump the default value for IFQ_MAXLEN > 10-fold, but would like to hear what do people think about it first. > > http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > Seems like a good idea, although I don't see where ifqmaxlen is being initialized. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat May 1 12:49:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5A32106566C for ; Sat, 1 May 2010 12:49:38 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas01p.mx.bigpond.com (nschwmtas01p.mx.bigpond.com [61.9.189.137]) by mx1.freebsd.org (Postfix) with ESMTP id 52CAD8FC0A for ; Sat, 1 May 2010 12:49:37 +0000 (UTC) Received: from nschwotgx03p.mx.bigpond.com ([124.188.161.100]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20100501124936.YIAB17427.nschwmtas01p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Sat, 1 May 2010 12:49:36 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20100501124936.HGWJ2192.nschwotgx03p.mx.bigpond.com@duncan.reilly.home>; Sat, 1 May 2010 12:49:36 +0000 Date: Sat, 1 May 2010 22:49:35 +1000 From: Andrew Reilly To: "K. Macy" Message-ID: <20100501124935.GA2542@duncan.reilly.home> References: <20100430161953.GW96847@bunrab.catwhisker.org> <20100430231240.GA28805@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sat, 1 May 2010 12:49:35 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4BDC2360.006A,ss=1,fgs=0 X-SIH-MSG-ID: rxs6GdL5TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rAIudRvN+vxC5NJhuHNGUpaa/iTY3Rs9mK Cc: current@freebsd.org Subject: Re: Panic @r207433: "System call fork returning with the following locks held" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 12:49:39 -0000 Hi Kip, Sorry for the delay: it's been a tussle... On Fri, Apr 30, 2010 at 04:42:12PM -0700, K. Macy wrote: > Does FBSDID get expanded when checking out with csup? Looks like it: > __FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30 > 22:31:37Z kmacy $"); My version says: __FBSDID("$FreeBSD: src/sys/vm/vm_pageout.c,v 1.316 2010/04/30 22:31:37 kmacy Exp $"); > line 451 is part of a KASSERT on this version. Yep. About half an hour after sending the previous message my system siezed up again, and I've been coaxing it back to health since. Must make a note to myself to be more careful... I managed to find a boot configuration that was stable enough to grab the latest updates off the local cvs server. Then back to single-user mode to build the kernel, and all was sweetness and puppies after that. Thanks for the fixes! All? Not quite: about simultaneous with the vm_pageout weirdness (which means something (else?) committed in the last week), my courier-authdaemond has been dying on startup thusly: May 1 22:29:06 duncan authdaemond: /var/run/authdaemond/socket: Cross-device link It never used to die like that before, and I haven't changed anything in its configuration. The socket in question is presumably the one listed: instead there's a socket in that directory called socket.tmp, but the process itself is long gone. I don't suppose that that rings a bell? Anything change with respect to unix-domain sockets or in the last week? Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Sat May 1 15:03:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0A7A106567B for ; Sat, 1 May 2010 15:03: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 6EAE98FC2B for ; Sat, 1 May 2010 15:03:39 +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 o41F3Wvp075917; Sat, 1 May 2010 17:03:33 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o41F3V75075916; Sat, 1 May 2010 17:03:31 +0200 (CEST) (envelope-from marius) Date: Sat, 1 May 2010 17:03:31 +0200 From: Marius Strobl To: pluknet Message-ID: <20100501150331.GA74398@alchemy.franken.de> References: <4BDAE7BD.4000503@feral.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-scsi , FreeBSD Current , Matthew Jacob Subject: Re: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 15:03:40 -0000 On Fri, Apr 30, 2010 at 06:50:26PM +0400, pluknet wrote: > On 30 April 2010 18:22, Matthew Jacob wrote: > > pluknet wrote: > > Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll put > > it in > > Err.. I thought that list is dedicated for cam related stuff. > > [cc'ing scsi@ for better coverage. Sorry for cross-posting :/ ] > > > > >> --- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c        2010-03-02 > >> 15:38:13.000000000 +0300 > >> +++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c   2010-04-21 > >> 19:31:00.000000000 +0400 > >> @@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req > >>                CAMLOCK_2_MPTLOCK(mpt); > >>                break; > >>        } > >> +       case MPI_EVENT_IR_RESYNC_UPDATE: > >> +       { > >> +               uint8_t resync = (data0 >> 16) & 0xff; > >> +               mpt_prt(mpt, "IR resync update %d completed\n", resync); > >> +               break; > >> +       } > >>        case MPI_EVENT_EVENT_CHANGE: > >>        case MPI_EVENT_INTEGRATED_RAID: > >>        case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: > >> > >> Another way - just hide such event since mptutil displays rebuild > >> progress. > >> > >> > Could you maybe avoid defining a variable inside a nested scope for consistency with the majority of the existing cases and in order to not violate style(9) unnecessarily? Marius Index: mpt_cam.c =================================================================== --- mpt_cam.c (revision 207463) +++ mpt_cam.c (working copy) @@ -2575,6 +2575,10 @@ mpt_cam_event(struct mpt_softc *mpt, request_t *re CAMLOCK_2_MPTLOCK(mpt); break; } + case MPI_EVENT_IR_RESYNC_UPDATE: + mpt_prt(mpt, "IR resync update %d completed\n", + (data0 >> 16) & 0xff); + break; case MPI_EVENT_EVENT_CHANGE: case MPI_EVENT_INTEGRATED_RAID: case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: From owner-freebsd-current@FreeBSD.ORG Sat May 1 16:28:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE8BF1065670; Sat, 1 May 2010 16:28:27 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB808FC0C; Sat, 1 May 2010 16:28:26 +0000 (UTC) Received: by bwz8 with SMTP id 8so685233bwz.3 for ; Sat, 01 May 2010 09:28:20 -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=qx4/vhoEC09HpoZzOd3BtnuZR7b/q9ZxK41COB7a7r0=; b=pdzNgDCwg3DNDnHlCOVEDzgha16GZnE9WQlEIHUAp59ovNcqENlmvx5Kwf+buV8TKz 4vxXlLNKq+fNNiGUA6UsLLrneKK161KqBihZaT88CNG8kiHHofBUcLc9ITLyhcd4xu3R qHwWvWx4Huh+vHuoqqm5NTxczcJNUA81ahNhI= 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=D1EsmKKOMD9agbT6iLJF0qbEPZhJ6m+ppC03xhsxG/9RCl3m0ui1a30fREVuoYYb2D mzUOpYLrkEM6/8GXBZCBg+bH5Id+L6++ESutAnQQ8Kc456D5NAK4w6rl89M6oa1ObKET s3kxxbwhm9OdEiKQwpaYs/H7PIqXjStr4FPok= MIME-Version: 1.0 Received: by 10.204.5.87 with SMTP id 23mr8089586bku.206.1272731300363; Sat, 01 May 2010 09:28:20 -0700 (PDT) Received: by 10.204.79.3 with HTTP; Sat, 1 May 2010 09:28:20 -0700 (PDT) In-Reply-To: <20100501150331.GA74398@alchemy.franken.de> References: <4BDAE7BD.4000503@feral.com> <20100501150331.GA74398@alchemy.franken.de> Date: Sat, 1 May 2010 20:28:20 +0400 Message-ID: From: pluknet To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi , FreeBSD Current , Matthew Jacob Subject: Re: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 16:28:28 -0000 On 1 May 2010 19:03, Marius Strobl wrote: > On Fri, Apr 30, 2010 at 06:50:26PM +0400, pluknet wrote: >> On 30 April 2010 18:22, Matthew Jacob wrote: >> > pluknet wrote: >> > Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'= ll put >> > it in >> >> Err.. I thought that list is dedicated for cam related stuff. >> >> [cc'ing scsi@ for better coverage. Sorry for cross-posting :/ ] >> >> > >> >> --- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c =A0 =A0 =A0 =A02010-03-02 >> >> 15:38:13.000000000 +0300 >> >> +++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c =A0 2010-04-21 >> >> 19:31:00.000000000 +0400 >> >> @@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CAMLOCK_2_MPTLOCK(mpt); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; >> >> =A0 =A0 =A0 =A0} >> >> + =A0 =A0 =A0 case MPI_EVENT_IR_RESYNC_UPDATE: >> >> + =A0 =A0 =A0 { >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 uint8_t resync =3D (data0 >> 16) & 0xff= ; >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpt_prt(mpt, "IR resync update %d compl= eted\n", resync); >> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; >> >> + =A0 =A0 =A0 } >> >> =A0 =A0 =A0 =A0case MPI_EVENT_EVENT_CHANGE: >> >> =A0 =A0 =A0 =A0case MPI_EVENT_INTEGRATED_RAID: >> >> =A0 =A0 =A0 =A0case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: >> >> >> >> Another way - just hide such event since mptutil displays rebuild >> >> progress. >> >> >> >> >> > > Could you maybe avoid defining a variable inside a nested scope for > consistency with the majority of the existing cases and in order to > not violate style(9) unnecessarily? > > Marius > > Index: mpt_cam.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- mpt_cam.c =A0 (revision 207463) > +++ mpt_cam.c =A0 (working copy) > @@ -2575,6 +2575,10 @@ mpt_cam_event(struct mpt_softc *mpt, request_t *re > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CAMLOCK_2_MPTLOCK(mpt); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0} > + =A0 =A0 =A0 case MPI_EVENT_IR_RESYNC_UPDATE: > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpt_prt(mpt, "IR resync update %d completed= \n", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (data0 >> 16) & 0xff); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > =A0 =A0 =A0 =A0case MPI_EVENT_EVENT_CHANGE: > =A0 =A0 =A0 =A0case MPI_EVENT_INTEGRATED_RAID: > =A0 =A0 =A0 =A0case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE: > I'm fine with it, resync variable is not necessary there. Thanks for review. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sat May 1 16:33:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E28DB1065691 for ; Sat, 1 May 2010 16:33:55 +0000 (UTC) (envelope-from p.massat@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 79D4F8FC12 for ; Sat, 1 May 2010 16:33:55 +0000 (UTC) Received: by gyh20 with SMTP id 20so612119gyh.13 for ; Sat, 01 May 2010 09:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=1YurNOLB0k7pIz0b8aqLWrUqJvI7a8vohoH8rhg8Nt4=; b=YRQ0k911hoGBCnor7VCPiTgat85R6+l28+arxBXanGdaWC4xfLSao2qXd1mBCxGJes MvQlSMeKCKc9kL7pEQKPCQLE5wH867XVmw09GAZVQ8hQ1LffJFK1QQRhXmJ+KWKJJ7aB vhw2IYMuIlEpqzuWRljqfNK4Rl1ycXTk7X1oE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=KXALm6jUH+MeSs+gIAQ/M9CWfn+OjeyL87NNqkKrxkWXLL7RWSMu087MpzHyVMwK9u ws842EW6XQ0D83vl0SsuwO7nIOEBGLAAh5dgUEBn7PvizAzbu4lpivimhNJ4pL0neZ79 T9g01Cj7CYGFbN7+WEVMQ5FX0rk70SodFbOSA= Received: by 10.150.127.24 with SMTP id z24mr7215999ybc.204.1272731628112; Sat, 01 May 2010 09:33:48 -0700 (PDT) MIME-Version: 1.0 Sender: p.massat@gmail.com Received: by 10.100.165.19 with HTTP; Sat, 1 May 2010 09:33:28 -0700 (PDT) In-Reply-To: References: <80219502-EDAD-4745-A89B-813601D1C15E@gmail.com> From: Pierre Massat Date: Sat, 1 May 2010 18:33:28 +0200 X-Google-Sender-Auth: 6bf5870a6674a10c Message-ID: To: "Jason J. W. Williams" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-current@freebsd.org" Subject: Re: ZFS Stability & MySQL (Comments Requested) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 May 2010 16:33:56 -0000 On Fri, Apr 30, 2010 at 11:39 PM, Jason J. W. Williams wrote: > By chance did you attempt to write a test file to the ZFS filesystem > holding the database and logs? Just curious if ZFS was hung since a > MySQL restart corrected it. Thank you for your help. Yes, I tried to write a file, without any problem. -- Pierre From owner-freebsd-current@FreeBSD.ORG Sat May 1 23:32:34 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98AB1106564A for ; Sat, 1 May 2010 23:32:34 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0328FC0C for ; Sat, 1 May 2010 23:32:33 +0000 (UTC) Received: from vbook.fbsd.ru ([77.232.23.6]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o41NWRMC010891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 May 2010 03:32:30 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O8MAc-0000mJ-8w; Sun, 02 May 2010 03:32:26 +0400 From: Vladimir Grebenschikov To: Kostik Belousov In-Reply-To: <20100430104934.GL2391@deviant.kiev.zoral.com.ua> References: <1272620170.9401.14.camel@localhost> <1272624229.2142.8.camel@localhost> <20100430104934.GL2391@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Sun, 02 May 2010 03:32:24 +0400 Message-ID: <1272756744.2586.55.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.0.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Jeff Roberson , current@freebsd.org Subject: Re: SUJ update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 23:32:34 -0000 Hi > > Ehh, looks like fresh kernel is not too stable, it holds after some tim= e > > of activity. > >=20 > > DDB may be activated, but even 'call cpu_reset' does nothing here. > >=20 > > Looks like it is not related to SUJ, it happens even with SUJ disabled. > Does reverting r207410 + r207412 help ? No, it does not helps, even without this revs system locks hard time-to-tim= e, usually=20 under heavy load (CPU + Disk). For example 'portupgrade -f cups\*' usually makes system to lock. Few times I had working DDB while such lockup, but did not see there anythi= ng suspicious. Ideas will be very appreciated. I have SMP i386 system. --=20 Vladimir B. Grebenschikov vova@fbsd.ru