From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 01:23:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 956A1CF for ; Sun, 13 Oct 2013 01:23:35 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C03B2A0F for ; Sun, 13 Oct 2013 01:23:35 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id gq1so3904700obb.29 for ; Sat, 12 Oct 2013 18:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5dS0eCzm81fI1emC3RRy4FPEafnUYw5MOJhZuZTcoBg=; b=aGcXvKzlhUH6ZG8Rha/6wymaqVwJi1DHMNMTJqTsJO75crXZrxyZq5YGbgj3E0mAzo BMljl5damXyYI5ibl+zPTXSgDBll3wLd9rz3f3tjWuZqrdB4s/TqCCCWzGLMrHdxLijv Sp2E2LXtypEaa8jRwukq03UapyvRLMMKAoIFGHiHuXjJ1j3wz2ti2FM2R/5HLL4MvbtO CQaqfWOdMTxDMJoOAWcGBVDl+c+m6MdO52WQ4ld7NlBKIDbpQnT6QUz/DXlNQJrjZN2i DVCvb7d2ygxTqqFHSyAE0NNWrG5GXOkFh6heg8we1rdEKUldrVQOr0ZC2aWNvz8sp/g+ V3pA== MIME-Version: 1.0 X-Received: by 10.60.118.41 with SMTP id kj9mr21137536oeb.31.1381627414642; Sat, 12 Oct 2013 18:23:34 -0700 (PDT) Received: by 10.76.106.83 with HTTP; Sat, 12 Oct 2013 18:23:34 -0700 (PDT) In-Reply-To: <20131012215729.GA2932@troutmask.apl.washington.edu> References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> Date: Sat, 12 Oct 2013 21:23:34 -0400 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Joe Nosay To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 01:23:35 -0000 I am not top posting. Do not accuse me of this. I am upset and depressed and I do not need you to accuse me of something I am not doing. My system is shitting out on me. I have already told you what is happening. Stop accusing me of something I am not doing. On Sat, Oct 12, 2013 at 5:57 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > Please, do not top post. It loses context. > > On Sat, Oct 12, 2013 at 04:05:27PM -0400, Joe Nosay wrote: > > > > On Fri, Oct 11, 2013 at 11:22 PM, Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > On Fri, Oct 11, 2013 at 10:05:56PM -0400, Joe Nosay wrote: > > > > Is the ALPHA base stable enough to do porting of applications? > > > > > > > > > > Huh? What do you mean? People have been running freebsd-current > > > for years and porting applications to FreeBSD. Alpha is simply > > > a point in time for freebsd-current. > > > > I was rebuilding world using an older CURRENT base and the src from > > 10/07/13. The build kept breaking with libiconv, msun, and a few others. > > The problem you had with msun was caused by you adding additional options > to CFLAGS in make.conf without actually understand what those options may > do. > > > This affected both the base and 3rd party. The system is still usable but > > it isn't stable enough for building a 3rd party application. > > Yes, it is stable enough. Remove your custom CFLAG options. > > > If I reinstall the base with CURRENT from 10/07/13 to present, will > > it be stable enough for building 3rd party? > > Of course. But, you need to read src/UPDATING and ports/UPDATING. > > -- > Steve > From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 03:21:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E5F96F3 for ; Sun, 13 Oct 2013 03:21:07 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id D8B0A2EB7 for ; Sun, 13 Oct 2013 03:21:04 +0000 (UTC) Received: from [192.168.1.105] (S01060015e9b562c7.hm.shawcable.net [50.70.17.171]) (Authenticated sender: roleaccount@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id AD4FF371C7 for ; Sun, 13 Oct 2013 03:21:03 +0000 (UTC) Message-ID: <525A119E.7000803@allanjude.com> Date: Sat, 12 Oct 2013 23:21:02 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: /usr/src/lib/msun errors References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 03:21:07 -0000 On 2013-10-12 21:23, Joe Nosay wrote: > I am not top posting. > Do not accuse me of this. > I am upset and depressed and I do not need you to accuse me of something I > am not doing. > My system is shitting out on me. > I have already told you what is happening. > Stop accusing me of something I am not doing. > > > On Sat, Oct 12, 2013 at 5:57 PM, Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > >> Please, do not top post. It loses context. >> >> On Sat, Oct 12, 2013 at 04:05:27PM -0400, Joe Nosay wrote: >>> On Fri, Oct 11, 2013 at 11:22 PM, Steve Kargl < >>> sgk@troutmask.apl.washington.edu> wrote: >>> >>>> On Fri, Oct 11, 2013 at 10:05:56PM -0400, Joe Nosay wrote: >>>>> Is the ALPHA base stable enough to do porting of applications? >>>>> >>>> Huh? What do you mean? People have been running freebsd-current >>>> for years and porting applications to FreeBSD. Alpha is simply >>>> a point in time for freebsd-current. >>> I was rebuilding world using an older CURRENT base and the src from >>> 10/07/13. The build kept breaking with libiconv, msun, and a few others. >> The problem you had with msun was caused by you adding additional options >> to CFLAGS in make.conf without actually understand what those options may >> do. >> >>> This affected both the base and 3rd party. The system is still usable but >>> it isn't stable enough for building a 3rd party application. >> Yes, it is stable enough. Remove your custom CFLAG options. >> >>> If I reinstall the base with CURRENT from 10/07/13 to present, will >>> it be stable enough for building 3rd party? >> Of course. But, you need to read src/UPDATING and ports/UPDATING. >> >> -- >> Steve >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Sorry, do you not know what 'top posting' is? The list just asks that you put your reply after the quoted text that you are replying to, instead of at the top of the email (above the quote) From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 04:06:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AAACDDED for ; Sun, 13 Oct 2013 04:06:27 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F4392079 for ; Sun, 13 Oct 2013 04:06:27 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id u16so3427656iet.4 for ; Sat, 12 Oct 2013 21:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f9nzvUVBKfEQ+yV9N7DOW2QM4H2jlzPCIvdKqVruhHo=; b=ybE5jQGWWdva4iCCMGi5cRF8V+ELwTlpTmOk54OLnBOdaptPM1GTXqkOh4Dtd+yN9w lzrd/2/oU1XTF26veqCvmQsHNpsPbusO4fvMrnK0DRTVM0BH9MwP7iU/BeQZzz0OSBHQ N/tbWyG/efgQNyOq65l5iWDy+XG7qJW1ZLrwlM1wTU4j/5aAUG4/Nac/YfX+7PJ/5C0P n+2tZEesgWFI9iKR6hI2jw20gRwGYZPpxDMrRXgvUG1IvvS/iwjtumWQUHsNEgQUomya TS6LFjtj93tBA0kUxmiWVaX+sImVTPELnIw4FZYNFFchR/yRy+/19VgGecHnNVkUiIh/ Vh/Q== MIME-Version: 1.0 X-Received: by 10.50.25.39 with SMTP id z7mr8337468igf.59.1381637185274; Sat, 12 Oct 2013 21:06:25 -0700 (PDT) Received: by 10.50.62.178 with HTTP; Sat, 12 Oct 2013 21:06:25 -0700 (PDT) In-Reply-To: <525A119E.7000803@allanjude.com> References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <525A119E.7000803@allanjude.com> Date: Sat, 12 Oct 2013 23:06:25 -0500 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Scot Hetzel To: Allan Jude , Joe Nosay Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 04:06:27 -0000 On Sat, Oct 12, 2013 at 10:21 PM, Allan Jude wrote: > On 2013-10-12 21:23, Joe Nosay wrote: >> I am not top posting. >> Do not accuse me of this. >> I am upset and depressed and I do not need you to accuse me of something I >> am not doing. >> My system is shitting out on me. >> I have already told you what is happening. >> Stop accusing me of something I am not doing. >> >> : : : > Sorry, do you not know what 'top posting' is? The list just asks that > you put your reply after the quoted text that you are replying to, > instead of at the top of the email (above the quote) > Joe might not have realized it, but for us gmail users we have top posting by default. We have to hit the 3 dots (...) to expand the quoted text, delete the first line and then scroll down to the text we want to quote. It's a bit annoying. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 04:39:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 376A5149 for ; Sun, 13 Oct 2013 04:39:15 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0C01E2152 for ; Sun, 13 Oct 2013 04:39:13 +0000 (UTC) Received: from [192.168.1.105] (S01060015e9b562c7.hm.shawcable.net [50.70.17.171]) (Authenticated sender: roleaccount@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id ADCF537250; Sun, 13 Oct 2013 04:39:11 +0000 (UTC) Message-ID: <525A23EE.80007@allanjude.com> Date: Sun, 13 Oct 2013 00:39:10 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scot Hetzel Subject: Re: /usr/src/lib/msun errors References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <525A119E.7000803@allanjude.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joe Nosay , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 04:39:15 -0000 On 2013-10-13 00:06, Scot Hetzel wrote: > On Sat, Oct 12, 2013 at 10:21 PM, Allan Jude wrote: >> On 2013-10-12 21:23, Joe Nosay wrote: >>> I am not top posting. >>> Do not accuse me of this. >>> I am upset and depressed and I do not need you to accuse me of something I >>> am not doing. >>> My system is shitting out on me. >>> I have already told you what is happening. >>> Stop accusing me of something I am not doing. >>> >>> > : > : > : >> Sorry, do you not know what 'top posting' is? The list just asks that >> you put your reply after the quoted text that you are replying to, >> instead of at the top of the email (above the quote) >> > Joe might not have realized it, but for us gmail users we have top > posting by default. We have to hit the 3 dots (...) to expand the > quoted text, delete the first line and then scroll down to the text we > want to quote. > > It's a bit annoying. > Luckily, in ThunderBird it is a setting per account, so I can have this account bottom post, and my business one for "customers" top post. I always love to get the complains from customers that my message shows up as an attachment because it was signed. From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 06:31:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 662D4F95 for ; Sun, 13 Oct 2013 06:31:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40A9824E2 for ; Sun, 13 Oct 2013 06:31:28 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r9D6VPxQ004512; Sat, 12 Oct 2013 23:31:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r9D6VOUp004511; Sat, 12 Oct 2013 23:31:24 -0700 (PDT) (envelope-from sgk) Date: Sat, 12 Oct 2013 23:31:24 -0700 From: Steve Kargl To: Joe Nosay Subject: Re: /usr/src/lib/msun errors Message-ID: <20131013063124.GA4498@troutmask.apl.washington.edu> References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 06:31:28 -0000 On Sat, Oct 12, 2013 at 09:23:34PM -0400, Joe Nosay wrote: > I am not top posting. Yes, you are. > Do not accuse me of this. I'm just stating fact. > I am upset and depressed and I do not need you to accuse me of something I > am not doing. Whatever. > My system is shitting out on me. Good luck fixing your system. You clearly do not want help from someone with 20 years of experience running FreeBSD. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 07:31:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 40C754F7 for ; Sun, 13 Oct 2013 07:31:14 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id 08A0126CB for ; Sun, 13 Oct 2013 07:31:13 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:57637] helo=localhost) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id EA/41-15529-A3C4A525; Sun, 13 Oct 2013 07:31:07 +0000 Date: Sun, 13 Oct 2013 07:31:06 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: stable-10 or head? X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Cc: Guido Falsi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 07:31:14 -0000 >From Guido Falsi: > On 10/12/13 15:29, John wrote: > > Hello currents, > > I have a 9.2-R vm and I'd like to bring it up to 10 (i.e what will > > eventually be 10-RELEASE). So, do I svn 10-STABLE or HEAD? > > I think 10-STABLE but I just want to check. > You are correct. > branch stable/10 on subversion. It's labelled as ALPHA6 at present. -- > Guido Falsi I would have updated source tree for HEAD thinking it was still 10-to-be. I follow stable and current emailing lists and didn't see any announcement about the branching of head and stable/10. There should have been a heads-up! I just checked http://svnweb.freebsd.org/ . Tom From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 07:43:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BD636865 for ; Sun, 13 Oct 2013 07:43:58 +0000 (UTC) (envelope-from joostmnl@gmail.com) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 568062750 for ; Sun, 13 Oct 2013 07:43:58 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id b10so2667988eae.24 for ; Sun, 13 Oct 2013 00:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=P8mdiyjh/+mkS8OCT2PjN8/H1migJ09MAJO8oe8ztVI=; b=GSDPgeef7qNrVPKng6UkYcRLacRwlxlNoLEGbERnzqs2zhF37ewioQmp+cicrCncdj IHWVd+yrskCZU5Qt/XoZQo1/a/c5Cu2wmHPMjA2TZTdMFzJx5wENEuRpOStnf+JH07dF E1QMUgBWJNDSNHsQmeGuOANUhQ+RI3QOad7Ve3p+YgImSc3XSaNJ/77Q/oRJ4CZXaMgI GpXny6t8Qu5iWh7sg/HNLPzHC6thgXB9O5+0ZcJd8fX+cynP/oZfgc0H+o2TQGGMYsxa /OMpF0houAium6KB/l+AY40tG2vuDX5mDB/RQNakorlDV/nBmEctxfgHE32b4mbd/IVE UzLA== X-Received: by 10.14.219.5 with SMTP id l5mr420038eep.63.1381650236829; Sun, 13 Oct 2013 00:43:56 -0700 (PDT) Received: from [172.17.114.101] (ip51cfd3ef.direct-adsl.nl. [81.207.211.239]) by mx.google.com with ESMTPSA id k7sm137338489eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Oct 2013 00:43:56 -0700 (PDT) Message-ID: <525A4F3B.8080005@gmail.com> Date: Sun, 13 Oct 2013 09:43:55 +0200 From: Joost Mulders User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: rfc4638 (mtu 1500 over a PPPoE) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 07:43:58 -0000 Hi all, Does FreeBSD 9.2 support RFC4638? I.e, is it possible to have a 1500 byte MTU over of PPPoE link? Thanks, Joost From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 10:53:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 12E2CE7F; Sun, 13 Oct 2013 10:53:44 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E9BA2D6E; Sun, 13 Oct 2013 10:53:43 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so2788962eak.4 for ; Sun, 13 Oct 2013 03:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WkDrNhmF459yjh82529uVbYFfgScC6xEpBYRqY6IwyM=; b=ZDfH6NHSlNYT1brB+VyuL5hsgu+fPX7oCR7sq/T69Xu/wYQhunlK+EkNbPMBUFIWmH BY18t+D0s+VQ/pST3gCV9yzedfZ0NIZLpndCPhyikBOIYZg4hlRkXU06gqZ+2ZvNyJID /s1giLiPbXcb9AzmyjHvc77/GDX1GYnAShChy71SW6cracFLrWeBaUuh8nzswHCF7E8V myILqUScoTiCe8tUlCgwlLjytnjFlAzrkBPNtH7Gepjy0MHPa2+sQJKaE6qazXaNVv+Y MPqrjWButp83Ah3LGAkHyc9mYO4cq3DQlcWcuZtf46zLF+GLUmMRFcGJrPUIiEtq6NZi b5qQ== X-Received: by 10.14.178.67 with SMTP id e43mr2286939eem.59.1381661621715; Sun, 13 Oct 2013 03:53:41 -0700 (PDT) Received: from mini.home (adho211.neoplus.adsl.tpnet.pl. [79.184.170.211]) by mx.google.com with ESMTPSA id a6sm139049073eei.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Oct 2013 03:53:41 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: New iSCSI stack. From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Sun, 13 Oct 2013 12:53:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A782312-6655-489D-927D-C8907C1D9883@freebsd.org> References: <522A1C73.9030402@mu.org> To: Outback Dingo X-Mailer: Apple Mail (2.1510) Cc: freebsd-scsi@freebsd.org, "freebsd-arch@freebsd.org" , Alfred Perlstein , "freebsd-current@FreeBSD.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 10:53:44 -0000 Wiadomo=B6=E6 napisana przez Outback Dingo w = dniu 11 pa=BC 2013, o godz. 14:37: > Quick question, is there a specific reason why ctld doesnt create the = file / device for iscsi, or fc ? > the previous iscsi would read the config file and create the file / = device ... it now appears to be a > manual process. You mean, the backing files ("path /dev/zvol/whatever", for example), = right? I thought about it. Problem is, while it makes it somewhat easier in = very simple situations, it's not very useful in real life - ctld (or CTL) has no = information what the permissions should be, should the file be fully or thin provisioned = (in other words, whether it supposed to be filled with zeroes, truncated to a = correct length, or perhaps it's a ZVOL with reservation set), etc. And you don't want = it to create files when you make a typo in path name. From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 11:54:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C5658B0 for ; Sun, 13 Oct 2013 11:54:31 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC6142FDB for ; Sun, 13 Oct 2013 11:54:30 +0000 (UTC) Received: from ubm.strangled.net (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id r9DBsHkl003048; Sun, 13 Oct 2013 13:54:18 +0200 Received: from ubm.strangled.net ([92.231.39.23] helo=ubm.strangled.net) by ASSP.nospam.UpPeRnEt; 13 Oct 2013 13:54:17 +0200 Date: Sun, 13 Oct 2013 13:54:17 +0200 From: Marc "UBM" Bocklet To: Guido Falsi Subject: Re: Possible iconv fallout? Message-Id: <20131013135417.82e8db7113d7fedf19f112b4@u-boot-man.de> In-Reply-To: <52593C6F.6080709@madpilot.net> References: <20131012132908.a122b1b3f85d9936b87fb4f3@u-boot-man.de> <52593C6F.6080709@madpilot.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 13 Oct 2013 12:42:10 +0000 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 11:54:31 -0000 On Sat, 12 Oct 2013 14:11:27 +0200 Guido Falsi wrote: > It most probably is some libtool ".la" file still referencing the > libiconv .la file. > > Please run the following command: > > find /usr/local/lib -name '*.la' -exec grep -n libiconv.la {} \; -print > | xargs -n 1 pkg which -qo | sort -u > > This will give you a list of ports still having reference to > libiconv.la, which does not exist anymore. > > These ports need to be reinstalled. I hope there are not many! :) Thanks a bunch, there were only about 6 ports and after I figured out the right order of updating/reinstalling them, everything went smoothly (though I had to sprinkle some LDFLAGS+=-ltinfow in there)! :-) Bye Marc From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 15:23:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9CE4AB6A for ; Sun, 13 Oct 2013 15:23:31 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5BA27C5 for ; Sun, 13 Oct 2013 15:23:31 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 5886E139AE for ; Sun, 13 Oct 2013 12:14:08 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1381677247; x=1382541248; bh=iOTWipoK1gVIUZiajHuqL3M6rKQtCar+0f8 JBL42R8s=; b=VcFeaphDlsIOZyTOfu8KZrP6W+fm9vTQhslexIDcl4vXXhZ8mHB pUQyQfmxiGxosucbsEqeyzjASCAvxJjHNFshzHYVLJV9In9VYePs0kbaFVN/Lv67 /342Lsynaxon2TLPjldDPSMZmhpHI0ZLThd8AdK5cCCPCdq+CqPE21Rs= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKvDmULmTcZz for ; Sun, 13 Oct 2013 12:14:07 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 2E90D139AC for ; Sun, 13 Oct 2013 12:14:06 -0300 (BRT) Message-ID: <525AB8B7.9080502@bsdinfo.com.br> Date: Sun, 13 Oct 2013 12:13:59 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: stable-10 or head? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 15:23:31 -0000 Em 13/10/13 04:31, Thomas Mueller escreveu: > >From Guido Falsi: > >> On 10/12/13 15:29, John wrote: >>> Hello currents, >>> I have a 9.2-R vm and I'd like to bring it up to 10 (i.e what will >>> eventually be 10-RELEASE). So, do I svn 10-STABLE or HEAD? >>> I think 10-STABLE but I just want to check. >> You are correct. > >> branch stable/10 on subversion. It's labelled as ALPHA6 at present. > > -- >> Guido Falsi > I would have updated source tree for HEAD thinking it was still 10-to-be. > > I follow stable and current emailing lists and didn't see any announcement about the branching of head and stable/10. > > There should have been a heads-up! > > I just checked http://svnweb.freebsd.org/ . > > Cool :) First beta version! # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 256420 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 256420 Last Changed Date: 2013-10-12 21:24:44 -0300 (Sat, 12 Oct 2013) # uname -a FreeBSD bkp-srv.teste.com.br 10.0-BETA1 FreeBSD 10.0-BETA1 #8 r256420: Sun Oct 13 05:31:43 BRT 2013 root@bkp-srv.teste.com.br:/usr/obj/usr/src/sys/TESTE10 i386 From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 15:57:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E513C6FC for ; Sun, 13 Oct 2013 15:57:23 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB00A290D for ; Sun, 13 Oct 2013 15:57:23 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id n2so3745682oag.25 for ; Sun, 13 Oct 2013 08:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3+vTP+Upi3gwh9KMrL7QJ+YawhilkykwpCHrbD9JUbc=; b=VkupjWgaApazm65OOUC14I111G56NuK+hYwVNJpVug8Bp2c94XAg7JxD6D1b1Ec3C0 KSCb6KMowPjgnNFQESBVOen7mg3QfZrhJ4mJQDhFKgP/aj6pdw012Z1TCMSQThn1czYO 8DdbEDb7iL/PKdxVRBiHHTZMS4SxPuFyvaFCxcgIdMPG5JIZda5UQIhmMsxFu7SWwrRu vsYZd38rvIYSdRz5XhdQOhCtFo3Qqrq9EquXtWCgfaUJmhekitV4lUMnLrHzuILaGuCX 8qMrI3MAlzCrDOGp3Qv8g0pRkKFzejTs6kMQiFY3eijPKO6CejuOaAiOQ2sEnyOsJfNX zeEQ== MIME-Version: 1.0 X-Received: by 10.60.74.170 with SMTP id u10mr100899oev.49.1381679842796; Sun, 13 Oct 2013 08:57:22 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Sun, 13 Oct 2013 08:57:22 -0700 (PDT) In-Reply-To: <20131013063124.GA4498@troutmask.apl.washington.edu> References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> Date: Sun, 13 Oct 2013 11:57:22 -0400 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Joe Nosay To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 15:57:24 -0000 I have a snapshot saved proving that I am not top posting and only using the bottom reply box. I did not know that gmail automatically top posts replies. I am willing to take a polygraph test to prove I am telling the truth. Steve Kargl, you think that I am lying but I have proof right here. I am willing to wait for you to visit me in person to prove to you I am telling the truth. You may have twenty years of BSD experience; yet, you do not know how to deal with people. I have over thirty years of depression and it has taught me a lot. Let me enlighten you and dispel your ignorance, Steve. I am homeless, sick, and depressed. I am half hispanic and have had to deal with a family of bigots that raised me. You are quick to judge me and even quicker to condemn me with your self righteousness. If this post comes up as a top post, I do not care about that. Learn, Steve, that what you perceive to be true from your end is not always what is true from the other. You may be human and err; but, you do not have the right to be a pompous jackass to me or anyone else. As I said, "Do not shit on me." On Sun, Oct 13, 2013 at 2:31 AM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Sat, Oct 12, 2013 at 09:23:34PM -0400, Joe Nosay wrote: > > I am not top posting. > > Yes, you are. > > > Do not accuse me of this. > > I'm just stating fact. > > > I am upset and depressed and I do not need you to accuse me of something > I > > am not doing. > > Whatever. > > > My system is shitting out on me. > > Good luck fixing your system. You clearly do not > want help from someone with 20 years of experience > running FreeBSD. > > -- > Steve > From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:06:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDD36975 for ; Sun, 13 Oct 2013 16:06:06 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F7F02986 for ; Sun, 13 Oct 2013 16:06:06 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id ii20so1880425qab.10 for ; Sun, 13 Oct 2013 09:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=7U/TgrAYXJBJbXZs61FOgiKy5cUr32X/gET2ZVW1QPs=; b=d7556InqD66soilxws1sxq2Mhk7FQGdsJKrb2+HoQ7alLItzO/uYZaQyYdm2R5bx7j GTV1JmQgck8NZX/B4SylFXAY9fnW5j1YmIFTpqMAsUkhIbYyRFdugu5Blg6Qw8xDHAxP zvw3QM1wUjYpkr0ovNrc48mG925lB/WuPArhw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=7U/TgrAYXJBJbXZs61FOgiKy5cUr32X/gET2ZVW1QPs=; b=ZjwFUXdLov+9/0qX5ZfD4Zjt2v+GvC2wiF/SANoFEeLMkV10FyOTHD+nc+zSlJymru a5hG5X8dHmWU6VMpcka0RY2aWgprGoKm+tHZzryPk6/Wy8LU1auZfm0I6P3ZfAU3luYH Q7dWJIkhpM9fzuS53z7MVOdSrR72myBJXGDFcmVZi5sQldMPfDfCrkJwUl5Q3/nofDf5 kTPhiZ95QZRxttGcvOgKx/qGzXdOAnpkdnY/SriV3RxfHvf6xMrWjxrqv+Kx4qBJQqGc HiaUSGNpq73qB5DmNctDLsG4Rt4DN9bBkqQEXDUv5JzVNw4jGcQCi1NymzZ3RDv0fyPp tQZw== X-Gm-Message-State: ALoCoQmvegJ2JMoeCS0iOkr3KX/Sw7Dyht0xthx7fJkr9idUwoLNYO/KvFKKsn1owc8zh07bCupc X-Received: by 10.224.88.70 with SMTP id z6mr1439802qal.116.1381680365768; Sun, 13 Oct 2013 09:06:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Sun, 13 Oct 2013 09:05:35 -0700 (PDT) From: Eitan Adler Date: Sun, 13 Oct 2013 12:05:35 -0400 Message-ID: Subject: devfs, zfs LoR To: freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:06:06 -0000 Hi, Is this real LoR or is it known to be invalid? lock order reversal: 1st 0xfffff800323725f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xfffff8010e9cdb78 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2210 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0231f8a460 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0231f8a510 witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe0231f8a5a0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe0231f8a6d0 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe0231f8a6f0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe0231f8a720 _vn_lock() at _vn_lock+0xab/frame 0xfffffe0231f8a790 vputx() at vputx+0x208/frame 0xfffffe0231f8a7f0 dounmount() at dounmount+0x327/frame 0xfffffe0231f8a870 sys_unmount() at sys_unmount+0x356/frame 0xfffffe0231f8a9a0 amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe0231f8aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0231f8aab0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80088a63a, rsp = 0x7fffffffd148, rbp = 0x7fffffffd260 --- -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:08:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4C83B6B for ; Sun, 13 Oct 2013 16:08:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8935D299E for ; Sun, 13 Oct 2013 16:08:45 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wm4so4137100obc.33 for ; Sun, 13 Oct 2013 09:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vjaxhF3HKorActzCgpgJFAys3lxAX8KuG+pTYikjJI0=; b=LeNw//0bGgKnLw+XyqBlZIObHmNOMLmJgUjKm/u5ex5i+1yvSGhWLT48M8enbBQMI0 TFLqZS/WN4w3rWehH2gzWvuBErgz+5N0XJdQIyNO2afRvi+N8pGz5tOv2ZN/trGTZnNC 0/Uqkus4U60X/CoW+aYLOH616SvI6ksTaT8TG22IJvr2I4jJByH7ZyFs09y4LncvFxoK +LW4AHee7+HIq8o5UpE/2SVvjOKMprbfGlJu/Swkuq4zhTnTGiGpTBWvj3XCIkE/t5nx Z3LsrEZWT1rMRo0cs0R+rQHKUjmkzhWc84Hr0h5xf+dYP4ri+f9zJ45sku7MLHnZzzzX 98/g== MIME-Version: 1.0 X-Received: by 10.60.78.227 with SMTP id e3mr23972562oex.5.1381680524858; Sun, 13 Oct 2013 09:08:44 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Sun, 13 Oct 2013 09:08:44 -0700 (PDT) In-Reply-To: References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> Date: Sun, 13 Oct 2013 12:08:44 -0400 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Joe Nosay To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:08:45 -0000 On Sun, Oct 13, 2013 at 11:57 AM, Joe Nosay wrote: > I have a snapshot saved proving that I am not top posting and only using > the bottom reply box. I did not know that gmail automatically top posts > replies. I am willing to take a polygraph test to prove I am telling the > truth. Steve Kargl, you think that I am lying but I have proof right here. > I am willing to wait for you to visit me in person to prove to you I am > telling the truth. You may have twenty years of BSD experience; yet, you do > not know how to deal with people. I have over thirty years of depression > and it has taught me a lot. Let me enlighten you and dispel your ignorance, > Steve. I am homeless, sick, and depressed. I am half hispanic and have had > to deal with a family of bigots that raised me. You are quick to judge me > and even quicker to condemn me with your self righteousness. If this post > comes up as a top post, I do not care about that. Learn, Steve, that what > you perceive to be true from your end is not always what is true from the > other. > > You may be human and err; but, you do not have the right to be a pompous > jackass to me or anyone else. As I said, "Do not shit on me." > > > On Sun, Oct 13, 2013 at 2:31 AM, Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > >> On Sat, Oct 12, 2013 at 09:23:34PM -0400, Joe Nosay wrote: >> > I am not top posting. >> >> Yes, you are. >> >> > Do not accuse me of this. >> >> I'm just stating fact. >> >> > I am upset and depressed and I do not need you to accuse me of >> something I >> > am not doing. >> >> Whatever. >> >> > My system is shitting out on me. >> >> Good luck fixing your system. You clearly do not >> want help from someone with 20 years of experience >> running FreeBSD. >> >> -- >> Steve >> > > Someone had to tell me what to do. Steve, are you the only person in the multiverse that is free of making any mistakes? From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:10:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8A534DD8 for ; Sun, 13 Oct 2013 16:10:38 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EFDC29BB for ; Sun, 13 Oct 2013 16:10:38 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id n2so3860696oag.11 for ; Sun, 13 Oct 2013 09:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4WMVasIqdvWOF+xtezxFyVYPpmq4bRUrT401fXjBUcE=; b=yyn1yqHDx6upuDw/GYQ7HjHSUG5Y5FwcCC0l4pxnBwjZqf3CYLhJ+RfZIp1fvQ6K/l ndJIc2J0hE8gJpOd7qA9CQi7ONu5oGYsPgQm/sLHmqHn9X/RKbUC73UZP5zgv9SsldkP 6tLSliZfr6adT/08cdlVvhjHFt4b6jbT4ZgjHJf1JFprq8Q0ZjSJ4WkdbxcIMl+uX5Vw bc/WOML42fKpsYM5neNe1BK1QjxZXQ58x79X8L3FHJgkNq8zZhva7H/z5GXWswLgneHP vHt0mrXid9FgrN6b7sBc5sEWKE91DIvR6CciZKX3NxcHEX/7RxywBhKdiQUynBJ+R8bH kv5w== MIME-Version: 1.0 X-Received: by 10.182.220.225 with SMTP id pz1mr32552obc.51.1381680637613; Sun, 13 Oct 2013 09:10:37 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Sun, 13 Oct 2013 09:10:37 -0700 (PDT) In-Reply-To: <20131013160703.GA79132@titania.njm.me.uk> References: <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> <20131013160703.GA79132@titania.njm.me.uk> Date: Sun, 13 Oct 2013 12:10:37 -0400 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Joe Nosay To: Joe Nosay , Steve Kargl , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:10:38 -0000 On Sun, Oct 13, 2013 at 12:07 PM, N.J. Mann wrote: > In message < > CA+WntOsduEh1GZUzg3G4gcW-Y7+LLRmvACe5bhbL9rtZxS+khw@mail.gmail.com>, > Joe Nosay (superbisquit@gmail.com) wrote: > > I have a snapshot saved proving that I am not top posting and only using > > the bottom reply box. I did not know that gmail automatically top posts > > replies. I am willing to take a polygraph test to prove I am telling the > > truth. Steve Kargl, you think that I am lying but I have proof right > here. > > You _are_ top posting. If you do not believe me point your web browser > at: > > http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045487.html > > > Cheers, > Nick, > -- > > Someone had to show me and tell me what was happening and that gmail automatically top posts. Again, I am willing to take a polygraph test to prove that I was unaware of this. From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:13:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 70979FB1 for ; Sun, 13 Oct 2013 16:13:47 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06C832A0D for ; Sun, 13 Oct 2013 16:13:46 +0000 (UTC) Received: (qmail 19866 invoked from network); 13 Oct 2013 16:07:04 -0000 X-APM-Authkey: 18389 3 Received: from unknown (HELO meld.njm.me.uk) (86.134.200.161) by smtp002.apm-internet.net with SMTP; 13 Oct 2013 16:07:04 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by meld.njm.me.uk (8.14.7/8.14.7) with ESMTP id r9DG73gg073281; Sun, 13 Oct 2013 17:07:03 +0100 (BST) (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.7/8.14.7) with ESMTP id r9DG73hl079405; Sun, 13 Oct 2013 17:07:03 +0100 (BST) (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.7/8.14.7/Submit) id r9DG73rM079404; Sun, 13 Oct 2013 17:07:03 +0100 (BST) (envelope-from njm@njm.me.uk) Date: Sun, 13 Oct 2013 17:07:03 +0100 From: "N.J. Mann" To: Joe Nosay Subject: Re: /usr/src/lib/msun errors Message-ID: <20131013160703.GA79132@titania.njm.me.uk> Mail-Followup-To: Joe Nosay , Steve Kargl , freebsd-current References: <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 8.4-STABLE User-Agent: mutt-NJM (2010-10-31) Cc: freebsd-current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:13:47 -0000 In message , Joe Nosay (superbisquit@gmail.com) wrote: > I have a snapshot saved proving that I am not top posting and only using > the bottom reply box. I did not know that gmail automatically top posts > replies. I am willing to take a polygraph test to prove I am telling the > truth. Steve Kargl, you think that I am lying but I have proof right here. You _are_ top posting. If you do not believe me point your web browser at: http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045487.html Cheers, Nick, -- From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:20:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 92D8F586 for ; Sun, 13 Oct 2013 16:20:07 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 566822A5E for ; Sun, 13 Oct 2013 16:20:07 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id n2so3755414oag.25 for ; Sun, 13 Oct 2013 09:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sNMe9z7BtG+8mDNJvVplSQLQg6ekAD9IPdUXtlp7V5c=; b=Q/65lruhQbrtCAO7xN1GLgHbHMuMrW2Z+36I1V46bBBizVbMBxjRWsLVwarz9EMmLU oo/7iiYlBFukpCCijV89iw38TIhe43t0L+VF7r0/yVbE0Nh6UZEYLB4N7TLuIO0+fteU naMa1qZT3NIorkTjKXalWWql6X83QBa3anArL5WpW37EuO33pTzTPzoctgX5qKRg53Of Kfm97OliES0K6lTqgtRzN7e/qHw9CnziEWW3Hta2nIuUI7AE88MKLdpkzTBNzcx6CJPF NdEReT4mGq1Qvhzek7WJHwiMzrn+JjfolUmexHEPU/3n8KQR6wNcTWxQGI/+kHEP8DD+ /03g== MIME-Version: 1.0 X-Received: by 10.182.237.44 with SMTP id uz12mr24350099obc.11.1381681206698; Sun, 13 Oct 2013 09:20:06 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Sun, 13 Oct 2013 09:20:06 -0700 (PDT) In-Reply-To: References: <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> <20131013160703.GA79132@titania.njm.me.uk> Date: Sun, 13 Oct 2013 12:20:06 -0400 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Joe Nosay To: Joe Nosay , Steve Kargl , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:20:07 -0000 On Sun, Oct 13, 2013 at 12:10 PM, Joe Nosay wrote: > > > > On Sun, Oct 13, 2013 at 12:07 PM, N.J. Mann wrote: > >> In message < >> CA+WntOsduEh1GZUzg3G4gcW-Y7+LLRmvACe5bhbL9rtZxS+khw@mail.gmail.com>, >> Joe Nosay (superbisquit@gmail.com) wrote: >> > I have a snapshot saved proving that I am not top posting and only using >> > the bottom reply box. I did not know that gmail automatically top posts >> > replies. I am willing to take a polygraph test to prove I am telling the >> > truth. Steve Kargl, you think that I am lying but I have proof right >> here. >> >> You _are_ top posting. If you do not believe me point your web browser >> at: >> >> >> http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045487.html >> >> >> Cheers, >> Nick, >> -- >> >> > Someone had to show me and tell me what was happening and that gmail > automatically top posts. Again, I am willing to take a polygraph test to > prove that I was unaware of this. > http://slexy.org/view/s20mg6Dh8w http://slexy.org/view/s20AvJUBNB http://i39.tinypic.com/1z1732q.jpg Okay, finally. There is proof that I did tell the truth. From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:23:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1EA43740 for ; Sun, 13 Oct 2013 16:23:24 +0000 (UTC) (envelope-from sunrenjie6@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84CB52AA7 for ; Sun, 13 Oct 2013 16:23:23 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id q8so4996059lbi.11 for ; Sun, 13 Oct 2013 09:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uOo3dSfrFRXFcobTkJ/e8MvZYoimgrLo638FPW3LHVA=; b=h1s99icqio/BCd/rTt10LOgwL1A3dwdtdKk/XhHf1J4Nb+cCiyih1VqZJHvnxPs7IY lZYqHVgb8PxrNinZBHGbRqjXjsGr8NuULKfpECedDr4uaCKi6yCItUhcStX7a/YIAlmT O5XEwFCQGLnOdRcNyvdgFMgcGF2vM5eQVd76aG6NR9uPkI7UjO9kzEF/z719+Pn9U8Hc R7Z/yjcNTPPqpXKqKgCE5le/bGbto8FYenmZYNCh8tejpftWG81ZKfl8Tl86P1ZsGebq ugb5oxK2g/O0RtKrl9C/SNFwqnOvWJRhdGqtMoRtQTllGpBcNCcbai2HCiL5bgORsTf2 +/PA== MIME-Version: 1.0 X-Received: by 10.152.120.37 with SMTP id kz5mr26485458lab.21.1381681401506; Sun, 13 Oct 2013 09:23:21 -0700 (PDT) Received: by 10.152.29.135 with HTTP; Sun, 13 Oct 2013 09:23:21 -0700 (PDT) Date: Mon, 14 Oct 2013 00:23:21 +0800 Message-ID: Subject: Re: mysql-client-5.6.14 build failed From: Sun Renjie To: vsityz@gmail.com, freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=089e0122814821336b04e8a1c5b7 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:23:24 -0000 --089e0122814821336b04e8a1c5b7 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexander: > Date: Wed, 02 Oct 2013 02:04:02 +0300 > From: Alexander Panyushkin > To: freebsd-current@freebsd.org > Subject: mysql-client-5.6.14 build failed > Message-ID: <524B54E2.1040608@gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi all. > > mysql-client-5.6.14 not build with clang > > /usr/ports/databases/mysql56-client/work/mysql-5.6.14/sql/net_serv.cc:48: > In file included from /usr/include/c++/v1/algorithm:627: > /usr/include/c++/v1/memory:968:39: error: expected unqualified-id > template static __two test(...); The build fails because the 'test' macro is defined in include/my_global.h: #define test(a) ((a) ? 1 : 0) yet libc++ standard header defines 'test' as the name of a function: template static char test(typename _Up::pointer* = 0); MySQL C++ source code files like sql/net_serv.cc #include before including . This ordering will result in the 'test' function in macro-expanded into nonsense. After a casual scan, more C++ source code files might be affacted: client/mysql.cc:45:#include client/mysqlbinlog.cc:58:#include client/mysqltest.cc:51:#include client/sql_string.cc:28:#include ... I've prepared an ad hoc patch that modifies include/my_global.h to include before defining the 'test' macro, so that further including of will be uneffective and hence unharmful. I believe this likely to be useful before there is a fix from upstream mysql or libc++. Now this package (mysql56-client) and the server counterpart (mysql56-server) build fine. I'm new to FreeBSD so I hope someone else could produce a better solution. Any comments will be highly appreciated! Thanks. Here comes the patch (see also the attachment): root@r:/svn/ports/databases/mysql56-client # cat files/patch-include_my_global.h --- include/my_global.h.orig 2013-10-13 22:22:33.000000000 +0800 +++ include/my_global.h 2013-10-13 22:26:57.000000000 +0800 @@ -460,6 +460,13 @@ typedef unsigned short ushort; #endif +/* the macro test() below will break libc++ standard header which + defines function named 'test'; fix it in an ad hoc manner by including the + header before definition of the macro. */ +#ifdef __cplusplus +#include +#endif + #define swap_variables(t, a, b) { t dummy; dummy= a; a= b; b= dummy; } #define test(a) ((a) ? 1 : 0) #define set_if_bigger(a,b) do { if ((a) < (b)) (a)=(b); } while(0) ---------- Regards, Renjie Sun --089e0122814821336b04e8a1c5b7-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:31:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F1527A35 for ; Sun, 13 Oct 2013 16:31:51 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D0FA2B16 for ; Sun, 13 Oct 2013 16:31:51 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r9DGVoRu079024; Sun, 13 Oct 2013 10:31:50 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r9DGVn5K079021; Sun, 13 Oct 2013 10:31:49 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 13 Oct 2013 10:31:49 -0600 (MDT) From: Warren Block To: Joe Nosay Subject: Re: /usr/src/lib/msun errors In-Reply-To: Message-ID: References: <20131010013338.GA10499@troutmask.apl.washington.edu> <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 13 Oct 2013 10:31:50 -0600 (MDT) Cc: freebsd-current , Steve Kargl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:31:52 -0000 On Sun, 13 Oct 2013, Joe Nosay wrote: > On Sun, Oct 13, 2013 at 11:57 AM, Joe Nosay wrote: > Someone had to tell me what to do. > Steve, are you the only person in the multiverse that is free of making any > mistakes? Nobody was accusing you of doing it intentionally. Anyway, that problem is now solved--thanks! From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:33:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09AF9B4B for ; Sun, 13 Oct 2013 16:33:03 +0000 (UTC) (envelope-from sunrenjie6@gmail.com) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BEDE2B26 for ; Sun, 13 Oct 2013 16:33:02 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id hp15so833817lab.38 for ; Sun, 13 Oct 2013 09:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iUQG4rSQMJD6iDxgyPbmGRKW/R/uiN/79lr8x/9xCcg=; b=zLlGj9HqyCzRlg3tLvza/Oe/OCSCUpM0lyYnIKBwZF80uOF5i6ah6cVUoXcz4nMfW5 gsho8sPpRrPeCy/M0RMkKOJ76AXp6nXsNk46d8M7aDEw2gZXTd9ggNn3x30YZPi+3pHE ANzVMD05Zun4gtohurQPBY7qOgn4KOWEl2Z3cYr/X4m549DAisSjFZY+6JnG5RC0dof0 OxeTEmleYNeqO/lvz+LscAOPYNmAjU9xQB2h4L7Y549IsIBZpAjoSPFYNVd5gh5wikuL jp7zjBc3yDpJ3AUdISwZR5j9CkQUnnpu0asFVV99YSK2qdzDOHl+1PiDPSt9mo3D5uJK 7acQ== MIME-Version: 1.0 X-Received: by 10.112.77.134 with SMTP id s6mr1842526lbw.38.1381681980481; Sun, 13 Oct 2013 09:33:00 -0700 (PDT) Received: by 10.152.29.135 with HTTP; Sun, 13 Oct 2013 09:33:00 -0700 (PDT) Date: Mon, 14 Oct 2013 00:33:00 +0800 Message-ID: Subject: Re: mysql-client-5.6.14 build failed From: Sun Renjie To: vsityz@gmail.com, freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001a11c3dfbaa3a6ac04e8a1e70e X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:33:03 -0000 --001a11c3dfbaa3a6ac04e8a1e70e Content-Type: text/plain; charset=ISO-8859-1 Hi Alexander: (Please ignore my previous message as it was not composed in plain text while this one is. Apart from that, the message content is all the same.) > Date: Wed, 02 Oct 2013 02:04:02 +0300 > From: Alexander Panyushkin > To: freebsd-current@freebsd.org > Subject: mysql-client-5.6.14 build failed > Message-ID: <524B54E2.1040608@gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi all. > > mysql-client-5.6.14 not build with clang > > /usr/ports/databases/mysql56-client/work/mysql-5.6.14/sql/net_serv.cc:48: > In file included from /usr/include/c++/v1/algorithm:627: > /usr/include/c++/v1/memory:968:39: error: expected unqualified-id > template static __two test(...); The build fails because the 'test' macro is defined in include/my_global.h: #define test(a) ((a) ? 1 : 0) yet libc++ standard header defines 'test' as the name of a function: template static char test(typename _Up::pointer* = 0); MySQL C++ source code files like sql/net_serv.cc #include before including . This ordering will result in the 'test' function in macro-expanded into nonsense. After a casual scan, more C++ source code files might be affacted: client/mysql.cc:45:#include client/mysqlbinlog.cc:58:#include client/mysqltest.cc:51:#include client/sql_string.cc:28:#include ... I've prepared an ad hoc patch that modifies include/my_global.h to include before defining the 'test' macro, so that further including of will be uneffective and hence unharmful. I believe this likely to be useful before there is a fix from upstream mysql or libc++. Now this package (mysql56-client) and the server counterpart (mysql56-server) build fine. I'm new to FreeBSD so I hope someone else could produce a better solution. Any comments will be highly appreciated! Thanks. Here comes the patch (see also the attachment): root@r:/svn/ports/databases/mysql56-client # cat files/patch-include_my_global.h --- include/my_global.h.orig 2013-10-13 22:22:33.000000000 +0800 +++ include/my_global.h 2013-10-13 22:26:57.000000000 +0800 @@ -460,6 +460,13 @@ typedef unsigned short ushort; #endif +/* the macro test() below will break libc++ standard header which + defines function named 'test'; fix it in an ad hoc manner by including the + header before definition of the macro. */ +#ifdef __cplusplus +#include +#endif + #define swap_variables(t, a, b) { t dummy; dummy= a; a= b; b= dummy; } #define test(a) ((a) ? 1 : 0) #define set_if_bigger(a,b) do { if ((a) < (b)) (a)=(b); } while(0) ---------- Regards, Renjie Sun patch-include_my_global.h --- include/my_global.h.orig 2013-10-13 22:22:33.000000000 +0800 +++ include/my_global.h 2013-10-13 22:26:57.000000000 +0800 @@ -460,6 +460,13 @@ typedef unsigned short ushort; #endif +/* the macro test() below will break libc++ standard header which + defines function named 'test'; fix it in an ad hoc manner by including the + header before definition of the macro. */ +#ifdef __cplusplus +#include +#endif + #define swap_variables(t, a, b) { t dummy; dummy= a; a= b; b= dummy; } #define test(a) ((a) ? 1 : 0) #define set_if_bigger(a,b) do { if ((a) < (b)) (a)=(b); } while(0) --001a11c3dfbaa3a6ac04e8a1e70e-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:40:12 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB8B5CAC; Sun, 13 Oct 2013 16:40:12 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7FFA72B59; Sun, 13 Oct 2013 16:40:12 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id i1so3844743oag.20 for ; Sun, 13 Oct 2013 09:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=C9EPWKjjgR50fLvuiEPG1dg/d1aNMtv1WCa7KlC9vmw=; b=YX8tMTqJ15n924aEfNFxMXwzllNbjNbnJHglhCeIhH/+LJdIc5RCvz3zZkVOm4P9GO SIcFYZV3//Ebof+VRqHYHKugLGDAhflpFzJ28/yyXM1PnsIkCw/h1VgETUitRRyWnCmL N/QlgaY7ogiN+Lgu4vB8XhMvcLtrPsupL+d9N0HkHZhJazuA9tzrMzdboJU8Rhk/QGpR xyGvTVbapRaf/AFsfcBlxiQV0UZxESsBlL4Pg3MXBdi5GJQCh8e8Uuh3RAEO22rLZszi CflKVTzfaRC4D775SZ+RNPjgd2BJXYIOQbOuHUa8J96wtpwNt2MeBESdE3tZfKzfYw1z mZqQ== MIME-Version: 1.0 X-Received: by 10.182.237.44 with SMTP id uz12mr24414287obc.11.1381682410850; Sun, 13 Oct 2013 09:40:10 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Sun, 13 Oct 2013 09:40:10 -0700 (PDT) Date: Sun, 13 Oct 2013 12:40:10 -0400 Message-ID: Subject: /usr/ports/UPDATING entry September 04, 2013 From: Joe Nosay To: ports , freebsd-current , madpilot@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:40:12 -0000 Will the pkg upgrade work with applications built from ports and not pkg add $APPLICATION? From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:47:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0D6AE82 for ; Sun, 13 Oct 2013 16:47:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B10852BAC for ; Sun, 13 Oct 2013 16:47:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r9DGlVJD007004; Sun, 13 Oct 2013 09:47:31 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r9DGlVnH007003; Sun, 13 Oct 2013 09:47:31 -0700 (PDT) (envelope-from sgk) Date: Sun, 13 Oct 2013 09:47:31 -0700 From: Steve Kargl To: Joe Nosay Subject: Re: /usr/src/lib/msun errors Message-ID: <20131013164731.GA6981@troutmask.apl.washington.edu> References: <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:47:33 -0000 On Sun, Oct 13, 2013 at 11:57:22AM -0400, Joe Nosay wrote: > I have a snapshot saved proving that I am not top posting and only using > the bottom reply box. I did not know that gmail automatically top posts > replies. I am willing to take a polygraph test to prove I am telling the > truth. Steve Kargl, you think that I am lying but I have proof right here. I have proof too. http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045473.html http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045474.html http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045477.html http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045487.html -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 16:52:35 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0EC46FC4 for ; Sun, 13 Oct 2013 16:52:35 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C847B2BF6 for ; Sun, 13 Oct 2013 16:52:34 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id n10so3902901oag.28 for ; Sun, 13 Oct 2013 09:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q/qJvgRPBAlf2Xr5jHVY+tnyO+CWmiKiwmocKMAw1eA=; b=MTe9vpsqPP7qgmxaj9nWfXqJnZ0AHLjbxvBtPKGUjXFg7vLe7CPPuqqHfKedzbmWZn 2/cdlE4GruzhNk7XR2RFIC2Jt6h6Ez8hHzrOJ9kvTaLidp9WPrJ7+tYghHrI5WDP1OP9 aIkKIwr/IQZwMragJTOOGViyzMbN5nctHpS7o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q/qJvgRPBAlf2Xr5jHVY+tnyO+CWmiKiwmocKMAw1eA=; b=bDKDdGHFByXYlsWDwaB6bofN/66ROgScrAy/v5c4OfZNsDo9lqzwvXBEQ39EVfKvd5 FgzUtrnmdzDA3qlSMYaUOayWhUx7yoVLsgk3EH0KyumerWHM1fQAXN6bJtnIlM81HdZt dXUrLePgAAfgvpb3D+6NkcPcKZq0n8jKwa81QSTRJmRsdmIrmznt0gabiRbf10mylx4Q QigGkvWEqALsmlzlbezliMjULHG1j/bNkIBsSgH/4+5By1lQmXaUsRnZyK+Ucaw6pgAa BdvLKlXQdZ3MVMIcQKCsXpkn6NsmM9SQ2yv/GSFi4i/I/VCgBwVsdwnb/ccLRynhnMrI AoLg== X-Gm-Message-State: ALoCoQm6oNzMVf9BrThklqcC06UWQG3EXRtmHP73qB04YfHt0yq5z5F4SWhUKk58jnB3kyMoFzgR MIME-Version: 1.0 X-Received: by 10.182.242.11 with SMTP id wm11mr24516268obc.26.1381683153570; Sun, 13 Oct 2013 09:52:33 -0700 (PDT) Sender: decke@bluelife.at Received: by 10.76.154.2 with HTTP; Sun, 13 Oct 2013 09:52:33 -0700 (PDT) X-Originating-IP: [46.206.177.151] In-Reply-To: References: Date: Sun, 13 Oct 2013 18:52:33 +0200 X-Google-Sender-Auth: ZWlb_6FZZqTgVqftLkUafxaxVDY Message-ID: Subject: Re: mysql-client-5.6.14 build failed From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: Sun Renjie Content-Type: text/plain; charset=ISO-8859-1 Cc: vsityz@gmail.com, Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 16:52:35 -0000 On Sun, Oct 13, 2013 at 6:23 PM, Sun Renjie wrote: > Hi Alexander: > >> Date: Wed, 02 Oct 2013 02:04:02 +0300 >> From: Alexander Panyushkin >> To: freebsd-current@freebsd.org >> Subject: mysql-client-5.6.14 build failed >> Message-ID: <524B54E2.1040608@gmail.com> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Hi all. >> >> mysql-client-5.6.14 not build with clang > >> >> /usr/ports/databases/mysql56-client/work/mysql-5.6.14/sql/net_serv.cc:48: >> In file included from /usr/include/c++/v1/algorithm:627: >> /usr/include/c++/v1/memory:968:39: error: expected unqualified-id >> template static __two test(...); > > The build fails because the 'test' macro is defined in include/my_global.h: > #define test(a) ((a) ? 1 : 0) > yet libc++ standard header defines 'test' as the name of a > function: > template static char test(typename _Up::pointer* = 0); > > MySQL C++ source code files like sql/net_serv.cc #include > before > including . This ordering will result in the 'test' function in > > macro-expanded into nonsense. > > After a casual scan, more C++ source code files might be affacted: > > client/mysql.cc:45:#include > client/mysqlbinlog.cc:58:#include > client/mysqltest.cc:51:#include > client/sql_string.cc:28:#include > ... > > I've prepared an ad hoc patch that modifies include/my_global.h to include > before defining the 'test' macro, so that further including of > > will be uneffective and hence unharmful. I believe this likely to be useful > before there is a fix from upstream mysql or libc++. Now this package > (mysql56-client) and the server counterpart (mysql56-server) build fine. > I'm new > to FreeBSD so I hope someone else could produce a better solution. Any > comments > will be highly appreciated! Thanks. > > Here comes the patch (see also the attachment): > > root@r:/svn/ports/databases/mysql56-client # cat > files/patch-include_my_global.h > --- include/my_global.h.orig 2013-10-13 22:22:33.000000000 +0800 > +++ include/my_global.h 2013-10-13 22:26:57.000000000 +0800 > @@ -460,6 +460,13 @@ > typedef unsigned short ushort; > #endif > > +/* the macro test() below will break libc++ standard header which > + defines function named 'test'; fix it in an ad hoc manner by including > the > + header before definition of the macro. */ > +#ifdef __cplusplus > +#include > +#endif > + > #define swap_variables(t, a, b) { t dummy; dummy= a; a= b; b= dummy; } > #define test(a) ((a) ? 1 : 0) > #define set_if_bigger(a,b) do { if ((a) < (b)) (a)=(b); } while(0) Please update to latest HEAD (about mid last week) and to latest portstree because the issues are already fixed in libc++ and the mysql 5.6 port. Btw your analysis is correct but I have chosen a less intrusive fix in libc++ memory to rename that internal test function and another patch to mysql 5.6. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 18:18:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A3C31F9C for ; Sun, 13 Oct 2013 18:18:27 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 688DD206D for ; Sun, 13 Oct 2013 18:18:27 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id j1so3973912oag.9 for ; Sun, 13 Oct 2013 11:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+6dCm+P+qK9y7FJgevFVVRVWIr7QOQMet+vCt7IP/bI=; b=Qx+s2MStNHp8bj4iZ/s02Lsl4YIDIisKtDAav/g3OnHAzJ+dUla+R11w0SILVDswMw gNTtV2lez2gbWZezGUSt+pBHF2zxnIdWX4ukdmt0cQ94K4Svwk/gbZ/2A/TO4EGawc5b J2rUCxDiX/TQcWVz7asCMIp6NzcadT7zk93nASzQZUhynFGBwMqjboyfRKwyvI9F4/7C tFMJnhDClcVn92FmDn6tSnzO4wufjmtxFAx2W/X4w9SL8l+UqqW/FT+lZeGzDcppOfkt CLE0098mF6BnwNfZLfK7ml5ZSvbAsllQTwIzdu3aau/N5k3FKyTCGzIrbMS4vE4/mlG3 hCbw== MIME-Version: 1.0 X-Received: by 10.60.136.226 with SMTP id qd2mr24495300oeb.20.1381688306620; Sun, 13 Oct 2013 11:18:26 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Sun, 13 Oct 2013 11:18:26 -0700 (PDT) In-Reply-To: <20131013164731.GA6981@troutmask.apl.washington.edu> References: <20131012032258.GA98799@troutmask.apl.washington.edu> <20131012215729.GA2932@troutmask.apl.washington.edu> <20131013063124.GA4498@troutmask.apl.washington.edu> <20131013164731.GA6981@troutmask.apl.washington.edu> Date: Sun, 13 Oct 2013 14:18:26 -0400 Message-ID: Subject: Re: /usr/src/lib/msun errors From: Joe Nosay To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 18:18:27 -0000 On Sun, Oct 13, 2013 at 12:47 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Sun, Oct 13, 2013 at 11:57:22AM -0400, Joe Nosay wrote: > > I have a snapshot saved proving that I am not top posting and only using > > the bottom reply box. I did not know that gmail automatically top posts > > replies. I am willing to take a polygraph test to prove I am telling the > > truth. Steve Kargl, you think that I am lying but I have proof right > here. > > I have proof too. > > http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045473.html > http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045474.html > http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045477.html > http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045487.html > > -- > Steve > Read the rest of this thread. Learn that each person processes and learns information- depending on type and environment- at different rates and with different methods. I have twelve years of speaking three different languages; yet, I am quite aware that I can mess up, that others do know more than me, and that each person learns at a different rate. I am willing to take personal email- and I give you permission to CC it to the list- if you want to discuss this subject any further. It is time that this thread returns to the original subject matter. The solution seems to be reinstalling everything starting with the base. There are many changes and building on the older CURRENT is not a good idea. My apologies to those who were caught up in this thread. From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 19:11:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5763EB0 for ; Sun, 13 Oct 2013 19:11:17 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8549122BE for ; Sun, 13 Oct 2013 19:11:17 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cb5so3201168wib.4 for ; Sun, 13 Oct 2013 12:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=paliA57AKjs+OoF1G2fdvjFHJLmevqBRrBwcbIMTjnQ=; b=iFYqt2YtR1o9bjTyLmr5sxuI19t9ZaXRbSEAt+v7KOnDN7PadVPzUDtUbbRdZsotIB +iD9JOSQ5UuaCkl4L9d8ZbeKxTXR4vGT4z6krTvwDtbTfQjfLoVLXxGssDh4XXkrUIaW lxkJEX3IOF/j6gfro/4csjNUfW6kCPt8EIY53XKBn+LWNr5gKrjbPb/qbP8Vw7xE41Ye nkxsmESwoPP6/hYqnr7Nex3HMzJKBX52GPt4gHIWsM84Q/e8tXIoPMqFjoAXwdQstT/H JSgADRn7+wVs3G92GWcMjfn34VohLBxMdGU4D4/ibhiefD/7fHOgJWgK01+OAboQsOn9 GnzA== X-Received: by 10.180.79.200 with SMTP id l8mr11719178wix.44.1381691475867; Sun, 13 Oct 2013 12:11:15 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.236.131 with HTTP; Sun, 13 Oct 2013 12:10:55 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 13 Oct 2013 21:10:55 +0200 X-Google-Sender-Auth: 1hlVx4f4fL4fz4Bcbu3e_5jv-OA Message-ID: Subject: Process stuck in D+ state To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 19:11:18 -0000 I've got a frequent problem on my desktop (FreeBSD 10.0-ALPHA5 #8 r256200): After few hours I can't acces to one of my folder: A simple "ls" in this folder stucks, and all filesystem information started after (df, fstat) stuck too in D+. SIGINFO report this usage for these processes: load: 0.15 cmd: ls 15716 [rpcrecon] 217.89r 0.00u 0.00s 0% 2440k load: 0.34 cmd: ls 15716 [connec] 2376.60r 0.00u 0.00s 0% 0k load: 0.40 cmd: ls 15716 [connec] 2379.80r 0.00u 0.00s 0% 0k load: 0.40 cmd: ls 15716 [connec] 2379.92r 0.00u 0.00s 0% 0k load: 0.37 cmd: ls 15716 [rpcrecon] 2850.26r 0.00u 0.00s 0% 0k load: 0.37 cmd: ls 15716 [rpcrecon] 2850.39r 0.00u 0.00s 0% 0k load: 0.40 cmd: fstat 15781 [rpcrecon] 2842.08r 0.00u 0.01s 0% 0k load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.35r 0.00u 0.01s 0% 0k load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.48r 0.00u 0.01s 0% 0k load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.63r 0.00u 0.01s 0% 0k load: 0.24 cmd: df 15919 [connec] 1047.98r 0.00u 0.00s 0% 0k load: 0.22 cmd: df 15919 [connec] 1054.22r 0.00u 0.00s 0% 0k and the PS status: olivier 15919 0.0 0.0 14400 16 7 D+ 7:06PM 0:00.01 df -h olivier 15781 0.0 0.0 20708 16 6 D+ 6:26PM 0:00.02 fstat olivier 15651 0.0 0.0 16784 16 4 D+ 6:25PM 0:00.00 ls My desktop use a geli system and JSU, nothing special, here are the mount point: /dev/ada1p3.eli on / (ufs, local, noatime, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/gpt/boot on /boot2 (ufs, local, noatime, soft-updates) What kind of commands can I use for getting more troubleshooting information next time ? Thanks From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 21:50:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06B8AF38 for ; Sun, 13 Oct 2013 21:50:00 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm21-vm10.bullet.mail.gq1.yahoo.com (nm21-vm10.bullet.mail.gq1.yahoo.com [98.136.217.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F6E82904 for ; Sun, 13 Oct 2013 21:49:59 +0000 (UTC) Received: from [98.137.12.188] by nm21.bullet.mail.gq1.yahoo.com with NNFMP; 13 Oct 2013 21:43:24 -0000 Received: from [208.71.42.204] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 13 Oct 2013 21:43:24 -0000 Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP; 13 Oct 2013 21:43:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381700604; bh=sYYbiH9gRaG+LXbN9cBGXnLy0VeCPNw5zYp+q+9AqZk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=5Ng2WNPeHMBfIUhlBhv5dVgZac8+jbe1chCY/cArE/APV2rmouQGC5Ggx+HdDBgo3eK0DglJxmVVdCtANO9aoeS6EL016WcvecXJPdJxsZdVobQn30stYGSXfgD45DD1bUlsqTqKtqUfOX0tB5UlLuCA+z/aQy0p+202Qu6XFaM= X-Yahoo-Newman-Id: 14835.56934.bm@smtp215.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mXMScNAVM1la0AeM2CfRmZBRlggVd.QOBEOgHJwH0g4_1vq B.bsGy28wyueG9Cz4Y0iVuOHR6hhFO0fkbGfYwwpSkUwfSMQ2gzm6.Q8i.wN 0YW8emgnqlZN8.YwaW8Lt9jAE9NAjBzaeZGvhwdeLJXi7OPFxlOkVM7TGw8F CVy_pRSKeqNVL7LFtwfw8mbYAAgl.zPIolKmuZBVsNOqJtsF2MjvIaZGeP08 K.G0uAT7sPHGtWcFNieNLLrV3DJMdLDLB_wF9uU6qcFwE34AIYUvOfZZIifn 7MRvnvf244nCNDFsBhLwT21iJBmhmGroxZvTXFAzgVt9TqOI3es8FbCXauAk Pmh6eGMVMsa767Vm17GS7mbGCkT8FWGLKwC5X7Xcm.o3NqezkPSupUEm6p.R tJGGKqUP.HfL4JUx4oHFq1XBIR68oApgpTpI5z0qJRz9vrJYPrm7XCr8V3B_ VFkCUlE9iqWnv7wVE7YyrNgwYyO5Snlaj4gQ42DVwhvtX0LZHLnjrPVvpvC_ _5RLliyulX4rMz7WKk_kLTDuvftomqZyXHeWip2lMzS_w1h2weUIK60OpZA- - X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.100.228] (sean_bruno@24.23.220.111 with ) by smtp215.mail.gq1.yahoo.com with SMTP; 13 Oct 2013 14:43:23 -0700 PDT Subject: Re: i386-wine + 10.0 From: Sean Bruno To: Tomasz Kowalczyk In-Reply-To: <4954264.LLnWvSthtt@tyson.x64.me> References: <1381533825.2273.0.camel@localhost> <4954264.LLnWvSthtt@tyson.x64.me> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fj9fv/bhLqN1vYSpiBTO" Date: Sun, 13 Oct 2013 14:43:23 -0700 Message-ID: <1381700603.1623.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@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: Sun, 13 Oct 2013 21:50:00 -0000 --=-fj9fv/bhLqN1vYSpiBTO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sat, 2013-10-12 at 13:12 +0200, Tomasz Kowalczyk wrote: > > When I try to run simple windows things I get: > > err:module:load_builtin_dll failed to load .so lib for builtin > > L"winex11.drv": /usr/local/lib/libXext.so.6: unsupported file layout >=20 > Think I had to add: >=20 > /usr/local/lib /usr/local/lib32 >=20 > to /etc/libmap32.conf,=20 Yepper. This was it. Thank you. Sean "grumbling at ports" Bruno --=-fj9fv/bhLqN1vYSpiBTO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSWxP3AAoJEBkJRdwI6BaHiPoIAIC9nuo/jfB2qGQQ09Tt7XGz PXldeb+mhySgt8ddTDZl/jLXgkkiMoZUoneThh+AyDVI7qy71Usznyslz1Ry3dVO NKFYFJZmQcBaCcBB3YTMy4xScDaAEjSv1mwhjqOHbwrH9ozsuoRMQSvDv6UjZQUa GM0Eb/i/Ri5cLaPoP05RTiq9xMeWDkDZCmFl/YMgaknzLbipUK0aIPJuS4NAoV1S NbohXOn4e6Mv2KoCOvtMRyfgWazlnDGM9FYW4Sd36gz+AEIugSUGRn5txLCLfgTA WTDD//FTsD5O7V1e7iScubvd/nUPYePhJF6StWWpSI9uV4n8V5D62oa/La2BbQo= =MaaW -----END PGP SIGNATURE----- --=-fj9fv/bhLqN1vYSpiBTO-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 22:59:20 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3E2FB357 for ; Sun, 13 Oct 2013 22:59:20 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id F07A62BDA for ; Sun, 13 Oct 2013 22:59:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:content-type; s=smtpapi; bh=fSnyVSMbFX3vfIXJk1NRyvLxeho=; b=Ne0LvsVNdYfUQPDkN9/4k6IkorX1q wF+KANV118eM949QzPousgHH+pxWLYr4YOemmLTMpELu7c0b5Rgw0B174YUi4w7Z BauucggFMKpuNQVgdp6J/szIp9aq02oFL27XkBjLt6YlexZeGPLdBLzzZ1kjTlQn 09fft1GIEXrj7M= Received: by mf105 with SMTP id mf105.22678.525B25C01 Sun, 13 Oct 2013 22:59:12 +0000 (GMT) Received: from mi17.sendgrid.net ([UNAVAILABLE]. [10.60.208.25]) by 10.60.208.6:2500 (trex/4.8.23); Sun, 13 Oct 2013 22:59:12 GMT Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi17 (SG) with ESMTP id 141b40b7800.18a.fb5a86 for ; Sun, 13 Oct 2013 22:59:12 +0000 (UTC) Received: (qmail 51883 invoked from network); 13 Oct 2013 22:59:11 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 13 Oct 2013 22:59:11 -0000 Received: (qmail 4131 invoked from network); 13 Oct 2013 22:58:23 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 13 Oct 2013 22:58:23 -0000 Message-ID: <525B258F.3030403@freebsd.org> Date: Sun, 13 Oct 2013 15:58:23 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: FreeBSD current , freebsd-rc@freebsd.org Subject: RFC: support for "first boot" rc.d scripts X-Enigmail-Version: 1.5.2 Content-Type: multipart/mixed; boundary="------------040902090405000607020909" X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wtiYLsweVOuFgAW9niUFk5ZQqk3CKx3WiLxLG14wPykUMiBzb93P5DsUsbDOrkIDnzhE0H9l5FCuo6i+9/Hvym2CWkPqfSFS2GtuCru7iwgJw8= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 22:59:20 -0000 This is a multi-part message in MIME format. --------------040902090405000607020909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, I've attached a very simple patch which makes /etc/rc: 1. Skip any rc.d scripts with the "firstboot" keyword if /var/db/firstboot does not exist, 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after running rc.d scripts, reboot. 3. Delete /var/db/firstboot (and firstboot-reboot) after the first boot. The purpose of this is to support "run on first boot" rc.d scripts. These can be useful for both virtual machines and embedded systems; unlike conventional desktops and servers, these may have a lengthy gap between "installing" and "turning on" the system. As examples of what such scripts could do: * In Amazon EC2, I use a "first boot" script to download an SSH public key from EC2 so that users can log in to newly provisioned EC2 instances. * Now that (starting from 10.0-BETA1) it is possible to use FreeBSD Update to update everything on EC2 instances, I'm planning on writing a script which runs 'freebsd-update fetch install' when the system first boots, and then reboots if there were updates installed. (I imagine this would be useful to other embedded / VM providers too.) * Once packages are provided (properly) for 10.0 I'd like to allow people to specify a list of packages they want installed onto an EC2 instance and have them downloaded and installed when the EC2 instance launches. I'd like to get this into HEAD in the near future in the hope that I can convince re@ that this is a simple enough (and safe enough) change to merge before 10.0-RELEASE. Comments? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------040902090405000607020909 Content-Type: text/plain; charset=us-ascii; name="firstboot.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="firstboot.patch" Index: etc/rc =================================================================== --- etc/rc (revision 256432) +++ etc/rc (working copy) @@ -81,6 +81,9 @@ skip="$skip -s nojailvnet" fi fi +if ! [ -e /var/db/firstboot ]; then + skip="$skip -s firstboot" +fi # Do a first pass to get everything up to $early_late_divider so that # we can do a second pass that includes $local_startup directories @@ -116,6 +119,13 @@ run_rc_script ${_rc_elem} ${_boot} done +if [ -e /var/db/firstboot ]; then + rm /var/db/firstboot + if [ -e /var/db/firstboot-reboot ]; then + rm /var/db/firstboot-reboot + kill -INT 1 + fi +fi echo '' date exit 0 --------------040902090405000607020909-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 23:14:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 623605B8 for ; Sun, 13 Oct 2013 23:14:58 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC662CA3 for ; Sun, 13 Oct 2013 23:14:55 +0000 (UTC) Received: from [192.168.1.105] (S01060015e9b562c7.hm.shawcable.net [50.70.17.171]) (Authenticated sender: roleaccount@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 246123794E for ; Sun, 13 Oct 2013 23:14:48 +0000 (UTC) Message-ID: <525B2967.9060404@allanjude.com> Date: Sun, 13 Oct 2013 19:14:47 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Process stuck in D+ state References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 23:14:58 -0000 On 2013-10-13 15:10, Olivier Cochard-Labbé wrote: > I've got a frequent problem on my desktop (FreeBSD 10.0-ALPHA5 #8 r256200): > After few hours I can't acces to one of my folder: A simple "ls" in > this folder stucks, and all filesystem information started after (df, > fstat) stuck too in D+. > > SIGINFO report this usage for these processes: > > load: 0.15 cmd: ls 15716 [rpcrecon] 217.89r 0.00u 0.00s 0% 2440k > load: 0.34 cmd: ls 15716 [connec] 2376.60r 0.00u 0.00s 0% 0k > load: 0.40 cmd: ls 15716 [connec] 2379.80r 0.00u 0.00s 0% 0k > load: 0.40 cmd: ls 15716 [connec] 2379.92r 0.00u 0.00s 0% 0k > load: 0.37 cmd: ls 15716 [rpcrecon] 2850.26r 0.00u 0.00s 0% 0k > load: 0.37 cmd: ls 15716 [rpcrecon] 2850.39r 0.00u 0.00s 0% 0k > > load: 0.40 cmd: fstat 15781 [rpcrecon] 2842.08r 0.00u 0.01s 0% 0k > load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.35r 0.00u 0.01s 0% 0k > load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.48r 0.00u 0.01s 0% 0k > load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.63r 0.00u 0.01s 0% 0k > > load: 0.24 cmd: df 15919 [connec] 1047.98r 0.00u 0.00s 0% 0k > load: 0.22 cmd: df 15919 [connec] 1054.22r 0.00u 0.00s 0% 0k > > and the PS status: > > olivier 15919 0.0 0.0 14400 16 7 D+ 7:06PM 0:00.01 df -h > olivier 15781 0.0 0.0 20708 16 6 D+ 6:26PM 0:00.02 fstat > olivier 15651 0.0 0.0 16784 16 4 D+ 6:25PM 0:00.00 ls > > My desktop use a geli system and JSU, nothing special, here are the mount point: > /dev/ada1p3.eli on / (ufs, local, noatime, journaled soft-updates) > devfs on /dev (devfs, local, multilabel) > /dev/gpt/boot on /boot2 (ufs, local, noatime, soft-updates) > > What kind of commands can I use for getting more troubleshooting( > information next time ? > > 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" Looking at the process states, connect and rpcreconnect, seem to suggest something involving yp/nis or NFS or some such. try: ls -n (skip uid to symbolic name lookup) and see if it behaves any differently From owner-freebsd-current@FreeBSD.ORG Sun Oct 13 23:32:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 134A8875 for ; Sun, 13 Oct 2013 23:32:08 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id E13662D43 for ; Sun, 13 Oct 2013 23:32:07 +0000 (UTC) Received: from [192.168.1.105] (S01060015e9b562c7.hm.shawcable.net [50.70.17.171]) (Authenticated sender: roleaccount@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5C4E037980 for ; Sun, 13 Oct 2013 23:32:06 +0000 (UTC) Message-ID: <525B2D75.7080803@allanjude.com> Date: Sun, 13 Oct 2013 19:32:05 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> In-Reply-To: <525B258F.3030403@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 13 Oct 2013 23:32:08 -0000 On 2013-10-13 18:58, Colin Percival wrote: > Hi all, > > I've attached a very simple patch which makes /etc/rc: > > 1. Skip any rc.d scripts with the "firstboot" keyword if /var/db/firstboot > does not exist, > > 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after running rc.d > scripts, reboot. > > 3. Delete /var/db/firstboot (and firstboot-reboot) after the first boot. > > The purpose of this is to support "run on first boot" rc.d scripts. These can > be useful for both virtual machines and embedded systems; unlike conventional > desktops and servers, these may have a lengthy gap between "installing" and > "turning on" the system. > > As examples of what such scripts could do: > > * In Amazon EC2, I use a "first boot" script to download an SSH public key > from EC2 so that users can log in to newly provisioned EC2 instances. > > * Now that (starting from 10.0-BETA1) it is possible to use FreeBSD Update > to update everything on EC2 instances, I'm planning on writing a script which > runs 'freebsd-update fetch install' when the system first boots, and then > reboots if there were updates installed. (I imagine this would be useful > to other embedded / VM providers too.) > > * Once packages are provided (properly) for 10.0 I'd like to allow people to > specify a list of packages they want installed onto an EC2 instance and have > them downloaded and installed when the EC2 instance launches. > > I'd like to get this into HEAD in the near future in the hope that I can > convince re@ that this is a simple enough (and safe enough) change to merge > before 10.0-RELEASE. > > Comments? > > > > _______________________________________________ > 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 looks extremely useful. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 00:47:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E277D50B for ; Mon, 14 Oct 2013 00:47:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B56812FBA for ; Mon, 14 Oct 2013 00:47:44 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id r9E0lewd058846 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 13 Oct 2013 17:47:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <525B3F33.4030103@freebsd.org> Date: Mon, 14 Oct 2013 08:47:47 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: What happened to nslookup? References: <0E.82.01315.25778525@cdptpa-oedge03> <20131011221302.GH1611@albert.catwhisker.org> <54.9B.16944.480B8525@cdptpa-oedge02> <20131012022825.GJ1611@albert.catwhisker.org> In-Reply-To: <20131012022825.GJ1611@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 00:47:44 -0000 On 10/12/13 10:28 AM, David Wolfskill wrote: > On Sat, Oct 12, 2013 at 02:14:28AM +0000, Thomas Mueller wrote: >> ... >> Thanks for info! > Glad to help. > >> I saw that bind was removed from the current branch because of security problems, > It was removed, but I believe that there was a bit more to it than > "security problems." I think it was just a personal preference that managed to get communicated as "important", and no-one had the energy or will to argue about it. (that's the way software projects often work.. loudest and most persistent voice wins). >> but didn't know nslookup was part of BIND. >> >> Now I see in $PORTSDIR/dns/bind-tools/pkg-plist >> >> bin/dig >> bin/host >> bin/nslookup >> >> so host is also part of BIND? > :-} The version of host we had when BIND was part of base was part of > BIND, yes. Looking in src/usr.bin/host/Makefile, I see: > > # $FreeBSD: head/usr.bin/host/Makefile 255949 2013-09-30 17:23:45Z des $ > > LDNSDIR= ${.CURDIR}/../../contrib/ldns > LDNSHOSTDIR= ${.CURDIR}/../../contrib/ldns-host > ... > > which indicates that this is a re-implementation of "host" as > provided by contrib/ldns. > >> I will remember to use "host" in the future. > I have found it generally easy to use (easier by far than nslookup). > > Peace, > david From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 00:48:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2E4E2631; Mon, 14 Oct 2013 00:48:45 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C97FD2FCD; Mon, 14 Oct 2013 00:48:43 +0000 (UTC) Received: from [10.0.2.15] (dsl-66-225-161-151.vianet.ca [66.225.161.151]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.4) with ESMTP id r9E0YE9C060375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Oct 2013 20:34:14 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Sun, 13 Oct 2013 20:34:15 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: freebsd-current@freebsd.org Subject: ZFS panic (dn->dn_datablkshift != 0) with r256304 and send/recv 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: avg@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 00:48:45 -0000 I get the following assert failure with a recent current: panic: solaris assert: dn->dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 # uname -a FreeBSD freebsd10 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r256304: Thu Oct 10 19:38:55 EDT 2013 kwhite@freebsd10:/tank/obj/usr/src/sys/GENERIC amd64 # kgdb /boot/kernel/kernel /var/crash/vmcore.last 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 "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: ... <118># zfs send -vi tank/RPI@20131004 tank/RPI@20131013 | zfs recv -vF m_tank/RPI@20131013 <118>send from @20131004 to tank/RPI@20131013 estimated size is 85.0M <118>total estimated size is 85.0M <118>TIME SENT SNAPSHOT <118>receiving incremental stream of tank/RPI@20131013 into m_tank/RPI@20131013 <118>19:45:12 5.90M tank/RPI@20131013 <118>19:45:13 36.4M tank/RPI@20131013 <118>19:45:15 38.4M tank/RPI@20131013 <118>19:45:16 41.3M tank/RPI@20131013 panic: solaris assert: dn->dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00977711a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0097771250 vpanic() at vpanic+0x126/frame 0xfffffe0097771290 panic() at panic+0x43/frame 0xfffffe00977712f0 assfail() at assfail+0x22/frame 0xfffffe0097771300 dmu_tx_hold_free() at dmu_tx_hold_free+0x162/frame 0xfffffe00977713e0 dmu_free_long_range() at dmu_free_long_range+0x244/frame 0xfffffe0097771450 dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfffffe0097771480 dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfffffe00977716b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfffffe0097771920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfffffe00977719c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfffffe0097771a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfffffe0097771a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfffffe0097771ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe0097771bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0097771bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019f49ca, rsp = 0x7fffffff9438, rbp = 0x7fffffff94c0 --- KDB: enter: panic Uptime: 7m30s ... (kgdb) where #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff808b88b7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff808b8dc5 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff808b8e13 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:683 #4 0xffffffff81dd1222 in assfail (a=, f=, l=) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 #5 0xffffffff81c847c2 in dmu_tx_hold_free (tx=0xfffff800118bda00, object=, off=, len=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c:638 #6 0xffffffff81c78124 in dmu_free_long_range (os=0xfffff8000580f000, object=, offset=0, length=18446744073709551615) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:654 #7 0xffffffff81c781df in dmu_free_long_object (os=0xfffff8000580f000, object=66055) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:700 #8 0xffffffff81c7c39e in dmu_recv_stream (drc=0xfffffe0097771728, fp=, voffp=0xfffffe0097771718, cleanup_fd=8, action_handlep=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1289 #9 0xffffffff81d0a1fc in zfs_ioc_recv (zc=0xfffffe0001830000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4102 #10 0xffffffff81d054ea in zfsdev_ioctl (dev=, zcmd=, arg=, flag=, td=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5960 #11 0xffffffff807b0d40 in devfs_ioctl_f (fp=0xfffff80005304dc0, com=3222821403, data=0xfffff800027abc40, cred=, td=0xfffff8000524f000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #12 0xffffffff8090ffea in kern_ioctl (td=0xfffff8000524f000, fd=, com=0) at file.h:319 #13 0xffffffff8090fccf in sys_ioctl (td=0xfffff8000524f000, uap=0xfffffe0097771b80) at /usr/src/sys/kern/sys_generic.c:698 #14 0xffffffff80cb2e05 in amd64_syscall (td=0xfffff8000524f000, traced=0) at subr_syscall.c:134 #15 0xffffffff80c979fb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #16 0x00000008019f49ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ...keith From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 04:57:40 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 82B5EE46 for ; Mon, 14 Oct 2013 04:57:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B8CB0299A for ; Mon, 14 Oct 2013 04:57:39 +0000 (UTC) Received: from porto.starpoint.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 HAA10536; Mon, 14 Oct 2013 07:57:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VVaDf-000LFn-Dp; Mon, 14 Oct 2013 07:57:28 +0300 Message-ID: <525B797C.4050500@FreeBSD.org> Date: Mon, 14 Oct 2013 07:56:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Keith White , freebsd-current@FreeBSD.org Subject: Re: ZFS panic (dn->dn_datablkshift != 0) with r256304 and send/recv References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 04:57:40 -0000 on 14/10/2013 03:34 Keith White said the following: > I get the following assert failure with a recent current: > > panic: solaris assert: dn->dn_datablkshift != 0, file: > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, > line: 638 Please see https://www.illumos.org/issues/4188 The current best known fix is to simply drop the assertion. Though, I am not entirely sure if this will be the final solution. I'll double-check with Matt. > # uname -a > FreeBSD freebsd10 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r256304: Thu Oct 10 > 19:38:55 EDT 2013 kwhite@freebsd10:/tank/obj/usr/src/sys/GENERIC amd64 > > # kgdb /boot/kernel/kernel /var/crash/vmcore.last > 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 "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > ... > <118># zfs send -vi tank/RPI@20131004 tank/RPI@20131013 | zfs recv -vF > m_tank/RPI@20131013 > <118>send from @20131004 to tank/RPI@20131013 estimated size is 85.0M > <118>total estimated size is 85.0M > <118>TIME SENT SNAPSHOT > <118>receiving incremental stream of tank/RPI@20131013 into m_tank/RPI@20131013 > <118>19:45:12 5.90M tank/RPI@20131013 > <118>19:45:13 36.4M tank/RPI@20131013 > <118>19:45:15 38.4M tank/RPI@20131013 > <118>19:45:16 41.3M tank/RPI@20131013 > panic: solaris assert: dn->dn_datablkshift != 0, file: > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, > line: 638 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00977711a0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0097771250 > vpanic() at vpanic+0x126/frame 0xfffffe0097771290 > panic() at panic+0x43/frame 0xfffffe00977712f0 > assfail() at assfail+0x22/frame 0xfffffe0097771300 > dmu_tx_hold_free() at dmu_tx_hold_free+0x162/frame 0xfffffe00977713e0 > dmu_free_long_range() at dmu_free_long_range+0x244/frame 0xfffffe0097771450 > dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfffffe0097771480 > dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfffffe00977716b0 > zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfffffe0097771920 > zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfffffe00977719c0 > devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfffffe0097771a20 > kern_ioctl() at kern_ioctl+0x2ca/frame 0xfffffe0097771a90 > sys_ioctl() at sys_ioctl+0x11f/frame 0xfffffe0097771ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe0097771bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0097771bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019f49ca, rsp = > 0x7fffffff9438, rbp = 0x7fffffff94c0 --- > KDB: enter: panic > Uptime: 7m30s > ... > (kgdb) where > #0 doadump (textdump=1) at pcpu.h:219 > #1 0xffffffff808b88b7 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:447 > #2 0xffffffff808b8dc5 in vpanic (fmt=, ap= out>) at /usr/src/sys/kern/kern_shutdown.c:754 > #3 0xffffffff808b8e13 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:683 > #4 0xffffffff81dd1222 in assfail (a=, f= out>, l=) at > /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:81 > > #5 0xffffffff81c847c2 in dmu_tx_hold_free (tx=0xfffff800118bda00, object= optimized out>, off=, len=) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c:638 > > #6 0xffffffff81c78124 in dmu_free_long_range (os=0xfffff8000580f000, > object=, offset=0, length=18446744073709551615) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:654 > #7 0xffffffff81c781df in dmu_free_long_object (os=0xfffff8000580f000, > object=66055) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:700 > #8 0xffffffff81c7c39e in dmu_recv_stream (drc=0xfffffe0097771728, fp= optimized out>, voffp=0xfffffe0097771718, cleanup_fd=8, action_handlep= optimized out>) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c:1289 > > #9 0xffffffff81d0a1fc in zfs_ioc_recv (zc=0xfffffe0001830000) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:4102 > > #10 0xffffffff81d054ea in zfsdev_ioctl (dev=, zcmd= optimized out>, arg=, flag=, td= optimized out>) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5960 > > #11 0xffffffff807b0d40 in devfs_ioctl_f (fp=0xfffff80005304dc0, com=3222821403, > data=0xfffff800027abc40, cred=, td=0xfffff8000524f000) at > /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #12 0xffffffff8090ffea in kern_ioctl (td=0xfffff8000524f000, fd= out>, com=0) at file.h:319 > #13 0xffffffff8090fccf in sys_ioctl (td=0xfffff8000524f000, > uap=0xfffffe0097771b80) at /usr/src/sys/kern/sys_generic.c:698 > #14 0xffffffff80cb2e05 in amd64_syscall (td=0xfffff8000524f000, traced=0) at > subr_syscall.c:134 > #15 0xffffffff80c979fb in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:391 > #16 0x00000008019f49ca in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > ...keith -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 06:34:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52DA0CCC for ; Mon, 14 Oct 2013 06:34:03 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6E2C2D9D for ; Mon, 14 Oct 2013 06:34:02 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBE6A6.dip0.t-ipconnect.de [217.251.230.166]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r9E6XrBe042269 for ; Mon, 14 Oct 2013 06:33:54 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r9E6XgXl023490 for ; Mon, 14 Oct 2013 08:33:42 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r9E6XZFV054096 for ; Mon, 14 Oct 2013 08:33:42 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310140633.r9E6XZFV054096@fire.js.berklix.net> To: current@freebsd.org Subject: vi drop outs with "Bus error" From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Mon, 14 Oct 2013 08:33:35 +0200 Sender: jhs@berklix.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 06:34:03 -0000 Anyone else seeing vi dropping out after a while with "Bus error" & no core ? Seen on 10.0-ALPHA4 & now on 10.0-ALPHA5 (after buildkernel installkernel buildworld installworld ) It's not hardware, the laptop is stable & has compiled 594 ports so far, cd /usr/bin ; ls -l nvi* -r-xr-xr-x 1 root wheel 402064 Oct 12 02:42 nvi.4* -r-xr-xr-x 1 root wheel 402432 Oct 12 02:42 nvi.5* file nvi* nvi.4: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically \ linked (uses shared libs), for FreeBSD 10.0 (1000055), stripped nvi.5: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically \ linked (uses shared libs), for FreeBSD 10.0 (1000055), stripped Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 07:43:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6069AB3F; Mon, 14 Oct 2013 07:43:14 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from winston.madpilot.net (winston.madpilot.net [78.47.75.155]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7612081; Mon, 14 Oct 2013 07:43:13 +0000 (UTC) Received: from winston.madpilot.net (localhost [127.0.0.1]) by winston.madpilot.net (Postfix) with ESMTP id 3cysFQ6SK5zFTXL; Mon, 14 Oct 2013 09:43:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at madpilot.net Received: from winston.madpilot.net ([127.0.0.1]) by winston.madpilot.net (winston.madpilot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dGWl_rRt2Le; Mon, 14 Oct 2013 09:43:05 +0200 (CEST) Received: from vwg82.hq.ignesti.it (unknown [77.246.14.163]) by winston.madpilot.net (Postfix) with ESMTPSA; Mon, 14 Oct 2013 09:43:05 +0200 (CEST) Message-ID: <525BA085.5060500@FreeBSD.org> Date: Mon, 14 Oct 2013 09:43:01 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Joe Nosay , ports , freebsd-current Subject: Re: /usr/ports/UPDATING entry September 04, 2013 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 07:43:14 -0000 On 10/13/13 18:40, Joe Nosay wrote: > Will the pkg upgrade work with applications built from ports and not pkg > add $APPLICATION? I'm not sure What you mean. the "pkg upgrade" command works only using binary packages, which can come and "official" repository or your own one. This is going to work. If you have a system where you used to build packages yourself and want to change to binary packages, things are more complicated. First of all if you have any port built with custom options you are going to loose those customizations, since the binary packages don't have them. I think pkg will try to handle that upgrade but I have never tried, it could work but you could also end up with come misalignment in your ports. It is generally not a good idea to mix ports and pkgs, it can work but problems will come up. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 07:57:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0BC39F9A; Mon, 14 Oct 2013 07:57:57 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1F6E2156; Mon, 14 Oct 2013 07:57:56 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wp18so267465obc.38 for ; Mon, 14 Oct 2013 00:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PzCL79TBDm5gPFxqHxLXhC/TqzUGqz7pMUnJ4MZupQs=; b=dtIjh+OwZn/GCZEs3j8F24Rw1/AYSmEpC2RZGmG54olVYRCdgrxH+S+DOdWSKDkMz9 vz5FRD44obz+O5HuYeSGoQ0vZB9Zd9sl1c2oKq1DedtGqOr1MOoVnvgBpTZ9lBif+H7R DtMcq67MjWstza3RTYQjqTm6ZoFzIutW0vhK+fdo0DQLT90CEWgnY8F1V5dxJps38/1Y XK/7BE3xpXPLeumadUzRTPp013K8e4fsbV59YjbzCtr24WTN7zhKZXweThVf1fKZ1+MR 7skQYt/JYKX95c3P3N8kTpkkJW+qZsmCZvWoSOpjybNRxJsE6fGcK/4bjbe0XPGCRr7F W9rQ== MIME-Version: 1.0 X-Received: by 10.182.213.97 with SMTP id nr1mr360926obc.48.1381737475985; Mon, 14 Oct 2013 00:57:55 -0700 (PDT) Received: by 10.182.78.100 with HTTP; Mon, 14 Oct 2013 00:57:55 -0700 (PDT) In-Reply-To: <525BA085.5060500@FreeBSD.org> References: <525BA085.5060500@FreeBSD.org> Date: Mon, 14 Oct 2013 03:57:55 -0400 Message-ID: Subject: Re: /usr/ports/UPDATING entry September 04, 2013 From: Joe Nosay To: Guido Falsi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ports , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 07:57:57 -0000 On Mon, Oct 14, 2013 at 3:43 AM, Guido Falsi wrote: > On 10/13/13 18:40, Joe Nosay wrote: > >> Will the pkg upgrade work with applications built from ports and not pkg >> add $APPLICATION? >> > > I'm not sure What you mean. > > the "pkg upgrade" command works only using binary packages, which can come > and "official" repository or your own one. > > This is going to work. > > If you have a system where you used to build packages yourself and want to > change to binary packages, things are more complicated. > > First of all if you have any port built with custom options you are going > to loose those customizations, since the binary packages don't have them. > > I think pkg will try to handle that upgrade but I have never tried, it > could work but you could also end up with come misalignment in your ports. > > It is generally not a good idea to mix ports and pkgs, it can work but > problems will come up. > > -- > Guido Falsi > Thanks much. From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 07:59:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 975BB206; Mon, 14 Oct 2013 07:59:54 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [IPv6:2a02:2308::216:3eff:feec:b1b5]) by mx1.freebsd.org (Postfix) with ESMTP id 4C55D217A; Mon, 14 Oct 2013 07:59:54 +0000 (UTC) Received: from [IPv6:2001:980:530a:1:44c2:cf25:e90c:4287] (unknown [IPv6:2001:980:530a:1:44c2:cf25:e90c:4287]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id 6132F5F2286; Mon, 14 Oct 2013 09:55:54 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: RFC: support for "first boot" rc.d scripts From: Nick Hibma In-Reply-To: <525B258F.3030403@freebsd.org> Date: Mon, 14 Oct 2013 09:59:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> References: <525B258F.3030403@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.1510) Cc: FreeBSD current , freebsd-rc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 07:59:54 -0000 Colin, Sounds useful: We have nanobsd images that configure a hard disk if = present, but obviously only need to be run once. However: NanoBSD stores uses a memory disk for /etc and stores it's = permanent scripts in /conf/* (/etc/rc.initdiskless) and/or /cfg = (NanoBSD) so I doubt whether the 'embedded systems' argument is of much = use, as deleting the script or flagging 'firstboot' is non-permanent. Nick Hibma nick@van-laarhoven.org Want to feel like going on a holiday tomorrow? Try GTD. On 14 Oct 2013, at 00:58, Colin Percival wrote: > Hi all, >=20 > I've attached a very simple patch which makes /etc/rc: >=20 > 1. Skip any rc.d scripts with the "firstboot" keyword if = /var/db/firstboot > does not exist, >=20 > 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after = running rc.d > scripts, reboot. >=20 > 3. Delete /var/db/firstboot (and firstboot-reboot) after the first = boot. >=20 > The purpose of this is to support "run on first boot" rc.d scripts. = These can > be useful for both virtual machines and embedded systems; unlike = conventional > desktops and servers, these may have a lengthy gap between = "installing" and > "turning on" the system. >=20 > As examples of what such scripts could do: >=20 > * In Amazon EC2, I use a "first boot" script to download an SSH public = key > from EC2 so that users can log in to newly provisioned EC2 instances. >=20 > * Now that (starting from 10.0-BETA1) it is possible to use FreeBSD = Update > to update everything on EC2 instances, I'm planning on writing a = script which > runs 'freebsd-update fetch install' when the system first boots, and = then > reboots if there were updates installed. (I imagine this would be = useful > to other embedded / VM providers too.) >=20 > * Once packages are provided (properly) for 10.0 I'd like to allow = people to > specify a list of packages they want installed onto an EC2 instance = and have > them downloaded and installed when the EC2 instance launches. >=20 > I'd like to get this into HEAD in the near future in the hope that I = can > convince re@ that this is a simple enough (and safe enough) change to = merge > before 10.0-RELEASE. >=20 > Comments? >=20 > --=20 > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly = paranoid > _______________________________________________ > 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 Oct 14 08:21:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 319975A9 for ; Mon, 14 Oct 2013 08:21:39 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog104.obsmtp.com (eu1sys200aog104.obsmtp.com [207.126.144.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15D8222AC for ; Mon, 14 Oct 2013 08:21:37 +0000 (UTC) Received: from mail-wg0-f49.google.com ([74.125.82.49]) (using TLSv1) by eu1sys200aob104.postini.com ([207.126.147.11]) with SMTP ID DSNKUlupdXHnnkt5x5lzGnf/bHDv6Caxf41g@postini.com; Mon, 14 Oct 2013 08:21:38 UTC Received: by mail-wg0-f49.google.com with SMTP id x12so4096293wgg.4 for ; Mon, 14 Oct 2013 01:21:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=uwxZb7PVjaWjNVMWUkK8TOj0iG9WB541xcI2oF5tAK0=; b=OiIZLhbHQmfghIRotnCRIMhDfS1fYU6gN4m4+8zGOxExIuKsJnBlVaqf9fAMqYFi57 UCitC+Xux4VxOZP+JcgRtw1SD7INx2PYNTv+IGafz8p3M46Km72eSSXj3f1GB3i28rXV kiq4jnU8cCatBc9CQnmU/aW+5O57uR9oj23LCteSj4DTEh5+luc3j9rxFkAXtDXzTW4Q B/WMv4o+RXvkviZd5wtL/ZdsYyDDCIUZ+3owe97jdQIz3/+9BpUk+Q0zaly8A7vpNIq2 tmpPqpyT2djeMK2zKWUWUu2Q27zB9WlbfI0sTmHaGq2c66DOOSqk6scti4hb+oaLpBsH rfcA== X-Gm-Message-State: ALoCoQmRGMs/Bm9sU9Muo8R+EjHptLMRuZrh/pCkpEaR1fgle1g6/U8DkGajZuR+WwC5f+Zp+it18lf0W9B4gVUzBoHqs6WdvWO159uz6TGvCmmIesNbchEv8yvQRbIvEC+Jr/+zvQZevv6U4AsfsMPBG3f8dW1kELjAecNqWCsECujtplgIidM= X-Received: by 10.180.208.97 with SMTP id md1mr13580947wic.41.1381738869056; Mon, 14 Oct 2013 01:21:09 -0700 (PDT) X-Received: by 10.180.208.97 with SMTP id md1mr13580938wic.41.1381738868955; Mon, 14 Oct 2013 01:21:08 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id jf2sm31806314wic.2.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 01:21:07 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9E8L5LZ014898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Oct 2013 09:21:05 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9E8L55j014897; Mon, 14 Oct 2013 09:21:05 +0100 (BST) (envelope-from mexas) Date: Mon, 14 Oct 2013 09:21:05 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310140821.r9E8L55j014897@mech-cluster241.men.bris.ac.uk> To: davide@freebsd.org, mexas@bris.ac.uk Subject: Re: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks In-Reply-To: Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:21:39 -0000 >From davide.italiano@gmail.com Fri Oct 11 15:39:49 2013 > >If you're not able to get a full dump, a textdump would be enough. >In your DDB scripts just remove the 'call doadump' step and you should >be done, unless I'm missing something. >Please adjust the script as well to include all the informations >requested as mentioned in my previous link, e.g. 'show lockedvnods' is >not mentioned on the example section of textdump(4) manpage but it >could be useful to ease debugging. I still haven't got it right, but I now collected manually some (hopefully) useful info (see below). - here's my /etc/ddb.conf: script lockinfo=show locks; show alllocks; show lockedvnods script kdb.enter.panic=textdump set; capture on; run lockinfo; show locks; show alllocks; show lockedvnods; show pcpu; bt; ps; alltrace; capture off; reset script kdb.enter.witness=run lockinfo Somehow when I get into a debugger, I can only see lockinfo. Why? - I've removed "call doadump", as you see above. Still the dump is being written. I've in /etc/rc.conf: dumpdev=/dev/da4p1 dumpdir=/var/crash ddb_enable=YES Shall I remove dumpdev completely? And leave only dumpdir defined? Thanks Anton db> textdump set textdump set db> capture on db> run lockinfo db:0:lockinfo> show locks db:0:locks> show alllocks db:0:alllocks> show lockedvnods Locked vnodes 0xe0000000123799d0: tag devfs, type VCHR usecount 1, writecount 0, refcount 408 mountedhere 0xe0000000126a4c00 flags (VI_ACTIVE) v_object 0xe000000012788100 ref 0 pages 21330 lock type devfs: EXCL by thread 0xe00000001268e000 (pid 21, syncer, tid 100062) dev da5p1 0xe0000000127d5448: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) v_object 0xe00000001277bc00 ref 0 pages 1 lock type ufs: EXCL by thread 0xe0000000127b5680 (pid 908, ntpd, tid 100080) ino 2889216, on dev da3p1 0xe0000002203c0ce8: tag ufs, type VREG usecount 1, writecount 1, refcount 16 mountedhere 0 flags (VI_ACTIVE) v_object 0xe000000223037700 ref 0 pages 56 lock type ufs: EXCL by thread 0xe00000001557e480 (pid 45384, pkg-static, tid 100133) ino 5780554, on dev da5p1 db> db> show pcpu cpuid = 0 dynamic pcpu = 0x40040040ff13ca80 curthread = 0xe000000011a26d80: pid 0 "deadlkres" curpcb = 0 fpcurthread = none idlethread = 0xe000000011178900: tid 100003 "idle: cpu0" MD: vhpt = 0xe0000040ff000000 MD: lid = 0 MD: clock = 0x214563ccc206 MD: clock_mode = 2 MD: clock_load = 0 MD: stats = 0x9ffc0000010ff130 MD: pmap = 0x9ffc000000eee760 spin locks held: db> db> bt Tracing pid 0 tid 100053 td 0xe000000011a26d80 kdb_enter(0x9ffc000000dc2fd0, 0x9ffc000000dc2fd0, 0x9ffc00000058e6b0, 0x40c) at kdb_enter+0x92 vpanic(0x9ffc000000db8a18, 0xa00000009dca7518) at vpanic+0x2b0 panic(0x9ffc000000db8a18, 0x9ffc000000db8c70, 0xe00000001557fb00, 0xdbd38) at panic+0x80 deadlkres(0xdbd38, 0xe00000001557fb00, 0x9ffc000000dbb648, 0x9ffc000000db89a8) at deadlkres+0x420 fork_exit(0x9ffc000000e0fca0, 0x0, 0xa00000009dca7550) at fork_exit+0x120 enter_userland() at enter_userland db> db> ps pid ppid pgrp uid state wmesg wchan cmd 47482 47176 1092 0 LV+J *pmap pv 0xe000000012402540 sh 47476 35326 1092 0 D+ vm map ( 0xe0000000110adac0 sh 47475 35326 1092 0 S+ piperd 0xe000000222b2f5a8 awk 47474 35326 1092 0 L+ *pmap pv 0xe000000012402540 awk 47335 47329 1092 0 LL+J *pmap pv 0xe000000012402540 cc1 47329 34696 1092 0 SW+J wait 0xe0000002233c3720 xgcc 47176 45981 1092 0 D+J ppwait 0xe0000000156af6d0 sh 46683 46681 1092 0 S+J piperd 0xe0000000127e3340 as 46682 46681 1092 0 LL+J *pmap pv 0xe000000012402540 cc1plus 46681 33402 1092 0 SW+J wait 0xe0000000154c4000 g++ 45981 44152 1092 0 SW+J wait 0xe0000002233c3280 pkg-static 45384 45009 1092 0 L+J *vm page 0xe00000001eff4f00 pkg-static 45009 44866 1092 0 SW+J wait 0xe0000002233c2940 sh 44866 38577 1092 0 SW+J wait 0xe00000001547cde0 make 44152 43869 1092 0 SW+J wait 0xe00000001f2dcde0 sh 43869 37427 1092 0 SW+J wait 0xe00000001549d280 make 39289 38577 1092 0 S+ piperd 0xe00000001556d0d8 tee 38577 1092 1092 0 SW+ wait 0xe0000000154f1280 sh 37813 37427 1092 0 S+ piperd 0xe000000222b2f810 tee 37427 1092 1092 0 SW+ wait 0xe000000012b3c4a0 sh 34696 89091 1092 0 SW+J wait 0xe00000001556e000 gmake 33402 33399 1092 0 SW+J wait 0xe00000001280e4a0 make 33399 33339 1092 0 SW+J wait 0xe0000000129e1720 sh 33339 33337 1092 0 SW+J wait 0xe00000001556e4a0 make 33337 88092 1092 0 SW+ wait 0xe00000001f2dd720 sh 90596 88092 1092 0 S+ piperd 0xe0000000127e3ce0 tee 89091 84462 1092 0 SW+J wait 0xe000000224d20000 gmake 88092 1092 1092 0 D+ vm map ( 0xe0000000110ad9d0 sh 84462 84441 1092 0 SW+J wait 0xe00000001efcd720 gmake 84441 84440 1092 0 SW+J wait 0xe00000001547c000 gmake 84440 84425 1092 0 SW+J wait 0xe00000001f2dc000 sh 84425 84423 1092 0 SW+J wait 0xe000000012b31720 make 84423 74621 1092 0 SW+ wait 0xe00000001280e000 sh 75146 74621 1092 0 S+ piperd 0xe000000012b54000 tee 74621 1092 1092 0 D+ vm map ( 0xe0000000110ad9d0 sh 39253 1151 39253 0 L+ *pmap pv 0xe000000012402540 top 35326 1092 1092 0 S+ wait 0xe0000000154f0000 sh 1151 1150 1151 0 SW+ wait 0xe00000001280f280 sh 1150 1146 1150 1001 SW+ wait 0xe000000012b304a0 su 1146 1145 1146 1001 SWs+ pause 0xe000000012b3c9e8 tcsh 1145 1143 1143 1001 S select 0xe0000000126d4f40 sshd 1143 968 1143 0 Ss select 0xe000000010c299c0 sshd 1092 1050 1092 0 LL+ *pmap pv 0xe000000012402540 sh 1050 1049 1050 0 SW+ wait 0xe000000012b3d720 sh 1049 1045 1049 1001 SW+ wait 0xe00000001280f720 su 1045 1044 1045 1001 SWs+ pause 0xe000000012b3ce88 tcsh 1044 1042 1042 1001 S select 0xe000000010c28e40 sshd 1042 968 1042 0 Ss select 0xe0000000126d5040 sshd 1041 1 1041 0 Ss+ ttyin 0xe00000001121c8a8 getty 1040 1 1 0 S ttydcd 0xe00000001121cce8 getty 1020 1 1020 0 Ss select 0xe000000010c290c0 inetd 979 1 979 0 LLs *pmap pv 0xe000000012402540 cron 974 1 974 25 LLs *pmap pv 0xe000000012402540 sendmail 971 1 971 0 LLs *pmap pv 0xe000000012402540 sendmail 968 1 968 0 Ss select 0xe0000000126d54c0 sshd 908 1 908 0 Ls *vm page 0xe00000001eff4f00 ntpd 827 1 827 0 Ss select 0xe0000000126d56c0 syslogd 818 1 818 0 Ss select 0xe0000000126d5740 ipmon 696 1 696 0 Ss select 0xe0000000126d57c0 devd 181 1 181 0 SWs pause 0xe00000001269a9e8 adjkerntz 23 0 0 0 DL sdflush 0x9ffc000000ed1ff0 [softdepflush] 22 0 0 0 DL vlruwt 0xe000000012409720 [vnlru] 21 0 0 0 LL *vm page 0xe00000001eff4f00 [syncer] 20 0 0 0 DL psleep 0x9ffc000000ed1390 [bufdaemon] 19 0 0 0 DL pgzero 0x9ffc000000ed239c [pagezero] 18 0 0 0 RL [vmdaemon] 17 0 0 0 LL *pmap pv 0xe000000012402540 [pagedaemon] 9 0 0 0 DL ccb_scan 0x9ffc000000ed26a0 [xpt_thrd] 6 0 0 0 DL waiting_ 0x9ffc0000010f33b0 [sctp_iterator] 5 0 0 0 RL (threaded) [zfskern] 100052 Run CPU 1 [l2arc_feed_thread] 100051 D arc_recl 0x9ffc000001538120 [arc_reclaim_thread] 4 0 0 0 DL ispf 0xe000000011a02000 [isp0: fc_thrd0] 3 0 0 0 DL idle 0xa000000000a16000 [mpt_recovery1] 2 0 0 0 DL idle 0xa0000000009fe000 [mpt_recovery0] 16 0 0 0 DL (threaded) [usb] 100039 D - 0xa0000000009fae18 [usbus2] 100038 D - 0xa0000000009fadc0 [usbus2] 100037 D - 0xa0000000009fad68 [usbus2] 100036 D - 0xa0000000009fad10 [usbus2] 100034 D - 0xa0000000009f1460 [usbus1] 100033 D - 0xa0000000009f1408 [usbus1] 100032 D - 0xa0000000009f13b0 [usbus1] 100031 D - 0xa0000000009f1358 [usbus1] 100029 D - 0xa0000000009ed460 [usbus0] 100028 D - 0xa0000000009ed408 [usbus0] 100027 D - 0xa0000000009ed3b0 [usbus0] 100026 D - 0xa0000000009ed358 [usbus0] 15 0 0 0 DL tzpoll 0x9ffc000000ecfd20 [acpi_thermal] 14 0 0 0 DL - 0x9ffc000000ed0008 [rand_harvestq] 13 0 0 0 DL (threaded) [geom] 100012 D - 0x9ffc000000ed0540 [g_down] 100011 D - 0x9ffc000000ed0538 [g_up] 100010 D - 0x9ffc000000ed0528 [g_event] 12 0 0 0 WL (threaded) [intr] 100048 I [swi0: uart uart+++] 100046 I [irq71: isp0] 100042 I [irq28: mpt1] 100040 I [irq27: mpt0] 100035 I [irq18: ehci0] 100030 I [irq17: ohci1] 100025 I [irq16: ohci0] 100022 I [swi6: task queue] 100021 I [swi6: Giant taskq] 100019 I [swi5: fast taskq] 100015 I [swi2: cambio] 100008 I [swi4: clock] 100007 I [swi4: clock] 100006 I [swi3: vm] 100005 I [swi1: netisr 0] 11 0 0 0 RL (threaded) [idle] 100004 CanRun [idle: cpu1] 100003 CanRun [idle: cpu0] 1 0 1 0 SLs wait 0xe000000011176de0 [init] 10 0 0 0 DL audit_wo 0x9ffc0000010f7a48 [audit] 0 0 0 0 RLs (threaded) [kernel] 100053 Run CPU 0 [deadlkres] 100050 D - 0xe000000011a2d300 [system_taskq_1] 100049 D - 0xe000000011a2d300 [system_taskq_0] 100045 D - 0xe000000011198500 [em1 taskq] 100044 D - 0xe000000011198600 [em0 taskq] 100023 D - 0xe00000001119b300 [ffs_trim taskq] 100020 D - 0xe00000001119b600 [thread taskq] 100018 D - 0xe00000001119b800 [acpi_task_2] 100017 D - 0xe00000001119b800 [acpi_task_1] 100016 D - 0xe00000001119b800 [acpi_task_0] 100014 D - 0xe00000001119ba00 [kqueue taskq] 100009 D - 0xe00000001119bd00 [firmware taskq] 100000 D swapin 0x9ffc000000eedd28 [swapper] db> db> alltrace Tracing command sh pid 47482 tid 100135 td 0xe00000001557fb00 cpu_switch(0xe00000001557fb00, 0xe000000015478d80, 0xe000000012402540, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe00000001557fb00, 0xe000000015478d80, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 mi_switch(0x103, 0x0, 0xe00000001557fb00, 0x9ffc00000062d1f0) at mi_switch+0x3f0 turnstile_wait(0xe000000012402540, 0xe000000012400000, 0x0, 0x9ffc000000dcb698, 0xe00000001557fb00) at turnstile_wait+0x960 __rw_wlock_hard(0x9ffc0000010ffc18, 0xe00000001557fb00, 0x0, 0x9ffc000000ecc03c, 0x9ffc0000010ffc00) at __rw_wlock_hard+0x4c0 _rw_wlock_cookie(0x9ffc0000010ffc00, 0x9ffc000000e081f8, 0x68a, 0x9ffc000000ab2720, 0x815) at _rw_wlock_cookie+0x150 pmap_enter(0x9ffc0000010ffc80, 0xa0000000e2802000, 0x2, 0xe00000027edd1590, 0x7, 0x0, 0x9ffc000000e081f8, 0xe000000019c28f18) at pmap_enter+0x40 vm_fault_hold(0xe000000010000000, 0xa0000000e2802000, 0x2, 0x0, 0x0) at vm_fault_hold+0x2c70 vm_fault(0xe000000010000000, 0xa0000000e2802000, 0x2, 0x0, 0xe00000001557fb00, 0x9ffc000000abbd60, 0x716, 0x30a) at vm_fault+0xf0 trap(0x14, 0xa00000009df21000) at trap+0xa60 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 --- trapframe at 0xa00000009df21000 copystr() at copystr+0x11 copyinstr(0x140c0cf70, 0xa0000000e2802000, 0x400, 0xa00000009df21350) at copyinstr+0xa0 exec_copyin_args(0xa00000009df21360, 0x140c0cf70, 0x0, 0x140c0ce18, 0x140c0ce40) at exec_copyin_args+0xf0 sys_execve(0xe00000001557fb00, 0xa00000009df214e8, 0x9ffc000000abac80, 0x48d) at sys_execve+0x40 syscall(0xe0000000156af280, 0x140c0ce18, 0x140c0ce40, 0xe00000001557fb00, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sh pid 47476 tid 100138 td 0xe000000015479b00 cpu_switch(0xe000000015479b00, 0xe00000001557e480, 0x9ffc000000f4b7b0, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe000000015479b00, 0xe00000001557e480, 0x9ffc000000f16398, 0x9ffc000000f16380) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000015479b00, 0x9ffc000000620b70) at mi_switch+0x3f0 sleepq_switch(0xe0000000110adac0, 0x0, 0xe000000015479e78, 0xe000000015479b00) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000110adac0, 0x0, 0x9ffc000000dca928, 0xe000000015479b00, 0x9ffc00000059ead0) at sleepq_wait+0xb0 _sx_xlock_hard(0xe0000000110adac0, 0xe000000015479b00, 0x0, 0xe0000000110adad8, 0xe0000000110adac0) at _sx_xlock_hard+0x8d0 _sx_xlock(0xe0000000110adac0, 0x0, 0x9ffc000000dfcf30, 0x1c2) at _sx_xlock+0x170 _vm_map_lock(0xe0000000110ada40, 0x9ffc000000dfcf30, 0x1c2, 0x9ffc000000a3fa50, 0x593, 0xe000000010c54f00) at _vm_map_lock+0x80 kmap_alloc_wait(0xe0000000110ada40, 0x42000) at kmap_alloc_wait+0x90 exec_alloc_args(0xa00000009df39360, 0x9ffc0000005253e0, 0x610, 0x140308ed0) at exec_alloc_args+0x30 exec_copyin_args(0xa00000009df39360, 0x140c148b0, 0x0, 0x140c14578, 0x140c14810) at exec_copyin_args+0x60 sys_execve(0xe000000015479b00, 0xa00000009df394e8, 0x9ffc000000abac80, 0x48d) at sys_execve+0x40 syscall(0xe0000000156ae4a0, 0x140c14578, 0x140c14810, 0xe000000015479b00, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command awk pid 47475 tid 100131 td 0xe000000015478480 cpu_switch(0xe000000015478480, 0xe00000001557fb00, 0x9ffc000000f4c228, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe000000015478480, 0xe00000001557fb00, 0x9ffc000000f16398, 0x9ffc000000f16380) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000015478480, 0x9ffc000000620b70) at mi_switch+0x3f0 sleepq_switch(0xe000000222b2f5a8, 0x5c, 0xe0000000154787f8, 0xe000000015478480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000222b2f5a8, 0x5c, 0x9ffc000000dca928, 0x9ffc000000dcace8) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000222b2f5a8, 0x5c, 0x9ffc000000dce2b0, 0x100, 0x9ffc0000005a0a90) at sleepq_wait_sig+0x30 _sleep(0xe000000222b2f5a8, 0xe000000222b2f7e8, 0x5c, 0x9ffc000000dce2b0, 0x0, 0x0, 0x100) at _sleep+0x7b0 pipe_read(0xe00000001edaa9d4, 0xa00000009df01360, 0xa00000009df01378, 0x0, 0xe000000222b2f6b0) at pipe_read+0x740 dofileread(0xe000000015478480, 0x0, 0xe00000001edaa9b0, 0xa00000009df01360, 0x0, 0x0) at dofileread+0x150 kern_readv(0xe000000015478480, 0x0, 0xa00000009df01360) at kern_readv+0xa0 sys_read(0xe000000015478480, 0xa00000009df014e8, 0x9ffc000000abac80, 0x48d) at sys_read+0x100 syscall(0xe00000001556e940, 0x140c8a000, 0x2000, 0xe000000015478480, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command awk pid 47474 tid 100165 td 0xe00000001f4b6000 cpu_switch(0xe00000001f4b6000, 0xe000000011197680, 0xe000000012402540, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe00000001f4b6000, 0xe000000011197680, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 mi_switch(0x103, 0x0, 0xe00000001f4b6000, 0x9ffc00000062d1f0) at mi_switch+0x3f0 turnstile_wait(0xe000000012402540, 0xe000000012400000, 0x0, 0x9ffc000000dcb698, 0xe00000001f4b6000) at turnstile_wait+0x960 __rw_wlock_hard(0x9ffc0000010ffc18, 0xe00000001f4b6000, 0x0, 0x9ffc000000ecc03c, 0x9ffc0000010ffc00) at __rw_wlock_hard+0x4c0 _rw_wlock_cookie(0x9ffc0000010ffc00, 0x9ffc000000e081f8, 0x68a, 0x9ffc000000ab2720, 0x815) at _rw_wlock_cookie+0x150 pmap_enter(0x9ffc0000010ffc80, 0xa0000000e2c4e000, 0x2, 0xe00000027edd13d0, 0x7, 0x0, 0x9ffc000000e081f8, 0xe00000001b1a6918) at pmap_enter+0x40 vm_fault_hold(0xe000000010000000, 0xa0000000e2c4e000, 0x2, 0x0, 0x0) at vm_fault_hold+0x2c70 vm_fault(0xe000000010000000, 0xa0000000e2c4e000, 0x2, 0x0, 0xe00000001f4b6000, 0x9ffc000000abbd60, 0x716, 0xe000000222b2f5a8) at vm_fault+0xf0 trap(0x14, 0xa000000000211000) at trap+0xa60 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 --- trapframe at 0xa000000000211000 bcopy() at bcopy+0xe1 copyin(0x140c70000, 0xa0000000e2c4e000, 0x10ae) at copyin+0x90 uiomove_faultflag(0xa0000000e2c4e000, 0x10ae, 0xa000000000211360, 0xa000000000211390) at uiomove_faultflag+0x2a0 uiomove(0xa0000000e2c4e000, 0x10ae, 0xa000000000211360, 0x9ffc00000064dc40, 0x1939, 0x9ffc00000064dc10) at uiomove+0x30 pipe_write(0xe0000000127220c4, 0xa000000000211360, 0xe000000222b2f6b0, 0x10ae, 0x10ae) at pipe_write+0x1bd0 dofilewrite(0xe00000001f4b6000, 0x1, 0xe0000000127220a0, 0xa000000000211360, 0xffffffffffffffff, 0x0) at dofilewrite+0x180 kern_writev(0xe00000001f4b6000, 0x1, 0xa000000000211360) at kern_writev+0xa0 sys_write(0xe00000001f4b6000, 0xa0000000002114e8, 0x9ffc000000abac80, 0x48d) at sys_write+0x100 syscall(0xe000000224d21280, 0x140c70000, 0x10ae, 0xe00000001f4b6000, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command cc1 pid 47335 tid 100146 td 0xe000000015478d80 cpu_switch(0xe000000015478d80, 0xe000000011178900, 0xe000000012402540, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe000000015478d80, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 mi_switch(0x103, 0x0, 0xe000000015478d80, 0x9ffc00000062d1f0) at mi_switch+0x3f0 turnstile_wait(0xe000000012402540, 0xe000000012400000, 0x0, 0x9ffc000000dcb698, 0xe000000015478d80) at turnstile_wait+0x960 __rw_wlock_hard(0x9ffc0000010ffc18, 0xe000000015478d80, 0x0, 0x9ffc000000ecc03c, 0x9ffc0000010ffc00) at __rw_wlock_hard+0x4c0 _rw_wlock_cookie(0x9ffc0000010ffc00, 0x9ffc000000e081f8, 0x68a, 0x9ffc000000ab2720, 0x815) at _rw_wlock_cookie+0x150 pmap_enter(0xe000000011185210, 0x2000000043cf2000, 0x2, 0xe00000027edd1c90, 0x3, 0x0, 0x9ffc000000e081f8, 0xe000000019c0c718) at pmap_enter+0x40 vm_fault_hold(0xe0000000111850d8, 0x2000000043cf2000, 0x2, 0x0, 0x0) at vm_fault_hold+0x2c70 vm_fault(0xe0000000111850d8, 0x2000000043cf2000, 0x2, 0x0, 0xe000000015478d80, 0x9ffc000000abbce0, 0x716, 0xe00000001f2dc5a0) at vm_fault+0xf0 trap(0x14, 0xa00000009df79400) at trap+0x9e0 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 Tracing command xgcc pid 47329 tid 100160 td 0xe000000222c26480 Tracing command sh pid 47176 tid 100110 td 0xe0000000154aad80 Tracing command as pid 46683 tid 100105 td 0xe000000012c3b680 Tracing command cc1plus pid 46682 tid 100115 td 0xe0000000154ba000 Tracing command g++ pid 46681 tid 100116 td 0xe0000000154b4480 Tracing command pkg-static pid 45981 tid 100161 td 0xe000000224c28d80 Tracing command pkg-static pid 45384 tid 100133 td 0xe00000001557e480 Tracing command sh pid 45009 tid 100163 td 0xe000000224c28480 Tracing command make pid 44866 tid 100104 td 0xe000000012c3bb00 Tracing command sh pid 44152 tid 100154 td 0xe00000001f4b7200 Tracing command make pid 43869 tid 100119 td 0xe0000000154abb00 Tracing command tee pid 39289 tid 100139 td 0xe000000015479680 Tracing command sh pid 38577 tid 100128 td 0xe00000001557e900 Tracing command tee pid 37813 tid 100159 td 0xe000000222c26900 Tracing command sh pid 37427 tid 100090 td 0xe000000012a7a480 Tracing command gmake pid 34696 tid 100125 td 0xe0000000154ba480 Tracing command make pid 33402 tid 100075 td 0xe0000000127b4000 Tracing command sh pid 33399 tid 100088 td 0xe000000012a7ad80 Tracing command make pid 33339 tid 100132 td 0xe000000015478000 Tracing command sh pid 33337 tid 100152 td 0xe00000001f4b7b00 Tracing command tee pid 90596 tid 100118 td 0xe0000000154b5b00 Tracing command gmake pid 89091 tid 100169 td 0xe000000224a18000 Tracing command sh pid 88092 tid 100124 td 0xe0000000154ba900 Tracing command gmake pid 84462 tid 100148 td 0xe00000001f4b6900 Tracing command gmake pid 84441 tid 100107 td 0xe000000012c3ad80 Tracing command sh pid 84440 tid 100147 td 0xe000000015478900 Tracing command make pid 84425 tid 100094 td 0xe000000012bbc900 Tracing command sh pid 84423 tid 100076 td 0xe0000000127f6900 Tracing command tee pid 75146 tid 100113 td 0xe0000000154aa000 Tracing command sh pid 74621 tid 100122 td 0xe0000000154bb200 Tracing command top pid 39253 tid 100097 td 0xe0000000127f7680 Tracing command sh pid 35326 tid 100121 td 0xe0000000154bb680 Tracing command sh pid 1151 tid 100072 td 0xe0000000127b4d80 Tracing command su pid 1150 tid 100086 td 0xe000000012a7b680 Tracing command tcsh pid 1146 tid 100099 td 0xe000000012c3a000 Tracing command sshd pid 1145 tid 100078 td 0xe0000000127f6000 Tracing command sshd pid 1143 tid 100069 td 0xe00000001268ed80 Tracing command sh pid 1092 tid 100095 td 0xe000000012bbc480 Tracing command sh pid 1050 tid 100092 td 0xe0000000127f7200 Tracing command su pid 1049 tid 100081 td 0xe000000012a7a000 Tracing command tcsh pid 1045 tid 100098 td 0xe000000012c3a480 Tracing command sshd pid 1044 tid 100085 td 0xe0000000127f6d80 Tracing command sshd pid 1042 tid 100091 td 0xe0000000127f7b00 Tracing command getty pid 1041 tid 100056 td 0xe000000012400d80 Tracing command getty pid 1040 tid 100071 td 0xe0000000127b5200 Tracing command inetd pid 1020 tid 100093 td 0xe000000012bbcd80 Tracing command cron pid 979 tid 100067 td 0xe00000001268f680 Tracing command sendmail pid 974 tid 100066 td 0xe00000001268fb00 Tracing command sendmail pid 971 tid 100073 td 0xe0000000127b4900 Tracing command sshd pid 968 tid 100055 td 0xe000000011a26480 Tracing command ntpd pid 908 tid 100080 td 0xe0000000127b5680 Tracing command syslogd pid 827 tid 100077 td 0xe0000000127f6480 Tracing command ipmon pid 818 tid 100065 td 0xe000000012401200 Tracing command devd pid 696 tid 100068 td 0xe00000001268f200 Tracing command adjkerntz pid 181 tid 100070 td 0xe00000001268e900 Tracing command softdepflush pid 23 tid 100064 td 0xe000000012401680 Tracing command vnlru pid 22 tid 100063 td 0xe000000012401b00 Tracing command syncer pid 21 tid 100062 td 0xe00000001268e000 Tracing command bufdaemon pid 20 tid 100061 td 0xe00000001268e480 Tracing command pagezero pid 19 tid 100060 td 0xe000000011a27b00 Tracing command vmdaemon pid 18 tid 100059 td 0xe000000012400000 Tracing command pagedaemon pid 17 tid 100058 td 0xe000000012400480 Tracing command xpt_thrd pid 9 tid 100057 td 0xe000000012400900 Tracing command sctp_iterator pid 6 tid 100054 td 0xe000000011a26900 Tracing command zfskern pid 5 tid 100052 td 0xe000000011a27200 Tracing command zfskern pid 5 tid 100051 td 0xe000000011a27680 Tracing command isp0: fc_thrd0 pid 4 tid 100047 td 0xe000000011931b00 Tracing command mpt_recovery1 pid 3 tid 100043 td 0xe000000011930000 Tracing command mpt_recovery0 pid 2 tid 100041 td 0xe000000011930900 Tracing command usb pid 16 tid 100039 td 0xe000000011924480 Tracing command usb pid 16 tid 100038 td 0xe000000011924900 Tracing command usb pid 16 tid 100037 td 0xe000000011924d80 Tracing command usb pid 16 tid 100036 td 0xe000000011925200 Tracing command usb pid 16 tid 100034 td 0xe000000011300d80 Tracing command usb pid 16 tid 100033 td 0xe000000011301200 Tracing command usb pid 16 tid 100032 td 0xe000000011301680 Tracing command usb pid 16 tid 100031 td 0xe000000011301b00 Tracing command usb pid 16 tid 100029 td 0xe000000011219680 Tracing command usb pid 16 tid 100028 td 0xe000000011219b00 Tracing command usb pid 16 tid 100027 td 0xe000000011300000 Tracing command usb pid 16 tid 100026 td 0xe000000011300480 Tracing command acpi_thermal pid 15 tid 100024 td 0xe000000011218000 Tracing command rand_harvestq pid 14 tid 100013 td 0xe000000011197680 Tracing command geom pid 13 tid 100012 td 0xe000000011197b00 Tracing command geom pid 13 tid 100011 td 0xe0000000111a6000 Tracing command geom pid 13 tid 100010 td 0xe000000011179680 Tracing command intr pid 12 tid 100048 td 0xe000000011931680 Tracing command intr pid 12 tid 100046 td 0xe000000011a26000 Tracing command intr pid 12 tid 100042 td 0xe000000011930480 Tracing command intr pid 12 tid 100040 td 0xe000000011924000 Tracing command intr pid 12 tid 100035 td 0xe000000011300900 Tracing command intr pid 12 tid 100030 td 0xe000000011219200 Tracing command intr pid 12 tid 100025 td 0xe0000000111a7b00 Tracing command intr pid 12 tid 100022 td 0xe000000011218900 Tracing command intr pid 12 tid 100021 td 0xe000000011218d80 Tracing command intr pid 12 tid 100019 td 0xe0000000111a6900 Tracing command intr pid 12 tid 100015 td 0xe000000011196d80 Tracing command intr pid 12 tid 100008 td 0xe000000011196000 Tracing command intr pid 12 tid 100007 td 0xe000000011196480 Tracing command intr pid 12 tid 100006 td 0xe000000011196900 Tracing command intr pid 12 tid 100005 td 0xe000000011178000 Tracing command idle pid 11 tid 100004 td 0xe000000011178480 Tracing command idle pid 11 tid 100003 td 0xe000000011178900 Tracing command init pid 1 tid 100002 td 0xe000000011178d80 Tracing command audit pid 10 tid 100001 td 0xe000000011179200 Tracing command kernel pid 0 tid 100053 td 0xe000000011a26d80 Tracing command kernel pid 0 tid 100050 td 0xe000000011930d80 Tracing command kernel pid 0 tid 100049 td 0xe000000011931200 Tracing command kernel pid 0 tid 100045 td 0xe000000011925680 Tracing command kernel pid 0 tid 100044 td 0xe000000011925b00 Tracing command kernel pid 0 tid 100023 td 0xe000000011218480 Tracing command kernel pid 0 tid 100020 td 0xe0000000111a6480 Tracing command kernel pid 0 tid 100018 td 0xe0000000111a6d80 Tracing command kernel pid 0 tid 100017 td 0xe0000000111a7200 Tracing command kernel pid 0 tid 100016 td 0xe0000000111a7680 Tracing command kernel pid 0 tid 100014 td 0xe000000011197200 Tracing command kernel pid 0 tid 100009 td 0xe000000011179b00 Tracing command kernel pid 0 tid 100000 td 0x9ffc000000eee1d0 db> From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 08:41:45 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8119DACB for ; Mon, 14 Oct 2013 08:41:45 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C15223E5 for ; Mon, 14 Oct 2013 08:41:44 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hm4so862410wib.8 for ; Mon, 14 Oct 2013 01:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:in-reply-to:references:date :message-id; bh=i58EZHKdal4lKmf5GO5N3aDP6jwGE+2QrowE7EAxwt8=; b=RcrsJFIGkR0luGh+ePcgbriEOmRr19D/eaiK2PDlUiZvJ1U+ucwHuv60anpAtKM56l d3PZYq8kgUH/isG+OgTsZYXu+kNj98OAjRBYX0cyFBRGxaSj7wCh7+S4CNhbylw9qdp6 RsqiXccO8hTIO/K1oVagzLbcBgP9qXhvMlpZDPr9oxuJEaNRHddFa2urT53Yee42n3u3 BpbMOBenYk6htiNyJy/Tgg4u4IRbKVpDSbvEfZ/VaO4URZjgeYtU3QR1M7eW6YDJ1tKO PH0AdB5ftb2i1dMDttOuO3AphJBGI77D1jiaTI4/Co3Z39nEi0q/uSD+YlIJH0TfP/LN Plig== X-Gm-Message-State: ALoCoQkABPVCTCxPXPnLHhIFuDc2MY45bqfKizNUkngDtp2x76XjTFH8aSGIDlAoHJaw9jhc4VHL X-Received: by 10.180.12.14 with SMTP id u14mr13542912wib.63.1381739750333; Mon, 14 Oct 2013 01:35:50 -0700 (PDT) Received: from clue.co.za (41-135-83-21.dsl.mweb.co.za. [41.135.83.21]) by mx.google.com with ESMTPSA id om10sm31913040wic.5.2013.10.14.01.35.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Oct 2013 01:35:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VVdct-000HZZ-Vw; Mon, 14 Oct 2013 10:35:44 +0200 To: Florent Peterschmitt From: Ian FREISLICH Subject: Re: libstdc++ fallout? mongodb fails to build. In-Reply-To: <523C0414.8090405@peterschmitt.fr> References: <523C0414.8090405@peterschmitt.fr> X-Attribution: BOFH Date: Mon, 14 Oct 2013 10:35:43 +0200 Message-Id: Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 08:41:45 -0000 Florent Peterschmitt wrote: > Le 20/09/2013 10:04, Ian FREISLICH a =E9crit : > > Hi > > > > Is this libstdc++ fallout? > > You can try these patchs: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/182110 I am sorry that I did not see your message until today. This fixes the build. Thanks very much. Ian -- Meditating Guru Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 08:44:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7C908C03 for ; Mon, 14 Oct 2013 08:44:39 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADC992407 for ; Mon, 14 Oct 2013 08:44:38 +0000 (UTC) Received: from mail-we0-f178.google.com ([74.125.82.178]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKUluu7zONS/qXr9O4+Z3aV34Jptf9ZLtc@postini.com; Mon, 14 Oct 2013 08:44:38 UTC Received: by mail-we0-f178.google.com with SMTP id q59so6577998wes.23 for ; Mon, 14 Oct 2013 01:44:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to; bh=2E6rMLSY6Ur4pvRQn3h6lX1kOOtQD3S/oaoQDfByWvc=; b=R3t91odQqWLCfYMMf6Czg/oLgdoikMDnZrXmOAW76L1T/l4l8/CQOD5iw8BwNQHNbc IGALsskDqjc1boB4kFsCPV+0RTlSk6Ky7JRahh17sOyvHwHd0JBNSIm291TWGrWL19yT XYMSgtuHnHU+8lulQMlggQGadG5nOFaubamNzj1z9JGCEb/KI+xZWVXpe6n7e5yXUkXn V+Z/Hu14hNP55vR7XHAEtO2XI1cBQbaO2rTWirLGaPsO30dnaJHBTeMdkzxF5EYI+IAq YKYySdgPCJSykh7OxZRgPDzzTUtdEYsNE0SuifyiRoDtMwOjbU/eWAPUuy35xy5YmbeJ g9SA== X-Gm-Message-State: ALoCoQmvQx4MBSYau7AP7Jp4eCooU+0kc1biyDyl6eICMYD25R44LPHYPYI5xN90RedL3dV1bVQpcgrCFRu5edX7/RIY9ToTrEAvQuGDF5H4VRiJhmGIZmPYkMaFuXWfa9ZXvERRvRNUgyEgnUa7T6gcxOgkug8VUWpJOrfDhRBVOCgnfn776iA= X-Received: by 10.180.73.134 with SMTP id l6mr13694124wiv.16.1381740271534; Mon, 14 Oct 2013 01:44:31 -0700 (PDT) X-Received: by 10.180.73.134 with SMTP id l6mr13694119wiv.16.1381740271454; Mon, 14 Oct 2013 01:44:31 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id q17sm31960706wiv.10.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 01:44:30 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9E8iSXr015099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Oct 2013 09:44:28 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9E8iSYM015098; Mon, 14 Oct 2013 09:44:28 +0100 (BST) (envelope-from mexas) Date: Mon, 14 Oct 2013 09:44:28 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310140844.r9E8iSYM015098@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: panic: uma_zfree: Freeing to non free bucket index. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:44:39 -0000 BTW, I see in dmesg: Starting ddb. ddb: sysctl: debug.ddb.scripting.scripts: Invalid argument /etc/rc: WARNING: failed to start ddb What is that about? panic: uma_zfree: Freeing to non free bucket index. cpuid = 0 KDB: stack backtrace: db_trace_self(0x9ffc000000158380) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc000000607370) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc000000ed0e10, 0x9ffc00000058e660, 0x40c, 0x9ffc0000010a44a0) at kdb_backtrace+0xc0 vpanic(0x9ffc000000dfc468, 0xa0000000e26e0fd8, 0x9ffc000000ef9670, 0x9ffc000000ed0bc0) at vpanic+0x260 kassert_panic(0x9ffc000000dfc468, 0xe000000015e25f90, 0xe000000015e243e0, 0xe00000027ffd5200) at kassert_panic+0x120 uma_zfree_arg(0xe00000027ffccfc0, 0xe000000015e243e0, 0x0) at uma_zfree_arg+0x2d0 g_destroy_bio(0xe000000015e243e0, 0x9ffc0000004ad4a0, 0x30a, 0x30a) at g_destroy_bio+0x30 g_disk_done(0xe000000015e243e0, 0xe000000015e15d10, 0xe000000012672700, 0x9ffc0000006b18c0) at g_disk_done+0x140 biodone(0xe000000015e243e0, 0x9ffc000000e0e150, 0xe000000010c24030, 0x0, 0x0, 0x0, 0x9ffc000000066890, 0x614) at biodone+0x180 dadone(0xe000000012672600, 0xe000000012541000, 0xe000000015e243e0, 0x7) at dadone+0x620 camisr_runqueue(0xe000000011a2dc00, 0xe000000012541054, 0xe000000012541000, 0x135d) at camisr_runqueue+0x6c0 camisr(0xe000000011a2dc20, 0xe000000011a2dc00, 0x9ffc000000bee9d0, 0xa0000000e26e1548) at camisr+0x260 intr_event_execute_handlers(0xe0000000111764a0, 0xe00000001118d998, 0xe000000011191c00, 0x0) at intr_event_execute_handlers+0x280 ithread_loop(0xe000000011192f00, 0xa0000000e26e1550, 0xe000000011192f14, 0xe00000001118d99c) at ithread_loop+0x1b0 fork_exit(0x9ffc000000e12a90, 0xe000000011192f00, 0xa0000000e26e1550) at fork_exit+0x120 enter_userland() at enter_userland KDB: enter: panic [ thread pid 12 tid 100015 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2c990,gp ;; db> db> scripts lockinfo=show locks; show alllocks; show lockedvnods db> run lockinfo db:0:lockinfo> show locks db:0:locks> show alllocks db:0:alllocks> show lockedvnods Locked vnodes 0xe00000001ab39ba8: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) v_object 0xe00000001cd30900 ref 0 pages 0 lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 100121) ino 5467932, on dev da5p1 0xe000000015ed3ba8: tag ufs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) v_object 0xe00000001cd33e00 ref 0 pages 0 lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 100092) ino 5467948, on dev da5p1 0xe00000001ab16938: tag ufs, type VREG usecount 1, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) v_object 0xe00000001cd98a00 ref 0 pages 1 lock type ufs: EXCL by thread 0xe000000018494000 (pid 41337, cpdup, tid 100137) ino 5469420, on dev da5p1 0xe00000001b2503b0: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 100092) ino 5469421, on dev da5p1 0xe00000001ab2a760: tag ufs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 100121) ino 5469422, on dev da5p1 db> db> script zzz=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; reset db> run zzz Then I see lots of info on the console. However, on reboot, there's nothing: from dmesg: *skip* Starting syslogd. No core dumps found. ^^^^^^^^^^^^^^^^^^^ Clearing /tmp (X related). *skip* # savecore -C -v unable to open bounds file, using 0 checking for kernel dump on device /dev/da4p1 mediasize = 72834820096 sectorsize = 512 magic mismatch on last dump header on /dev/da4p1 No dump exists # ls -al /var/crash/ total 16 drwxr-x--- 2 root wheel 512 Oct 13 21:55 . drwxr-xr-x 28 root wheel 512 Oct 14 09:37 .. -rw-r--r-- 1 root wheel 2 Oct 13 21:54 bounds -rw-r--r-- 1 root wheel 5 Jun 12 2009 minfree # Where did my textdump go? Thanks Anton From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 11:03:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 020FABFE; Mon, 14 Oct 2013 11:03:30 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54FB82BC9; Mon, 14 Oct 2013 11:03:30 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id lc6so4563325vcb.1 for ; Mon, 14 Oct 2013 04:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VIarfLrSItDa0I1UHnua40yktAvSk4My/jyoISGCW94=; b=yvEgTxObOzxAY39fgp93ola9tpKy55YMsjBAJ6FjPvwEJjBNrkaKY0rUL+JLIMB1yu 5b7RB8inDc2d7re47XiyUNyXBx0HsASFOJn4YxcAiv5GBbg5gb2HGTkaLm9KJbx9eJkz jcOTK06QJbBypNVR7YZCaPk/BW5tHNgbeY5l+8PX8QXhIjUXORa8cHWKM8UmBXcwFtcm yjAJpX15szI+7EnRkXL8khiT3xVyelafuwIl+Ql6LjfbGirAnt9U2e/1p2G11nRZlmB3 uHn/WVstuy1+ZmsI96Hk5kqiRGu05TYEM2xW9DXuPXu7nk2ow6YfaaUD9PoIzAxLwKiQ aXQQ== MIME-Version: 1.0 X-Received: by 10.52.52.137 with SMTP id t9mr598589vdo.22.1381748609331; Mon, 14 Oct 2013 04:03:29 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Mon, 14 Oct 2013 04:03:29 -0700 (PDT) In-Reply-To: <201310140821.r9E8L55j014897@mech-cluster241.men.bris.ac.uk> References: <201310140821.r9E8L55j014897@mech-cluster241.men.bris.ac.uk> Date: Mon, 14 Oct 2013 13:03:29 +0200 X-Google-Sender-Auth: iTdbcUU87dE3NdiYBpiwJnWXRTw Message-ID: Subject: Re: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks From: Davide Italiano To: mexas@bris.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 11:03:32 -0000 On Mon, Oct 14, 2013 at 10:21 AM, Anton Shterenlikht wrote: > >From davide.italiano@gmail.com Fri Oct 11 15:39:49 2013 >> >>If you're not able to get a full dump, a textdump would be enough. >>In your DDB scripts just remove the 'call doadump' step and you should >>be done, unless I'm missing something. >>Please adjust the script as well to include all the informations >>requested as mentioned in my previous link, e.g. 'show lockedvnods' is >>not mentioned on the example section of textdump(4) manpage but it >>could be useful to ease debugging. > > I still haven't got it right, but I now collected manually > some (hopefully) useful info (see below). > This is fair enough -- If you're still at the ddb prompt, please print the whole panic message (or at least the address of the lock reported as deadlocked by DEADLKRES), so that we can at least have a candidate. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 12:09:12 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED9196A4; Mon, 14 Oct 2013 12:09:12 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6ACB821FA; Mon, 14 Oct 2013 12:09:12 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r9EC8qwU070797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 21:09:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id r9EC8oi9015742; Mon, 14 Oct 2013 21:08:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 14 Oct 2013 21:07:26 +0900 (JST) Message-Id: <20131014.210726.1989833413225901961.hrs@allbsd.org> To: cperciva@FreeBSD.org Subject: Re: RFC: support for "first boot" rc.d scripts From: Hiroki Sato In-Reply-To: <525B258F.3030403@freebsd.org> References: <525B258F.3030403@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Oct_14_21_07_26_2013_864)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 14 Oct 2013 21:09:03 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 12:09:13 -0000 ----Security_Multipart(Mon_Oct_14_21_07_26_2013_864)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Colin Percival wrote in <525B258F.3030403@freebsd.org>: cp> I've attached a very simple patch which makes /etc/rc: cp> +if ! [ -e /var/db/firstboot ]; then cp> + skip="$skip -s firstboot" cp> +fi At this stage, it is possible that /var/db does not exist because it is before rc.d/mountcritlocal. -- Hiroki ----Security_Multipart(Mon_Oct_14_21_07_26_2013_864)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlJb3n4ACgkQTyzT2CeTzy37bgCfXuALJ9zLzm1tBIK73KZK9zDl Ic0AnjTzKnonc/e4rjO4LVw0naeAtRqZ =CHGa -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Oct_14_21_07_26_2013_864)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 12:10:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 433FF81E; Mon, 14 Oct 2013 12:10:42 +0000 (UTC) (envelope-from kwhite@site.uottawa.ca) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00B18223F; Mon, 14 Oct 2013 12:10:41 +0000 (UTC) Received: from [10.0.2.15] (dsl-66-225-161-151.vianet.ca [66.225.161.151]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.4) with ESMTP id r9ECAcNg091518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Oct 2013 08:10:39 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Mon, 14 Oct 2013 08:10:41 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Andriy Gapon Subject: Re: ZFS panic (dn->dn_datablkshift != 0) with r256304 and send/recv In-Reply-To: <525B797C.4050500@FreeBSD.org> Message-ID: References: <525B797C.4050500@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 Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 12:10:42 -0000 On Mon, 14 Oct 2013, Andriy Gapon wrote: > on 14/10/2013 03:34 Keith White said the following: >> I get the following assert failure with a recent current: >> >> panic: solaris assert: dn->dn_datablkshift != 0, file: >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, >> line: 638 > > Please see https://www.illumos.org/issues/4188 > The current best known fix is to simply drop the assertion. > ... Thanks! It works for me. Receive completes, and filesystems compare the same. Index: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c =================================================================== --- /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (revision 256304) +++ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c (working copy) @@ -635,7 +635,7 @@ uint64_t start = off >> shift; uint64_t end = (off + len) >> shift; - ASSERT(dn->dn_datablkshift != 0); + /* XXX may be false alarm: ASSERT(dn->dn_datablkshift != 0); XXX */ ASSERT(dn->dn_indblkshift != 0); zio = zio_root(tx->tx_pool->dp_spa, > Though, I am not entirely sure if this will be the final solution. I'll > double-check with Matt. > ...keith From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 13:00:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A6BA86E7 for ; Mon, 14 Oct 2013 13:00:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6D56C2568 for ; Mon, 14 Oct 2013 13:00:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEACrqW1KDaFve/2dsb2JhbABZgz9Sgym9eUuBOHSCJQEBAQMBAQEBICsgCwUWDgoCAg0ZAikBCSYGCAcEARwEh18GDKsmkjGBKYxwgQU0B4JqgTkDlTqDepBTg0AgMYEDOQ X-IronPort-AV: E=Sophos;i="4.93,492,1378872000"; d="scan'208";a="59217229" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 14 Oct 2013 09:00:45 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 43140B403B; Mon, 14 Oct 2013 09:00:45 -0400 (EDT) Date: Mon, 14 Oct 2013 09:00:45 -0400 (EDT) From: Rick Macklem To: Allan Jude Message-ID: <2030585715.40821095.1381755645240.JavaMail.root@uoguelph.ca> In-Reply-To: <525B2967.9060404@allanjude.com> Subject: Re: Process stuck in D+ state MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 13:00:52 -0000 Allan Jude wrote: > On 2013-10-13 15:10, Olivier Cochard-Labb=C3=A9 wrote: > > I've got a frequent problem on my desktop (FreeBSD 10.0-ALPHA5 #8 > > r256200): > > After few hours I can't acces to one of my folder: A simple "ls" in > > this folder stucks, and all filesystem information started after > > (df, > > fstat) stuck too in D+. > > > > SIGINFO report this usage for these processes: > > > > load: 0.15 cmd: ls 15716 [rpcrecon] 217.89r 0.00u 0.00s 0% 2440k > > load: 0.34 cmd: ls 15716 [connec] 2376.60r 0.00u 0.00s 0% 0k > > load: 0.40 cmd: ls 15716 [connec] 2379.80r 0.00u 0.00s 0% 0k > > load: 0.40 cmd: ls 15716 [connec] 2379.92r 0.00u 0.00s 0% 0k > > load: 0.37 cmd: ls 15716 [rpcrecon] 2850.26r 0.00u 0.00s 0% 0k > > load: 0.37 cmd: ls 15716 [rpcrecon] 2850.39r 0.00u 0.00s 0% 0k > > > > load: 0.40 cmd: fstat 15781 [rpcrecon] 2842.08r 0.00u 0.01s 0% 0k > > load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.35r 0.00u 0.01s 0% 0k > > load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.48r 0.00u 0.01s 0% 0k > > load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.63r 0.00u 0.01s 0% 0k > > > > load: 0.24 cmd: df 15919 [connec] 1047.98r 0.00u 0.00s 0% 0k > > load: 0.22 cmd: df 15919 [connec] 1054.22r 0.00u 0.00s 0% 0k > > > > and the PS status: > > > > olivier 15919 0.0 0.0 14400 16 7 D+ 7:06PM > > 0:00.01 df -h > > olivier 15781 0.0 0.0 20708 16 6 D+ 6:26PM > > 0:00.02 fstat > > olivier 15651 0.0 0.0 16784 16 4 D+ 6:25PM > > 0:00.00 ls > > > > My desktop use a geli system and JSU, nothing special, here are the > > mount point: > > /dev/ada1p3.eli on / (ufs, local, noatime, journaled soft-updates) > > devfs on /dev (devfs, local, multilabel) > > /dev/gpt/boot on /boot2 (ufs, local, noatime, soft-updates) > > > > What kind of commands can I use for getting more troubleshooting( > > information next time ? > > > > 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" > Looking at the process states, connect and rpcreconnect, seem to > suggest > something involving yp/nis or NFS or some such. >=20 Yea. I don't think yp/nis uses the kernel rpc. All I can think of is that you either have an NFS entry in your /etc/fstab or an amd mapped mount point. rpc.lockd also uses the kernel rpc, but I can't think of how it would become actiev without an NFS mount. (rpcrecon and connec suggest the kernel RPC is trying to (re)connect via TCP to an NFS server) Good luck with it, rick > try: ls -n (skip uid to symbolic name lookup) and see if it behaves > any > differently > _______________________________________________ > 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 Oct 14 13:25:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E8B1EE8E; Mon, 14 Oct 2013 13:25:51 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77B532797; Mon, 14 Oct 2013 13:25:51 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBEA04.dip0.t-ipconnect.de [217.251.234.4]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r9ECe4NL054714; Mon, 14 Oct 2013 12:40:04 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r9ECdrGH025824; Mon, 14 Oct 2013 14:39:53 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r9ECdlIX002506; Mon, 14 Oct 2013 14:39:53 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310141239.r9ECdlIX002506@fire.js.berklix.net> To: Mark Felder Subject: Re: May you please add alias for nslookup? From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sat, 12 Oct 2013 12:40:56 CDT." <1381599656.13750.33215025.2D6F9352@webmail.messagingengine.com> Date: Mon, 14 Oct 2013 14:39:47 +0200 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 13:25:52 -0000 > > Removing src/contrib/bind9 from FreeBSD-10 will get criticised as: > > "Calls itself a server OS, but no name server out of the box!" > > > > Please resist periodic urges to strip src/ towards just a tool set > > capable of rebuilding itself. Tossing expected tools (even if a > > port is more up to date & secure) will annoy users, & potential > > immigrants from other Unixes may try then toss FreeBSD. > > > > Cheers, > > Julian > > I don't think anyone can explain this better than the last post DES put > on his blog about it > > http://blog.des.no/2013/09/dns-again-a-clarification/ Thanks Mark. Useful insight. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 15:56:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 314F4D87 for ; Mon, 14 Oct 2013 15:56:21 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id DFCA12237 for ; Mon, 14 Oct 2013 15:56:20 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 2412C1E007B7; Mon, 14 Oct 2013 17:56:19 +0200 (CEST) Received: from enceladus10.kn-bremen.de (noident@localhost [127.0.0.1]) by enceladus10.kn-bremen.de (8.14.5/8.14.5) with ESMTP id r9EFsS51065273; Mon, 14 Oct 2013 17:54:28 +0200 (CEST) (envelope-from nox@enceladus10.kn-bremen.de) Received: (from nox@localhost) by enceladus10.kn-bremen.de (8.14.5/8.14.5/Submit) id r9EFsRIk065272; Mon, 14 Oct 2013 17:54:27 +0200 (CEST) (envelope-from nox) Date: Mon, 14 Oct 2013 17:54:27 +0200 (CEST) From: Juergen Lock Message-Id: <201310141554.r9EFsRIk065272@enceladus10.kn-bremen.de> To: mueller6724@bellsouth.net Subject: Re: BE Loader Menu (was Re: rcs) X-Newsgroups: local.list.freebsd.current In-Reply-To: <59.81.16944.C6136525@cdptpa-oedge02> References: <60177810-8DC4-4EA3-8040-A834B79039D2@orthanc.ca> <52538EDC.2080001@freebsd.org> <52541202.3010707@mu.org> <20131008.170444.74714516.sthaug@nethelp.no> <52542BD4.5070706@FreeBSD.org> <52542E1D.9000000@mu.org> <52555D1C.8010407@freebsd.org> <52558577.5020401@allanjude.com> <52558779.2070203@pcbsd.org> <517D65A3D61F684FAE2B2EC2D2DA06C3@fisglobal.com> <13CA24D6AB415D428143D44749F57D720FC4B2A3@LTCFISWMSGMB21.FNFIS.com> Organization: home Cc: freebsd-current@freebsd.org, "Teske, Devin" , Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 15:56:21 -0000 In article <59.81.16944.C6136525@cdptpa-oedge02> you write: >Sorry for previous typo in From: line, missing right angle bracket at end. >Then, in a finger error, I resent that message just before finding the error and making the needed correction. > >from Devin Teske: > >> I'm late to the party again ;D (didn't realize the rcs thread had turned BE) > >> Both problems can be solved. >> The loading of the kernel *after* choosing your boot device is trivial. >> We've been doing it at $work for *years* (almost a decade?) > >> I can put that in, whenever. Probably at the same time as implementing >> the live/dynamic BE menus for selecting the root device. > >I'd like to know how to boot FreeBSD >= 9.1 with grub2. > >Following the instructions under $PORTSDIR/sysutils/grub2 > >insmod ufs2 >set root=(hd0,gpt3) >kfreebsd /boot/loader >boot > >stopped working around FreeBSD 9.1-stable. > If you mean it loads the kernel but then crashes instead of booting it then your grub2 version is missing this fix: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 >I used Super Grub2 Disk image on the System Rescue CD written to USB stick. > A super grub disk beta version with the mentioned fix is here: https://forja.cenatic.es/frs/?group_id=204 (2.00s1b6, it also has fixed autodetection of FreeBSD installs.) >Recently, I built sysutils/grub2, ran mkrescue, wrote that image to the System Rescue USB stick and made the entry in /syslinux/syslinux.cfg, but haven't tested that yet. > >What is the method you or PC-BSD uses? > PC-BSD uses (more or less?) the sysutils/grub2 port that has the above fix. (as well as zfs patches etc.) >I want to use it on FreeBSD 9.2 and 10-current. > >I tried visiting pcbsd.org website but couldn't find any details. > >Tom > HTH, :) Juergen From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 16:52:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5FE981FE for ; Mon, 14 Oct 2013 16:52:15 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 0EC7F26A6 for ; Mon, 14 Oct 2013 16:52:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=hqG6oe06w4CXi8S9XwbVCMld+Bs=; b=CL/tb8Go1Q3DugdV8k rrKU06rfHzVlofXQOjFzk48UgjfdO4rosMXyy3cm1eEBj9QyXVRNMb1abCQbAYqQ rNNnXdZpZ2HLTngzV/N/WV2Aoe/EmEdwhPn/kvenEvNjZ9UE2PrrfTUyk9dF+fBw RbodsOjzcBir30fPhkGVwCQgk= Received: by mf33.sendgrid.net with SMTP id mf33.4238.525C213D7 Mon, 14 Oct 2013 16:52:13 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi20 (SG) with ESMTP id 141b7e1d997.61f5.b52117 for ; Mon, 14 Oct 2013 16:52:13 +0000 (UTC) Received: (qmail 88618 invoked from network); 14 Oct 2013 16:52:12 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 14 Oct 2013 16:52:12 -0000 Received: (qmail 10679 invoked from network); 14 Oct 2013 16:51:22 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 14 Oct 2013 16:51:22 -0000 Message-ID: <525C210A.2000306@freebsd.org> Date: Mon, 14 Oct 2013 09:51:22 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nick Hibma Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> In-Reply-To: <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wtidg2lR5lnvTopD/6Uik507TVmZxTadkpb/JrD6JEGeenoRYMrEf/M7F3FUoZ4LSHH065IvNa53pL0vWGEQABoXuH5gPIlce2jBBCRCNQHDgc= Cc: FreeBSD current , freebsd-rc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 16:52:15 -0000 Hi Nick, On 10/14/13 00:59, Nick Hibma wrote: > Sounds useful: We have nanobsd images that configure a hard disk if present, but obviously only need to be run once. > > However: NanoBSD stores uses a memory disk for /etc and stores it's permanent scripts in /conf/* (/etc/rc.initdiskless) and/or /cfg (NanoBSD) so I doubt whether the 'embedded systems' argument is of much use, as deleting the script or flagging 'firstboot' is non-permanent. Yes, it's hard to store state on diskless systems... but I figured that anyone building a diskless system would know to not create a "run firstboot scripts" marker. And not all embedded systems are diskless... -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 16:54:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A24FE358 for ; Mon, 14 Oct 2013 16:54:37 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 4413826C7 for ; Mon, 14 Oct 2013 16:54:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=0kISZbOR38SkcdNY1JMLJQ6HxRY=; b=Ygbx9OUu/4wdcs89zU qNdiaMd+/y58J0j2tzZgnDjYFNEh6P2veGgwsCZptiUlKYiRnwHGnl1ypOKjgQ7U QzlTvoY/JcZ9m2zbVDO4jcpK5yi7HLAkQ8qfHg6T70DGJCw6R8GNw/81NZ4FrVDq Nc2Wzo5aY7BnaGcKN3edLDvZw= Received: by filter-011.sjc1.sendgrid.net with SMTP id filter-011.16430.525C21CB4 Mon, 14 Oct 2013 16:54:35 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi14 (SG) with ESMTP id 141b7e40308.3726.1acba51 for ; Mon, 14 Oct 2013 16:54:35 +0000 (UTC) Received: (qmail 88673 invoked from network); 14 Oct 2013 16:54:34 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 14 Oct 2013 16:54:34 -0000 Received: (qmail 10689 invoked from network); 14 Oct 2013 16:53:43 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 14 Oct 2013 16:53:43 -0000 Message-ID: <525C2197.9020405@freebsd.org> Date: Mon, 14 Oct 2013 09:53:43 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Hiroki Sato Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> <20131014.210726.1989833413225901961.hrs@allbsd.org> In-Reply-To: <20131014.210726.1989833413225901961.hrs@allbsd.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wtiLSVg6pZ7XHkaMG6t/hHd+weRiw6Yf6aSBscE/UypbcP1ATFCockRwiAzGKKTAulqV0tcGK1U1YwYoKMZhs2e01XaLWecgAaPFoeYzrpXfBI= Cc: freebsd-current@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 16:54:37 -0000 On 10/14/13 05:07, Hiroki Sato wrote: > Colin Percival wrote > in <525B258F.3030403@freebsd.org>: > > cp> I've attached a very simple patch which makes /etc/rc: > > cp> +if ! [ -e /var/db/firstboot ]; then > cp> + skip="$skip -s firstboot" > cp> +fi > > At this stage, it is possible that /var/db does not exist because it > is before rc.d/mountcritlocal. Ah, good point. I guess we need something on / then? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 17:00:17 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 42ABF67E; Mon, 14 Oct 2013 17:00:17 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 182522740; Mon, 14 Oct 2013 17:00:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VVlV4-000MmG-Fm; Mon, 14 Oct 2013 17:00:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9EH07FS025748; Mon, 14 Oct 2013 11:00:07 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qFMUf7Hs80LW2GBYfnaWJ Subject: Re: RFC: support for "first boot" rc.d scripts From: Ian Lepore To: Colin Percival In-Reply-To: <525C210A.2000306@freebsd.org> References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> <525C210A.2000306@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Oct 2013 11:00:07 -0600 Message-ID: <1381770007.42859.82.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD current , freebsd-rc@FreeBSD.org, Nick Hibma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 17:00:17 -0000 On Mon, 2013-10-14 at 09:51 -0700, Colin Percival wrote: > Hi Nick, > > On 10/14/13 00:59, Nick Hibma wrote: > > Sounds useful: We have nanobsd images that configure a hard disk if present, but obviously only need to be run once. > > > > However: NanoBSD stores uses a memory disk for /etc and stores it's permanent scripts in /conf/* (/etc/rc.initdiskless) and/or /cfg (NanoBSD) so I doubt whether the 'embedded systems' argument is of much use, as deleting the script or flagging 'firstboot' is non-permanent. > > Yes, it's hard to store state on diskless systems... but I figured > that anyone building a diskless system would know to not create a > "run firstboot scripts" marker. And not all embedded systems are > diskless... > The embedded systems we create at $work have readonly root and mfs /var, but we do have writable storage on another filesystem. It would work for us (not that we need this feature right now) if there were an rcvar that pointed to the marker file. Of course to make it work, something would have to get the alternate filesystem mounted early enough to be useful (that is something we do already with a custom rc script). Note that I'm not asking for any changes here, just babbling. -- Ian From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 17:00:42 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A0FF7B0; Mon, 14 Oct 2013 17:00:42 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57C1A277A; Mon, 14 Oct 2013 17:00:42 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 7A051B0A1; Mon, 14 Oct 2013 17:00:40 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 7A051B0A1 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 14 Oct 2013 13:00:38 -0400 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-snapshots@FreeBSD.org Subject: FreeBSD 10.0-BETA1 now available Message-ID: <20131014170038.GE2029@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 17:00:42 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The first BETA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/10" branch. Important note to freebsd-update(8) users: Due to a last minute problem found in the 10.0-BETA1 freebsd-update(8) builds, freebsd-update(8) is NOT supported for 10.0-BETA1 upgrades. Please do not use freebsd-update(8) to upgrade to 10.0-BETA1. Please be aware that cvsup and CVS are not supported methods of updating the src/ tree. Also note, due to the size of the images, the ports.txz distribution is not included in 10.0-BETA1, however is expected to be included with disc1.iso for subsequent builds during the release cycle. The ports tree can be fetched either with the portsnap(8) utility, or using svnlite using any of the mirrors listed here: http://www.freebsd.org/doc/en/books/handbook/svn-mirrors.html Changes between -ALPHA5 and -BETA1 include: o Introduce freebsd-version(1), which is intended to be used as an auditing tool, to determine the userland patch level when it differs from what 'uname -r' reports. o Improve ZFS lzjb decompress performance. =20 o Add two new MIPS CPU families - mips24k and mips74k. o The "jail__*" rc.conf(5) variables for per-jail configuration are automatically converted to /var/run/jail..conf before the jail(8) utility is invoked, so the new jail.conf(5) syntax is used. o Remove most of the ATF tools and the _atf user. o Updates to random(4). Please note the following: - In 10.0-BETA1, it is not possible for random(4) to be loaded as a kernel module via kldload(8). If not using GENERIC, and the system kernel configuration excludes 'device random', please include random(4) in the kernel configuration file. The fix for this issue is pending review, and is expected to be fixed in 10.0-BETA2. o Updates to bsdinstall(8). Please note the following: - 10.0-BETA1 introduces a number of updates to bsdinstall(8), notably the ability to install to a full ZFS filesystem. Please keep in mind that this is an experimental feature. - If using the ZFS installation option in *and* have enabled full-disk encryption is enabled, a few entries will need to be manually added to loader.conf(5) before the 'bootpool' zpool will be available after the system boots. This manual step is expected to be fixed in 10.0-BETA2. The entries that need to be added are: zpool_cache_load=3D"YES" zpool_cache_type=3D"/boot/zfs/zpool.cache" zpool_cache_name=3D"/boot/zfs/zpool.cache" This can be done at the final menu of bsdinstall(8), when prompted to boot into the newly-installed system; alternatively, this can be done post-install, in which case, the following must be run before appending loader.conf(5): # zpool import -f bootpool Pre-installed virtual machine images for 10.0-BETA1 are also available for amd64 and i386 architectures. The images are located under the 'snapshots' directory on FTP, here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/20131012/10.0-BET= A1/ The disk images are available in both QCOW2 and VMDK format. The image download size is approximately 136 MB, which decompress to a 20GB sparse image. The partition layout is: - 512k - freebsd-boot GPT partition type (bootfs GPT label) - 1GB - freebsd-swap GPT partition type (swapfs GPT label) - ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) ISO Checksums: amd64 SHA256 (FreeBSD-10.0-BETA1-amd64-bootonly.iso) =3D d3c28a2b972fb38f6b29= 81729d72b50fcbb5ca07835e9d4e3cfa014e27527631 SHA256 (FreeBSD-10.0-BETA1-amd64-disc1.iso) =3D 226b88265e11accd4a873d5= fa49e4eaf87f22c00a6580c23879bd18cdb6077b3 SHA256 (FreeBSD-10.0-BETA1-amd64-memstick.img) =3D 1ff5f2e25a212a213873= e8670b88cbbf88e55105844ad44e425f73a99ebfd795 MD5 (FreeBSD-10.0-BETA1-amd64-bootonly.iso) =3D 13879ecb4dd06a8931c5373= db61af4bc MD5 (FreeBSD-10.0-BETA1-amd64-disc1.iso) =3D 4a6ba36de48ac51a5f1c060b32= 8e01c4 MD5 (FreeBSD-10.0-BETA1-amd64-memstick.img) =3D 85a2ae840db8b7cf59a002f= 4bc014d38 i386 SHA256 (FreeBSD-10.0-BETA1-i386-bootonly.iso) =3D 07c53db7588db0bf350bf= 374fe11b1973908ddf875cf110a306fb524760385d8 SHA256 (FreeBSD-10.0-BETA1-i386-disc1.iso) =3D 2d57b022f47359b2f3e11770= 7058aa0d4e410705563a5e2cd74b5e516ca299b5 SHA256 (FreeBSD-10.0-BETA1-i386-memstick.img) =3D 6a4e065c78799921675d9= ed219e605326a2d362c4a52b039ce99ce8af3874f23 MD5 (FreeBSD-10.0-BETA1-i386-bootonly.iso) =3D b9f43e74e2d33dad5d3ef4eb= 1f8720e1 MD5 (FreeBSD-10.0-BETA1-i386-disc1.iso) =3D 552be24b9b6a18b649c4a7fb97a= f72f6 MD5 (FreeBSD-10.0-BETA1-i386-memstick.img) =3D 7f77b584dcd47c7ef506c150= cd4b6823 ia64 SHA256 (FreeBSD-10.0-BETA1-ia64-bootonly.iso) =3D 50a63645a25fe32dc4a79= 8e62c1223b4f30338094dd29d721c5b3d09af8a8ebd SHA256 (FreeBSD-10.0-BETA1-ia64-disc1.iso) =3D a92d5b7ffc6976b2c1c72469= feaec02b24a5f743c2db4937002cbafc9054359c SHA256 (FreeBSD-10.0-BETA1-ia64-memstick.img) =3D fa74b5d72590e6c8961fa= 77a3bcd9f8f4f16e8e1115be05be6a694efcf7b9807 MD5 (FreeBSD-10.0-BETA1-ia64-bootonly.iso) =3D 4dfdab8653c6e23cf0d5da62= 4985c568 MD5 (FreeBSD-10.0-BETA1-ia64-disc1.iso) =3D 94ed426913097ebdda68382e8b3= 7db9d MD5 (FreeBSD-10.0-BETA1-ia64-memstick.img) =3D ab9710f1f17ccd06a37b46ff= 23831c56 powerpc SHA256 (FreeBSD-10.0-BETA1-powerpc-bootonly.iso) =3D 526d97055f4dbd4899= cdfc453609c24e3c3184562d61a295b617a8412a93aed0 SHA256 (FreeBSD-10.0-BETA1-powerpc-disc1.iso) =3D 0afcfdd26ed6cb1882226= 06fbf7cb1488343f460c70c3be6a7426093860d8a51 SHA256 (FreeBSD-10.0-BETA1-powerpc-memstick.img) =3D f6772e05f966d67c0e= 6e5c82986b4ec1eeeb44622a756638ff2f73aed66346ea MD5 (FreeBSD-10.0-BETA1-powerpc-bootonly.iso) =3D f28cd0dea86733c9384b0= cda5aacb72b MD5 (FreeBSD-10.0-BETA1-powerpc-disc1.iso) =3D f0c440bcb952bd86e1596255= 4ae24b16 MD5 (FreeBSD-10.0-BETA1-powerpc-memstick.img) =3D 42661e222189530f3faae= 69c428bd0ce powerpc64 SHA256 (FreeBSD-10.0-BETA1-powerpc-powerpc64-bootonly.iso) =3D f62dad40= a593a6e690dc54100a6d26b0f2029af1bda4144bd10b12076aaeb513 SHA256 (FreeBSD-10.0-BETA1-powerpc-powerpc64-disc1.iso) =3D 6aaa5d392cb= 4cdb555e4ef6e1805b9d7efcbf3eb92c142298def1415410ce092 SHA256 (FreeBSD-10.0-BETA1-powerpc-powerpc64-memstick.img) =3D 5db7fc6e= 448870ff53c1ea1b40008d244f27962b38dbdaa3232b162b2e2e00d0 MD5 (FreeBSD-10.0-BETA1-powerpc-powerpc64-bootonly.iso) =3D 603fce7c27f= 8fd4c55fa9e7380ae5542 MD5 (FreeBSD-10.0-BETA1-powerpc-powerpc64-disc1.iso) =3D b67d0fe1d5b019= d6961dbb3dcc04fa13 MD5 (FreeBSD-10.0-BETA1-powerpc-powerpc64-memstick.img) =3D e4083c808a7= 263aa26c9fb943bd2c8dc sparc64 SHA256 (FreeBSD-10.0-BETA1-sparc64-bootonly.iso) =3D 6c8ebc06be941ad3d7= ebbd7bcbc289fd8d150664eb71171ca98f8eef27941b0f SHA256 (FreeBSD-10.0-BETA1-sparc64-disc1.iso) =3D 60761fb88c7eb3b9397e5= 9a170ea02cb6e95ada7aa6f3b50ef5c99f6c3aaf5fe MD5 (FreeBSD-10.0-BETA1-sparc64-bootonly.iso) =3D 07c959194946873e2326d= c1a34c3b75d MD5 (FreeBSD-10.0-BETA1-sparc64-disc1.iso) =3D 5173acba64d32f6ab7cf45ee= 55620fa2 VM Image Checksums: amd64: SHA256 (FreeBSD-10.0-BETA1-amd64.qcow2.xz) =3D 6d837b0f7b9f460e99dfb915= d77c04d498faaf795edba42aaaec9745de20bd15 SHA256 (FreeBSD-10.0-BETA1-amd64.vmdk.xz) =3D 694ded4fc767c9aa58f3f9f08= b3fc52a6db293a2e6219ea01dc9dee12a6cc11f MD5 (FreeBSD-10.0-BETA1-amd64.qcow2.xz) =3D 3b99ca17904304d2bd1d2c23aa5= 59146 MD5 (FreeBSD-10.0-BETA1-amd64.vmdk.xz) =3D b55f45265a275bb9aa5361d823b7= 8770 i386: SHA256 (FreeBSD-10.0-BETA1-i386.qcow2.xz) =3D 914aa8df98d7a6c4cafe8bddc= 2fa20b985612d36ad1b209fc3283959cc89c6a0 SHA256 (FreeBSD-10.0-BETA1-i386.vmdk.xz) =3D c585975b94bf15129e5a68dc69= c9e8e1b02c970468361a9327230b3a045152c7 MD5 (FreeBSD-10.0-BETA1-i386.qcow2.xz) =3D dad81ab2ea0b15bdacdb5fa7c684= 2e60 MD5 (FreeBSD-10.0-BETA1-i386.vmdk.xz) =3D f89ddca64717043e7988ace7b1890= 4b1 Glen --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSXCM2AAoJELls3eqvi17Q3bIP/jhYxgBw3YgR3MLY1Zk09eiz N7rUsbF/iUwYrduwFwBUfq4Yed4n/jXhj8AaWM+UbOsq0pmFjL+z+uNPO2gsRGBv jcnKfcAsH7Q/dGnWZfMtWdteom1CZPakUMbnjZJkNvy93BamWsHn3N7OG61Baw9l 8NXHy+RXEgmTC1nNPQ4qMGKIYhb6jMqpdKYCcdKQdnLDjuHB8/gC6GQD579C5V/Z H9WzXSM6Z37xKCSGcjFMOa3me0tmLmmjrCyIyDKh+yWYlLqtpJHaJejvhoLoI2qo 10i/FaxUJx1hQuvXskcGghP663lOqXn3IgcwE9YFWmjhNlZ7zIlGtYP2fiDalHmN bqmp0fYgDvl7KavuB+1ijI7fxlX0gWg+hUK04HSrPWJHerirv4jFrHXxabl3Ex9p uG9N5IH7lUvAPngIajPStl2ZTLEnlEU/QDkMLRK3fLb3XmPi02kAf+EY0lLmSU5Z fkTxxEXljuV92AFvLkoVlNZ27P6v9qg/IVL+8YUjaWZPnp9cOOEkSU9JrH+abuUO Z6hXgHTACP2BAjM7hCBOEsYTPxhuAbmlqHHYZylrQdtiavAZ+PcvPCVnLIPLNSnD YjoJK5XnbMdNu512MpDCSHaloTzwniZrXzkWPdMiZgzcR1oObAiZm+paHZpfxKCn Z/cGPIff//uWza1cTETu =1GrD -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 19:12:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1AA3C5AD for ; Mon, 14 Oct 2013 19:12:07 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id C86432016 for ; Mon, 14 Oct 2013 19:12:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpapi; bh=gxGTAjlIQXnVU2nkFXqhxHbw/7I=; b=ZIAYAc0OHHePv+A9ln NU8GvX7bLDiFa6rJtFKYiu3DGlC9TO8o9o6n4YJTEpkDF8lF/cmAm9h0ZFanfobX Or5bg3vWL5YCBrPyA/CsaUQx3FImsP/vXsVy9S+QmVK1N4yO4Bs/n5LJ4ASDSR0X NuEIC34S9U03vY9rtGYIGa/ig= Received: by mf92 with SMTP id mf92.885.525C4205F Mon, 14 Oct 2013 19:12:05 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi20 (SG) with ESMTP id 141b861e636.6203.15402f4 for ; Mon, 14 Oct 2013 19:12:05 +0000 (UTC) Received: (qmail 93492 invoked from network); 14 Oct 2013 19:12:04 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 14 Oct 2013 19:12:04 -0000 Received: (qmail 17355 invoked from network); 14 Oct 2013 19:11:13 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 14 Oct 2013 19:11:13 -0000 Message-ID: <525C41D1.3040204@freebsd.org> Date: Mon, 14 Oct 2013 12:11:13 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> <525C210A.2000306@freebsd.org> <1381770007.42859.82.camel@revolution.hippie.lan> In-Reply-To: <1381770007.42859.82.camel@revolution.hippie.lan> X-Enigmail-Version: 1.5.2 Content-Type: multipart/mixed; boundary="------------030903020801090603020103" X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wtiZLvmVMY7SO3laMEiLE9Ua9Xxm/8D6Ipt49ZPGGr5Ir1u110b+BueSybNM4Zc+Dvfw0GdNedQ32C9rTnRhSe14rpeAL884xU6IO6JajXIr9o= Cc: FreeBSD current , freebsd-rc@FreeBSD.org, Nick Hibma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 19:12:07 -0000 This is a multi-part message in MIME format. --------------030903020801090603020103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/14/13 10:00, Ian Lepore wrote: > On Mon, 2013-10-14 at 09:51 -0700, Colin Percival wrote: >> Yes, it's hard to store state on diskless systems... but I figured >> that anyone building a diskless system would know to not create a >> "run firstboot scripts" marker. And not all embedded systems are >> diskless... > > The embedded systems we create at $work have readonly root and mfs /var, > but we do have writable storage on another filesystem. It would work > for us (not that we need this feature right now) if there were an rcvar > that pointed to the marker file. Of course to make it work, something > would have to get the alternate filesystem mounted early enough to be > useful (that is something we do already with a custom rc script). Indeed... the way my patch currently does things, it looks for the firstboot sentinel at the start of /etc/rc, which means it *has* to be on /. Making the path an rcvar is a good idea (updated patch attached) but we still need some way to re-probe for that file after mounting extra filesystems. > Note that I'm not asking for any changes here, just babbling. Babbling is good. Between us we might babble a useful solution. ;-) -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------030903020801090603020103 Content-Type: text/plain; charset=us-ascii; name="firstboot.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="firstboot.patch" Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 256432) +++ etc/defaults/rc.conf (working copy) @@ -619,6 +619,9 @@ accounting_enable="NO" # Turn on process accounting (or NO). ibcs2_enable="NO" # Ibcs2 (SCO) emulation loaded at startup (or NO). ibcs2_loaders="coff" # List of additional Ibcs2 loaders (or NO). +firstboot_sentinel="/firstboot" # Scripts with "firstboot" keyword are run if + # this file exists. Should be on a R/W filesystem so + # the file can be deleted after the boot completes. # Emulation/compatibility services provided by /etc/rc.d/abi sysvipc_enable="NO" # Load System V IPC primitives at startup (or NO). Index: etc/rc =================================================================== --- etc/rc (revision 256432) +++ etc/rc (working copy) @@ -81,6 +81,9 @@ skip="$skip -s nojailvnet" fi fi +if ! [ -e ${firstboot_sentinel} ]; then + skip="$skip -s firstboot" +fi # Do a first pass to get everything up to $early_late_divider so that # we can do a second pass that includes $local_startup directories @@ -116,6 +119,13 @@ run_rc_script ${_rc_elem} ${_boot} done +if [ -e ${firstboot_sentinel} ]; then + rm ${firstboot_sentinel} + if [ -e ${firstboot_sentinel}-reboot ]; then + rm ${firstboot_sentinel}-reboot + kill -INT 1 + fi +fi echo '' date exit 0 --------------030903020801090603020103-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 20:53:54 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 059B6E2D for ; Mon, 14 Oct 2013 20:53:54 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 955262754 for ; Mon, 14 Oct 2013 20:53:53 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so619493wid.11 for ; Mon, 14 Oct 2013 13:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4T42qN/W7qj2P8dL8U7s17xuESs0nWmK549NCjhIxf0=; b=QkZ6fSf1g5Ofor5qGLNMYejHOW7OrA9D4u4qJAKL5WjZhdbfPtub9gJmTT2UceuHhJ lq0fDC7NxFvGBsgQszwhC0C8AdTuCHihViMSCijJi06kPEwFiuxXyUL8/ZFycYRmeuKo Z7Jv/OYK6zQ0gTpr5+lDQcQZnoOUHRWWQv5tSmU6KfTT4HL1WwBUL/06iubimwkvllze gHmLP4z/WtdT9k5RQA+XMjkwaSKOrBigGZN8NFIwygzm4R30iwAwUB9iAWgSGYO8/7/x +z5WvfEG/A8nWJseGhWOd8j9DiIAeVyL4b4fZhQg+0qEFPAMdYYjCdVN9Y/w40dwPw2t XB7w== X-Received: by 10.180.100.194 with SMTP id fa2mr16408537wib.44.1381784031873; Mon, 14 Oct 2013 13:53:51 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.236.131 with HTTP; Mon, 14 Oct 2013 13:53:31 -0700 (PDT) In-Reply-To: <525B2967.9060404@allanjude.com> References: <525B2967.9060404@allanjude.com> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 14 Oct 2013 22:53:31 +0200 X-Google-Sender-Auth: ZvW_pqDwNQEx4071hrJ4HOMN7Hw Message-ID: Subject: Re: Process stuck in D+ state To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 20:53:54 -0000 On Mon, Oct 14, 2013 at 1:14 AM, Allan Jude wrote: > Looking at the process states, connect and rpcreconnect, seem to suggest > something involving yp/nis or NFS or some such. > Oops, yes you've right, I've got an sub-folder on my homedir that was NFS mounted and the NFS server was poweroff without unmounting this sub-folder first. I need to check the NFS mount option for avoiding to stuck all the disk-related process once the NFS server disapear. Thanks for pointing this. Olivier From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 20:55:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CAFF41D4 for ; Mon, 14 Oct 2013 20:55:48 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id A5D78278E for ; Mon, 14 Oct 2013 20:55:48 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1E1E73D46B; Mon, 14 Oct 2013 20:55:46 +0000 (UTC) Message-ID: <525C5A6F.6050906@allanjude.com> Date: Mon, 14 Oct 2013 16:56:15 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= Subject: Re: Process stuck in D+ state References: <525B2967.9060404@allanjude.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 20:55:48 -0000 On 2013-10-14 16:53, Olivier Cochard-Labbé wrote: > On Mon, Oct 14, 2013 at 1:14 AM, Allan Jude wrote: >> Looking at the process states, connect and rpcreconnect, seem to suggest >> something involving yp/nis or NFS or some such. >> > Oops, yes you've right, I've got an sub-folder on my homedir that was > NFS mounted and the NFS server was poweroff without unmounting this > sub-folder first. > I need to check the NFS mount option for avoiding to stuck all the > disk-related process once the NFS server disapear. > > Thanks for pointing this. > > Olivier my fstab nfs options: rw,bg,intr,soft,noatime -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 21:28:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 60AE9185 for ; Mon, 14 Oct 2013 21:28:06 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2463D2966 for ; Mon, 14 Oct 2013 21:28:05 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:60064] helo=localhost) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id D6/92-01315-ED16C525; Mon, 14 Oct 2013 21:27:59 +0000 Date: Mon, 14 Oct 2013 21:27:58 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: BE Loader Menu (was Re: rcs) References: <60177810-8DC4-4EA3-8040-A834B79039D2@orthanc.ca> <52538EDC.2080001@freebsd.org> <52541202.3010707@mu.org> <20131008.170444.74714516.sthaug@nethelp.no> <52542BD4.5070706@FreeBSD.org> <52542E1D.9000000@mu.org> <52555D1C.8010407@freebsd.org> <52558577.5020401@allanjude.com> <52558779.2070203@pcbsd.org> <517D65A3D61F684FAE2B2EC2D2DA06C3@fisglobal.com> <13CA24D6AB415D428143D44749F57D720FC4B2A3@LTCFISWMSGMB21.FNFIS.com> <201310141554.r9EFsRIk065272@enceladus10.kn-bremen.de> X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Cc: Juergen Lock , "Teske, Devin" , Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 21:28:06 -0000 from Juergen Lock: > If you mean it loads the kernel but then crashes instead of booting it > then your grub2 version is missing this fix: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699002 > >I used Super Grub2 Disk image on the System Rescue CD written to USB stick. > A super grub disk beta version with the mentioned fix is here: > https://forja.cenatic.es/frs/?group_id=204 > (2.00s1b6, it also has fixed autodetection of FreeBSD installs.) I did the download, now will copy it to the System Rescue CD USB stick and make the appropriate entry in syslinux.cfg . I don't think the Super Grub2 Disk was able to load the kernel. It led to a prompt like what I get when I escape from the boot menu to loader prompt. My image resulting from mkrescue in sysutils/grub2 built from FreeBSD ports worked on FreeBSD 10-head, now 10-stable. But I got the same failure on FreeBSD 9.2. I copied /boot/kernel/kernel from the hard-drive installation to /boot/kernel/kernel92 on the USB-stick installation. Then I was able to boot the USB stick, escape to loader prompt, then unload boot /boot/kernel/kernel92 -a -s (or without -s for regular boot, but I was upgrading from 9.2-prerelease). Now uname -a shows FreeBSD amelia2 9.2-STABLE FreeBSD 9.2-STABLE #19 r256095M: Tue Oct 8 08:57:11 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 14 22:40:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5120D336 for ; Mon, 14 Oct 2013 22:40:14 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFFB2D2E for ; Mon, 14 Oct 2013 22:40:13 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 996153D563 for ; Mon, 14 Oct 2013 22:40:12 +0000 (UTC) Message-ID: <525C72E8.1070901@allanjude.com> Date: Mon, 14 Oct 2013 18:40:40 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "" Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52531295.7090700@allanjude.com> <5254D231.5070803@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC4B3F2@LTCFISWMSGMB21.FNFIS.com> <525596A7.2090701@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC4B907@LTCFISWMSGMB21.FNFIS.com> <52561AB6.3030802@allanjude.com> In-Reply-To: <52561AB6.3030802@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 14 Oct 2013 22:40:14 -0000 For those of you not aware, the latest version of the root-on-ZFS+GELI in bsdinstall patch shipped as part of FreeBSD 10.0-BETA1 today. Please test it and report any issues you have. There is one known issue (already patched in our repo), where if you do a GELI pool, the unencrypted /boot pool is not mounted properly once the system is up (a case where the /boot/zfs/zpool.cache is still useful) -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 05:52:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D9228168 for ; Tue, 15 Oct 2013 05:52:45 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8D5B23BF for ; Tue, 15 Oct 2013 05:52:45 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wp18so1290060obc.38 for ; Mon, 14 Oct 2013 22:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rDX5w1yZNwBdWPmTTyx8G9iq8ezHS9cbWe8zLHtdNeE=; b=l75H/C+qUeku/HEgGzhv2hkjCEVSGj16gNQppM4MVhoPSFrLHtq2k+2oTNOuYouY10 tiFMsN4ih6HN7oWE/qKwhyExRcPona+3boLBnPBULovVr6mByvvgNfjMmcvMuWwgjryC BebH9slIemq/HZVRzqS/kFGH0eKv7GodbgUITMFQEn8NOrmgs97O4Ix0BCycMUwH3wX5 eP3cSh4GMkB+6FaEvUOKQs5jNwpJgj26Aw5iv4/pnCbCmPuBHkTkSMzFWQ3WG89ArglX gbpy5jInZD9DWE5qeA1r5Fli5nVDh5U9XXJ7PbuLiYBgM11llATjE2khpCRL/0YpQRIU Pm1A== MIME-Version: 1.0 X-Received: by 10.182.16.201 with SMTP id i9mr31582013obd.21.1381816364975; Mon, 14 Oct 2013 22:52:44 -0700 (PDT) Received: by 10.76.156.8 with HTTP; Mon, 14 Oct 2013 22:52:44 -0700 (PDT) Date: Tue, 15 Oct 2013 09:52:44 +0400 Message-ID: Subject: Buildworld with ccache fails From: "Sevan / Venture37" To: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 05:52:45 -0000 Hi, I noticed that back in April changes had been commited to allow ccache to build -HEAD world so give it a try again on r256380. The build process now fails at building libc.so.7 with error /usr/bin/ld: this linker was not configured to use sysroots cc: error: linker command failed with exit code 1 (use -v to see invocation) Sevan / Venture37 From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 08:36:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4BAEEBB7 for ; Tue, 15 Oct 2013 08:36:31 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A09522CC7 for ; Tue, 15 Oct 2013 08:36:30 +0000 (UTC) Received: from mail-wg0-f47.google.com ([74.125.82.47]) (using TLSv1) by eu1sys200aob115.postini.com ([207.126.147.11]) with SMTP ID DSNKUlz+ct12D82Z7wGKuWKweB9cV3aHZqWF@postini.com; Tue, 15 Oct 2013 08:36:30 UTC Received: by mail-wg0-f47.google.com with SMTP id c11so3357876wgh.2 for ; Tue, 15 Oct 2013 01:36:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=Ou4YbHxnVaCL/YU6ZS0DdIh3k55xIIg4DZs6C/5sJRE=; b=H4IxteGmI8/YTQZFkbvDZq2CWrB5fwTfZq4k+T/6AmTlvv1E+oDScsVoSnljgPN32L JimD28JjkaxjQfCzqp/Y5wvL90D4IvVMr5e4PrrkBj2CVxpDTP7dttS7cdS2XYwLsfLy tk366anJkBbiSiRwtRfapWyjcZq/wSr50J/LOEI7MqLqHUuecmRSCyvSnLbq1fgakR++ h84kWyr39bdwTF3volOUt6ZQKNUqN5ercnJYzIOkDSxb65OqfhKWUwY1m1htYvhEj9Ia Ak2VlLGU2PDDdvYi6Cz79hH4si3b6ixpHTUlcI5qlI1OUaqI0POgFW39EBc3atahbMpM M2gg== X-Gm-Message-State: ALoCoQkLFmtrMF0YT4yhMkyTbqxYd46JYRVHF5skr1MDRrJOTtGm/0lj2IYPNUm2IiFdHNZD3x+07853Yg6taXIfM2odx7V7KgD2+t9gGzuf8Wg0kT0+6MZMt9NVRVSntLgdqUmDMHymNWVwRJiNxF4EpCFi8u/fInx5Y19mNm38c+307yx7BrI= X-Received: by 10.180.95.202 with SMTP id dm10mr13692836wib.62.1381826162075; Tue, 15 Oct 2013 01:36:02 -0700 (PDT) X-Received: by 10.180.95.202 with SMTP id dm10mr13692817wib.62.1381826161932; Tue, 15 Oct 2013 01:36:01 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id mw9sm376220wib.0.2013.10.15.01.35.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2013 01:36:00 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9F8ZwlK043225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Oct 2013 09:35:58 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9F8ZwZk043224; Tue, 15 Oct 2013 09:35:58 +0100 (BST) (envelope-from mexas) Date: Tue, 15 Oct 2013 09:35:58 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310150835.r9F8ZwZk043224@mech-cluster241.men.bris.ac.uk> To: davide@freebsd.org, mexas@bris.ac.uk Subject: Re: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks In-Reply-To: Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:36:31 -0000 >From davide.italiano@gmail.com Fri Oct 11 15:39:49 2013 > >If you're not able to get a full dump, a textdump would be enough. >In your DDB scripts just remove the 'call doadump' step and you should >be done, unless I'm missing something. >Please adjust the script as well to include all the informations >requested as mentioned in my previous link, e.g. 'show lockedvnods' is >not mentioned on the example section of textdump(4) manpage but it >could be useful to ease debugging. It seems "call doadump" is always needed. At least it is included in textdump(4) examples. Also, this tutorial incluldes it: http://www.etinc.com/122/Using-FreeBSD-Text-Dumps I think I still haven't got textdump right, because instead of savecore: writing core to textdump.tar.0 I see: savecore: writing core to /var/crash/vmcore.9 Thanks Anton From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 08:43:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 654E0D85 for ; Tue, 15 Oct 2013 08:43:56 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com [207.126.144.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 671D42D2C for ; Tue, 15 Oct 2013 08:43:54 +0000 (UTC) Received: from mail-wg0-f51.google.com ([74.125.82.51]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKUl0ASamvSHv8ND3C6dkFNxh7x0przGNz@postini.com; Tue, 15 Oct 2013 08:43:55 UTC Received: by mail-wg0-f51.google.com with SMTP id l18so4260021wgh.30 for ; Tue, 15 Oct 2013 01:43:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=qIZOnKs6cocoqi24maySE41oy63uT+WI8F4kkYMQedY=; b=m6urSfwkEZk/kazrc/6YCSRNbhhGCuSAvdfcYM0wXhHeT+TOAGtN+XdxeJoSMFvZoU VrHdCklqzZrj7Q+aNm0UUmzB7JpTVOT2hROUcWnpS2RoGZZQWELqX14sguB8DwNtFW7Y xCffBF4wkvaeC7PqXTAOS6Yq3OJGR6V96vfZqEyu9p9zmaOOWfLtAZ+zfIsjEJdxyDXj TrXuwu6WU31YFezTGKq7xzpHysgz5uczYO+vrCg5PnjZvwRqijA8CGmhHrZ1qhWIzT45 NVKAGXjPoFfOzZHgk7YpEq9HtDgLPMSDlaxqaCV+oWHUyOzks17eN2vT++KRGsX7XrgY YhYA== X-Gm-Message-State: ALoCoQlXbRezJcg+8OvT9FMiCi90r0kDoaNq74ya8lP/ugLTb4MoQ6W3L6UGDQIwbbw/IB0ayQQMOtIetykWXJugnH9REa/oWqiQg0pebx+byIX6rx3BWfDYfl/7bCi+zTQAfjRe5QHDkF5mqxBp8rtkdHmisBNiJ4Z95iOFkq5kc4CAtKhx8As= X-Received: by 10.180.187.169 with SMTP id ft9mr18481612wic.14.1381826633644; Tue, 15 Oct 2013 01:43:53 -0700 (PDT) X-Received: by 10.180.187.169 with SMTP id ft9mr18481606wic.14.1381826633515; Tue, 15 Oct 2013 01:43:53 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id om10sm3947130wic.5.2013.10.15.01.43.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2013 01:43:52 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9F8hok0043236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Oct 2013 09:43:50 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9F8ho1c043235; Tue, 15 Oct 2013 09:43:50 +0100 (BST) (envelope-from mexas) Date: Tue, 15 Oct 2013 09:43:50 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310150843.r9F8ho1c043235@mech-cluster241.men.bris.ac.uk> To: davide@freebsd.org, mexas@bris.ac.uk Subject: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock In-Reply-To: Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:43:56 -0000 >From davide.italiano@gmail.com Mon Oct 14 12:50:44 2013 > >This is fair enough -- If you're still at the ddb prompt, please print >the whole panic message (or at least the address of the lock reported >as deadlocked by DEADLKRES), so that we can at least have a candidate. > Here's another one, followed by savecore deadlock. ia64 r255488 panic: wrong page state m 0xe00000027a9adb40 cpuid = 0 KDB: stack backtrace: db_trace_self(0x9ffc000000158380) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc000000607370) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc000000ed0e10, 0x9ffc00000058e660, 0x40c, 0x9ffc0000010a44a0) at kdb_backtrace+0xc0 vpanic(0x9ffc000000dd3fe0, 0xa00000009de61118, 0x9ffc000000ef9670, 0x9ffc000000ed0bc0) at vpanic+0x260 kassert_panic(0x9ffc000000dd3fe0, 0xe00000027a9adb40, 0x81f, 0xe0000002013cf400, 0x9ffc0000006a0220, 0x2c60, 0xe0000002013cf400, 0xe0000002013cf418) at kassert_panic+0x120 vn_sendfile(0x8df, 0xd, 0x0, 0x0, 0x0, 0x8df, 0x7fffffffffffdfe0, 0x0) at vn_sendfile+0x15d0 sys_sendfile(0xe000000012aef200, 0xa00000009de614e8, 0x10, 0xa00000009de61360) at sys_sendfile+0x2b0 syscall(0xe0000000154f2940, 0xd, 0x0, 0xe000000012aef200, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return KDB: enter: panic [ thread pid 5989 tid 100111 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2c990,gp ;; db> db> scripts lockinfo=show locks; show alllocks; show lockedvnods zzz=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset db> db> run zzz I get to db:0:alltrace> capture off db:0:off> call doadump Dumping 10220 MB (25 chunks) chunk 0: 1 pages ... ok chunk 1: 159 pages ... ok chunk 2: 256 pages ... ok chunk 3: 7680 pages ... ok chunk 4: 8192 pages ... ok chunk 5: 239734 pages ... ok chunk 6: 748 pages ... ok chunk 7: 533 pages ... ok chunk 8: 21 pages ... ok chunk 9: 1572862 pages ... ok chunk 10: 781683 pages ... ok chunk 11: 512 pages ... ok chunk 12: 139 pages ... ok chunk 13: 484 pages ... ok chunk 14: 1565 pages ... ok chunk 15: 1 pages ... ok chunk 16: 506 pages ... ok chunk 17: 1 pages ... ok chunk 18: 3 pages ... ok chunk 19: 566 pages ... ok chunk 20: 66 pages ... ok chunk 21: 1 pages ... ok chunk 22: 285 pages ... ok chunk 23: 6 pages ... ok chunk 24: 354 pages ... ok Dump complete = 0 db:0:doadump> reset So far, so good. On reboot I get: Starting ddb. ddb: sysctl: debug.ddb.scripting.scripts: Invalid argument /etc/rc: WARNING: failed to start ddb This probably already indicates some problem? Eventually I get to: savecore: reboot after panic: wrong page state m 0xe00000027a9adb40 Oct 15 09:05:50 mech-as28 savecore: reboot after panic: wrong page state m 0xe00000027a9adb40 savecore: writing core to /var/crash/vmcore.9 So here I'm confused. I think I set up textdump as in the man page. So I think the core should not be written. Instead I was expecting ddb.txt, config.txt, etc., as in textdump(4). Anyway, savecore eventually deadlocks: panic: deadlkres: possible deadlock detected for 0xe0000000127b7b00, blocked for 901401 ticks cpuid = 0 KDB: stack backtrace: db_trace_self(0x9ffc000000158380) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc000000607370) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc000000ed0e10, 0x9ffc00000058e660, 0x40c, 0x9ffc0000010a44a0) at kdb_backtrace+0xc0 vpanic(0x9ffc000000db8a18, 0xa00000009dca7518) at vpanic+0x260 panic(0x9ffc000000db8a18, 0x9ffc000000db8c70, 0xe0000000127b7b00, 0xdc119) at panic+0x80 deadlkres(0xdc119, 0xe0000000127b7b00, 0x9ffc000000dbb648, 0x9ffc000000db89a8) at deadlkres+0x420 fork_exit(0x9ffc000000e0fca0, 0x0, 0xa00000009dca7550) at fork_exit+0x120 enter_userland() at enter_userland KDB: enter: panic [ thread pid 0 tid 100053 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2c990,gp ;; db> db> scripts lockinfo=show locks; show alllocks; show lockedvnods db> run lockinfo db:0:lockinfo> show locks db:0:locks> show alllocks db:0:alllocks> show lockedvnods Locked vnodes 0xe0000000127cbba8: tag devfs, type VCHR usecount 1, writecount 0, refcount 19 mountedhere 0xe0000000126ab200 flags (VI_ACTIVE) v_object 0xe0000000127c2b00 ref 0 pages 422 lock type devfs: EXCL by thread 0xe000000012690000 (pid 21, syncer, tid 100062) dev da3p1 0xe0000000127f4ec0: tag ufs, type VREG usecount 1, writecount 1, refcount 32934 mountedhere 0 flags (VI_ACTIVE) v_object 0xe0000000127f7200 ref 0 pages 1242850 lock type ufs: EXCL by thread 0xe0000000127b7b00 (pid 805, savecore, tid 100079) ino 6500740, on dev da3p1 db> db> ps pid ppid pgrp uid state wmesg wchan cmd 805 803 24 0 L+ *vm page 0xe000000012402fc0 savecore 803 24 24 0 DL+ vm map ( 0xe00000001285fa88 sh 801 1 801 0 Ss select 0xe000000010c296c0 syslogd 792 1 792 0 Ss select 0xe000000010c29840 ipmon 670 1 670 0 Ss select 0xe0000000126d5740 devd 155 1 155 0 SWs pause 0xe0000000127fe9e8 adjkerntz 24 1 24 0 LLs+ *vm activ 0xe000000012403bc0 sh 23 0 0 0 DL sdflush 0x9ffc000000ed1ff0 [softdepflush] 22 0 0 0 DL vlruwt 0xe000000012409720 [vnlru] 21 0 0 0 LL *vm objec 0xe000000010c30240 [syncer] 20 0 0 0 DL psleep 0x9ffc000000ed1390 [bufdaemon] 19 0 0 0 DL pgzero 0x9ffc000000ed239c [pagezero] 18 0 0 0 RL [vmdaemon] 17 0 0 0 LL *pmap pv 0xe000000010c2e180 [pagedaemon] 9 0 0 0 DL ccb_scan 0x9ffc000000ed26a0 [xpt_thrd] 6 0 0 0 DL waiting_ 0x9ffc0000010f33b0 [sctp_iterator] 5 0 0 0 DL (threaded) [zfskern] 100052 D l2arc_fe 0x9ffc000001547f40 [l2arc_feed_thread] 100051 D arc_recl 0x9ffc000001538120 [arc_reclaim_thread] --More-- 4 0 0 0 DL ispf 0xe000000011a02000 [isp0: fc_thrd0] 3 0 0 0 DL idle 0xa000000000a16000 [mpt_recovery1] 2 0 0 0 DL idle 0xa0000000009fe000 [mpt_recovery0] 16 0 0 0 DL (threaded) [usb] 100039 D - 0xa0000000009fae18 [usbus2] 100038 D - 0xa0000000009fadc0 [usbus2] 100037 D - 0xa0000000009fad68 [usbus2] 100036 D - 0xa0000000009fad10 [usbus2] 100034 D - 0xa0000000009f1460 [usbus1] 100033 D - 0xa0000000009f1408 [usbus1] 100032 D - 0xa0000000009f13b0 [usbus1] 100031 D - 0xa0000000009f1358 [usbus1] 100029 D - 0xa0000000009ed460 [usbus0] 100028 D - 0xa0000000009ed408 [usbus0] 100027 D - 0xa0000000009ed3b0 [usbus0] 100026 D - 0xa0000000009ed358 [usbus0] 15 0 0 0 DL tzpoll 0x9ffc000000ecfd20 [acpi_thermal] 14 0 0 0 DL - 0x9ffc000000ed0008 [rand_harvestq] 13 0 0 0 LL (threaded) [geom] 100012 D - 0x9ffc000000ed0540 [g_down] --More-- 100011 L *vm objec 0xe000000010c30240 [g_up] 100010 D - 0x9ffc000000ed0528 [g_event] 12 0 0 0 RL (threaded) [intr] 100048 I [swi0: uart uart+++] 100046 I [irq71: isp0] 100042 I [irq28: mpt1] 100040 I [irq27: mpt0] 100035 I [irq18: ehci0] 100030 I [irq17: ohci1] 100025 I [irq16: ohci0] 100022 I [swi6: task queue] 100021 I [swi6: Giant taskq] 100019 I [swi5: fast taskq] 100015 I [swi2: cambio] 100008 I [swi4: clock] 100007 Run CPU 1 [swi4: clock] 100006 I [swi3: vm] 100005 I [swi1: netisr 0] 11 0 0 0 RL (threaded) [idle] 100004 CanRun [idle: cpu1] 100003 CanRun [idle: cpu0] 1 0 1 0 SLs wait 0xe000000011176de0 [init] 10 0 0 0 DL audit_wo 0x9ffc0000010f7a48 [audit] 0 0 0 0 RLs (threaded) [kernel] 100053 Run CPU 0 [deadlkres] 100050 D - 0xe000000011a2d300 [system_taskq_1] 100049 D - 0xe000000011a2d300 [system_taskq_0] 100045 D - 0xe000000011198500 [em1 taskq] 100044 D - 0xe000000011198600 [em0 taskq] 100023 D - 0xe00000001119b300 [ffs_trim taskq] 100020 D - 0xe00000001119b600 [thread taskq] 100018 D - 0xe00000001119b800 [acpi_task_2] 100017 D - 0xe00000001119b800 [acpi_task_1] 100016 D - 0xe00000001119b800 [acpi_task_0] 100014 D - 0xe00000001119ba00 [kqueue taskq] 100009 D - 0xe00000001119bd00 [firmware taskq] 100000 D swapin 0x9ffc000000eedd28 [swapper] db> db> show pcpu cpuid = 0 dynamic pcpu = 0x40040040ff13ca80 curthread = 0xe000000011a26d80: pid 0 "deadlkres" curpcb = 0 fpcurthread = none idlethread = 0xe000000011178900: tid 100003 "idle: cpu0" MD: vhpt = 0xe0000040ff000000 MD: lid = 0 MD: clock = 0x2351ad02dce MD: clock_mode = 2 MD: clock_load = 0 MD: stats = 0x9ffc0000010ff130 MD: pmap = 0x9ffc000000eee760 spin locks held: db> db> bt Tracing pid 0 tid 100053 td 0xe000000011a26d80 kdb_enter(0x9ffc000000dc2fd0, 0x9ffc000000dc2fd0, 0x9ffc00000058e6b0, 0x40c) at kdb_enter+0x92 vpanic(0x9ffc000000db8a18, 0xa00000009dca7518) at vpanic+0x2b0 panic(0x9ffc000000db8a18, 0x9ffc000000db8c70, 0xe0000000127b7b00, 0xdc119) at panic+0x80 deadlkres(0xdc119, 0xe0000000127b7b00, 0x9ffc000000dbb648, 0x9ffc000000db89a8) at deadlkres+0x420 fork_exit(0x9ffc000000e0fca0, 0x0, 0xa00000009dca7550) at fork_exit+0x120 enter_userland() at enter_userland db> db> alltrace Tracing command savecore pid 805 tid 100079 td 0xe0000000127b7b00 cpu_switch(0xe0000000127b7b00, 0xe000000011178900, 0xe000000012402fc0, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe0000000127b7b00, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 mi_switch(0x103, 0x0, 0xe0000000127b7b00, 0x9ffc00000062d1f0) at mi_switch+0x3f0 turnstile_wait(0xe000000012402fc0, 0xe000000012400480, 0x0, 0x9ffc000000dcb698) at turnstile_wait+0x960 __mtx_lock_sleep(0x9ffc0000010f9998, 0xe0000000127b7b00, 0xe000000012402fc0, 0x9ffc000000dc0558, 0x742) at __mtx_lock_sleep+0x2f0 __mtx_lock_flags(0x9ffc0000010f9980, 0x0, 0x9ffc000000dd4a90, 0x742) at __mtx_lock_flags+0x1e0 vfs_vmio_release(0xa00000009ebe72f0, 0xe00000027ed2ab70, 0x3, 0xa00000009ebe736c, 0xa00000009ebe7498, 0xa00000009ebe72f8, 0x9ffc000000dd4a90, 0x9ffc0000010f9680) at vfs_vmio_release+0x290 getnewbuf(0xe0000000127f4ec0, 0x0, 0x0, 0x8000, 0xa00000009ebe99a8, 0x0, 0x9ffc0000010f0798, 0xa00000009ebe72f0) at getnewbuf+0x7e0 getblk(0xe0000000127f4ec0, 0x4cbaa, 0x8000, 0x0, 0x0, 0x0, 0x0, 0x0) at getblk+0xee0 ffs_balloc_ufs2(0xe0000000127f4ec0, 0x4cbaa, 0xa0000000c60ba000, 0xe000000011165a00, 0x7f050000, 0xa00000009dd79160) at ffs_balloc_ufs2+0x2950 ffs_write(0xa00000009dd79248, 0x3000, 0x265d50000) at ffs_write+0x5c0 VOP_WRITE_APV(0x9ffc000000e94ac0, 0xa00000009dd79248, 0x0, 0x0) at VOP_WRITE_APV+0x330 vn_write(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000129ae830, 0xe0000000127f4ec0) at vn_write+0x450 vn_io_fault(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000127b7b00) at vn_io_fault+0x330 dofilewrite(0xe0000000127b7b00, 0x7, 0xe0000000129ae820, 0xa00000009dd79360, 0xffffffffffffffff, 0x0) at dofilewrite+0x180 kern_writev(0xe0000000127b7b00, 0x7, 0xa00000009dd79360) at kern_writev+0xa0 sys_write(0xe0000000127b7b00, 0xa00000009dd794e8, 0x9ffc000000abac80, 0x48d) at sys_write+0x100 syscall(0xe0000000129d04a0, 0x140857000, 0x8000, 0xe0000000127b7b00, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 --More-- epc_syscall_return() at epc_syscall_return Tracing command sh pid 803 tid 100075 td 0xe0000000127b6000 cpu_switch(0xe0000000127b6000, 0xe000000011178900, 0x9ffc000000f4c570, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe0000000127b6000, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000127b6000, 0x9ffc000000620b70) at mi_switch+0x3f0 sleepq_switch(0xe00000001285fa88, 0x0, 0xe0000000127b6378, 0xe0000000127b6000) at sleepq_switch+0x2e0 sleepq_wait(0xe00000001285fa88, 0x0, 0x9ffc000000dca928, 0xe0000000127b6000, 0x9ffc00000059d350) at sleepq_wait+0xb0 _sx_slock_hard(0xe00000001285fa88, 0x0, 0xe00000001285faa0, 0xe000000012400000, 0xe00000001285fa88) at _sx_slock_hard+0x5f0 _sx_slock(0xe00000001285fa88, 0x0, 0x9ffc000000dfd218, 0xefa) at _sx_slock+0x190 _vm_map_lock_read(0xe00000001285fa08, 0x9ffc000000dfd218, 0xefa) at _vm_map_lock_read+0x80 vm_map_lookup(0xa00000009dd58928, 0x100046000, 0x1, 0xa00000009dd58930, 0xa00000009dd58918, 0xa00000009dd58920, 0xa00000009dd588f0, 0xa00000009dd588f4) at vm_map_lookup+0x70 vm_fault_hold(0xe00000001285fa08, 0x100046000, 0x1, 0x0, 0x0) at vm_fault_hold+0x280 vm_fault(0xe00000001285fa08, 0x100046000, 0x1, 0x0, 0xe0000000127b6000, 0x9ffc000000abbce0, 0x716, 0xe0000000127fe5a0) at vm_fault+0xf0 trap(0x14, 0xa00000009dd59400) at trap+0x9e0 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 --- trapframe at 0xa00000009dd59400 (null)(...) at 0x8000000000000120 Tracing command syslogd pid 801 tid 100078 td 0xe00000001282c000 cpu_switch(0xe00000001282c000, 0xe000000011178480, 0x9ffc000000f4c110, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe00000001282c000, 0xe000000011178480, 0x9ffc000000f16398, 0x9ffc000000f16380) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001282c000, 0x9ffc000000620b70) at mi_switch+0x3f0 sleepq_switch(0xe000000010c296c0, 0x0, 0xe00000001282c378, 0xe00000001282c000) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000010c296c0, 0x0, 0x9ffc000000dca928, 0x9ffc00000056ab00) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000010c296c0, 0x0, 0x9ffc0000004f7230, 0x611, 0x9ffc0000004f7270) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe000000010c296c0, 0xe000000010c296a0, 0xe00000001282c000, 0x0, 0x9ffc000000ef0710) at _cv_wait_sig+0x4d0 seltdwait(0xe000000010c29680, 0xffffffffffffffff, 0x0, 0xe000000010c296b8, 0x9ffc000000dcdfe0, 0x9ffc000000645bf0) at seltdwait+0x110 kern_select(0xe00000001282c000, 0x0, 0x140866180, 0x0, 0x0, 0xffffffffffffffff, 0x9) at kern_select+0xb40 sys_select(0xe00000001282c000, 0xa00000009dd714e8, 0x9ffc000000abac80, 0x48d) at sys_select+0xb0 syscall(0xe0000000129d0940, 0x140866180, 0x0, 0xe00000001282c000, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command ipmon pid 792 tid 100077 td 0xe00000001282c480 cpu_switch(0xe00000001282c480, 0xe000000011178900, 0x9ffc000000f4d560, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe00000001282c480, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001282c480, 0x9ffc000000620b70) at mi_switch+0x3f0 sleepq_switch(0xe000000010c29840, 0x0, 0xe00000001282c7f8, 0xe00000001282c480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000010c29840, 0x0, 0x9ffc000000dca928, 0x9ffc00000056ab00) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000010c29840, 0x0, 0x9ffc0000004f7230, 0x611, 0x9ffc0000004f7270) at sleepq_wait_sig+0x30 --More-- _cv_wait_sig(0xe000000010c29840, 0xe000000010c29820, 0xe00000001282c480, 0x0, 0x9ffc000000ef0710) at _cv_wait_sig+0x4d0 seltdwait(0xe000000010c29800, 0xffffffffffffffff, 0x0, 0xe000000010c29838, 0x9ffc000000dcdfe0, 0x9ffc000000645bf0) at seltdwait+0x110 kern_select(0xe00000001282c480, 0x0, 0x7fffffffffff6b50, 0x0, 0x0, 0xffffffffffffffff, 0x4) at kern_select+0xb40 sys_select(0xe00000001282c480, 0xa00000009dd694e8, 0x9ffc000000abac80, 0x48d) at sys_select+0xb0 syscall(0xe0000000129d0de0, 0x7fffffffffff6b50, 0x0, 0xe00000001282c480, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command devd pid 670 tid 100056 td 0xe000000012400d80 cpu_switch(0xe000000012400d80, 0xe000000011178480, 0x9ffc000000f4b738, 0x9ffc0000005e7e80) at cpu_switch+0xd0 sched_switch(0xe000000012400d80, 0xe000000011178480, 0x9ffc000000f16398, 0x9ffc000000f16380) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012400d80, 0x9ffc000000620b70) at mi_switch+0x3f0 sleepq_switch(0xe0000000126d5740, 0x0, 0xe0000000124010f8, 0xe000000012400d80) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000126d5740, 0x0, 0x9ffc000000dca928, 0xe0000000126d5720) at sleepq_catch_signals+0x190 sleepq_timedwait_sig(0xe0000000126d5740, 0x0, 0x9ffc0000004f6430, 0x9ffc0000004f6470, 0x713) at sleepq_timedwait_sig+0x30 _cv_timedwait_sig_sbt(0xe0000000126d5740, 0xe0000000126d5720, 0x5bbba38f388, 0x3c0000000, 0x200) at _cv_timedwait_sig_sbt+0x4f0 seltdwait(0xe0000000126d5700, 0x5bbba38f388, 0x3c0000000, 0xe0000000126d5738, 0x9ffc000000dcdfe0, 0x9ffc000000645bf0) at seltdwait+0xf0 kern_select(0xe000000012400d80, 0x0, 0x7fffffffffffcd00, 0x0, 0x0, 0x5bbba38f388, 0x5) at kern_select+0xb40 sys_select(0xe000000012400d80, 0xa00000009dcc14e8, 0x9ffc000000abac80, 0x48d) at sys_select+0xb0 syscall(0xe0000000111cb280, 0x7fffffffffffcd00, 0x0, 0xe000000012400d80, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return --More-- Tracing command adjkerntz pid 155 tid 100074 td 0xe0000000127b6480 Tracing command sh pid 24 tid 100065 td 0xe000000012401200 Tracing command softdepflush pid 23 tid 100064 td 0xe000000012401680 Tracing command vnlru pid 22 tid 100063 td 0xe000000012401b00 Tracing command syncer pid 21 tid 100062 td 0xe000000012690000 Tracing command bufdaemon pid 20 tid 100061 td 0xe000000012690480 Tracing command pagezero pid 19 tid 100060 td 0xe000000011a27b00 Tracing command vmdaemon pid 18 tid 100059 td 0xe000000012400000 Tracing command pagedaemon pid 17 tid 100058 td 0xe000000012400480 Tracing command xpt_thrd pid 9 tid 100057 td 0xe000000012400900 --More-- Tracing command sctp_iterator pid 6 tid 100054 td 0xe000000011a26900 Tracing command zfskern pid 5 tid 100052 td 0xe000000011a27200 Tracing command zfskern pid 5 tid 100051 td 0xe000000011a27680 Tracing command isp0: fc_thrd0 pid 4 tid 100047 td 0xe000000011931b00 Tracing command mpt_recovery1 pid 3 tid 100043 td 0xe000000011930000 Tracing command mpt_recovery0 pid 2 tid 100041 td 0xe000000011930900 Tracing command usb pid 16 tid 100039 td 0xe000000011924480 Tracing command usb pid 16 tid 100038 td 0xe000000011924900 Tracing command usb pid 16 tid 100037 td 0xe000000011924d80 Tracing command usb pid 16 tid 100036 td 0xe000000011925200 --More-- Tracing command usb pid 16 tid 100034 td 0xe000000011300d80 Tracing command usb pid 16 tid 100033 td 0xe000000011301200 Tracing command usb pid 16 tid 100032 td 0xe000000011301680 Tracing command usb pid 16 tid 100031 td 0xe000000011301b00 Tracing command usb pid 16 tid 100029 td 0xe000000011219680 Tracing command usb pid 16 tid 100028 td 0xe000000011219b00 Tracing command usb pid 16 tid 100027 td 0xe000000011300000 Tracing command usb pid 16 tid 100026 td 0xe000000011300480 Tracing command acpi_thermal pid 15 tid 100024 td 0xe000000011218000 Tracing command rand_harvestq pid 14 tid 100013 td 0xe000000011197680 --More-- Tracing command geom pid 13 tid 100012 td 0xe000000011197b00 Tracing command geom pid 13 tid 100011 td 0xe0000000111a6000 Tracing command geom pid 13 tid 100010 td 0xe000000011179680 Tracing command intr pid 12 tid 100048 td 0xe000000011931680 Tracing command intr pid 12 tid 100046 td 0xe000000011a26000 Tracing command intr pid 12 tid 100042 td 0xe000000011930480 Tracing command intr pid 12 tid 100040 td 0xe000000011924000 Tracing command intr pid 12 tid 100035 td 0xe000000011300900 Tracing command intr pid 12 tid 100030 td 0xe000000011219200 Tracing command intr pid 12 tid 100025 td 0xe0000000111a7b00 --More-- Tracing command intr pid 12 tid 100022 td 0xe000000011218900 Tracing command intr pid 12 tid 100021 td 0xe000000011218d80 Tracing command intr pid 12 tid 100019 td 0xe0000000111a6900 Tracing command intr pid 12 tid 100015 td 0xe000000011196d80 Tracing command intr pid 12 tid 100008 td 0xe000000011196000 Tracing command intr pid 12 tid 100007 td 0xe000000011196480 Tracing command intr pid 12 tid 100006 td 0xe000000011196900 Tracing command intr pid 12 tid 100005 td 0xe000000011178000 Tracing command idle pid 11 tid 100004 td 0xe000000011178480 Tracing command idle pid 11 tid 100003 td 0xe000000011178900 --More-- Tracing command init pid 1 tid 100002 td 0xe000000011178d80 Tracing command audit pid 10 tid 100001 td 0xe000000011179200 Tracing command kernel pid 0 tid 100053 td 0xe000000011a26d80 Tracing command kernel pid 0 tid 100050 td 0xe000000011930d80 Tracing command kernel pid 0 tid 100049 td 0xe000000011931200 Tracing command kernel pid 0 tid 100045 td 0xe000000011925680 Tracing command kernel pid 0 tid 100044 td 0xe000000011925b00 Tracing command kernel pid 0 tid 100023 td 0xe000000011218480 Tracing command kernel pid 0 tid 100020 td 0xe0000000111a6480 Tracing command kernel pid 0 tid 100018 td 0xe0000000111a6d80 --More-- Tracing command kernel pid 0 tid 100017 td 0xe0000000111a7200 Tracing command kernel pid 0 tid 100016 td 0xe0000000111a7680 Tracing command kernel pid 0 tid 100014 td 0xe000000011197200 Tracing command kernel pid 0 tid 100009 td 0xe000000011179b00 Tracing command kernel pid 0 tid 100000 td 0x9ffc000000eee1d0 db> I'll go check textdump setup again... Many thanks Anton From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 08:58:57 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5939226; Tue, 15 Oct 2013 08:58:57 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from vps.van-laarhoven.org (www.hibma.org [IPv6:2a02:2308::216:3eff:feec:b1b5]) by mx1.freebsd.org (Postfix) with ESMTP id 845532E27; Tue, 15 Oct 2013 08:58:57 +0000 (UTC) Received: from [IPv6:2001:980:530a:1:ad2b:26d6:5b53:cd53] (unknown [IPv6:2001:980:530a:1:ad2b:26d6:5b53:cd53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by vps.van-laarhoven.org (Postfix) with ESMTPSA id D20C95F2647; Tue, 15 Oct 2013 10:54:56 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: RFC: support for "first boot" rc.d scripts From: Nick Hibma In-Reply-To: <525C41D1.3040204@freebsd.org> Date: Tue, 15 Oct 2013 10:58:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C7D69EB-204B-45B9-AD67-EBC1AB39AB8B@van-laarhoven.org> References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> <525C210A.2000306@freebsd.org> <1381770007.42859.82.camel@revolution.hippie.lan> <525C41D1.3040204@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.1510) Cc: FreeBSD current , freebsd-rc@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 08:58:57 -0000 >>> Yes, it's hard to store state on diskless systems... but I figured >>> that anyone building a diskless system would know to not create a >>> "run firstboot scripts" marker. And not all embedded systems are >>> diskless... >>=20 >> The embedded systems we create at $work have readonly root and mfs = /var, >> but we do have writable storage on another filesystem. It would work >> for us (not that we need this feature right now) if there were an = rcvar >> that pointed to the marker file. Of course to make it work, = something >> would have to get the alternate filesystem mounted early enough to be >> useful (that is something we do already with a custom rc script). >=20 > Indeed... the way my patch currently does things, it looks for the > firstboot sentinel at the start of /etc/rc, which means it *has* to > be on /. Making the path an rcvar is a good idea (updated patch > attached) but we still need some way to re-probe for that file after > mounting extra filesystems. In many cases a simple=20 test -f /firstboot && bla_enable=3D'YES' || bla_enable=3D'NO' rm -f /firstboot in your specific rc.d script would suffice. Or for installing packages: for pkg in $PKGS; do if ! pkg_info $pkg-'[0-9]*' >/dev/null 2>&1; then pkg_add /some/dir/$pkg.txz fi done I am not quite sure why we need /firstboot handling in /etc/rc. Perhaps it is a better idea to make this more generic, to move the rc.d = script containing a 'runonce' keyword to a subdirectory as the last step = in rc (or make that an rc.d script in itself!). That way you could = consider moving it back if you need to re-run it. Or have an rc.d script = setup something like a database after installing a package by creating a = rc.d runonce script. Default dir could be ./run-once relative to the rc.d dir it is in, = configurable through runonce_directory . Note: The move would need to be done at the very end of rc.d to prevent = rcorder returning a different ordering and skipping scripts because of = that. Nick= From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 10:26:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 17EC122C; Tue, 15 Oct 2013 10:26:03 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9AC8231B; Tue, 15 Oct 2013 10:26:02 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id q14so5160573vbe.13 for ; Tue, 15 Oct 2013 03:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s7DQ0MDelyv7nT0h1Ggu1i7oanK1teHvtlyCywi/RoQ=; b=CSPZoscpGX/+C0xTxUeAJBSJQRcuWxgldkv78q2IgYtUypOtFjFiij4cMY3yjxqnVy NcqLdoa6FovWXP3aP0TYTLmiKUH0xoLlYbHRCtJ9lHm0A3NiyJCF4b5gA9CT77VhwLJH KAPyc32oBgBmMLuLFakJoeToNIl6DKsodtOfKz/TH0P+i3E6taF5hwo5cs0R73/LrJrp fFp4S4ziJetvt495XIvxWI6TeRHbRe2HIRTWU+ufGM3j4d7+Hp76A+AXHwusLYR5RiiT 4Ebh2xKE/bl//L/Y6DkXgS/rYpFDIp58aFcK8bxLpobYOF6+5Ot6Foc2uPrA5d9/7JF6 VpzQ== MIME-Version: 1.0 X-Received: by 10.220.1.203 with SMTP id 11mr11251898vcg.15.1381832761735; Tue, 15 Oct 2013 03:26:01 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 15 Oct 2013 03:26:01 -0700 (PDT) In-Reply-To: <201310150843.r9F8ho1c043235@mech-cluster241.men.bris.ac.uk> References: <201310150843.r9F8ho1c043235@mech-cluster241.men.bris.ac.uk> Date: Tue, 15 Oct 2013 12:26:01 +0200 X-Google-Sender-Auth: J1uWHL85Gj2CzKF49DGZReO-iA8 Message-ID: Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock From: Davide Italiano To: mexas@bris.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 10:26:03 -0000 On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht wrote: > Anyway, savecore eventually deadlocks: > > panic: deadlkres: possible deadlock detected for 0xe0000000127b7b00, blocked for 901401 ticks > [trim] > > Tracing command savecore pid 805 tid 100079 td 0xe0000000127b7b00 > cpu_switch(0xe0000000127b7b00, 0xe000000011178900, 0xe000000012402fc0, 0x9ffc0000005e7e80) at cpu_switch+0xd0 > sched_switch(0xe0000000127b7b00, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 > mi_switch(0x103, 0x0, 0xe0000000127b7b00, 0x9ffc00000062d1f0) at mi_switch+0x3f0 > turnstile_wait(0xe000000012402fc0, 0xe000000012400480, 0x0, 0x9ffc000000dcb698) at turnstile_wait+0x960 > __mtx_lock_sleep(0x9ffc0000010f9998, 0xe0000000127b7b00, 0xe000000012402fc0, 0x9ffc000000dc0558, 0x742) at __mtx_lock_sleep+0x2f0 > __mtx_lock_flags(0x9ffc0000010f9980, 0x0, 0x9ffc000000dd4a90, 0x742) at __mtx_lock_flags+0x1e0 > vfs_vmio_release(0xa00000009ebe72f0, 0xe00000027ed2ab70, 0x3, 0xa00000009ebe736c, 0xa00000009ebe7498, 0xa00000009ebe72f8, 0x9ffc000000dd4a90, 0x9ffc0000010f9680) at vfs_vmio_release+0x290 > getnewbuf(0xe0000000127f4ec0, 0x0, 0x0, 0x8000, 0xa00000009ebe99a8, 0x0, 0x9ffc0000010f0798, 0xa00000009ebe72f0) at getnewbuf+0x7e0 > getblk(0xe0000000127f4ec0, 0x4cbaa, 0x8000, 0x0, 0x0, 0x0, 0x0, 0x0) at getblk+0xee0 > ffs_balloc_ufs2(0xe0000000127f4ec0, 0x4cbaa, 0xa0000000c60ba000, 0xe000000011165a00, 0x7f050000, 0xa00000009dd79160) at ffs_balloc_ufs2+0x2950 > ffs_write(0xa00000009dd79248, 0x3000, 0x265d50000) at ffs_write+0x5c0 > VOP_WRITE_APV(0x9ffc000000e94ac0, 0xa00000009dd79248, 0x0, 0x0) at VOP_WRITE_APV+0x330 > vn_write(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000129ae830, 0xe0000000127f4ec0) at vn_write+0x450 > vn_io_fault(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000127b7b00) at vn_io_fault+0x330 > dofilewrite(0xe0000000127b7b00, 0x7, 0xe0000000129ae820, 0xa00000009dd79360, 0xffffffffffffffff, 0x0) at dofilewrite+0x180 > kern_writev(0xe0000000127b7b00, 0x7, 0xa00000009dd79360) at kern_writev+0xa0 > sys_write(0xe0000000127b7b00, 0xa00000009dd794e8, 0x9ffc000000abac80, 0x48d) at sys_write+0x100 > syscall(0xe0000000129d04a0, 0x140857000, 0x8000, 0xe0000000127b7b00, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 > --More-- I'm not commenting on the first panic you got -- but on the deadlock reported by DEADLKRES. I think that's the vm_page lock. You can run kgdb /boot/${KERNEL}/kernel where ${KERNEL} is the incrimined one then l *vfs_vmio_release+0x290 to get the exact point where it fails. I'm unsure here because 'show alllocks' and 'show locks' outputs are empty -- are you building your kernel with WITNESS etc..? Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 11:53:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6BACB80C for ; Tue, 15 Oct 2013 11:53:44 +0000 (UTC) (envelope-from supportme@ukr.net) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 269AE2A08 for ; Tue, 15 Oct 2013 11:53:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=TyclM4L4jeSewdtEfQekCZ5CCWyhR820wpaGaK0fWLg=; b=ajNEhFzpvCAyIBM14TCF8UAekePbZOSth77illNTYnbeE9fUX74I3tFSGGLWnbd7+8py/oR16bXB1oD/Qk1cTiOtkEtc8n/IKygRzQWdzxkUnApIawmJh4RI5Z5FU6Nsu3c2rAsIJoUF7oPimruhZ07AJHysowr1MG15K07p4LI=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv196.fwdcdn.com with smtp ID 1VW3Bt-000K5X-ER for freebsd-current@freebsd.org; Tue, 15 Oct 2013 14:53:33 +0300 Date: Tue, 15 Oct 2013 14:53:31 +0300 From: Dmitriy Makarov Subject: Re: vmstat -z: zfs related failures on r255173 To: freebsd-current@freebsd.org X-Mailer: freemail.ukr.net 5.0 Message-Id: <1381837350.494453682.d94z37mg@frv45.ukr.net> In-Reply-To: <1381521443.74219922.8eyuscyw@frv45.ukr.net> References: <1381521443.74219922.8eyuscyw@frv45.ukr.net> MIME-Version: 1.0 Received: from supportme@ukr.net by frv45.ukr.net; Tue, 15 Oct 2013 14:53:32 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 11:53:44 -0000 Please, any idea, thougth, help! Maybe what information can be useful for diggin - anything... System what I'm talkin about has a huge problem: performance degradation in short time period (day-two). Don't know can we somehow relate this vmstat fails with degradation. > Hi all > > On CURRENT r255173 we have some interesting values from vmstat -z : REQ = FAIL > > [server]# vmstat -z > ITEM                   SIZE  LIMIT     USED     FREE      REQ FAIL SLEEP > ....... skipped.... > NCLNODE:                528,      0,       0,       0,       0,   0,   0 > space_seg_cache:         64,      0,  289198,  299554,25932081,25932081,   0 > zio_cache:              944,      0,   37512,   50124,1638254119,1638254119,   0 > zio_link_cache:          48,      0,   50955,   38104,1306418638,1306418638,   0 > sa_cache:                80,      0,   63694,      56,  198643,198643,   0 > dnode_t:                864,      0,  128813,       3,  184863,184863,   0 > dmu_buf_impl_t:         224,      0, 1610024,  314631,157119686,157119686,   0 > arc_buf_hdr_t:          216,      0,82949975,   56107,156352659,156352659,   0 > arc_buf_t:               72,      0, 1586866,  314374,158076670,158076670,   0 > zil_lwb_cache:          192,      0,    6354,    7526, 2486242,2486242,   0 > zfs_znode_cache:        368,      0,   63694,      16,  198643,198643,   0 > ..... skipped ...... > > Can anybody explain this strange failures in zfs related parameters in vmstat, can we do something with this and is this really bad signal? > > Thanks! From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 12:19:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 932D1A9E for ; Tue, 15 Oct 2013 12:19:24 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com [207.126.144.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF06C2CE6 for ; Tue, 15 Oct 2013 12:19:23 +0000 (UTC) Received: from mail-wi0-f181.google.com ([209.85.212.181]) (using TLSv1) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKUl0ytgsBH4yu31YxwPlUK1U2LGqZ4tWI@postini.com; Tue, 15 Oct 2013 12:19:23 UTC Received: by mail-wi0-f181.google.com with SMTP id l12so4900827wiv.2 for ; Tue, 15 Oct 2013 05:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=RfOk2gtNSoGNWHOJ16mbrs3U17bKsA1qKO3HI+8RIRE=; b=nM/pHj2s8RCcCERfq/AsmEyGr9T1Sx01l+dJ1pHTUdv5GXeBzlGyZiJ148zAdgjapa ql8PR5Uh4pMq2zH+1/pvrazZ1l5qWiJmmnV7sd9g9M2cAHWQU244yxbVgsseZ6szsa18 MYE1PXE9AhpUczp6Ir63FhWk/0JCncLtP5ZA9BPCUTqMb2c8r4GzoeTiyef1lE+Tmczj 7kw5Fsn4MtTqmBCszPixST7DZs6Ts1njRkJYa57tWeSIY/2/azStxYsDWA0QlTvOy6cW gqTMyrdR76UiEEacsE8GxZ4RsdRGF0Uzi7l7gFLHrGx07yVlYWiZsbXAWrXJg0WrPnW1 k/TA== X-Gm-Message-State: ALoCoQmj/UFpeNL4H4INBUjWaVTgm8DrcjHHfZ78Ud3ItXy+qP9865nW1iWkGEXFpMcY+0c5be5/tUXV5MzERgpls2jG8X2Kz8py5F9w4KaZ4eunzC5CLm0EGkXEe1/zvvxAsqV05KUlcL0O+EPzfTaBYW8s1lk6nq0LvL6z1zdJmHPBbdFAOIo= X-Received: by 10.194.20.202 with SMTP id p10mr7276494wje.39.1381839541894; Tue, 15 Oct 2013 05:19:01 -0700 (PDT) X-Received: by 10.194.20.202 with SMTP id p10mr7276485wje.39.1381839541766; Tue, 15 Oct 2013 05:19:01 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id i8sm5676961wiy.6.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 05:19:00 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9FCIwYh043809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Oct 2013 13:18:58 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9FCIwBx043808; Tue, 15 Oct 2013 13:18:58 +0100 (BST) (envelope-from mexas) Date: Tue, 15 Oct 2013 13:18:58 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310151218.r9FCIwBx043808@mech-cluster241.men.bris.ac.uk> To: davide@freebsd.org, mexas@bris.ac.uk Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock In-Reply-To: Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:19:24 -0000 >From davide.italiano@gmail.com Tue Oct 15 11:30:07 2013 > >On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht wrote: > >> Anyway, savecore eventually deadlocks: >> >> panic: deadlkres: possible deadlock detected for 0xe0000000127b7b00, blocked for 901401 ticks >> > >[trim] > >> >> Tracing command savecore pid 805 tid 100079 td 0xe0000000127b7b00 >> cpu_switch(0xe0000000127b7b00, 0xe000000011178900, 0xe000000012402fc0, 0x9ffc0000005e7e80) at cpu_switch+0xd0 >> sched_switch(0xe0000000127b7b00, 0xe000000011178900, 0x9ffc000000f15698, 0x9ffc000000f15680) at sched_switch+0x890 >> mi_switch(0x103, 0x0, 0xe0000000127b7b00, 0x9ffc00000062d1f0) at mi_switch+0x3f0 >> turnstile_wait(0xe000000012402fc0, 0xe000000012400480, 0x0, 0x9ffc000000dcb698) at turnstile_wait+0x960 >> __mtx_lock_sleep(0x9ffc0000010f9998, 0xe0000000127b7b00, 0xe000000012402fc0, 0x9ffc000000dc0558, 0x742) at __mtx_lock_sleep+0x2f0 >> __mtx_lock_flags(0x9ffc0000010f9980, 0x0, 0x9ffc000000dd4a90, 0x742) at __mtx_lock_flags+0x1e0 >> vfs_vmio_release(0xa00000009ebe72f0, 0xe00000027ed2ab70, 0x3, 0xa00000009ebe736c, 0xa00000009ebe7498, 0xa00000009ebe72f8, 0x9ffc000000dd4a90, 0x9ffc0000010f9680) at vfs_vmio_release+0x290 >> getnewbuf(0xe0000000127f4ec0, 0x0, 0x0, 0x8000, 0xa00000009ebe99a8, 0x0, 0x9ffc0000010f0798, 0xa00000009ebe72f0) at getnewbuf+0x7e0 >> getblk(0xe0000000127f4ec0, 0x4cbaa, 0x8000, 0x0, 0x0, 0x0, 0x0, 0x0) at getblk+0xee0 >> ffs_balloc_ufs2(0xe0000000127f4ec0, 0x4cbaa, 0xa0000000c60ba000, 0xe000000011165a00, 0x7f050000, 0xa00000009dd79160) at ffs_balloc_ufs2+0x2950 >> ffs_write(0xa00000009dd79248, 0x3000, 0x265d50000) at ffs_write+0x5c0 >> VOP_WRITE_APV(0x9ffc000000e94ac0, 0xa00000009dd79248, 0x0, 0x0) at VOP_WRITE_APV+0x330 >> vn_write(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000129ae830, 0xe0000000127f4ec0) at vn_write+0x450 >> vn_io_fault(0xe0000000129ae820, 0xa00000009dd79360, 0xe000000011165a00, 0x0, 0xe0000000127b7b00) at vn_io_fault+0x330 >> dofilewrite(0xe0000000127b7b00, 0x7, 0xe0000000129ae820, 0xa00000009dd79360, 0xffffffffffffffff, 0x0) at dofilewrite+0x180 >> kern_writev(0xe0000000127b7b00, 0x7, 0xa00000009dd79360) at kern_writev+0xa0 >> sys_write(0xe0000000127b7b00, 0xa00000009dd794e8, 0x9ffc000000abac80, 0x48d) at sys_write+0x100 >> syscall(0xe0000000129d04a0, 0x140857000, 0x8000, 0xe0000000127b7b00, 0x0, 0x0, 0x9ffc000000ab7280, 0x8) at syscall+0x5e0 >> --More-- > >I'm not commenting on the first panic you got -- but on the deadlock >reported by DEADLKRES. I think that's the vm_page lock. >You can run kgdb /boot/${KERNEL}/kernel where ${KERNEL} is the incrimined one >then l *vfs_vmio_release+0x290 >to get the exact point where it fails. Like this? # kgdb /boot/kernel/kernel 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 "ia64-marcel-freebsd"... (kgdb) l *vfs_vmio_release+0x290 0x9ffc0000006b8830 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1859). 1854 /* 1855 * In order to keep page LRU ordering consistent, put 1856 * everything on the inactive queue. 1857 */ 1858 vm_page_lock(m); 1859 vm_page_unwire(m, 0); 1860 1861 /* 1862 * Might as well free the page if we can and it has 1863 * no valid data. We also free the page if the (kgdb) >I'm unsure here because 'show alllocks' and 'show locks' outputs are >empty -- are you building your kernel with WITNESS etc..? I think so: # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use (turn off in stable branch): options DDB # Support DDB options GDB # Support remote GDB options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # textdump(4) options TEXTDUMP_PREFERRED options TEXTDUMP_VERBOSE # http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC Also, does this look right: $ sysctl -a | grep kdb debug.ddb.scripting.scripts: kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo debug.kassert.do_kdb: 0 debug.kdb.alt_break_to_debugger: 0 debug.kdb.break_to_debugger: 0 debug.kdb.trap_code: 0 debug.kdb.trap: 0 debug.kdb.panic: 0 debug.kdb.enter: 0 debug.kdb.current: ddb debug.kdb.available: ddb gdb debug.witness.kdb: 0 $ Thank you Anton From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 12:53:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 878C5BF4 for ; Tue, 15 Oct 2013 12:53:18 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4749A2005 for ; Tue, 15 Oct 2013 12:53:18 +0000 (UTC) Received: from [78.35.183.143] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1VW41Y-0004aI-20 for freebsd-current@freebsd.org; Tue, 15 Oct 2013 14:46:56 +0200 Date: Tue, 15 Oct 2013 14:46:58 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: claws-mail deadlocking in iconv Message-ID: <71d1dac3.0871b43c@fabiankeil.de> In-Reply-To: <73d40037.635a97ef@fabiankeil.de> References: <73d40037.635a97ef@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//xPmTHbtD9I4ueGz8iGWpOe"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 12:53:18 -0000 --Sig_//xPmTHbtD9I4ueGz8iGWpOe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > After the iconv import claws-mail started to deadlock in iconv every now > and then on my system, which prevented claws-mail from rendering windows > or reacting to input. [...]=20 > Did anyone else run into this or can comment on the patch or > the backtraces? Thanks for the feedback, everyone. This is now bin/182994: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D182994 Fabian --Sig_//xPmTHbtD9I4ueGz8iGWpOe Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlJdOUIACgkQBYqIVf93VJ3CQgCgwDwFZYkAnimT2p8VmzYupkBN nqoAoLRKcfXXYl2sugscV8LDy1I1s/Mn =XKgS -----END PGP SIGNATURE----- --Sig_//xPmTHbtD9I4ueGz8iGWpOe-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 13:37:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A3B8341 for ; Tue, 15 Oct 2013 13:37:10 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id EAEA92431 for ; Tue, 15 Oct 2013 13:37:09 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 87E453C317 for ; Tue, 15 Oct 2013 13:37:06 +0000 (UTC) Message-ID: <525D451F.3040005@allanjude.com> Date: Tue, 15 Oct 2013 09:37:35 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: vmstat -z: zfs related failures on r255173 References: <1381521443.74219922.8eyuscyw@frv45.ukr.net> <1381837350.494453682.d94z37mg@frv45.ukr.net> In-Reply-To: <1381837350.494453682.d94z37mg@frv45.ukr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 13:37:10 -0000 On 2013-10-15 07:53, Dmitriy Makarov wrote: > Please, any idea, thougth, help! > Maybe what information can be useful for diggin - anything... > > System what I'm talkin about has a huge problem: performance degradation in short time period (day-two). Don't know can we somehow relate this vmstat fails with degradation. > > > >> Hi all >> >> On CURRENT r255173 we have some interesting values from vmstat -z : REQ = FAIL >> >> [server]# vmstat -z >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >> ....... skipped.... >> NCLNODE: 528, 0, 0, 0, 0, 0, 0 >> space_seg_cache: 64, 0, 289198, 299554,25932081,25932081, 0 >> zio_cache: 944, 0, 37512, 50124,1638254119,1638254119, 0 >> zio_link_cache: 48, 0, 50955, 38104,1306418638,1306418638, 0 >> sa_cache: 80, 0, 63694, 56, 198643,198643, 0 >> dnode_t: 864, 0, 128813, 3, 184863,184863, 0 >> dmu_buf_impl_t: 224, 0, 1610024, 314631,157119686,157119686, 0 >> arc_buf_hdr_t: 216, 0,82949975, 56107,156352659,156352659, 0 >> arc_buf_t: 72, 0, 1586866, 314374,158076670,158076670, 0 >> zil_lwb_cache: 192, 0, 6354, 7526, 2486242,2486242, 0 >> zfs_znode_cache: 368, 0, 63694, 16, 198643,198643, 0 >> ..... skipped ...... >> >> Can anybody explain this strange failures in zfs related parameters in vmstat, can we do something with this and is this really bad signal? >> >> 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 am guessing those 'failures' are failures to allocate memory. I'd recommend you install sysutils/zfs-stats and send the list the output of 'zfs-stats -a' -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 13:52:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B1B02B3F for ; Tue, 15 Oct 2013 13:52:22 +0000 (UTC) (envelope-from supportme@ukr.net) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50C7025A6 for ; Tue, 15 Oct 2013 13:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=A5B7PT+CEvKVNzoUXWXdfuDdZOfy6LO/mflrqeQJJms=; b=rkBKPob3xUyOBObE4CcQy6QpRDA3exx5mbgcLO/4CzZdspEpjbOzgStR3CrltDd0jy1cfFSoTNle8k1HNL6R3HqWWwtUhnF83P2ceHi9YhOvYUn7KSNM5nyuoO77RgzXC+xjoTi/GewAvyCYajV2uyQBZo1k9EVf22Kngbvhw3Y=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by frv196.fwdcdn.com with smtp ID 1VW52m-0002nf-UP for freebsd-current@freebsd.org; Tue, 15 Oct 2013 16:52:16 +0300 Date: Tue, 15 Oct 2013 16:52:16 +0300 From: Dmitriy Makarov Subject: Re[3]: vmstat -z: zfs related failures on r255173 To: freebsd-current@freebsd.org X-Mailer: freemail.ukr.net 5.0 Message-Id: <1381844603.448086716.c7o4v52z@frv45.ukr.net> In-Reply-To: <1381837350.494453682.d94z37mg@frv45.ukr.net> References: <1381521443.74219922.8eyuscyw@frv45.ukr.net> <1381837350.494453682.d94z37mg@frv45.ukr.net> MIME-Version: 1.0 Received: from supportme@ukr.net by frv45.ukr.net; Tue, 15 Oct 2013 16:52:16 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 13:52:22 -0000 [:~]# zfs-stats -a ------------------------------------------------------------------------ ZFS Subsystem Report Tue Oct 15 16:48:43 2013 ------------------------------------------------------------------------ System Information: Kernel Version: 1000051 (osreldate) Hardware Platform: amd64 Processor Architecture: amd64 ZFS Storage pool Version: 5000 ZFS Filesystem Version: 5 FreeBSD 10.0-CURRENT #3 r255173: Fri Oct 11 17:15:50 EEST 2013 root 16:48 up 16:27, 1 user, load averages: 12,58 12,51 14,44 ------------------------------------------------------------------------ System Memory: 15.05% 18.76 GiB Active, 0.05% 61.38 MiB Inact 83.42% 103.98 GiB Wired, 0.55% 702.44 MiB Cache 0.92% 1.14 GiB Free, 0.01% 16.93 MiB Gap Real Installed: 128.00 GiB Real Available: 99.96% 127.95 GiB Real Managed: 97.41% 124.65 GiB Logical Total: 128.00 GiB Logical Used: 98.52% 126.11 GiB Logical Free: 1.48% 1.89 GiB Kernel Memory: 91.00 GiB Data: 99.99% 90.99 GiB Text: 0.01% 13.06 MiB Kernel Memory Map: 124.65 GiB Size: 69.88% 87.11 GiB Free: 30.12% 37.54 GiB ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 30.38m Recycle Misses: 25.16m Mutex Misses: 7.45m Evict Skips: 444.42m ARC Size: 100.00% 90.00 GiB Target Size: (Adaptive) 100.00% 90.00 GiB Min Size (Hard Limit): 44.44% 40.00 GiB Max Size (High Water): 2:1 90.00 GiB ARC Size Breakdown: Recently Used Cache Size: 92.69% 83.42 GiB Frequently Used Cache Size: 7.31% 6.58 GiB ARC Hash Breakdown: Elements Max: 14.59m Elements Current: 99.70% 14.54m Collisions: 71.31m Chain Max: 25 Chains: 2.08m ------------------------------------------------------------------------ ARC Efficiency: 1.11b Cache Hit Ratio: 93.89% 1.04b Cache Miss Ratio: 6.11% 67.70m Actual Hit Ratio: 91.73% 1.02b Data Demand Efficiency: 90.56% 294.97m Data Prefetch Efficiency: 9.64% 7.07m CACHE HITS BY CACHE LIST: Most Recently Used: 8.80% 91.66m Most Frequently Used: 88.89% 925.41m Most Recently Used Ghost: 0.50% 5.16m Most Frequently Used Ghost: 2.97% 30.95m CACHE HITS BY DATA TYPE: Demand Data: 25.66% 267.11m Prefetch Data: 0.07% 681.36k Demand Metadata: 72.04% 749.94m Prefetch Metadata: 2.24% 23.31m CACHE MISSES BY DATA TYPE: Demand Data: 41.15% 27.86m Prefetch Data: 9.43% 6.38m Demand Metadata: 48.71% 32.98m Prefetch Metadata: 0.71% 478.11k ------------------------------------------------------------------------ L2 ARC Summary: (HEALTHY) Passed Headroom: 1.38m Tried Lock Failures: 403.24m IO In Progress: 1.19k Low Memory Aborts: 6 Free on Write: 1.69m Writes While Full: 3.48k R/W Clashes: 608.58k Bad Checksums: 0 IO Errors: 0 SPA Mismatch: 321.48m L2 ARC Size: (Adaptive) 268.26 GiB Header Size: 0.85% 2.27 GiB L2 ARC Breakdown: 67.70m Hit Ratio: 54.97% 37.21m Miss Ratio: 45.03% 30.48m Feeds: 62.45k L2 ARC Buffer: Bytes Scanned: 531.83 TiB Buffer Iterations: 62.45k List Iterations: 3.96m NULL List Iterations: 334.83k L2 ARC Writes: Writes Sent: 100.00% 61.84k ------------------------------------------------------------------------ File-Level Prefetch: (HEALTHY) DMU Efficiency: 1.66b Hit Ratio: 52.82% 874.41m Miss Ratio: 47.18% 780.96m Colinear: 780.96m Hit Ratio: 0.00% 9.21k Miss Ratio: 100.00% 780.95m Stride: 871.48m Hit Ratio: 99.63% 868.25m Miss Ratio: 0.37% 3.22m DMU Misc: Reclaim: 780.95m Successes: 0.42% 3.27m Failures: 99.58% 777.68m Streams: 6.12m +Resets: 0.87% 53.59k -Resets: 99.13% 6.07m Bogus: 0 ------------------------------------------------------------------------ VDEV Cache Summary: 8.17m Hit Ratio: 25.98% 2.12m Miss Ratio: 73.37% 6.00m Delegations: 0.66% 53.76k ------------------------------------------------------------------------ ZFS Tunables (sysctl): kern.maxusers 8525 vm.kmem_size 133836881920 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 1319413950874 vfs.zfs.arc_max 96636764160 vfs.zfs.arc_min 42949672960 vfs.zfs.arc_meta_used 17673106536 vfs.zfs.arc_meta_limit 5368709120 vfs.zfs.l2arc_write_max 25000000 vfs.zfs.l2arc_write_boost 50000000 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_noprefetch 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_norw 1 vfs.zfs.anon_size 99774976 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_data_lsize 0 vfs.zfs.mru_size 87902746112 vfs.zfs.mru_metadata_lsize 1672704 vfs.zfs.mru_data_lsize 78890405888 vfs.zfs.mru_ghost_size 8778126848 vfs.zfs.mru_ghost_metadata_lsize 8681146368 vfs.zfs.mru_ghost_data_lsize 96980480 vfs.zfs.mfu_size 1736881152 vfs.zfs.mfu_metadata_lsize 10414592 vfs.zfs.mfu_data_lsize 2311168 vfs.zfs.mfu_ghost_size 87868106240 vfs.zfs.mfu_ghost_metadata_lsize 11637033472 vfs.zfs.mfu_ghost_data_lsize 76230990848 vfs.zfs.l2c_only_size 254670908416 vfs.zfs.dedup.prefetch 1 vfs.zfs.nopwrite_enabled 1 vfs.zfs.mdcomp_disable 0 vfs.zfs.no_write_throttle 0 vfs.zfs.write_limit_shift 3 vfs.zfs.write_limit_min 134217728 vfs.zfs.write_limit_max 17173743104 vfs.zfs.write_limit_inflated 412169834496 vfs.zfs.write_limit_override 8589934592 vfs.zfs.prefetch_disable 1 vfs.zfs.zfetch.max_streams 8 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.top_maxinflight 32 vfs.zfs.resilver_delay 2 vfs.zfs.scrub_delay 4 vfs.zfs.scan_idle 50 vfs.zfs.scan_min_time_ms 1000 vfs.zfs.free_min_time_ms 1000 vfs.zfs.resilver_min_time_ms 3000 vfs.zfs.no_scrub_io 0 vfs.zfs.no_scrub_prefetch 0 vfs.zfs.mg_alloc_failures 18 vfs.zfs.write_to_degraded 0 vfs.zfs.check_hostid 1 vfs.zfs.recover 0 vfs.zfs.deadman_synctime 1000 vfs.zfs.deadman_enabled 1 vfs.zfs.space_map_last_hope 0 vfs.zfs.txg.synctime_ms 1000 vfs.zfs.txg.timeout 5 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.cache.size 16777216 vfs.zfs.vdev.cache.bshift 14 vfs.zfs.vdev.trim_on_init 1 vfs.zfs.vdev.max_pending 200 vfs.zfs.vdev.min_pending 4 vfs.zfs.vdev.time_shift 29 vfs.zfs.vdev.ramp_rate 2 vfs.zfs.vdev.aggregation_limit 268435456 vfs.zfs.vdev.read_gap_limit 32768 vfs.zfs.vdev.write_gap_limit 4096 vfs.zfs.vdev.bio_flush_disable 0 vfs.zfs.vdev.bio_delete_disable 0 vfs.zfs.vdev.trim_max_bytes 2147483648 vfs.zfs.vdev.trim_max_pending 64 vfs.zfs.max_auto_ashift 13 vfs.zfs.zil_replay_disable 0 vfs.zfs.cache_flush_disable 0 vfs.zfs.zio.use_uma 0 vfs.zfs.zio.exclude_metadata 0 vfs.zfs.sync_pass_deferred_free 2 vfs.zfs.sync_pass_dont_compress 5 vfs.zfs.sync_pass_rewrite 2 vfs.zfs.snapshot_list_prefetch 0 vfs.zfs.super_owner 0 vfs.zfs.debug 0 vfs.zfs.version.ioctl 3 vfs.zfs.version.acl 1 vfs.zfs.version.spa 5000 vfs.zfs.version.zpl 5 vfs.zfs.trim.enabled 1 vfs.zfs.trim.txg_delay 32 vfs.zfs.trim.timeout 30 vfs.zfs.trim.max_interval 1 ------------------------------------------------------------------------ > On 2013-10-15 07:53, Dmitriy Makarov wrote: > > Please, any idea, thougth, help! > > Maybe what information can be useful for diggin - anything... > > > > System what I'm talkin about has a huge problem: performance degradation in short time period (day-two). Don't know can we somehow relate this vmstat fails with degradation. > > > > > > > >> Hi all > >> > >> On CURRENT r255173 we have some interesting values from vmstat -z : REQ = FAIL > >> > >> [server]# vmstat -z > >> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > >> ....... skipped.... > >> NCLNODE: 528, 0, 0, 0, 0, 0, 0 > >> space_seg_cache: 64, 0, 289198, 299554,25932081,25932081, 0 > >> zio_cache: 944, 0, 37512, 50124,1638254119,1638254119, 0 > >> zio_link_cache: 48, 0, 50955, 38104,1306418638,1306418638, 0 > >> sa_cache: 80, 0, 63694, 56, 198643,198643, 0 > >> dnode_t: 864, 0, 128813, 3, 184863,184863, 0 > >> dmu_buf_impl_t: 224, 0, 1610024, 314631,157119686,157119686, 0 > >> arc_buf_hdr_t: 216, 0,82949975, 56107,156352659,156352659, 0 > >> arc_buf_t: 72, 0, 1586866, 314374,158076670,158076670, 0 > >> zil_lwb_cache: 192, 0, 6354, 7526, 2486242,2486242, 0 > >> zfs_znode_cache: 368, 0, 63694, 16, 198643,198643, 0 > >> ..... skipped ...... > >> > >> Can anybody explain this strange failures in zfs related parameters in vmstat, can we do something with this and is this really bad signal? > >> > >> Thanks! > > > > _______________________________________________ > > freebsd-current at freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org" > I am guessing those 'failures' are failures to allocate memory. I'd > recommend you install sysutils/zfs-stats and send the list the output of > 'zfs-stats -a' > > -- > Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 14:17:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5956F3C6 for ; Tue, 15 Oct 2013 14:17:38 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog125.obsmtp.com (eu1sys200aog125.obsmtp.com [207.126.144.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B342F27C1 for ; Tue, 15 Oct 2013 14:17:37 +0000 (UTC) Received: from mail-wg0-f44.google.com ([74.125.82.44]) (using TLSv1) by eu1sys200aob125.postini.com ([207.126.147.11]) with SMTP ID DSNKUl1OetBOhMDAJ77z42xOJ3KMT01jV1qr@postini.com; Tue, 15 Oct 2013 14:17:37 UTC Received: by mail-wg0-f44.google.com with SMTP id n12so7651516wgh.23 for ; Tue, 15 Oct 2013 07:17:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to; bh=d3m6irkYhFk09xY5JV48Qrr6QJXacaQw5uKffXZ2JeY=; b=dkHLIYdZv/CcA8JHw0rzT07jAstaiww7jZlUmoNk/INExbScWUCF3fmsNO34F9K+pb u6vncDoHaS0YLWJ+cFIDcEDaETtbL5BUnq5DhxrBk4zSGfFsRm3whaXaaiwNau0/mWbq vtgjuujw/QDt5CYlrxwhwD88XAcCIp57A+2pR2uw2jBplDbsoaY4JuEVPCYrNccw9YLN s2onZpwb/B1zGOTtASYv+wUPwxoGbvaT+fvj0/Pv85kIhkDKKA3nz0gZNtg8C//WW0+w fFudIj74RbVI8qh3q5BNlCWMGARtw5xYKjGgggXLnyo0TTa9kyHkqWynCxeRhUl5hgFg snuQ== X-Gm-Message-State: ALoCoQmZk5RttXVpZacIIfOWIa29Oc8iWSIJEZzWda0tMLspHw1u+35z9CznjGW4w2FoDcbTVQQ0LBR/DPVw8EMkYqfS1mhZ0JVt/BB6E05ipW2tvjwdEZiY5W+/lFFo7ookUD+G/kZO0WzCU9oG3a1S6FLVLz3NW8ICVIruLZvzI70q42aPSaI= X-Received: by 10.180.99.99 with SMTP id ep3mr19820933wib.11.1381846649926; Tue, 15 Oct 2013 07:17:29 -0700 (PDT) X-Received: by 10.180.99.99 with SMTP id ep3mr19820926wib.11.1381846649866; Tue, 15 Oct 2013 07:17:29 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id dq11sm563876wid.3.2013.10.15.07.17.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2013 07:17:28 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9FEHRUv047122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Oct 2013 15:17:27 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9FEHRe8047121 for freebsd-current@freebsd.org; Tue, 15 Oct 2013 15:17:27 +0100 (BST) (envelope-from mexas) Date: Tue, 15 Oct 2013 15:17:27 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310151417.r9FEHRe8047121@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org Subject: WITNESS: unable to allocate a new witness object X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:17:38 -0000 I'm trying to set up textdump(4). On boot I see: WITNESS: unable to allocate a new witness object also Expensive timeout(9) function: 0x9ffc000000e222e0(0xa0000000009ed320) 0.002434387 s kickstart. Does the first indicate I haven't set up WITNESS correctly? What does the second tell me? Thanks Anton From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 15:10:10 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5E66D83 for ; Tue, 15 Oct 2013 15:10:10 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog105.obsmtp.com (eu1sys200aog105.obsmtp.com [207.126.144.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A45A2D22 for ; Tue, 15 Oct 2013 15:10:09 +0000 (UTC) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by eu1sys200aob105.postini.com ([207.126.147.11]) with SMTP ID DSNKUl1az8cewRQ22613PR2+G15O0LTygpBE@postini.com; Tue, 15 Oct 2013 15:10:09 UTC Received: by mail-wi0-f182.google.com with SMTP id ez12so2889935wid.9 for ; Tue, 15 Oct 2013 08:10:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to; bh=KIaFojNslQIooXIGB9biXraDvdn0yCcCK5EVeJtf3Zw=; b=PrBbF5hY7A8ML5DB6Jv43GLZio+o+sDKqk9avDg/EaaUAcYdYFVLHkSvwmDCHei1E2 FeHwBWbELa3sJG+xXnx/1BvcB/ayqoKMVbgNMV+gzYhuWIj93yR3D41oSDDag2Jcd5KZ LuTJ+/BsNZ/tc4qeEwrbw0FkV6srWXPHehqaWOSqtNitSF+qIi4+rrjd/dxB4DwKW4eC V/Tw7muZ/s8fSOVErZx+QDKCGxjVdSoav2TQG6krnokwoqKc9Cd1n4SQJamERjQsi5VU 2Y1DXOrDRFW6pW+3SNqWKnZaLJM25K8wnoIZMXEmcOhz7sSpqw7V3Nh8O45REYgevW9J Dd4g== X-Gm-Message-State: ALoCoQkxqsbLFsTFwqPg4Jrc05BvYs8QBhyFH2XinCWUw2fI4uZJ7uAAyTKBkQQKx7UIarArGiUsYwr2pAKpkoSKgtDljQ2BYLmaLOQQKCluo69a7BBIvVN7yg5e23mk1TG0YRo0cqVdzB4SG94U9dWrbUffy9i+5eONCq2IFCSXDMsCdyjayAc= X-Received: by 10.194.201.202 with SMTP id kc10mr35081729wjc.1.1381849807804; Tue, 15 Oct 2013 08:10:07 -0700 (PDT) X-Received: by 10.194.201.202 with SMTP id kc10mr35081710wjc.1.1381849807638; Tue, 15 Oct 2013 08:10:07 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id fr4sm48650wib.0.2013.10.15.08.10.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2013 08:10:06 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9FFA4MT047274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Oct 2013 16:10:04 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9FFA4fH047273; Tue, 15 Oct 2013 16:10:04 +0100 (BST) (envelope-from mexas) Date: Tue, 15 Oct 2013 16:10:04 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310151510.r9FFA4fH047273@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: ia64: panic: wrong page state m 0xe00000027fcc1900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:10:11 -0000 This panic is always reproducible by starting nginx, and directing the browser to poudriere logs/bulk/ia64-default/latest/. I tried to do manually: show proc show threads run lockinfo show pcpu bt ps alltrace since I cannot get savecore to run successfully. Thanks Anton db> show proc Process 1035 (nginx) at 0xe0000000128c1280: state: NORMAL uid: 80 gids: 80 parent: pid 1034 at 0xe00000001273e940 ABI: FreeBSD ELF64 arguments: nginx: worker process threads: 1 100097 Run CPU 0 nginx db> db> show threads 100097 (0xe000000012800000) (stack 0xa00000009df7e000) kdb_enter(0x9ffc000000dcfac8, 0x9ffc000000dcfac8, 0x9ffc000000592a90, 0x40c) at kdb_enter+0x92 100078 (0xe0000000124bc000) (stack 0xa00000009defe000) cpu_switch(0xe0000000124bc000, 0xe000000011182900, 0x9ffc000000f5c148, 0x9ffc0000005ec410) at cpu_switch+0xd0 100072 (0xe000000012500d80) (stack 0xa00000009dece000) cpu_switch(0xe000000012500d80, 0xe000000011182900, 0x9ffc000000f5d160, 0x9ffc0000005ec410) at cpu_switch+0xd0 100071 (0xe000000012501200) (stack 0xa00000009dec6000) cpu_switch(0xe000000012501200, 0xe000000011182900, 0x9ffc000000f5dfc0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100069 (0xe0000000123fed80) (stack 0xa00000009deb6000) cpu_switch(0xe0000000123fed80, 0xe000000011182480, 0x9ffc000000f5e510, 0x9ffc0000005ec410) at cpu_switch+0xd0 100081 (0xe0000000127a0000) (stack 0xa00000009df16000) cpu_switch(0xe0000000127a0000, 0xe000000011182480, 0x9ffc000000f5cdf0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100073 (0xe000000012500900) (stack 0xa00000009ded6000) cpu_switch(0xe000000012500900, 0xe000000011182900, 0x9ffc000000f5e1c8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100099 (0xe000000012890480) (stack 0xa00000009df8e000) cpu_switch(0xe000000012890480, 0xe000000011182900, 0x9ffc000000f5c620, 0x9ffc0000005ec410) at cpu_switch+0xd0 100098 (0xe0000000127a1b00) (stack 0xa00000009df86000) cpu_switch(0xe0000000127a1b00, 0xe000000011182900, 0x9ffc000000f5d0c0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100088 (0xe0000000124bcd80) (stack 0xa00000009df36000) cpu_switch(0xe0000000124bcd80, 0xe0000000127a1680, 0x9ffc000000f5de08, 0x9ffc0000005ec410) at cpu_switch+0xd0 100096 (0xe000000012800480) (stack 0xa00000009df76000) cpu_switch(0xe000000012800480, 0xe000000011182480, 0x9ffc000000f5e5b0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100089 (0xe0000000127a1680) (stack 0xa00000009df3e000) cpu_switch(0xe0000000127a1680, 0xe000000011182900, 0x9ffc000000f5d2f0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100075 (0xe000000012500000) (stack 0xa00000009dee6000) cpu_switch(0xe000000012500000, 0xe000000011182900, 0x9ffc000000f5cd78, 0x9ffc0000005ec410) at cpu_switch+0xd0 100076 (0xe0000000124bc900) (stack 0xa00000009deee000) cpu_switch(0xe0000000124bc900, 0xe000000011182480, 0x9ffc000000f5dde0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100079 (0xe000000012501b00) (stack 0xa00000009df06000) cpu_switch(0xe000000012501b00, 0xe0000000127a1200, 0x9ffc000000f5dc28, 0x9ffc0000005ec410) at cpu_switch+0xd0 100080 (0xe000000012501680) (stack 0xa00000009df0e000) cpu_switch(0xe000000012501680, 0xe000000011182480, 0x9ffc000000f5e290, 0x9ffc0000005ec410) at cpu_switch+0xd0 100067 (0xe0000000123ff680) (stack 0xa00000009dea6000) cpu_switch(0xe0000000123ff680, 0xe000000011182900, 0x9ffc000000f5ceb8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100077 (0xe0000000124bc480) (stack 0xa00000009def6000) cpu_switch(0xe0000000124bc480, 0xe000000011182480, 0x9ffc000000f5cee0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100068 (0xe0000000123ff200) (stack 0xa00000009deae000) cpu_switch(0xe0000000123ff200, 0xe000000011182900, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 100056 (0xe000000012168d80) (stack 0xa00000009de4e000) cpu_switch(0xe000000012168d80, 0xe000000011182480, 0x9ffc000000f5e308, 0x9ffc0000005ec410) at cpu_switch+0xd0 100055 (0xe00000001178c480) (stack 0xa00000009de46000) cpu_switch(0xe00000001178c480, 0xe000000011182480, 0x9ffc000000f5e358, 0x9ffc0000005ec410) at cpu_switch+0xd0 100074 (0xe000000012500480) (stack 0xa00000009dede000) cpu_switch(0xe000000012500480, 0xe000000011182900, 0x9ffc000000f5d548, 0x9ffc0000005ec410) at cpu_switch+0xd0 100064 (0xe000000012169680) (stack 0xa00000009de8e000) cpu_switch(0xe000000012169680, 0xe00000001178d680, 0x9ffc000000f5c5a8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100063 (0xe000000012169b00) (stack 0xa00000009de86000) cpu_switch(0xe000000012169b00, 0xe000000012169680, 0x9ffc000000f5c9b8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100062 (0xe0000000123fe000) (stack 0xa00000009de7e000) cpu_switch(0xe0000000123fe000, 0xe000000011182480, 0x9ffc000000f5d6b0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100061 (0xe0000000123fe480) (stack 0xa00000009de76000) cpu_switch(0xe0000000123fe480, 0xe0000000111a1680, 0x9ffc000000f5e560, 0x9ffc0000005ec410) at cpu_switch+0xd0 100060 (0xe00000001178db00) (stack 0xa00000009de6e000) cpu_switch(0xe00000001178db00, 0xe000000011182480, 0x9ffc000000f5e4c0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100059 (0xe000000012168000) (stack 0xa00000009de66000) cpu_switch(0xe000000012168000, 0xe0000000123fe480, 0x9ffc000000f5c300, 0x9ffc0000005ec410) at cpu_switch+0xd0 100058 (0xe000000012168480) (stack 0xa00000009de5e000) cpu_switch(0xe000000012168480, 0xe0000000123fe480, 0x9ffc000000f5cf80, 0x9ffc0000005ec410) at cpu_switch+0xd0 100057 (0xe000000012168900) (stack 0xa00000009de56000) cpu_switch(0xe000000012168900, 0xe000000011182480, 0x9ffc000000f5d818, 0x9ffc0000005ec410) at cpu_switch+0xd0 100054 (0xe00000001178c900) (stack 0xa00000009de3e000) cpu_switch(0xe00000001178c900, 0xe000000011182480, 0x9ffc000000f5d2c8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100052 (0xe00000001178d200) (stack 0xa00000009de2c000) cpu_switch(0xe00000001178d200, 0xe000000011182900, 0x9ffc000000f5ded0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100051 (0xe00000001178d680) (stack 0xa00000009de24000) cpu_switch(0xe00000001178d680, 0xe0000000123fe000, 0x9ffc000000f5c620, 0x9ffc0000005ec410) at cpu_switch+0xd0 100047 (0xe00000001174db00) (stack 0xa00000009de04000) cpu_switch(0xe00000001174db00, 0xe000000011425b00, 0x9ffc000000f5d520, 0x9ffc0000005ec410) at cpu_switch+0xd0 100043 (0xe00000001174c000) (stack 0xa00000009ddc6000) cpu_switch(0xe00000001174c000, 0xe00000001174db00, 0x9ffc000000f5d020, 0x9ffc0000005ec410) at cpu_switch+0xd0 100041 (0xe00000001174c900) (stack 0xa00000009dd68000) cpu_switch(0xe00000001174c900, 0xe00000001174c000, 0x9ffc000000f5e420, 0x9ffc0000005ec410) at cpu_switch+0xd0 100039 (0xe000000011744480) (stack 0xa00000009dd0a000) cpu_switch(0xe000000011744480, 0xe00000001174c900, 0x9ffc000000f5dd90, 0x9ffc0000005ec410) at cpu_switch+0xd0 100038 (0xe000000011744900) (stack 0xa00000009dd02000) cpu_switch(0xe000000011744900, 0xe000000011182900, 0x9ffc000000f5d228, 0x9ffc0000005ec410) at cpu_switch+0xd0 100037 (0xe000000011744d80) (stack 0xa00000009dcfa000) cpu_switch(0xe000000011744d80, 0xe000000011744900, 0x9ffc000000f5dfe8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100036 (0xe000000011745200) (stack 0xa00000009dcf2000) cpu_switch(0xe000000011745200, 0xe000000011744d80, 0x9ffc000000f5dea8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100034 (0xe000000011480d80) (stack 0xa0000000e2fe6000) cpu_switch(0xe000000011480d80, 0xe000000011745200, 0x9ffc000000f5d340, 0x9ffc0000005ec410) at cpu_switch+0xd0 100033 (0xe000000011481200) (stack 0xa0000000e2fde000) cpu_switch(0xe000000011481200, 0xe000000011182900, 0x9ffc000000f5c580, 0x9ffc0000005ec410) at cpu_switch+0xd0 100032 (0xe000000011481680) (stack 0xa0000000e2fd6000) cpu_switch(0xe000000011481680, 0xe000000011182480, 0x9ffc000000f5da98, 0x9ffc0000005ec410) at cpu_switch+0xd0 100031 (0xe000000011481b00) (stack 0xa0000000e2fce000) cpu_switch(0xe000000011481b00, 0xe000000011182480, 0x9ffc000000f5ccd8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100029 (0xe000000011425680) (stack 0xa0000000e2f36000) cpu_switch(0xe000000011425680, 0xe000000011182480, 0x9ffc000000f5dd40, 0x9ffc0000005ec410) at cpu_switch+0xd0 100028 (0xe000000011425b00) (stack 0xa0000000e2f2e000) cpu_switch(0xe000000011425b00, 0xe000000011182480, 0x9ffc000000f5e380, 0x9ffc0000005ec410) at cpu_switch+0xd0 100027 (0xe000000011480000) (stack 0xa0000000e2f26000) cpu_switch(0xe000000011480000, 0xe000000011425b00, 0x9ffc000000f5d098, 0x9ffc0000005ec410) at cpu_switch+0xd0 100026 (0xe000000011480480) (stack 0xa0000000e2f1e000) cpu_switch(0xe000000011480480, 0xe000000011480000, 0x9ffc000000f5d6d8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100024 (0xe000000011424000) (stack 0xa0000000e2e8a000) cpu_switch(0xe000000011424000, 0xe000000011182480, 0x9ffc000000f5cf30, 0x9ffc0000005ec410) at cpu_switch+0xd0 100013 (0xe0000000111a1680) (stack 0xa0000000a07f6000) cpu_switch(0xe0000000111a1680, 0xe000000011182480, 0x9ffc000000f5c968, 0x9ffc0000005ec410) at cpu_switch+0xd0 100012 (0xe0000000111a1b00) (stack 0xa0000000a07ee000) cpu_switch(0xe0000000111a1b00, 0xe000000011182480, 0x9ffc000000f5d070, 0x9ffc0000005ec410) at cpu_switch+0xd0 100011 (0xe0000000111b0000) (stack 0xa0000000a07e6000) cpu_switch(0xe0000000111b0000, 0xe000000011182480, 0x9ffc000000f5d430, 0x9ffc0000005ec410) at cpu_switch+0xd0 100010 (0xe000000011183680) (stack 0xa0000000a07de000) cpu_switch(0xe000000011183680, 0xe000000011182900, 0x9ffc000000f5ccb0, 0x9ffc0000005ec410) at cpu_switch+0xd0 100048 (0xe00000001174d680) (stack 0xa00000009de0c000) cpu_switch(0xe00000001174d680, 0xe000000012500d80, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 100046 (0xe00000001178c000) (stack 0xa00000009ddde000) cpu_switch(0xe00000001178c000, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 100042 (0xe00000001174c480) (stack 0xa00000009dd70000) cpu_switch(0xe00000001174c480, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 100040 (0xe000000011744000) (stack 0xa00000009dd12000) cpu_switch(0xe000000011744000, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 100035 (0xe000000011480900) (stack 0xa00000009dcea000) fork_trampoline() at fork_trampoline 100030 (0xe000000011425200) (stack 0xa0000000e2fc6000) fork_trampoline() at fork_trampoline 100025 (0xe0000000111b1b00) (stack 0xa0000000e2f16000) fork_trampoline() at fork_trampoline 100022 (0xe000000011424900) (stack 0xa0000000e2e7a000) cpu_switch(0xe000000011424900, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 100021 (0xe000000011424d80) (stack 0xa0000000e2e72000) cpu_switch(0xe000000011424d80, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 100019 (0xe0000000111b0900) (stack 0xa0000000e2e62000) cpu_switch(0xe0000000111b0900, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 100018 (0xe0000000111b0d80) (stack 0xa0000000e2e5a000) cpu_switch(0xe0000000111b0d80, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 100008 (0xe0000000111a0000) (stack 0xa0000000a07ce000) fork_trampoline() at fork_trampoline 100007 (0xe0000000111a0480) (stack 0xa0000000a07c6000) cpu_switch(0xe0000000111a0480, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 100006 (0xe0000000111a0900) (stack 0xa0000000a07be000) fork_trampoline() at fork_trampoline 100005 (0xe000000011182000) (stack 0xa0000000a07b6000) cpu_switch(0xe000000011182000, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 100004 (0xe000000011182480) (stack 0xa0000000a07ae000) ia64_ih_stop(0x9ffc000000aa9070, 0x40b) at ia64_ih_stop+0x80 100003 (0xe000000011182900) (stack 0xa0000000a07a6000) cpu_switch(0xe000000011182900, 0xe000000012800000, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 100002 (0xe000000011182d80) (stack 0xa0000000a079e000) cpu_switch(0xe000000011182d80, 0xe000000011182480, 0x9ffc000000f5e628, 0x9ffc0000005ec410) at cpu_switch+0xd0 100001 (0xe000000011183200) (stack 0xa0000000a0796000) cpu_switch(0xe000000011183200, 0xe000000011183680, 0x9ffc000000f5cd78, 0x9ffc0000005ec410) at cpu_switch+0xd0 100053 (0xe00000001178cd80) (stack 0xa00000009de34000) cpu_switch(0xe00000001178cd80, 0xe0000000124bc480, 0x9ffc000000f5def8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100050 (0xe00000001174cd80) (stack 0xa00000009de1c000) cpu_switch(0xe00000001174cd80, 0xe00000001178cd80, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 100049 (0xe00000001174d200) (stack 0xa00000009de14000) cpu_switch(0xe00000001174d200, 0xe00000001174cd80, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 100045 (0xe000000011745680) (stack 0xa00000009ddd6000) cpu_switch(0xe000000011745680, 0xe000000011182480, 0x9ffc000000f5c6e8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100044 (0xe000000011745b00) (stack 0xa00000009ddce000) cpu_switch(0xe000000011745b00, 0xe000000011182900, 0x9ffc000000f5c710, 0x9ffc0000005ec410) at cpu_switch+0xd0 100023 (0xe000000011424480) (stack 0xa0000000e2e82000) cpu_switch(0xe000000011424480, 0xe000000011182900, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 100020 (0xe0000000111b0480) (stack 0xa0000000e2e6a000) cpu_switch(0xe0000000111b0480, 0xe000000011182480, 0x9ffc000000f5ce90, 0x9ffc0000005ec410) at cpu_switch+0xd0 100017 (0xe0000000111b1200) (stack 0xa0000000e2e52000) cpu_switch(0xe0000000111b1200, 0xe0000000111b0480, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 111b0480, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 100016 (0xe0000000111b1680) (stack 0xa0000000e2e4a000) cpu_switch(0xe0000000111b1680, 0xe0000000111b1200, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 100015 (0xe0000000111a0d80) (stack 0xa0000000e2e42000) cpu_switch(0xe0000000111a0d80, 0xe0000000111b1680, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 100014 (0xe0000000111a1200) (stack 0xa0000000e2e3a000) cpu_switch(0xe0000000111a1200, 0xe0000000111a0d80, 0x9ffc000000f5cf30, 0x9ffc0000005ec410) at cpu_switch+0xd0 100009 (0xe000000011183b00) (stack 0xa0000000a07d6000) cpu_switch(0xe000000011183b00, 0xe000000011182480, 0x9ffc000000f5cfa8, 0x9ffc0000005ec410) at cpu_switch+0xd0 100000 (0x9ffc000000efef70) (stack 0xe0000040fffc0000) cpu_switch(0x9ffc000000efef70, 0xe000000011182900, 0x9ffc000000f5c670, 0x9ffc0000005ec410) at cpu_switch+0xd0 db> db> show msgbuf msgbufp = 0xe0000040fffdffb8 magic = 63062, size = 98232, r= 10746, w = 11693, ptr = 0xe0000040fffc8000, cksum= 890849 panic: wrong page state m 0xe00000027fcc1900 cpuid = 0 KDB: stack backtrace: db_trace_self(0x9ffc000000158380) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc00000060b900) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc000000ee1b48, 0x9ffc000000592a40, 0x40c, 0x9ffc0000010b48a0) at kdb_backtrace+0xc0 vpanic(0x9ffc000000de0c20, 0xa00000009df85118, 0x9ffc000000f0a410, 0x9ffc000000ee18f0) at vpanic+0x260 kassert_panic(0x9ffc000000de0c20, 0xe00000027fcc1900, 0x81f, 0xe0000000127a7800, 0x9ffc0000006a4f10, 0x2c60, 0xe0000000127a7800, 0xe0000000127a7818) at kassert_panic+0x120 vn_sendfile(0x8df, 0x3, 0x0, 0x0, 0x0, 0x8df, 0x7fffffffffffe000, 0x0) at vn_sendfile+0x15d0 sys_sendfile(0xe000000012800000, 0xa00000009df854e8, 0x9, 0xa00000009df85360) at sys_sendfile+0x2b0 syscall(0xe0000000128c1280, 0x3, 0x0, 0xe000000012800000, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return KDB: enter: panic GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2013 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 10.0-CURRENT #7 r255488: Tue Oct 15 10:09:07 BST 2013 root@mech-as28.men.bris.ac.uk:/usr/obj/usr/src/sys/ZEEV ia64 gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Madison II (1600 MHz Itanium 2) Origin = "GenuineIntel" Revision = 2 Features = 0x1 real memory = 10737418240 (10240 MB) avail memory = 10484695040 (9998 MB) FPSWA Revision = 0x10012, Entry = 0xe0000040ffcc4050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: ACPI Id=0, SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: ACPI Id=1, SAPIC Id=1, SAPIC Eid=0 random: initialized Event timer "ITC" frequency 1600000000 Hz quality 1000 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 32/16 (20130823/tbfadt-603) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 32/16 (20130823/tbfadt-603) acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) cpu0: on acpi0 cpu1: on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pcib0: could not evaluate _ADR - AE_NOT_FOUND pci0: on pcib0 ohci0: mem 0x80002000-0x80002fff irq 16 at device 1.0 on pci0 usbus0 on ohci0 ohci1: mem 0x80001000-0x80001fff irq 17 at device 1.1 on pci0 usbus1 on ohci1 ehci0: mem 0x80000000-0x800000ff irq 18 at device 1.2 on pci0 usbus2: EHCI version 0.95 usbus2 on ehci0 pci0: at device 2.0 (no driver attached) pcib1: on acpi0 pcib1: could not evaluate _ADR - AE_NOT_FOUND pci32: on pcib1 mpt0: port 0x2100-0x21ff mem 0x903a0000-0x903bffff,0x90380000-0x9039ffff irq 27 at device 1.0 on pci32 mpt0: MPI Version=1.2.12.0 mpt1: port 0x2000-0x20ff mem 0x90360000-0x9037ffff,0x90340000-0x9035ffff irq 28 at device 1.1 on pci32 mpt1: MPI Version=1.2.12.0 em0: port 0x2240-0x227f mem 0x90320000-0x9033ffff,0x90280000-0x902fffff irq 29 at device 2.0 on pci32 em0: Ethernet address: 00:13:21:5b:05:1c em1: port 0x2200-0x223f mem 0x90300000-0x9031ffff irq 30 at device 2.1 on pci32 em1: Ethernet address: 00:13:21:5b:05:1d pcib2: on acpi0 pcib2: could not evaluate _ADR - AE_NOT_FOUND pci64: on pcib2 pcib3: on acpi0 pcib3: could not evaluate _ADR - AE_NOT_FOUND pci96: on pcib3 pcib4: on acpi0 pcib4: could not evaluate _ADR - AE_NOT_FOUND pci128: on pcib4 pcib5: on acpi0 pcib5: could not evaluate _ADR - AE_NOT_FOUND pci192: on pcib5 isp0: port 0xc000-0xc0ff mem 0xe0040000-0xe0040fff irq 71 at device 1.0 on pci192 pcib6: on acpi0 pcib6: could not evaluate _ADR - AE_NOT_FOUND pci224: on pcib6 uart0: mem 0xf8051000-0xf805100f irq 82 at device 1.0 on pci224 puc0: mem 0xf8050000-0xf8050fff,0xf8020000-0xf803ffff irq 82 at device 1.1 on pci224 uart1: at port 1 on puc0 uart1: console (9600,n,8,1) uart2: at port 3 on puc0 vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf7ffffff,0xf8040000-0xf804ffff at device 2.0 on pci224 uart3: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0 uart4: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart4: debug port (9600,n,8,1) ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 IP Filter: v5.1.2 initialized. Default = block all, Logging = enabled usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub0: on usbus2 ugen0.1: at usbus0 uhub1: on usbus0 ugen1.1: at usbus1 uhub2: on usbus1 uhub2: 2 ports with 2 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub0: 5 ports with 5 removable, self powered da0 at mpt0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit) da1: Command Queueing enabled da1: 17366MB (35566478 512 byte sectors: 255H 63S/T 2213C) da3 at isp0 bus 0 scbus2 target 0 lun 1 da3: Fixed Direct Access SCSI-4 device da3: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x10000 da3: Command Queueing enabled da3: 69460MB (142255575 512 byte sectors: 255H 63S/T 8855C) da4 at isp0 bus 0 scbus2 target 0 lun 2 da4: Fixed Direct Access SCSI-4 device da4: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x10000 da4: Command Queueing enabled da4: 69460MB (142255575 512 byte sectors: 255H 63S/T 8855C) da5 at isp0 bus 0 scbus2 target 0 lun 3 da5: Fixed Direct Access SCSI-4 device da5: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x10000 da5: Command Queueing enabled da5: 69460MB (142255575 512 byte sectors: 255H 63S/T 8855C) da6 at isp0 bus 0 scbus2 target 0 lun 5 da6: Fixed Direct Access SCSI-4 device da6: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x10000 da6: Command Queueing enabled da6: 140011MB (286744185 512 byte sectors: 255H 63S/T 17849C) da2 at mpt1 bus 0 scbus1 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit) da2: Command Queueing enabled da2: 17366MB (35566478 512 byte sectors: 255H 63S/T 2213C) pass3 at isp0 bus 0 scbus2 target 0 lun 0 pass3: Fixed Storage Array SCSI-4 device pass3: 200.000MB/s transfers WWNN 0x500805f3000ec220 WWPN 0x500805f3000ec221 PortID 0x10000 pass3: Command Queueing enabled WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0p2 [rw]... WARNING: / was not properly dismounted WITNESS: unable to allocate a new witness object <118>Setting hostuuid: ee652761-3dcc-11df-9074-0013215b051c. <118>Setting hostid: 0x8968724b. <118>Starting ddb. <118>Entropy harvesting: interrupts ethernet point_to_point Expensive timeout(9) function: 0x9ffc000000e222e0(0xa0000000009f1320) 0.002119543 s <118> kickstart. <118>Starting file system checks: <118>/dev/da0p2: 582356 files, 3927896 used, 30688528 free (183320 frags, 3813151 blocks, 0.5% fragmentation) <118>/dev/da3p1: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) <118>/dev/da3p1: SUMMARY INFORMATION BAD (SALVAGED) <118>/dev/da3p1: BLK(S) MISSING IN BIT MAPS (SALVAGED) <118>/dev/da3p1: 1968 files, 7223676 used, 9999685 free (245 frags, 1249930 blocks, 0.0% fragmentation) <118>/dev/da5p1: 436860 files, 1247548 used, 15975813 free (36405 frags, 1992426 blocks, 0.2% fragmentation) <118>/dev/da6p1: 5481 files, 1323234 used, 68104269 free (5773 frags, 8512312 blocks, 0.0% fragmentation) <118>Mounting local file systems:. <118>Writing entropy file:. <118>Setting hostname: mech-as28.men.bris.ac.uk. <118>Enabling ipfilter. <118>Starting Network: lo0 em0 em1. <118>lo0: flags=8049 metric 0 mtu 16384 <118> options=600003 <118> inet6 ::1 prefixlen 128 <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 <118> inet 127.0.0.1 netmask 0xff000000 <118> nd6 options=21 <118>em0: flags=8843 metric 0 mtu 1500 <118> options=209b <118> ether 00:13:21:5b:05:1c <118> inet 137.222.187.28 netmask 0xffffff00 broadcast 137.222.187.255 <118> inet6 fe80::213:21ff:fe5b:51c%em0 prefixlen 64 scopeid 0x1 <118> nd6 options=29 <118> media: Ethernet autoselect <118> status: no carrier <118>em1: flags=8843 metric 0 mtu 1500 <118> options=209b <118> ether 00:13:21:5b:05:1d <118> inet 10.10.10.14 netmask 0xffffff00 broadcast 10.10.10.255 <118> inet6 fe80::213:21ff:fe5b:51d%em1 prefixlen 64 scopeid 0x2 <118> nd6 options=29 <118> media: Ethernet autoselect (100baseTX ) <118> status: active <118>filter sync'd <118>Starting devd. <118>add net default: gateway 137.222.187.250 <118>add net fe80::: gateway ::1 <118>add net ff02::: gateway ::1 <118>add net ::ffff:0.0.0.0: gateway ::1 <118>add net ::0.0.0.0: gateway ::1 <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib <118>Starting ipmon. <118>Creating and/or trimming log files. <118>Starting syslogd. <118>No core dumps found. <118>Clearing /tmp (X related). <118>Recovering vi editor sessions:. <118>Updating motd:. <118>Mounting late file systems:. <118>Starting ntpd. <118>Starting bsdstats. <118>Posting monthly OS statistics to rpt.bsdstats.org <118>Performing sanity check on sshd configuration. <118>Starting sshd. <118>Starting cron. <118>Local package initialization:cd: /var/portbuild/: No such file or directory <118>. <118>Starting inetd. <118>Starting background file system checks in 60 seconds. <118> <118>Tue Oct 15 15:38:25 BST 2013 <118>Oct 15 15:39:44 mech-as28 su: mexas to root on /dev/pts/0 db> db> run lockinfo db:0:lockinfo> show locks db:0:locks> show alllocks db:0:alllocks> show lockedvnods Locked vnodes 0xe0000000129789c0: tag ufs, type VREG usecount 2, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) v_object 0xe0000000127a7800 ref 1 pages 1 lock type ufs: SHARED (count 1) ino 5220225, on dev da5p1 db> db> show pcpu cpuid = 0 dynamic pcpu = 0x40040040ff12c680 curthread = 0xe000000012800000: pid 1035 "nginx" curpcb = 0 fpcurthread = none idlethread = 0xe000000011182900: tid 100003 "idle: cpu0" MD: vhpt = 0xe0000040ff000000 MD: lid = 0 MD: clock = 0x64261bc9ce MD: clock_mode = 2 MD: clock_load = 0 MD: stats = 0x9ffc00000110feb0 MD: pmap = 0xe00000001118ef00 spin locks held: db> db> bt Tracing pid 1035 tid 100097 td 0xe000000012800000 kdb_enter(0x9ffc000000dcfac8, 0x9ffc000000dcfac8, 0x9ffc000000592a90, 0x40c) at kdb_enter+0x92 vpanic(0x9ffc000000de0c20, 0xa00000009df85118, 0x100, 0x9ffc000000ee18f0) at vpanic+0x2b0 kassert_panic(0x9ffc000000de0c20, 0xe00000027fcc1900, 0x81f, 0xe0000000127a7800, 0x9ffc0000006a4f10, 0x2c60, 0xe0000000127a7800, 0xe0000000127a7818) at kassert_panic+0x120 vn_sendfile(0x8df, 0x3, 0x0, 0x0, 0x0, 0x8df, 0x7fffffffffffe000, 0x0) at vn_sendfile+0x15d0 sys_sendfile(0xe000000012800000, 0xa00000009df854e8, 0x9, 0xa00000009df85360) at sys_sendfile+0x2b0 syscall(0xe0000000128c1280, 0x3, 0x0, 0xe000000012800000, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return db> db> ps pid ppid pgrp uid state wmesg wchan cmd 1035 1034 1034 80 R CPU 0 nginx 1034 1 1034 0 Ss pause 0xe00000001273e9e8 nginx 1032 1031 1032 0 S+ ttyin 0xe00000001253c0a8 sh 1031 1027 1031 1001 S+ wait 0xe0000000124064a0 su 1027 1026 1027 1001 Ss+ pause 0xe000000012406e88 tcsh 1026 1024 1024 1001 S select 0xe0000000124392c0 sshd 1024 926 1024 0 Ss select 0xe000000010c29140 sshd 999 1 999 0 Ss+ ttyin 0xe0000000114288a8 getty 998 1 1 0 S ttydcd 0xe000000011428ce8 getty 994 992 24 0 S+ nanslp 0x9ffc000000f0c178 sleep 993 1 24 0 S+ piperd 0xe000000012848268 logger 992 1 24 0 S+ wait 0xe00000001273f280 sh 976 1 976 0 Ss select 0xe000000010c28fc0 inetd 937 1 937 0 Ss nanslp 0x9ffc000000f0c179 cron 932 1 932 25 Ss pause 0xe00000001273e548 sendmail 929 1 929 0 Ss select 0xe000000012439640 sendmail 926 1 926 0 Ss select 0xe0000000124397c0 sshd 866 1 866 0 Ss select 0xe0000000124398c0 ntpd 786 1 786 0 Ss select 0xe000000010c293c0 syslogd 777 1 777 0 Ss select 0xe000000012439940 ipmon 655 1 655 0 Ss select 0xe000000012439b40 devd 140 1 140 0 Ss pause 0xe0000000125469e8 adjkerntz 23 0 0 0 DL sdflush 0x9ffc000000ee2d30 [softdepflush] 22 0 0 0 DL vlruwt 0xe000000012171720 [vnlru] 21 0 0 0 DL syncer 0x9ffc000001101a90 [syncer] 20 0 0 0 DL psleep 0x9ffc000000ee20c8 [bufdaemon] 19 0 0 0 DL pgzero 0x9ffc000000ee30d4 [pagezero] 18 0 0 0 DL psleep 0x9ffc000000ee303c [vmdaemon] 17 0 0 0 DL psleep 0x9ffc000000ee306c [pagedaemon] 9 0 0 0 DL ccb_scan 0x9ffc000000ee33a0 [xpt_thrd] 6 0 0 0 DL waiting_ 0x9ffc000001104130 [sctp_iterator] 5 0 0 0 DL (threaded) [zfskern] 100052 D l2arc_fe 0x9ffc000001557ec0 [l2arc_feed_thread] 100051 D arc_recl 0x9ffc0000015480a0 [arc_reclaim_thread] 4 0 0 0 DL ispf 0xe000000011768000 [isp0: fc_thrd0] 3 0 0 0 DL idle 0xa000000000a16000 [mpt_recovery1] 2 0 0 0 DL idle 0xa0000000009fe000 [mpt_recovery0] 16 0 0 0 DL (threaded) [usb] 100039 D - 0xa0000000009fae18 [usbus2] 100038 D - 0xa0000000009fadc0 [usbus2] 100037 D - 0xa0000000009fad68 [usbus2] 100036 D - 0xa0000000009fad10 [usbus2] 100034 D - 0xa0000000009f1460 [usbus1] 100033 D - 0xa0000000009f1408 [usbus1] 100032 D - 0xa0000000009f13b0 [usbus1] 100031 D - 0xa0000000009f1358 [usbus1] 100029 D - 0xa0000000009ed460 [usbus0] 100028 D - 0xa0000000009ed408 [usbus0] 100027 D - 0xa0000000009ed3b0 [usbus0] 100026 D - 0xa0000000009ed358 [usbus0] 15 0 0 0 DL tzpoll 0x9ffc000000ee0a50 [acpi_thermal] 14 0 0 0 DL - 0x9ffc000000ee0d38 [rand_harvestq] 13 0 0 0 DL (threaded) [geom] 100012 D - 0x9ffc000000ee1270 [g_down] 100011 D - 0x9ffc000000ee1268 [g_up] 100010 D - 0x9ffc000000ee1258 [g_event] 12 0 0 0 WL (threaded) [intr] 100048 I [swi0: uart uart+++] 100046 I [irq71: isp0] 100042 I [irq28: mpt1] 100040 I [irq27: mpt0] 100035 I [irq18: ehci0] 100030 I [irq17: ohci1] 100025 I [irq16: ohci0] 100022 I [swi6: task queue] 100021 I [swi6: Giant taskq] 100019 I [swi5: fast taskq] 100018 I [swi2: cambio] 100008 I [swi4: clock] 100007 I [swi4: clock] 100006 I [swi3: vm] 100005 I [swi1: netisr 0] 11 0 0 0 RL (threaded) [idle] 100004 Run CPU 1 [idle: cpu1] 100003 CanRun [idle: cpu0] 1 0 1 0 SLs wait 0xe000000011180de0 [init] 10 0 0 0 DL audit_wo 0x9ffc0000011087c8 [audit] 0 0 0 0 DLs (threaded) [kernel] 100053 D - 0x9ffc000000f0af10 [deadlkres] 100050 D - 0xe000000011795300 [system_taskq_1] 100049 D - 0xe000000011795300 [system_taskq_0] 100045 D - 0xe0000000111a2500 [em1 taskq] 100044 D - 0xe0000000111a2600 [em0 taskq] 100023 D - 0xe0000000111a5300 [ffs_trim taskq] 100020 D - 0xe0000000111a5600 [thread taskq] 100017 D - 0xe0000000111a5900 [acpi_task_2] 100016 D - 0xe0000000111a5900 [acpi_task_1] 100015 D - 0xe0000000111a5900 [acpi_task_0] 100014 D - 0xe0000000111a5a00 [kqueue taskq] 100009 D - 0xe0000000111a5d00 [firmware taskq] 100000 D swapin 0x9ffc000000efeac8 [swapper] db> db> alltrace Tracing command nginx pid 1035 tid 100097 td 0xe000000012800000 kdb_enter(0x9ffc000000dcfac8, 0x9ffc000000dcfac8, 0x9ffc000000592a90, 0x40c) at kdb_enter+0x92 vpanic(0x9ffc000000de0c20, 0xa00000009df85118, 0x100, 0x9ffc000000ee18f0) at vpanic+0x2b0 kassert_panic(0x9ffc000000de0c20, 0xe00000027fcc1900, 0x81f, 0xe0000000127a7800, 0x9ffc0000006a4f10, 0x2c60, 0xe0000000127a7800, 0xe0000000127a7818) at kassert_panic+0x120 vn_sendfile(0x8df, 0x3, 0x0, 0x0, 0x0, 0x8df, 0x7fffffffffffe000, 0x0) at vn_sendfile+0x15d0 sys_sendfile(0xe000000012800000, 0xa00000009df854e8, 0x9, 0xa00000009df85360) at sys_sendfile+0x2b0 syscall(0xe0000000128c1280, 0x3, 0x0, 0xe000000012800000, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command nginx pid 1034 tid 100078 td 0xe0000000124bc000 cpu_switch(0xe0000000124bc000, 0xe000000011182900, 0x9ffc000000f5c148, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000124bc000, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000124bc000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe00000001273e9e8, 0x74, 0xe0000000124bc378, 0xe0000000124bc000) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe00000001273e9e8, 0x74, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe00000001273e9e8, 0x74, 0x9ffc000000dcff18, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe00000001273e9e8, 0xe00000001273ea40, 0x74, 0x9ffc000000dcff18, 0x0, 0x0, 0x100) at _sleep+0x7b0 kern_sigsuspend(0xe0000000124bc000, 0x0, 0xe00000001273e9e8) at kern_sigsuspend+0x140 sys_sigsuspend(0xe0000000124bc000, 0xa00000009df054e8, 0x9ffc000000ac2c80, 0x48d) at sys_sigsuspend+0x60 syscall(0xe00000001273e940, 0x7fffffffffffead0, 0x0, 0xe0000000124bc000, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sh pid 1032 tid 100072 td 0xe000000012500d80 cpu_switch(0xe000000012500d80, 0xe000000011182900, 0x9ffc000000f5d160, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012500d80, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012500d80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe00000001253c0a8, 0x0, 0xe0000000125010f8, 0xe000000012500d80) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe00000001253c0a8, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe00000001253c0a8, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe00000001253c0a8, 0xe00000001253c008, 0xe000000012500d80, 0x0) at _cv_wait_sig+0x4d0 tty_wait(0xe00000001253c000, 0xe00000001253c0a8, 0x0, 0x9ffc000000dddc28, 0x9ffc0000006756c0) at tty_wait+0xb0 ttydisc_read(0xe00000001253c000, 0xa00000009ded5360, 0x0, 0x0) at ttydisc_read+0x4c0 ttydev_read(0xe00000001253c000, 0xa00000009ded5360, 0x0, 0x9ffc000000378070) at ttydev_read+0xe0 devfs_read_f(0xe0000000124aa000, 0xa00000009ded5360, 0xe000000012431400, 0x0, 0xe000000012500d80) at devfs_read_f+0xf0 dofileread(0xe000000012500d80, 0x0, 0xe0000000124aa000, 0xa00000009ded5360, 0x0, 0x0) at dofileread+0x150 kern_readv(0xe000000012500d80, 0x0, 0xa00000009ded5360) at kern_readv+0xa0 sys_read(0xe000000012500d80, 0xa00000009ded54e8, 0x9ffc000000ac2c80, 0x48d) at sys_read+0x100 syscall(0xe000000012547280, 0x7fffffffffffec60, 0x1, 0xe000000012500d80, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command su pid 1031 tid 100071 td 0xe000000012501200 cpu_switch(0xe000000012501200, 0xe000000011182900, 0x9ffc000000f5dfc0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012501200, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012501200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000124064a0, 0x6c, 0xe000000012501578, 0xe000000012501200) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000124064a0, 0x6c, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe0000000124064a0, 0x6c, 0x9ffc000000e06798, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe0000000124064a0, 0xe0000000124065a0, 0x6c, 0x9ffc000000e06798, 0x0, 0x0, 0x100, 0x0) at _sleep+0x7b0 kern_wait6(0xe000000012501200, 0x0, 0x408, 0xa00000009decd390, 0x32, 0x0, 0x0) at kern_wait6+0xba0 kern_wait(0xe000000012501200, 0x408, 0xa00000009decd390, 0x2, 0x0) at kern_wait+0xe0 sys_wait4(0xe000000012501200, 0xa00000009decd4e8, 0xa00000009decd390, 0x9ffc000000ac2c80) at sys_wait4+0x70 syscall(0xe0000000124064a0, 0x7fffffffffffe640, 0x2, 0xe000000012501200, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command tcsh pid 1027 tid 100069 td 0xe0000000123fed80 cpu_switch(0xe0000000123fed80, 0xe000000011182480, 0x9ffc000000f5e510, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000123fed80, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000123fed80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000012406e88, 0x74, 0xe0000000123ff0f8, 0xe0000000123fed80) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000012406e88, 0x74, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000012406e88, 0x74, 0x9ffc000000dcff18, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe000000012406e88, 0xe000000012406ee0, 0x74, 0x9ffc000000dcff18, 0x0, 0x0, 0x100) at _sleep+0x7b0 kern_sigsuspend(0xe0000000123fed80, 0x0, 0xe000000012406e88) at kern_sigsuspend+0x140 sys_sigsuspend(0xe0000000123fed80, 0xa00000009debd4e8, 0x9ffc000000ac2c80, 0x48d) at sys_sigsuspend+0x60 syscall(0xe000000012406de0, 0x0, 0x10004f5d0, 0xe0000000123fed80, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sshd pid 1026 tid 100081 td 0xe0000000127a0000 cpu_switch(0xe0000000127a0000, 0xe000000011182480, 0x9ffc000000f5cdf0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000127a0000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000127a0000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000124392c0, 0x0, 0xe0000000127a0378, 0xe0000000127a0000) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000124392c0, 0x0, 0x9ffc000000dd7480, 0xe0000000124392a0) at sleepq_catch_signals+0x190 sleepq_timedwait_sig(0xe0000000124392c0, 0x0, 0x9ffc0000004fa750, 0x9ffc0000004fa790, 0x713) at sleepq_timedwait_sig+0x30 _cv_timedwait_sig_sbt(0xe0000000124392c0, 0xe0000000124392a0, 0x1e0fa3e4187, 0x12c0000000, 0x200) at _cv_timedwait_sig_sbt+0x4f0 seltdwait(0xe000000012439280, 0x1e0fa3e4187, 0x12c0000000, 0xe0000000124392b8, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0xf0 kern_select(0xe0000000127a0000, 0x0, 0x141416230, 0x141416238, 0x0, 0x1e0fa3e4187, 0xa) at kern_select+0xb40 sys_select(0xe0000000127a0000, 0xa00000009df1d4e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe000000012547720, 0x141416230, 0x141416238, 0xe0000000127a0000, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sshd pid 1024 tid 100073 td 0xe000000012500900 cpu_switch(0xe000000012500900, 0xe000000011182900, 0x9ffc000000f5e1c8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012500900, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012500900, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000010c29140, 0x0, 0xe000000012500c78, 0xe000000012500900) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000010c29140, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000010c29140, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe000000010c29140, 0xe000000010c29120, 0xe000000012500900, 0x0, 0x9ffc000000f014b0) at _cv_wait_sig+0x4d0 seltdwait(0xe000000010c29100, 0xffffffffffffffff, 0x0, 0xe000000010c29138) at seltdwait+0x110 sys_poll(0xe000000012500900, 0xa00000009dedd4e8, 0xe000000012352170, 0xa00000009dedd290) at sys_poll+0x620 syscall(0xe000000012546de0, 0x1, 0xffffffffffffffff, 0xe000000012500900, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command getty pid 999 tid 100099 td 0xe000000012890480 cpu_switch(0xe000000012890480, 0xe000000011182900, 0x9ffc000000f5c620, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012890480, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012890480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000114288a8, 0x0, 0xe0000000128907f8, 0xe000000012890480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000114288a8, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe0000000114288a8, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe0000000114288a8, 0xe000000011428808, 0xe000000012890480, 0x0) at _cv_wait_sig+0x4d0 tty_wait(0xe000000011428800, 0xe0000000114288a8, 0x2, 0x9ffc000000dddc28, 0x9ffc0000006756c0) at tty_wait+0xb0 ttydisc_read(0xe000000011428800, 0xa00000009df95360, 0x0, 0x0) at ttydisc_read+0x4c0 ttydev_read(0xe000000011428800, 0xa00000009df95360, 0x0, 0x9ffc000000378070) at ttydev_read+0xe0 devfs_read_f(0xe000000012486690, 0xa00000009df95360, 0xe00000001116e700, 0x0, 0xe000000012890480) at devfs_read_f+0xf0 dofileread(0xe000000012890480, 0x0, 0xe000000012486690, 0xa00000009df95360, 0x0, 0x0) at dofileread+0x150 kern_readv(0xe000000012890480, 0x0, 0xa00000009df95360) at kern_readv+0xa0 sys_read(0xe000000012890480, 0xa00000009df954e8, 0x9ffc000000ac2c80, 0x48d) at sys_read+0x100 syscall(0xe0000000128c0940, 0x7fffffffffffed20, 0x1, 0xe000000012890480, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command getty pid 998 tid 100098 td 0xe0000000127a1b00 cpu_switch(0xe0000000127a1b00, 0xe000000011182900, 0x9ffc000000f5d0c0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000127a1b00, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000127a1b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000011428ce8, 0x0, 0xe0000000127a1e78, 0xe0000000127a1b00) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000011428ce8, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000011428ce8, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe000000011428ce8, 0xe000000011428c08, 0xe0000000127a1b00, 0x0) at _cv_wait_sig+0x4d0 tty_wait(0xe000000011428c00, 0xe000000011428ce8, 0x1, 0x9ffc000000dddc28, 0x9ffc00000066a8f0, 0x694, 0xe0000000128df500) at tty_wait+0xb0 ttydev_open(0xe000000011785600, 0x9ffc000000dddc60, 0x2000, 0x9ffc000000dddd48, 0xe000000011428c00) at ttydev_open+0x710 devfs_open(0xa00000009df8d158, 0x0, 0xa00000009df8d118) at devfs_open+0x2c0 VOP_OPEN_APV(0x9ffc000000e684f0, 0xa00000009df8d158, 0x0, 0x9ffc000000e18760) at VOP_OPEN_APV+0x270 vn_open_vnode(0xe000000012872c30, 0x3, 0xe00000001116e100, 0xe0000000127a1b00, 0xe000000012487900) at vn_open_vnode+0x2c0 vn_open_cred(0xa00000009df8d288, 0xa00000009df8d390, 0x980, 0x0, 0xe00000001116e100, 0xe000000012487900) at vn_open_cred+0x520 vn_open(0xa00000009df8d288, 0xa00000009df8d390, 0x980, 0xe000000012487900, 0x9ffc000000703760, 0x695, 0x0) at vn_open+0x50 kern_openat(0xe0000000127a1b00, 0xffffffffffffff9c, 0x10001ca90, 0x0, 0x0, 0x7980) at kern_openat+0x490 kern_open(0xe0000000127a1b00, 0x10001ca90, 0x0, 0x2, 0x7980) at kern_open+0x40 sys_open(0xe0000000127a1b00, 0xa00000009df8d4e8, 0x9ffc000000ac2c80, 0x48d) at sys_open+0x40 syscall(0xe0000000128c0de0, 0x2, 0x100007980, 0xe0000000127a1b00, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sleep pid 994 tid 100088 td 0xe0000000124bcd80 cpu_switch(0xe0000000124bcd80, 0xe0000000127a1680, 0x9ffc000000f5de08, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000124bcd80, 0xe0000000127a1680, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000124bcd80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000f0c178, 0x6c, 0xe0000000124bd0f8, 0xe0000000124bcd80) at sleepq_switch+0x2e0 sleepq_catch_signals(0x9ffc000000f0c178, 0x6c, 0x9ffc000000dd7480, 0xe0000000124bd110) at sleepq_catch_signals+0x190 sleepq_timedwait_sig(0x9ffc000000f0c178, 0x6c, 0x3c0000000, 0x9ffc0000005a4e40, 0x998) at sleepq_timedwait_sig+0x30 _sleep(0x9ffc000000f0c178, 0x0, 0x6c, 0x9ffc000000dd1750, 0x1, 0x3c0000000, 0x200) at _sleep+0x750 kern_nanosleep(0xe0000000124bcd80, 0x3c00000000, 0xa00000009df3d380) at kern_nanosleep+0x2a0 sys_nanosleep(0xe0000000124bcd80, 0xa00000009df3d4e8, 0x0, 0x9ffc000000ac2c80) at sys_nanosleep+0xb0 syscall(0xe00000001273f720, 0x7fffffffffffed60, 0x7fffffffffffed30, 0xe0000000124bcd80, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command logger pid 993 tid 100096 td 0xe000000012800480 cpu_switch(0xe000000012800480, 0xe000000011182480, 0x9ffc000000f5e5b0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012800480, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012800480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000012848268, 0x5c, 0xe0000000128007f8, 0xe000000012800480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000012848268, 0x5c, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000012848268, 0x5c, 0x9ffc000000ddaf48, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe000000012848268, 0xe0000000128484a8, 0x5c, 0x9ffc000000ddaf48, 0x0, 0x0, 0x100) at _sleep+0x7b0 pipe_read(0xe000000012487e74, 0xa00000009df7d360, 0xa00000009df7d378, 0x0, 0xe000000012848370) at pipe_read+0x740 dofileread(0xe000000012800480, 0x0, 0xe000000012487e50, 0xa00000009df7d360, 0x0, 0x0) at dofileread+0x150 kern_readv(0xe000000012800480, 0x0, 0xa00000009df7d360) at kern_readv+0xa0 sys_read(0xe000000012800480, 0xa00000009df7d4e8, 0x9ffc000000ac2c80, 0x48d) at sys_read+0x100 syscall(0xe0000000128c1720, 0x140810000, 0x2000, 0xe000000012800480, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sh pid 992 tid 100089 td 0xe0000000127a1680 cpu_switch(0xe0000000127a1680, 0xe000000011182900, 0x9ffc000000f5d2f0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000127a1680, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000127a1680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe00000001273f280, 0x6c, 0xe0000000127a19f8, 0xe0000000127a1680) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe00000001273f280, 0x6c, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe00000001273f280, 0x6c, 0x9ffc000000e06798, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe00000001273f280, 0xe00000001273f380, 0x6c, 0x9ffc000000e06798, 0x0, 0x0, 0x100, 0x0) at _sleep+0x7b0 kern_wait6(0xe0000000127a1680, 0x7, 0x0, 0xa00000009df45390, 0x30, 0x0, 0x0) at kern_wait6+0xba0 kern_wait(0xe0000000127a1680, 0xffffffff, 0xa00000009df45390, 0x0, 0x0) at kern_wait+0xe0 sys_wait4(0xe0000000127a1680, 0xa00000009df454e8, 0xa00000009df45390, 0x9ffc000000ac2c80) at sys_wait4+0x70 syscall(0xe00000001273f280, 0x7fffffffffffd100, 0x0, 0xe0000000127a1680, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command inetd pid 976 tid 100075 td 0xe000000012500000 cpu_switch(0xe000000012500000, 0xe000000011182900, 0x9ffc000000f5cd78, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012500000, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012500000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000010c28fc0, 0x0, 0xe000000012500378, 0xe000000012500000) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000010c28fc0, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000010c28fc0, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe000000010c28fc0, 0xe000000010c28fa0, 0xe000000012500000, 0x0, 0x9ffc000000f014b0) at _cv_wait_sig+0x4d0 seltdwait(0xe000000010c28f80, 0xffffffffffffffff, 0x0, 0xe000000010c28fb8, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0x110 kern_select(0xe000000012500000, 0x0, 0x7fffffffffffe0e0, 0x0, 0x0, 0xffffffffffffffff, 0x6) at kern_select+0xb40 sys_select(0xe000000012500000, 0xa00000009deed4e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe0000000125464a0, 0x7fffffffffffe0e0, 0x0, 0xe000000012500000, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command cron pid 937 tid 100076 td 0xe0000000124bc900 cpu_switch(0xe0000000124bc900, 0xe000000011182480, 0x9ffc000000f5dde0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000124bc900, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000124bc900, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000f0c179, 0x6c, 0xe0000000124bcc78, 0xe0000000124bc900) at sleepq_switch+0x2e0 sleepq_catch_signals(0x9ffc000000f0c179, 0x6c, 0x9ffc000000dd7480, 0xe0000000124bcc90) at sleepq_catch_signals+0x190 sleepq_timedwait_sig(0x9ffc000000f0c179, 0x6c, 0x206df9538, 0x9ffc0000005a4e40, 0x998) at sleepq_timedwait_sig+0x30 _sleep(0x9ffc000000f0c179, 0x0, 0x6c, 0x9ffc000000dd1750, 0x1, 0x206df9538, 0x200) at _sleep+0x750 kern_nanosleep(0xe0000000124bc900, 0x206df9538f, 0xa00000009def5380) at kern_nanosleep+0x2a0 sys_nanosleep(0xe0000000124bc900, 0xa00000009def54e8, 0x0, 0x9ffc000000ac2c80) at sys_nanosleep+0xb0 syscall(0xe000000012546000, 0x7fffffffffffec28, 0x4, 0xe0000000124bc900, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sendmail pid 932 tid 100079 td 0xe000000012501b00 cpu_switch(0xe000000012501b00, 0xe0000000127a1200, 0x9ffc000000f5dc28, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012501b00, 0xe0000000127a1200, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012501b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe00000001273e548, 0x74, 0xe000000012501e78, 0xe000000012501b00) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe00000001273e548, 0x74, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe00000001273e548, 0x74, 0x9ffc000000dcff18, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe00000001273e548, 0xe00000001273e5a0, 0x74, 0x9ffc000000dcff18, 0x0, 0x0, 0x100) at _sleep+0x7b0 kern_sigsuspend(0xe000000012501b00, 0x0, 0xe00000001273e548) at kern_sigsuspend+0x140 sys_sigsuspend(0xe000000012501b00, 0xa00000009df0d4e8, 0x9ffc000000ac2c80, 0x48d) at sys_sigsuspend+0x60 syscall(0xe00000001273e4a0, 0xe000000012501b08, 0x9ffc000000abebb0, 0xe000000012501b00, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sendmail pid 929 tid 100080 td 0xe000000012501680 cpu_switch(0xe000000012501680, 0xe000000011182480, 0x9ffc000000f5e290, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012501680, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012501680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000012439640, 0x0, 0xe0000000125019f8, 0xe000000012501680) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000012439640, 0x0, 0x9ffc000000dd7480, 0xe000000012439620) at sleepq_catch_signals+0x190 sleepq_timedwait_sig(0xe000000012439640, 0x0, 0x9ffc0000004fa750, 0x9ffc0000004fa790, 0x713) at sleepq_timedwait_sig+0x30 _cv_timedwait_sig_sbt(0xe000000012439640, 0xe000000012439620, 0xbd71ec5aba, 0x50000000, 0x200) at _cv_timedwait_sig_sbt+0x4f0 seltdwait(0xe000000012439600, 0xbd71ec5aba, 0x50000000, 0xe000000012439638, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0xf0 kern_select(0xe000000012501680, 0x0, 0x7fffffffffffc3c8, 0x0, 0x0, 0xbd71ec5aba, 0x4) at kern_select+0xb40 sys_select(0xe000000012501680, 0xa00000009df154e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe00000001273e000, 0x7fffffffffffc3c8, 0x0, 0xe000000012501680, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command sshd pid 926 tid 100067 td 0xe0000000123ff680 cpu_switch(0xe0000000123ff680, 0xe000000011182900, 0x9ffc000000f5ceb8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000123ff680, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000123ff680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000124397c0, 0x0, 0xe0000000123ff9f8, 0xe0000000123ff680) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000124397c0, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe0000000124397c0, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe0000000124397c0, 0xe0000000124397a0, 0xe0000000123ff680, 0x0, 0x9ffc000000f014b0) at _cv_wait_sig+0x4d0 seltdwait(0xe000000012439780, 0xffffffffffffffff, 0x0, 0xe0000000124397b8, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0x110 kern_select(0xe0000000123ff680, 0x0, 0x1414161a0, 0x0, 0x0, 0xffffffffffffffff, 0x5) at kern_select+0xb40 sys_select(0xe0000000123ff680, 0xa00000009dead4e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe000000012407720, 0x1414161a0, 0x0, 0xe0000000123ff680, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command ntpd pid 866 tid 100077 td 0xe0000000124bc480 cpu_switch(0xe0000000124bc480, 0xe000000011182480, 0x9ffc000000f5cee0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000124bc480, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000124bc480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000124398c0, 0x0, 0xe0000000124bc7f8, 0xe0000000124bc480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000124398c0, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe0000000124398c0, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe0000000124398c0, 0xe0000000124398a0, 0xe0000000124bc480, 0x0, 0x9ffc000000f014b0) at _cv_wait_sig+0x4d0 seltdwait(0xe000000012439880, 0xffffffffffffffff, 0x0, 0xe0000000124398b8, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0x110 kern_select(0xe0000000124bc480, 0x0, 0x7fffffffffffec88, 0x0, 0x0, 0xffffffffffffffff, 0x1e) at kern_select+0xb40 sys_select(0xe0000000124bc480, 0xa00000009defd4e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe00000001273ede0, 0x7fffffffffffec88, 0x0, 0xe0000000124bc480, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command syslogd pid 786 tid 100068 td 0xe0000000123ff200 cpu_switch(0xe0000000123ff200, 0xe000000011182900, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000123ff200, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000123ff200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000010c293c0, 0x0, 0xe0000000123ff578, 0xe0000000123ff200) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000010c293c0, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000010c293c0, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe000000010c293c0, 0xe000000010c293a0, 0xe0000000123ff200, 0x0, 0x9ffc000000f014b0) at _cv_wait_sig+0x4d0 seltdwait(0xe000000010c29380, 0xffffffffffffffff, 0x0, 0xe000000010c293b8, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0x110 kern_select(0xe0000000123ff200, 0x0, 0x140866180, 0x0, 0x0, 0xffffffffffffffff, 0x9) at kern_select+0xb40 sys_select(0xe0000000123ff200, 0xa00000009deb54e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe000000012407280, 0x140866180, 0x0, 0xe0000000123ff200, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command ipmon pid 777 tid 100056 td 0xe000000012168d80 cpu_switch(0xe000000012168d80, 0xe000000011182480, 0x9ffc000000f5e308, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012168d80, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012168d80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000012439940, 0x0, 0xe0000000121690f8, 0xe000000012168d80) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000012439940, 0x0, 0x9ffc000000dd7480, 0x9ffc00000056eef0) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000012439940, 0x0, 0x9ffc0000004fb550, 0x611, 0x9ffc0000004fb590) at sleepq_wait_sig+0x30 _cv_wait_sig(0xe000000012439940, 0xe000000012439920, 0xe000000012168d80, 0x0, 0x9ffc000000f014b0) at _cv_wait_sig+0x4d0 seltdwait(0xe000000012439900, 0xffffffffffffffff, 0x0, 0xe000000012439938, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0x110 kern_select(0xe000000012168d80, 0x0, 0x7fffffffffff6b50, 0x0, 0x0, 0xffffffffffffffff, 0x4) at kern_select+0xb40 sys_select(0xe000000012168d80, 0xa00000009de554e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe0000000111d7280, 0x7fffffffffff6b50, 0x0, 0xe000000012168d80, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command devd pid 655 tid 100055 td 0xe00000001178c480 cpu_switch(0xe00000001178c480, 0xe000000011182480, 0x9ffc000000f5e358, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178c480, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001178c480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000012439b40, 0x0, 0xe00000001178c7f8, 0xe00000001178c480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000012439b40, 0x0, 0x9ffc000000dd7480, 0xe000000012439b20) at sleepq_catch_signals+0x190 sleepq_timedwait_sig(0xe000000012439b40, 0x0, 0x9ffc0000004fa750, 0x9ffc0000004fa790, 0x713) at sleepq_timedwait_sig+0x30 _cv_timedwait_sig_sbt(0xe000000012439b40, 0xe000000012439b20, 0xe321aaea70, 0x3c0000000, 0x200) at _cv_timedwait_sig_sbt+0x4f0 seltdwait(0xe000000012439b00, 0xe321aaea70, 0x3c0000000, 0xe000000012439b38, 0x9ffc000000ddac78, 0x9ffc00000064a8d0) at seltdwait+0xf0 kern_select(0xe00000001178c480, 0x0, 0x7fffffffffffcd00, 0x0, 0x0, 0xe321aaea70, 0x5) at kern_select+0xb40 sys_select(0xe00000001178c480, 0xa00000009de4d4e8, 0x9ffc000000ac2c80, 0x48d) at sys_select+0xb0 syscall(0xe0000000111d7720, 0x7fffffffffffcd00, 0x0, 0xe00000001178c480, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command adjkerntz pid 140 tid 100074 td 0xe000000012500480 cpu_switch(0xe000000012500480, 0xe000000011182900, 0x9ffc000000f5d548, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012500480, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012500480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000125469e8, 0x74, 0xe0000000125007f8, 0xe000000012500480) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe0000000125469e8, 0x74, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe0000000125469e8, 0x74, 0x9ffc000000dcff18, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe0000000125469e8, 0xe000000012546a40, 0x74, 0x9ffc000000dcff18, 0x0, 0x0, 0x100) at _sleep+0x7b0 kern_sigsuspend(0xe000000012500480, 0x0, 0xe0000000125469e8) at kern_sigsuspend+0x140 sys_sigsuspend(0xe000000012500480, 0xa00000009dee54e8, 0x9ffc000000ac2c80, 0x48d) at sys_sigsuspend+0x60 syscall(0xe000000012546940, 0x0, 0x0, 0xe000000012500480, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command softdepflush pid 23 tid 100064 td 0xe000000012169680 cpu_switch(0xe000000012169680, 0xe00000001178d680, 0x9ffc000000f5c5a8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012169680, 0xe00000001178d680, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012169680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee2d30, 0x54, 0xe0000000121699f8, 0xe000000012169680) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000ee2d30, 0x54, 0x0, 0x9ffc000000dd7480, 0xe000000012169680) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000ee2d30, 0x9ffc0000011091e0, 0x54, 0x9ffc000000e06260, 0x1, 0x0, 0x100) at _sleep+0x780 softdep_flush(0x9ffc0000011091f8, 0x0, 0xe00000001255daa0, 0x0) at softdep_flush+0x390 fork_exit(0x9ffc000000e24940, 0x0, 0xa00000009de95550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command vnlru pid 22 tid 100063 td 0xe000000012169b00 cpu_switch(0xe000000012169b00, 0xe000000012169680, 0x9ffc000000f5c9b8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012169b00, 0xe000000012169680, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012169b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000012171720, 0x60, 0xe000000012169e78, 0xe000000012169b00) at sleepq_switch+0x2e0 sleepq_timedwait(0xe000000012171720, 0x60, 0x0, 0x9ffc000000dd7480, 0xe000000012169b00) at sleepq_timedwait+0xb0 _sleep(0xe000000012171720, 0x9ffc000001101a50, 0x60, 0x9ffc000000de6420, 0x1, 0x0, 0x100) at _sleep+0x780 vnlru_proc(0x0, 0xa00000009de8d550, 0x9ffc000000dc8140, 0x9ffc000000de4db0) at vnlru_proc+0x2c0 fork_exit(0x9ffc000000e1ee40, 0x0, 0xa00000009de8d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command syncer pid 21 tid 100062 td 0xe0000000123fe000 cpu_switch(0xe0000000123fe000, 0xe000000011182480, 0x9ffc000000f5d6b0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000123fe000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000123fe000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000001101a90, 0x0, 0xe0000000123fe378, 0xe0000000123fe000) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000001101a90, 0x0, 0x9ffc0000004fae60, 0x9ffc000000dd7480, 0xe0000000123fe000) at sleepq_timedwait+0xb0 _cv_timedwait_sbt(0x9ffc000001101a90, 0x9ffc000001101a70, 0xfffffed8, 0x0, 0x100) at _cv_timedwait_sbt+0x4f0 sched_sync(0xba, 0xe000000012579008, 0xe000000012578ea0, 0xe0000000117952a0) at sched_sync+0xba0 fork_exit(0x9ffc000000e202a0, 0x0, 0xa00000009de85550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command bufdaemon pid 20 tid 100061 td 0xe0000000123fe480 cpu_switch(0xe0000000123fe480, 0xe0000000111a1680, 0x9ffc000000f5e560, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000123fe480, 0xe0000000111a1680, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000123fe480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee20c8, 0x54, 0xe0000000123fe7f8, 0xe0000000123fe480) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000ee20c8, 0x54, 0x0, 0x9ffc000000dd7480, 0xe0000000123fe480) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000ee20c8, 0x9ffc000001101600, 0x54, 0x9ffc000000de20d0, 0x1, 0x0, 0x100) at _sleep+0x780 buf_daemon(0x203b, 0x9ffc000000ee2094, 0x9ffc000000ee20c8, 0x9ffc000000de1700) at buf_daemon+0x2f0 fork_exit(0x9ffc000000e1ad90, 0x0, 0xa00000009de7d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command pagezero pid 19 tid 100060 td 0xe00000001178db00 cpu_switch(0xe00000001178db00, 0xe000000011182480, 0x9ffc000000f5e4c0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178db00, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001178db00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee30d4, 0x0, 0xe00000001178de78, 0xe00000001178db00) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000ee30d4, 0x0, 0x0, 0x9ffc000000dd7480, 0xe00000001178db00) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000ee30d4, 0x9ffc00000110a380, 0x0, 0x9ffc000000e0e998, 0x1, 0x0, 0x100) at _sleep+0x780 vm_pagezero(0x9ffc000000ee30d4, 0x9ffc000000ee1ba8, 0x9ffc000000ee1bc0, 0x9ffc000000e0e998) at vm_pagezero+0x280 fork_exit(0x9ffc000000e21ce0, 0x0, 0xa00000009de75550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command vmdaemon pid 18 tid 100059 td 0xe000000012168000 cpu_switch(0xe000000012168000, 0xe0000000123fe480, 0x9ffc000000f5c300, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012168000, 0xe0000000123fe480, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012168000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee303c, 0x74, 0xe000000012168378, 0xe000000012168000) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc000000ee303c, 0x74, 0x9ffc000000dd7480, 0xe000000012168000, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0x9ffc000000ee303c, 0x9ffc00000110b400, 0x74, 0x9ffc000000de20d0, 0x0, 0x0, 0x100) at _sleep+0x7d0 vm_daemon(0x0, 0xa00000009de6d550, 0x9ffc000000e0d7d0, 0x3d5) at vm_daemon+0xd0 fork_exit(0x9ffc000000e22f10, 0x0, 0xa00000009de6d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command pagedaemon pid 17 tid 100058 td 0xe000000012168480 cpu_switch(0xe000000012168480, 0xe0000000123fe480, 0x9ffc000000f5cf80, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012168480, 0xe0000000123fe480, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012168480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee306c, 0x54, 0xe0000000121687f8, 0xe000000012168480) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000ee306c, 0x54, 0x0, 0x9ffc000000dd7480, 0xe000000012168480) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000ee306c, 0x9ffc00000110a380, 0x54, 0x9ffc000000de20d0, 0x1, 0x0, 0x100) at _sleep+0x780 vm_pageout(0x9ffc000000edfd98, 0xe00000027d37f5b0, 0x0, 0x0) at vm_pageout+0x8a0 fork_exit(0x9ffc000000e274d0, 0x0, 0xa00000009de65550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command xpt_thrd pid 9 tid 100057 td 0xe000000012168900 cpu_switch(0xe000000012168900, 0xe000000011182480, 0x9ffc000000f5d818, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000012168900, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000012168900, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee33a0, 0x5c, 0xe000000012168c78, 0xe000000012168900) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc000000ee33a0, 0x5c, 0x9ffc000000dd7480, 0xe000000012168900, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0x9ffc000000ee33a0, 0x9ffc000000ee3420, 0x5c, 0x9ffc000000bfb200, 0x0, 0x0, 0x100) at _sleep+0x7d0 xpt_scanner_thread(0xe000000011795c20, 0xe00000001219f000, 0x9ffc000000ee33a0, 0x9ffc000000bfb040) at xpt_scanner_thread+0xb0 fork_exit(0x9ffc000000e1a910, 0x0, 0xa00000009de5d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command sctp_iterator pid 6 tid 100054 td 0xe00000001178c900 cpu_switch(0xe00000001178c900, 0xe000000011182480, 0x9ffc000000f5d2c8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178c900, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001178c900, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000001104130, 0x0, 0xe00000001178cc78, 0xe00000001178c900) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc000001104130, 0x0, 0x9ffc000000dd7480, 0xe00000001178c900, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0x9ffc000001104130, 0x9ffc0000011040d0, 0x0, 0x9ffc000000df1610, 0x0, 0x0, 0x100) at _sleep+0x7d0 sctp_iterator_thread(0x9ffc000000df1610, 0x9ffc0000011040d0, 0x9ffc000001104130, 0x9ffc0000005335f0) at sctp_iterator_thread+0x90 fork_exit(0x9ffc000000e1e730, 0x0, 0xa00000009de45550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command zfskern pid 5 tid 100052 td 0xe00000001178d200 cpu_switch(0xe00000001178d200, 0xe000000011182900, 0x9ffc000000f5ded0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178d200, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001178d200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000001557ec0, 0x0, 0xe00000001178d578, 0xe00000001178d200) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000001557ec0, 0x0, 0x713, 0x9ffc000000dd7480, 0xe00000001178d200) at sleepq_timedwait+0xb0 _cv_timedwait_sbt(0x9ffc000001557ec0, 0x9ffc000001557ea0, 0xfffffed8, 0x0, 0x100, 0xe00000001178d200, 0x1, 0x9ffc000000e84138) at _cv_timedwait_sbt+0x4f0 l2arc_feed_thread(0x9ffc000001546de0, 0x9ffc000001546dd8, 0x9ffc000001546dd0, 0x9ffc0000014e9468) at l2arc_feed_thread+0x800 fork_exit(0x9ffc000000e3e7b0, 0x0, 0xa00000009de33550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command zfskern pid 5 tid 100051 td 0xe00000001178d680 cpu_switch(0xe00000001178d680, 0xe0000000123fe000, 0x9ffc000000f5c620, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178d680, 0xe0000000123fe000, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001178d680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc0000015480a0, 0x0, 0xe00000001178d9f8, 0xe00000001178d680) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc0000015480a0, 0x0, 0x713, 0x9ffc000000dd7480, 0xe00000001178d680) at sleepq_timedwait+0xb0 _cv_timedwait_sbt(0x9ffc0000015480a0, 0x9ffc000001548080, 0xfffffed8, 0x0, 0x100) at _cv_timedwait_sbt+0x4f0 arc_reclaim_thread(0x0, 0xa00000009de2b550, 0x9ffc000000dc8140, 0x3d5) at arc_reclaim_thread+0x610 fork_exit(0x9ffc000000e3e870, 0x0, 0xa00000009de2b550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command isp0: fc_thrd0 pid 4 tid 100047 td 0xe00000001174db00 cpu_switch(0xe00000001174db00, 0xe000000011425b00, 0x9ffc000000f5d520, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174db00, 0xe000000011425b00, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001174db00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000011768000, 0x5c, 0xe00000001174de78, 0xe00000001174db00) at sleepq_switch+0x2e0 sleepq_wait(0xe000000011768000, 0x5c, 0x9ffc000000dd7480, 0xe00000001174db00, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe000000011768000, 0xe000000011786400, 0x5c, 0x9ffc000000c27460, 0x0, 0x0, 0x100) at _sleep+0x7d0 isp_kthread(0xe000000011768000, 0xe000000011786400, 0x0, 0xe000000011768040) at isp_kthread+0x580 fork_exit(0x9ffc000000e1f480, 0xe000000011768000, 0xa00000009de0b550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command mpt_recovery1 pid 3 tid 100043 td 0xe00000001174c000 cpu_switch(0xe00000001174c000, 0xe00000001174db00, 0x9ffc000000f5d020, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174c000, 0xe00000001174db00, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001174c000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa000000000a16000, 0x78, 0xe00000001174c378, 0xe00000001174c000) at sleepq_switch+0x2e0 sleepq_wait(0xa000000000a16000, 0x78, 0x9ffc000000dd7480, 0xe00000001174c000, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xa000000000a16000, 0xa000000000a16008, 0x78, 0x9ffc000000da3878, 0x0, 0x0, 0x100, 0x0) at _sleep+0x7d0 mpt_recovery_thread(0xa000000000a16000, 0xa00000009ddcd550, 0x9ffc000000dc8140, 0xa000000000a16440) at mpt_recovery_thread+0x170 fork_exit(0x9ffc000000e1d050, 0xa000000000a16000, 0xa00000009ddcd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command mpt_recovery0 pid 2 tid 100041 td 0xe00000001174c900 cpu_switch(0xe00000001174c900, 0xe00000001174c000, 0x9ffc000000f5e420, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174c900, 0xe00000001174c000, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001174c900, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009fe000, 0x78, 0xe00000001174cc78, 0xe00000001174c900) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009fe000, 0x78, 0x9ffc000000dd7480, 0xe00000001174c900, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xa0000000009fe000, 0xa0000000009fe008, 0x78, 0x9ffc000000da3878, 0x0, 0x0, 0x100, 0x0) at _sleep+0x7d0 mpt_recovery_thread(0xa0000000009fe000, 0xa00000009dd6f550, 0x9ffc000000dc8140, 0xa0000000009fe440) at mpt_recovery_thread+0x170 fork_exit(0x9ffc000000e1d050, 0xa0000000009fe000, 0xa00000009dd6f550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100039 td 0xe000000011744480 cpu_switch(0xe000000011744480, 0xe00000001174c900, 0x9ffc000000f5dd90, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011744480, 0xe00000001174c900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011744480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009fae18, 0x0, 0xe0000000117447f8, 0xe000000011744480) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009fae18, 0x0, 0x9ffc000000dd7480, 0xe000000011744480, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009fae18, 0xa0000000009fb040, 0xe000000011744480, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009fae08, 0x0, 0xa0000000009fae55, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009fae08, 0xa00000009dd11550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100038 td 0xe000000011744900 cpu_switch(0xe000000011744900, 0xe000000011182900, 0x9ffc000000f5d228, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011744900, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011744900, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009fadc0, 0x0, 0xe000000011744c78, 0xe000000011744900) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009fadc0, 0x0, 0x9ffc000000dd7480, 0xe000000011744900, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009fadc0, 0xa0000000009fb040, 0xe000000011744900, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009fadb0, 0x0, 0xa0000000009fadfd, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009fadb0, 0xa00000009dd09550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100037 td 0xe000000011744d80 cpu_switch(0xe000000011744d80, 0xe000000011744900, 0x9ffc000000f5dfe8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011744d80, 0xe000000011744900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011744d80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009fad68, 0x0, 0xe0000000117450f8, 0xe000000011744d80) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009fad68, 0x0, 0x9ffc000000dd7480, 0xe000000011744d80, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009fad68, 0xa0000000009fb040, 0xe000000011744d80, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009fad58, 0x0, 0xa0000000009fada5, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009fad58, 0xa00000009dd01550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100036 td 0xe000000011745200 cpu_switch(0xe000000011745200, 0xe000000011744d80, 0x9ffc000000f5dea8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011745200, 0xe000000011744d80, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011745200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009fad10, 0x0, 0xe000000011745578, 0xe000000011745200) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009fad10, 0x0, 0x9ffc000000dd7480, 0xe000000011745200, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009fad10, 0xa0000000009fb040, 0xe000000011745200, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009fad00, 0x0, 0xa0000000009fad4d, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009fad00, 0xa00000009dcf9550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100034 td 0xe000000011480d80 cpu_switch(0xe000000011480d80, 0xe000000011745200, 0x9ffc000000f5d340, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011480d80, 0xe000000011745200, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011480d80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009f1460, 0x0, 0xe0000000114810f8, 0xe000000011480d80) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009f1460, 0x0, 0x9ffc000000dd7480, 0xe000000011480d80, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009f1460, 0xa0000000009f1688, 0xe000000011480d80, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009f1450, 0x0, 0xa0000000009f149d, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009f1450, 0xa0000000e2fed550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100033 td 0xe000000011481200 cpu_switch(0xe000000011481200, 0xe000000011182900, 0x9ffc000000f5c580, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011481200, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011481200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009f1408, 0x0, 0xe000000011481578, 0xe000000011481200) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009f1408, 0x0, 0x9ffc000000dd7480, 0xe000000011481200, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009f1408, 0xa0000000009f1688, 0xe000000011481200, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009f13f8, 0x0, 0xa0000000009f1445, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009f13f8, 0xa0000000e2fe5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100032 td 0xe000000011481680 cpu_switch(0xe000000011481680, 0xe000000011182480, 0x9ffc000000f5da98, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011481680, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011481680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009f13b0, 0x0, 0xe0000000114819f8, 0xe000000011481680) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009f13b0, 0x0, 0x9ffc000000dd7480, 0xe000000011481680, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009f13b0, 0xa0000000009f1688, 0xe000000011481680, 0x9ffc000000efef70) at _cv_wait+0x4d0 usb_process(0xa0000000009f13a0, 0x0, 0xa0000000009f13ed, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009f13a0, 0xa0000000e2fdd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100031 td 0xe000000011481b00 cpu_switch(0xe000000011481b00, 0xe000000011182480, 0x9ffc000000f5ccd8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011481b00, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011481b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009f1358, 0x0, 0xe000000011481e78, 0xe000000011481b00) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009f1358, 0x0, 0x9ffc000000dd7480, 0xe000000011481b00, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009f1358, 0xa0000000009f1688, 0xe000000011481b00, 0x9ffc000000efef70) at _cv_wait+0x4d0 usb_process(0xa0000000009f1348, 0x0, 0xa0000000009f1395, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009f1348, 0xa0000000e2fd5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100029 td 0xe000000011425680 cpu_switch(0xe000000011425680, 0xe000000011182480, 0x9ffc000000f5dd40, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011425680, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011425680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009ed460, 0x0, 0xe0000000114259f8, 0xe000000011425680) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009ed460, 0x0, 0x9ffc000000dd7480, 0xe000000011425680, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009ed460, 0xa0000000009ed688, 0xe000000011425680, 0x9ffc000000efef70) at _cv_wait+0x4d0 usb_process(0xa0000000009ed450, 0x0, 0xa0000000009ed49d, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009ed450, 0xa0000000e2f3d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100028 td 0xe000000011425b00 cpu_switch(0xe000000011425b00, 0xe000000011182480, 0x9ffc000000f5e380, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011425b00, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011425b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009ed408, 0x0, 0xe000000011425e78, 0xe000000011425b00) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009ed408, 0x0, 0x9ffc000000dd7480, 0xe000000011425b00, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009ed408, 0xa0000000009ed688, 0xe000000011425b00, 0x0) at _cv_wait+0x4d0 usb_process(0xa0000000009ed3f8, 0x0, 0xa0000000009ed445, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009ed3f8, 0xa0000000e2f35550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100027 td 0xe000000011480000 cpu_switch(0xe000000011480000, 0xe000000011425b00, 0x9ffc000000f5d098, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011480000, 0xe000000011425b00, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011480000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009ed3b0, 0x0, 0xe000000011480378, 0xe000000011480000) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009ed3b0, 0x0, 0x9ffc000000dd7480, 0xe000000011480000, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009ed3b0, 0xa0000000009ed688, 0xe000000011480000, 0x9ffc000000efef70) at _cv_wait+0x4d0 usb_process(0xa0000000009ed3a0, 0x0, 0xa0000000009ed3ed, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009ed3a0, 0xa0000000e2f2d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command usb pid 16 tid 100026 td 0xe000000011480480 cpu_switch(0xe000000011480480, 0xe000000011480000, 0x9ffc000000f5d6d8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011480480, 0xe000000011480000, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011480480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xa0000000009ed358, 0x0, 0xe0000000114807f8, 0xe000000011480480) at sleepq_switch+0x2e0 sleepq_wait(0xa0000000009ed358, 0x0, 0x9ffc000000dd7480, 0xe000000011480480, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0xa0000000009ed358, 0xa0000000009ed688, 0xe000000011480480, 0x9ffc000000efef70) at _cv_wait+0x4d0 usb_process(0xa0000000009ed348, 0x0, 0xa0000000009ed395, 0x9ffc000000ee0ea4) at usb_process+0x380 fork_exit(0x9ffc000000e20c30, 0xa0000000009ed348, 0xa0000000e2f25550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command acpi_thermal pid 15 tid 100024 td 0xe000000011424000 cpu_switch(0xe000000011424000, 0xe000000011182480, 0x9ffc000000f5cf30, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011424000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011424000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee0a50, 0x64, 0xe000000011424378, 0xe000000011424000) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000ee0a50, 0x64, 0x0, 0x9ffc000000dd7480, 0xe000000011424000) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000ee0a50, 0x9ffc000000ee9f80, 0x64, 0x9ffc000000c1e9c8, 0x1, 0x0, 0x100) at _sleep+0x780 acpi_tz_thread(0x1, 0xe000000011177a00, 0xe0000000111bed68, 0x1) at acpi_tz_thread+0x4e0 fork_exit(0x9ffc000000e20700, 0x0, 0xa0000000e2e91550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command rand_harvestq pid 14 tid 100013 td 0xe0000000111a1680 cpu_switch(0xe0000000111a1680, 0xe000000011182480, 0x9ffc000000f5c968, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111a1680, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111a1680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee0d38, 0x0, 0xe0000000111a19f8, 0xe0000000111a1680) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000ee0d38, 0x0, 0x713, 0x9ffc000000dd7480, 0xe0000000111a1680) at sleepq_timedwait+0xb0 msleep_spin_sbt(0x9ffc000000ee0d38, 0x9ffc000000eea5f0, 0x9ffc000000dab938, 0x19999999, 0x0, 0x4) at msleep_spin_sbt+0x420 random_kthread(0x9ffc000000e3bb70, 0x0, 0x9ffc000000eea518, 0x3) at random_kthread+0x370 fork_exit(0x9ffc000000e264c0, 0x9ffc000000e3bb70, 0xa0000000a07fd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command geom pid 13 tid 100012 td 0xe0000000111a1b00 cpu_switch(0xe0000000111a1b00, 0xe000000011182480, 0x9ffc000000f5d070, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111a1b00, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111a1b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee1270, 0x5c, 0xe0000000111a1e78, 0xe0000000111a1b00) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc000000ee1270, 0x5c, 0x9ffc000000dd7480, 0xe0000000111a1b00, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0x9ffc000000ee1270, 0x9ffc000000efe8c8, 0x5c, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 g_io_schedule_down(0x0, 0x9ffc000000ee120c, 0x9fe3a7400, 0x9ffc000000efe8b8) at g_io_schedule_down+0x190 g_down_procbody(0x9ffc000000ee1228, 0x9ffc000000dc1218, 0x9ffc0000005335f0, 0x40c) at g_down_procbody+0xb0 fork_exit(0x9ffc000000e1cbe0, 0x0, 0xa0000000a07f5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command geom pid 13 tid 100011 td 0xe0000000111b0000 cpu_switch(0xe0000000111b0000, 0xe000000011182480, 0x9ffc000000f5d430, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111b0000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111b0000, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee1268, 0x5c, 0xe0000000111b0378, 0xe0000000111b0000) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc000000ee1268, 0x5c, 0x9ffc000000dd7480, 0xe0000000111b0000, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0x9ffc000000ee1268, 0x9ffc000000efe900, 0x5c, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 g_io_schedule_up(0x0, 0xe0000000111b0350, 0x9ffc000000efe8f0, 0xe0000000111b0350) at g_io_schedule_up+0x1c0 g_up_procbody(0x9ffc000000ee1220, 0x9ffc000000dc1218, 0x9ffc0000005335f0, 0x40c) at g_up_procbody+0xb0 fork_exit(0x9ffc000000e1a640, 0x0, 0xa0000000a07ed550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command geom pid 13 tid 100010 td 0xe000000011183680 cpu_switch(0xe000000011183680, 0xe000000011182900, 0x9ffc000000f5ccb0, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011183680, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011183680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000ee1258, 0x5c, 0xe0000000111839f8, 0xe000000011183680) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc000000ee1258, 0x5c, 0x9ffc000000dd7480, 0xe000000011183680, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0x9ffc000000ee1258, 0x9ffc000000efe898, 0x5c, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 g_run_events(0x9ffc000000efe8b0, 0x0, 0x0, 0x0) at g_run_events+0xb00 g_event_procbody(0x9ffc000000ee1230, 0x9ffc000000dc1218, 0x9ffc0000005335f0, 0x40c) at g_event_procbody+0xb0 fork_exit(0x9ffc000000e1a620, 0x0, 0xa0000000a07e5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100048 td 0xe00000001174d680 cpu_switch(0xe00000001174d680, 0xe000000012500d80, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174d680, 0xe000000012500d80, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe00000001174d680, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cc60, 0xa00000009de13550, 0xe00000001119cc74, 0xe00000001119689c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cc60, 0xa00000009de13550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100046 td 0xe00000001178c000 cpu_switch(0xe00000001178c000, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178c000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe00000001178c000, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cd00, 0xa00000009dde5550, 0xe00000001119cd14, 0xe000000011196a9c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cd00, 0xa00000009dde5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100042 td 0xe00000001174c480 cpu_switch(0xe00000001174c480, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174c480, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe00000001174c480, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cd20, 0xa00000009dd77550, 0xe00000001119cd34, 0xe000000011196f9c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cd20, 0xa00000009dd77550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100040 td 0xe000000011744000 cpu_switch(0xe000000011744000, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011744000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe000000011744000, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119ccc0, 0xa00000009dd19550, 0xe00000001119ccd4, 0xe000000011196d9c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119ccc0, 0xa00000009dd19550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100035 td 0xe000000011480900 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100030 td 0xe000000011425200 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100025 td 0xe0000000111b1b00 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100022 td 0xe000000011424900 cpu_switch(0xe000000011424900, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011424900, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe000000011424900, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cea0, 0xa0000000e2e81550, 0xe00000001119ceb4, 0xe00000001119769c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cea0, 0xa0000000e2e81550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100021 td 0xe000000011424d80 cpu_switch(0xe000000011424d80, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011424d80, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe000000011424d80, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cec0, 0xa0000000e2e79550, 0xe00000001119ced4, 0xe00000001119779c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cec0, 0xa0000000e2e79550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100019 td 0xe0000000111b0900 cpu_switch(0xe0000000111b0900, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111b0900, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe0000000111b0900, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cee0, 0xa0000000e2e69550, 0xe00000001119cef4, 0xe00000001119789c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cee0, 0xa0000000e2e69550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100018 td 0xe0000000111b0d80 cpu_switch(0xe0000000111b0d80, 0xe000000011182900, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111b0d80, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe0000000111b0d80, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cf00, 0xa0000000e2e61550, 0xe00000001119cf14, 0xe00000001119799c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cf00, 0xa0000000e2e61550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100008 td 0xe0000000111a0000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100007 td 0xe0000000111a0480 cpu_switch(0xe0000000111a0480, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111a0480, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe0000000111a0480, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cf40, 0xa0000000a07cd550, 0xe00000001119cf54, 0xe000000011197b9c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cf40, 0xa0000000a07cd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command intr pid 12 tid 100006 td 0xe0000000111a0900 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100005 td 0xe000000011182000 cpu_switch(0xe000000011182000, 0xe000000011182480, 0x9ffc000000f27100, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011182000, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x109, 0x0, 0xe000000011182000, 0x9ffc00000053c9d0) at mi_switch+0x3f0 ithread_loop(0xe00000001119cf80, 0xa0000000a07bd550, 0xe00000001119cf94, 0xe000000011197d9c) at ithread_loop+0x420 fork_exit(0x9ffc000000e20f50, 0xe00000001119cf80, 0xa0000000a07bd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command idle pid 11 tid 100004 td 0xe000000011182480 ia64_ih_stop(0x9ffc000000aa9070, 0x40b) at ia64_ih_stop+0x80 ia64_handle_intr(0xa0000000a07b5000) at ia64_handle_intr+0x110 ivt_External_Interrupt() at ivt_External_Interrupt+0x30 --- trapframe at 0xa0000000a07b5000 acpi_cpu_c1(0x9ffc0000001779f0, 0x48b) at acpi_cpu_c1+0x71 acpi_cpu_idle(0x0, 0x9ffc000000edce20, 0x642ea6cd77, 0xe000000011177c00) at acpi_cpu_idle+0x420 cpu_idle(0x0, 0x19526e0b, 0x9ffc0000005e96d0, 0xd9f) at cpu_idle+0x130 sched_idletd(0x10, 0x10, 0x2, 0xfffffffffffffffd) at sched_idletd+0x670 fork_exit(0x9ffc000000e3bef0, 0x0, 0xa0000000a07b5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command idle pid 11 tid 100003 td 0xe000000011182900 cpu_switch(0xe000000011182900, 0xe000000012800000, 0x9ffc000000f26400, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011182900, 0xe000000012800000, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x608, 0x0, 0xe000000011182900, 0x9ffc00000059ff20) at mi_switch+0x3f0 critical_exit(0xe000000011182900, 0xe000000011182cec, 0x9ffc000000aad1e0, 0x289) at critical_exit+0x170 cpu_idle(0x0, 0xddf3fdd, 0x9ffc0000005e96d0, 0xd9f) at cpu_idle+0x190 sched_idletd(0xd, 0xd, 0x2, 0xfffffffffffffffe) at sched_idletd+0x670 fork_exit(0x9ffc000000e3bef0, 0x0, 0xa0000000a07ad550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command init pid 1 tid 100002 td 0xe000000011182d80 cpu_switch(0xe000000011182d80, 0xe000000011182480, 0x9ffc000000f5e628, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011182d80, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011182d80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000011180de0, 0x6c, 0xe0000000111830f8, 0xe000000011182d80) at sleepq_switch+0x2e0 sleepq_catch_signals(0xe000000011180de0, 0x6c, 0x9ffc000000dd7480, 0x9ffc000000dd7840) at sleepq_catch_signals+0x190 sleepq_wait_sig(0xe000000011180de0, 0x6c, 0x9ffc000000e06798, 0x100, 0x9ffc0000005a4ea0) at sleepq_wait_sig+0x30 _sleep(0xe000000011180de0, 0xe000000011180ee0, 0x6c, 0x9ffc000000e06798, 0x0, 0x0, 0x100, 0x0) at _sleep+0x7b0 kern_wait6(0xe000000011182d80, 0x7, 0x0, 0xa0000000a07a5390, 0x30, 0x0, 0x0) at kern_wait6+0xba0 kern_wait(0xe000000011182d80, 0xffffffff, 0xa0000000a07a5390, 0x0, 0x0) at kern_wait+0xe0 sys_wait4(0xe000000011182d80, 0xa0000000a07a54e8, 0xa0000000a07a5390, 0x9ffc000000ac2c80) at sys_wait4+0x70 syscall(0xe000000011180de0, 0x0, 0x0, 0xe000000011182d80, 0x0, 0x0, 0x9ffc000000abeba0, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return Tracing command audit pid 10 tid 100001 td 0xe000000011183200 cpu_switch(0xe000000011183200, 0xe000000011183680, 0x9ffc000000f5cd78, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011183200, 0xe000000011183680, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011183200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc0000011087c8, 0x0, 0xe000000011183578, 0xe000000011183200) at sleepq_switch+0x2e0 sleepq_wait(0x9ffc0000011087c8, 0x0, 0x9ffc000000dd7480, 0xe000000011183200, 0x9ffc0000004fc2c0) at sleepq_wait+0xb0 _cv_wait(0x9ffc0000011087c8, 0x9ffc000001108798, 0xe000000011183200, 0x9ffc000000efef70, 0x9ffc000000f014b0, 0x9ffc000000e81ac0, 0x0) at _cv_wait+0x4d0 audit_worker(0x0, 0xa0000000a079d550, 0xa0000000a079d538, 0x9ffc0000011087d8) at audit_worker+0x150 fork_exit(0x9ffc000000e1ef20, 0x0, 0xa0000000a079d550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100053 td 0xe00000001178cd80 cpu_switch(0xe00000001178cd80, 0xe0000000124bc480, 0x9ffc000000f5def8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001178cd80, 0xe0000000124bc480, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001178cd80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000f0af10, 0x0, 0xe00000001178d0f8, 0xe00000001178cd80) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000f0af10, 0x0, 0x0, 0x9ffc000000dd7480, 0xe00000001178cd80) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000f0af10, 0x0, 0x0, 0x9ffc000000dab938, 0x1, 0x0, 0x100) at _sleep+0x780 pause_sbt(0x9ffc000000dab938, 0x2fffffc88, 0x0, 0x100) at pause_sbt+0x1b0 deadlkres(0x9ffc000000efeac8, 0x0, 0x9ffc000000dc8140, 0x9ffc000000dc5468) at deadlkres+0x670 fork_exit(0x9ffc000000e23230, 0x0, 0xa00000009de3b550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100050 td 0xe00000001174cd80 cpu_switch(0xe00000001174cd80, 0xe00000001178cd80, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174cd80, 0xe00000001178cd80, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001174cd80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000011795300, 0x0, 0xe00000001174d0f8, 0xe00000001174cd80) at sleepq_switch+0x2e0 sleepq_wait(0xe000000011795300, 0x0, 0x9ffc000000dd7480, 0xe00000001174cd80, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe000000011795300, 0xe000000011795330, 0x0, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 taskqueue_thread_loop(0xe000000011795300, 0xe000000011795360, 0xe00000001179535c, 0xe000000011795330) at taskqueue_thread_loop+0x1d0 fork_exit(0x9ffc000000e3bff0, 0xe000000011162740, 0xa00000009de23550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100049 td 0xe00000001174d200 cpu_switch(0xe00000001174d200, 0xe00000001174cd80, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe00000001174d200, 0xe00000001174cd80, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe00000001174d200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe000000011795300, 0x0, 0xe00000001174d578, 0xe00000001174d200) at sleepq_switch+0x2e0 sleepq_wait(0xe000000011795300, 0x0, 0x9ffc000000dd7480, 0xe00000001174d200, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe000000011795300, 0xe000000011795330, 0x0, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 taskqueue_thread_loop(0xe000000011795300, 0xe000000011795360, 0xe00000001179535c, 0xe000000011795330) at taskqueue_thread_loop+0x1d0 fork_exit(0x9ffc000000e3bff0, 0xe000000011162740, 0xa00000009de1b550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100045 td 0xe000000011745680 cpu_switch(0xe000000011745680, 0xe000000011182480, 0x9ffc000000f5c6e8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011745680, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011745680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a2500, 0x0, 0xe0000000117459f8, 0xe000000011745680) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a2500, 0x0, 0x9ffc000000dd7480, 0xe000000011745680, 0x9ffc0000005a4520) at sleepq_wait+0xb0 msleep_spin_sbt(0xe0000000111a2500, 0xe0000000111a2530, 0x9ffc000000dab938, 0x0, 0x0, 0x100, 0xe0000000111a2548) at msleep_spin_sbt+0x440 taskqueue_thread_loop(0xe0000000111a2500, 0xe0000000111a2560, 0xe0000000111a255c, 0xe0000000111a2530) at taskqueue_thread_loop+0x190 fork_exit(0x9ffc000000e3bff0, 0xa000000000a34830, 0xa00000009dddd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100044 td 0xe000000011745b00 cpu_switch(0xe000000011745b00, 0xe000000011182900, 0x9ffc000000f5c710, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011745b00, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011745b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a2600, 0x0, 0xe000000011745e78, 0xe000000011745b00) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a2600, 0x0, 0x9ffc000000dd7480, 0xe000000011745b00, 0x9ffc0000005a4520) at sleepq_wait+0xb0 msleep_spin_sbt(0xe0000000111a2600, 0xe0000000111a2630, 0x9ffc000000dab938, 0x0, 0x0, 0x100, 0xe0000000111a2648) at msleep_spin_sbt+0x440 taskqueue_thread_loop(0xe0000000111a2600, 0xe0000000111a2660, 0xe0000000111a265c, 0xe0000000111a2630) at taskqueue_thread_loop+0x190 fork_exit(0x9ffc000000e3bff0, 0xa000000000a30830, 0xa00000009ddd5550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100023 td 0xe000000011424480 cpu_switch(0xe000000011424480, 0xe000000011182900, 0x9ffc000000f5ce18, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011424480, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011424480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5300, 0x0, 0xe0000000114247f8, 0xe000000011424480) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5300, 0x0, 0x9ffc000000dd7480, 0xe000000011424480, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe0000000111a5300, 0xe0000000111a5330, 0x0, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 taskqueue_thread_loop(0xe0000000111a5300, 0xe0000000111a5360, 0xe0000000111a535c, 0xe0000000111a5330) at taskqueue_thread_loop+0x1d0 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee2c68, 0xa0000000e2e89550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100020 td 0xe0000000111b0480 cpu_switch(0xe0000000111b0480, 0xe000000011182480, 0x9ffc000000f5ce90, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111b0480, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111b0480, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5600, 0x0, 0xe0000000111b07f8, 0xe0000000111b0480) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5600, 0x0, 0x9ffc000000dd7480, 0xe0000000111b0480, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe0000000111a5600, 0xe0000000111a5630, 0x0, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 taskqueue_thread_loop(0xe0000000111a5600, 0xe0000000111a5660, 0xe0000000111a565c, 0xe0000000111a5630) at taskqueue_thread_loop+0x1d0 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee1d48, 0xa0000000e2e71550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100017 td 0xe0000000111b1200 cpu_switch(0xe0000000111b1200, 0xe0000000111b0480, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111b1200, 0xe0000000111b0480, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111b1200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5900, 0x0, 0xe0000000111b1578, 0xe0000000111b1200) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5900, 0x0, 0x9ffc000000dd7480, 0xe0000000111b1200, 0x9ffc0000005a4520) at sleepq_wait+0xb0 msleep_spin_sbt(0xe0000000111a5900, 0xe0000000111a5930, 0x9ffc000000dab938, 0x0, 0x0, 0x100, 0xe0000000111a5948) at msleep_spin_sbt+0x440 taskqueue_thread_loop(0xe0000000111a5900, 0xe0000000111a5960, 0xe0000000111a595c, 0xe0000000111a5930) at taskqueue_thread_loop+0x190 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee0900, 0xa0000000e2e59550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100016 td 0xe0000000111b1680 cpu_switch(0xe0000000111b1680, 0xe0000000111b1200, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111b1680, 0xe0000000111b1200, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111b1680, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5900, 0x0, 0xe0000000111b19f8, 0xe0000000111b1680) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5900, 0x0, 0x9ffc000000dd7480, 0xe0000000111b1680, 0x9ffc0000005a4520) at sleepq_wait+0xb0 msleep_spin_sbt(0xe0000000111a5900, 0xe0000000111a5930, 0x9ffc000000dab938, 0x0, 0x0, 0x100, 0xe0000000111a5948) at msleep_spin_sbt+0x440 taskqueue_thread_loop(0xe0000000111a5900, 0xe0000000111a5960, 0xe0000000111a595c, 0xe0000000111a5930) at taskqueue_thread_loop+0x190 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee0900, 0xa0000000e2e51550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100015 td 0xe0000000111a0d80 cpu_switch(0xe0000000111a0d80, 0xe0000000111b1680, 0x9ffc000000f5cf08, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111a0d80, 0xe0000000111b1680, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111a0d80, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5900, 0x0, 0xe0000000111a10f8, 0xe0000000111a0d80) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5900, 0x0, 0x9ffc000000dd7480, 0xe0000000111a0d80, 0x9ffc0000005a4520) at sleepq_wait+0xb0 msleep_spin_sbt(0xe0000000111a5900, 0xe0000000111a5930, 0x9ffc000000dab938, 0x0, 0x0, 0x100, 0xe0000000111a5948) at msleep_spin_sbt+0x440 taskqueue_thread_loop(0xe0000000111a5900, 0xe0000000111a5960, 0xe0000000111a595c, 0xe0000000111a5930) at taskqueue_thread_loop+0x190 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee0900, 0xa0000000e2e49550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100014 td 0xe0000000111a1200 cpu_switch(0xe0000000111a1200, 0xe0000000111a0d80, 0x9ffc000000f5cf30, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe0000000111a1200, 0xe0000000111a0d80, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe0000000111a1200, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5a00, 0x0, 0xe0000000111a1578, 0xe0000000111a1200) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5a00, 0x0, 0x9ffc000000dd7480, 0xe0000000111a1200, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe0000000111a5a00, 0xe0000000111a5a30, 0x0, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 taskqueue_thread_loop(0xe0000000111a5a00, 0xe0000000111a5a60, 0xe0000000111a5a5c, 0xe0000000111a5a30) at taskqueue_thread_loop+0x1d0 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee1488, 0xa0000000e2e41550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100009 td 0xe000000011183b00 cpu_switch(0xe000000011183b00, 0xe000000011182480, 0x9ffc000000f5cfa8, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0xe000000011183b00, 0xe000000011182480, 0x9ffc000000f27118, 0x9ffc000000f27100) at sched_switch+0x890 mi_switch(0x104, 0x0, 0xe000000011183b00, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0xe0000000111a5d00, 0x0, 0xe000000011183e78, 0xe000000011183b00) at sleepq_switch+0x2e0 sleepq_wait(0xe0000000111a5d00, 0x0, 0x9ffc000000dd7480, 0xe000000011183b00, 0x9ffc0000005a4ec0) at sleepq_wait+0xb0 _sleep(0xe0000000111a5d00, 0xe0000000111a5d30, 0x0, 0x9ffc000000dab938, 0x0, 0x0, 0x100) at _sleep+0x7d0 taskqueue_thread_loop(0xe0000000111a5d00, 0xe0000000111a5d60, 0xe0000000111a5d5c, 0xe0000000111a5d30) at taskqueue_thread_loop+0x1d0 fork_exit(0x9ffc000000e3bff0, 0x9ffc000000ee1b20, 0xa0000000a07dd550) at fork_exit+0x120 enter_userland() at enter_userland Tracing command kernel pid 0 tid 100000 td 0x9ffc000000efef70 cpu_switch(0x9ffc000000efef70, 0xe000000011182900, 0x9ffc000000f5c670, 0x9ffc0000005ec410) at cpu_switch+0xd0 sched_switch(0x9ffc000000efef70, 0xe000000011182900, 0x9ffc000000f26418, 0x9ffc000000f26400) at sched_switch+0x890 mi_switch(0x104, 0x0, 0x9ffc000000efef70, 0x9ffc000000625100) at mi_switch+0x3f0 sleepq_switch(0x9ffc000000efeac8, 0x54, 0x9ffc000000eff2e8, 0x9ffc000000efef70) at sleepq_switch+0x2e0 sleepq_timedwait(0x9ffc000000efeac8, 0x54, 0x0, 0x9ffc000000dd7480, 0x9ffc000000efef70) at sleepq_timedwait+0xb0 _sleep(0x9ffc000000efeac8, 0x0, 0x54, 0x9ffc000000e0a9b8, 0x1, 0x0, 0x100) at _sleep+0x780 swapper(0x9ffc000000f014b0, 0x0, 0x9ffc000000e0a848, 0xffffffff80000000) at swapper+0x480 mi_startup(0x9ffc000000f014b0) at mi_startup+0x3a0 __start() at __start+0xd0 db> From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 15:17:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E20EA2AD for ; Tue, 15 Oct 2013 15:17:05 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A40B82E06 for ; Tue, 15 Oct 2013 15:17:05 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ht10so5194912vcb.24 for ; Tue, 15 Oct 2013 08:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BceUZ+bSCWkOeY1RS8olmXOclfurHTOLhZL18gKRxsc=; b=BhPKnmFDJmP1udw3bnB+KiBpgpWfg+WM8k3qmxWlHgthBMl+nV4FnNSjmyAbytnroa DQC4fQp6cJJNfUCEuEAlg0WArDxor5IBop2QdD7HWVXCMmwOBC5nkKP2swqsdIUl7y9j MYzJLDDQadUMq0DHo3isNbUEDDqxMiJOnB888jK7dBcsoJmBIowWYXLuRxBSaZu/73X3 y0lodxCFN3u8olNABedDxJIPmu5y28esNtXaG482AYmL/AbIV/9mMp4gD5ys+0WJWdDG Ydsqhg1I2Rxgr/2ctLHHCJbJ618QekDJwal0U8PgsYhQYrDugMUFDUbjd5WVwkQZAAk/ ifQQ== MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr1315529vcb.22.1381850224793; Tue, 15 Oct 2013 08:17:04 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.94.71 with HTTP; Tue, 15 Oct 2013 08:17:04 -0700 (PDT) In-Reply-To: <201310151417.r9FEHRe8047121@mech-cluster241.men.bris.ac.uk> References: <201310151417.r9FEHRe8047121@mech-cluster241.men.bris.ac.uk> Date: Tue, 15 Oct 2013 17:17:04 +0200 X-Google-Sender-Auth: T09ba7-rtZ1dkc_1IVbpR3IDV3c Message-ID: Subject: Re: WITNESS: unable to allocate a new witness object From: Davide Italiano To: mexas@bris.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 15:17:05 -0000 On Tue, Oct 15, 2013 at 4:17 PM, Anton Shterenlikht wrote: > I'm trying to set up textdump(4). > > On boot I see: > > WITNESS: unable to allocate a new witness object > > also It means that you run out of WITNESS object on the free list. > > Expensive timeout(9) function: 0x9ffc000000e222e0(0xa0000000009ed320) 0.002434387 s > kickstart. > It's output from DIAGNOSTIC, it's triggered when the callout handler execution time exceeds a given threshold. You can safely ignore it. Also, please stop spamming on mailing lists with new posts. They more or less all refers to the same problem. Keeps posting doesn't encourage people to look at it, neither it helps to have it solved more quickly. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 15:01:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A40438E2 for ; Tue, 15 Oct 2013 15:01:37 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4050F2C0A for ; Tue, 15 Oct 2013 15:01:36 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sweb; b=jqhi/YxKVXhxRhQBFO8jy0AYX4IHYYL4r otWLLR4KOKC2HbaoMkmQOJPJUBoA9ttKv0CA/T2+3rc1irZfGlug4NGjn1ZVEL1Y uzUsF71Y1m8Nta1OqSRDjLryxLQEUDWjQNCUoiFC8RHYkKpFnQ8aVoZSc23F4dLb yqzyM128V4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=sweb; bh=KX9O9ae1/AvSANatOWWTnMCYaySoehxZ9gHG+4o 2lwY=; b=kAZPMkPogzQCqlfA/alvDeK9MtdRUn+tpqawT6fy6vLEy6kM6msLP3S xhGbobrIhJKMDrDVP3HRfvjrApmxQh312g0dXzxIfyTewdRqX9RjHGJnaGZiDL3K ubNzyYOl3JsEbKvkMt3/iW9Htm6cKQ3nBYUqr8aLXvUvr9Rayo5k= Received: (qmail 37117 invoked from network); 15 Oct 2013 10:01:35 -0500 Received: from unknown (HELO admin.xzibition.com) (bryan@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 15 Oct 2013 10:01:35 -0500 Date: Tue, 15 Oct 2013 10:01:34 -0500 From: Bryan Drewery To: Sevan / Venture37 Subject: Re: Buildworld with ccache fails Message-ID: <20131015150133.GE98118@admin.xzibition.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="10jrOL3x2xqLmOsH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 15 Oct 2013 15:29:08 +0000 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 15:01:37 -0000 --10jrOL3x2xqLmOsH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2013 at 09:52:44AM +0400, Sevan / Venture37 wrote: > Hi, > I noticed that back in April changes had been commited to allow ccache > to build -HEAD world so give it a try again on r256380. > The build process now fails at building libc.so.7 with error > /usr/bin/ld: this linker was not configured to use sysroots > cc: error: linker command failed with exit code 1 (use -v to see invocati= on) This is a known failure. I haven't had a chance to look into what the reason is, but ccache simply doesn't work with clang right now anyway. Despite the CCACHE_CPP2 change I committed to devel/ccache, there are still some other issues as well. >=20 >=20 > Sevan / Venture37 --10jrOL3x2xqLmOsH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQJ8BAEBCgBmBQJSXVjNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNkZFQkU5OTJGNTI4MERGNDgxMTM2MkE2 RTc4MkFDMDNDOUIwQ0Y5AAoJEG54KsA8mwz5FxgQAKkLTaDmcQEjc9cKSf+xs+NP n3et5cKLFjXpn0DUcSvdvhh0Nsj5Bz5a2+LIwHPmJ/tOsebC43+zUCsUKoPbzsVi 8DuQ4dUILkM1CRhZ9ncrO8GhHGPHJd9PCh0NOXhlYKN3ix3FsrAAKu7a4K5mC5PG kYHny42WFxWCGn11c7SHFMzPE0yYQoJ/A42CW1VLkysAot5X6QdWXKCkLCN47xyw rJ+oQJzboyWCbIyn3wObfzMzxGD23YJ9uF/q3lolO77NDJlBYkH4tp1V6RbjUI/K AWLF2Ynuj8IlG+Z6tseo1bi6ZKkEu+BbegiGX0bsNqJ8My9wJ2nwz6rB1d9yzQwI 8/07gebrAsxt13vdY6iAMl82lvNE9BQ+YMbRN1mzG/GRe7XOSRet7nIrd+rqyMKl V/ua4aQ2EeYweNECYZlFywUb0are2xnNGrAT+2XoRE89StFljIsuY3k0AyC4pFf8 ThTy4YJ6Qyhhg9+TE8MxyllwqjxvTWUEJJ8NepKUElM19S/tIyAZ2MqIkU1nxz6u NoVLBxk4vUt4dscIVC/xMuaH61rRqM0EfeHzdcALH1eNKMFOxKwOzt19R2D9I4S9 hx4FfdrFKpyvJ8S6ZkRfc8PYPiEdysYQWI9JYGyEMCd+qRUUWfuTW9NgaRohiWSc S0mBjgeSlGRsVJFZKNTs =+htF -----END PGP SIGNATURE----- --10jrOL3x2xqLmOsH-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 16:21:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EC4EAD34; Tue, 15 Oct 2013 16:21:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4306023F5; Tue, 15 Oct 2013 16:21:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9FGKhWd031017; Tue, 15 Oct 2013 19:20:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9FGKhWd031017 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9FGKhfv031016; Tue, 15 Oct 2013 19:20:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Oct 2013 19:20:43 +0300 From: Konstantin Belousov To: Anton Shterenlikht Subject: Re: ia64: panic: wrong page state m 0xe00000027fcc1900 Message-ID: <20131015162043.GG3865@kib.kiev.ua> References: <201310151510.r9FFA4fH047273@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ahP6B03r4gLOj5uD" Content-Disposition: inline In-Reply-To: <201310151510.r9FFA4fH047273@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 16:21:12 -0000 --ahP6B03r4gLOj5uD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2013 at 04:10:04PM +0100, Anton Shterenlikht wrote: > This panic is always reproducible by > starting nginx, and directing the browser > to poudriere logs/bulk/ia64-default/latest/. =46rom ddb, do 'show pginfo
'. --ahP6B03r4gLOj5uD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSXWtaAAoJEJDCuSvBvK1BswgQAKMLIIYinz2naNH/hURuh+OM z1c9DXmszb0GwjldHmtOViOd74FNpzVQGF/dkR6OA+QO6YtzvBBYHeg1RtVrPtiK xbaKXxso0ca3m31KLzYPMGWg8RzmMrieljU56JXn1i+nFCup2pBQZGl4DsH1Y93M VQKKMwjrFAvV9E1v36GW+ziRd3QdmRag6toim0M6KuybXJ6y3FcMmANAKIYhjSZt GrXNTu2XVEdIegrTEdFGa7bk7k/Ux8sRDxn85GMmE6nVlwbhJFGjbC4j1Wb362j2 39cT6fNcZ20KgnXykOxnL/r5QfuJNBOLS571NWUmmnilWhe9w3l9xgASyYcypHnC tYy/QGjsdNRPjGC2szAxws6FfAWxzRxMZ4U1Y0Zx3ePJChJrDuUs/XYozSTGw1gh ey+/TzswfpuvWJKvUAn16NKo2avNk6kXgtvpPNP9xGaEqcoChFlsTYDGgOM0KjZq h1vGu1ghGGK+nocaiYDrqKmOTHJAnnFfypTxdihxpKJTye/oQ5UTmgHav3lei3Z6 +QEc9dTLgk+d4OJ8KLzT4ITVyh3IDTdX5AnZhUNlzaxpG7kpahPzfpM60G92XMsH BtYZwZKSDNDqw870GOsfby9abDraO7kJeyjZOpMJQ92hNEA0iTYnOZ2oVwfN6Fxs 6vk8Rj7K6IAft8LmblCR =U/qT -----END PGP SIGNATURE----- --ahP6B03r4gLOj5uD-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 18:15:26 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 47A131F1; Tue, 15 Oct 2013 18:15:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A2442D34; Tue, 15 Oct 2013 18:15:25 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id z12so7115718wgg.0 for ; Tue, 15 Oct 2013 11:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=BFvy5l1swFpCN0sNLb7nsOX7ZtdmmrbD/jdJJMt0A8g=; b=oKyEfksYvtwpRxTh1QgnzP2qiy1eTJEvS74CN9KLFIxGEcu9JVhWRhiMm0TdymM5yd 3cfeQqyn02VRIlnMFgYeuY5lTGatRz0q9/FpsUIr2Z4Vx177/Vkeyq1v8VCRQDi5+4CW RwvrP0iF5g/VJVxa419lunCgPfyspzV3NyffutcfVmS5U8QuQAhIymaKxplCiBrT2twp OmeakvPd2bB/w5h5ppzoF0GZaodK8fobz4oPGpqAObu0SW+jgYF0h6mT8T6I8BzL3HrI mdgjUvvP65zs+PtYgT7ISdyecLU84kxPSztSHP+OwoIw/ZcuhrEyjPqRJD2dR9JFWKJT zfwA== MIME-Version: 1.0 X-Received: by 10.180.208.80 with SMTP id mc16mr9804979wic.2.1381860924147; Tue, 15 Oct 2013 11:15:24 -0700 (PDT) Received: by 10.227.207.129 with HTTP; Tue, 15 Oct 2013 11:15:24 -0700 (PDT) In-Reply-To: <20131012001410.GA56872@funkthat.com> References: <20131011215210.GY56872@funkthat.com> <72DA2C4F-44F0-456D-8679-A45CE617F8E6@gmail.com> <20131012001410.GA56872@funkthat.com> Date: Tue, 15 Oct 2013 11:15:24 -0700 Message-ID: Subject: Re: [rfc] small bioq patch From: Maksim Yevmenkin To: Maksim Yevmenkin , Maksim Yevmenkin , "current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 18:15:26 -0000 On Fri, Oct 11, 2013 at 5:14 PM, John-Mark Gurney wrote: > Maksim Yevmenkin wrote this message on Fri, Oct 11, 2013 at 15:39 -0700: >> > On Oct 11, 2013, at 2:52 PM, John-Mark Gurney wrote= : >> > >> > Maksim Yevmenkin wrote this message on Fri, Oct 11, 2013 at 11:17 -070= 0: >> >> i would like to submit the attached bioq patch for review and >> >> comments. this is proof of concept. it helps with smoothing disk read >> >> service times and arrear to eliminates outliers. please see attached >> >> pictures (about a week worth of data) >> >> >> >> - c034 "control" unmodified system >> >> - c044 patched system >> > >> > Can you describe how you got this data? Were you using the gstat >> > code or some other code? >> >> Yes, it's basically gstat data. > > The reason I ask this is that I don't think the data you are getting > from gstat is what you think you are... It accumulates time for a set > of operations and then divides by the count... So I'm not sure if the > stat improvements you are seeing are as meaningful as you might think > they are... yes, i'm aware of it. however, i'm not aware of "better" tools. we also use dtrace and PCM/PMC. ktrace is not particularly useable for us because it does not really work well when we push system above 5 Gbps. in order to actually see any "issues" we need to push system to 10 Gbps range at least. >> >> graphs show max/avg disk read service times for both systems across 3= 6 >> >> spinning drives. both systems are relatively busy serving production >> >> traffic (about 10 Gbps at peak). grey shaded areas on the graphs >> >> represent time when systems are refreshing their content, i.e. disks >> >> are both reading and writing at the same time. >> > >> > Can you describe why you think this change makes an improvement? Unle= ss >> > you're running 10k or 15k RPM drives, 128 seems like a large number.. = as >> > that's about halve number of IOPs that a normal HD handles in a second= .. >> >> Our (Netflix) load is basically random disk io. We have tweaked the syst= em to ensure that our io path is "wide" enough, I.e. We read 1mb per disk i= o for majority of the requests. However offsets we read from are all over t= he place. It appears that we are getting into situation where larger offset= s are getting delayed because smaller offsets are "jumping" ahead of them. = Forcing bioq insert tail operation and effectively moving insertion point s= eems to help avoiding getting into this situation. And, no. We don't use 10= k or 15k drives. Just regular enterprise 7200 sata drives. > > I assume that the 1mb reads are then further broken up into 8 128kb > reads? so it's more like every 16 reads in your work load that you > insert the "ordered" io... i'm not sure where 128kb comes from. are you referring to MAXPHYS/DLFPHYS? if so, then, no, we have increased *PHYS to 1MB. > I want to make sure that we choose the right value for this number.. > What number of IOPs are you seeing? generally we see < 100 IOPs per disk on a system pushing 10+ Gbps. i've experimented with different numbers on our system and i did not see much of a difference on our workload. i'm up a value of 1024 now. higher numbers seem to produce slightly bigger difference between average and max time, but i do not think its statistically meaningful. general shape of the curve remains smooth for all tried values so far. [...] >> > Also, do you see a similar throughput of the system? >> >> Yes. We do see almost identical throughput from both systems. I have no= t pushed the system to its limit yet, but having much smoother disk read se= rvice time is important for us because we use it as one of the components o= f system health metrics. We also need to ensure that disk io request is act= ually dispatched to the disk in a timely manner. > > Per above, have you measured at the application layer that you are > getting better latency times on your reads? Maybe by doing a ktrace > of the io, and calculating times between read and return or something > like that... ktrace is not particularly useful. i can see if i can come up with dtrace probe or something. our application (or rather clients) are _very_ sensitive to latency. having read service times outliers is not very good for us. > Have you looked at the geom disk schedulers work that Luigi did a few > years back? There have been known issues w/ our io scheduler for a > long time... If you search the mailing lists, you'll see lots of > reports from some processes starving out others, probably due to a > similar issue... I've seen similar unfair behavior between processes, > but spend time tracking it down... yes, we have looked at it. it makes things worse for us, unfortunately. > It does look like a good improvement though... > > Thanks for the work! ok :) i'm interested to hear from people who have different workload profile. for example lots of iops, i.e. very small files reads or something like that. thanks, max From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 19:33:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6EE2149B for ; Tue, 15 Oct 2013 19:33:49 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F50F2277 for ; Tue, 15 Oct 2013 19:33:48 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id n4so6509534qcx.13 for ; Tue, 15 Oct 2013 12:33:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kV1AoZF4f1mqFmpZmwol/iz4TWJt5v7yn+b3DCl5lGA=; b=biLvd8HXNlyeV6p26kUOUobElV649M7607t+zCqLPJlEl8zcmAJBYy1qqr7k5BV5kt CcLCHAUr3u5gHQHcXzuOmY5vSoOdqz+2p2S9pU9K3qZxqqV49wRioS5U2zBNlfPFsCSc 5nYzy8B+gmyqSQmh5rDIIIcPMkc7zApTRfktfWo0KyCmTbgrlZwqu6rxD9981WAKXulX u0oM/kFMpFfNsxI1lA66H2p49NUC7fsrnmnqOc4Xui0pRdqsC864jNr4cQ0TVoQne7hM Q6PgM/2IlzKa85SjWE47yVKBt4yaYpKcENkMgfuVvFmjlNwt6N6/BBoy1tw68O90IsTY xGJA== X-Gm-Message-State: ALoCoQl3AvcIwh2SZAOPK8+wMWG/kV8LDkLz6YUVzqdBUqCLCbdq2b47PByBAKEn0dgbVF0SEwHO X-Received: by 10.224.137.133 with SMTP id w5mr2667156qat.24.1381865622154; Tue, 15 Oct 2013 12:33:42 -0700 (PDT) Received: from [10.1.20.109] ([50.59.37.123]) by mx.google.com with ESMTPSA id i4sm158845987qan.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 12:33:41 -0700 (PDT) Sender: Tim Kientzle Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: RFC: support for "first boot" rc.d scripts From: Tim Kientzle In-Reply-To: <525B258F.3030403@freebsd.org> Date: Tue, 15 Oct 2013 12:33:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <89D8FB48-81BA-47CD-BAB9-BB2D448DE9A2@freebsd.org> References: <525B258F.3030403@freebsd.org> To: Colin Percival X-Mailer: Apple Mail (2.1510) Cc: FreeBSD current , freebsd-rc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 19:33:49 -0000 Wonderful! This capability is long overdue. On Oct 13, 2013, at 3:58 PM, Colin Percival wrote: > As examples of what such scripts could do: More examples: I've been experimenting with putting "gpart resize" and "growfs" into rc.d scripts to construct images that can be dd'ed onto some medium and then automatically grow to fill the medium. When cross-installing ports, there are certain operations (e.g., updating 'info' database) that can really only be done after the system next boots. > I'd like to get this into HEAD in the near future in the hope that I can > convince re@ that this is a simple enough (and safe enough) change to merge > before 10.0-RELEASE. Please. Tim From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 19:35:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0AFF684D for ; Tue, 15 Oct 2013 19:35:41 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id DB99D22B7 for ; Tue, 15 Oct 2013 19:35:40 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id ACBD93E169 for ; Tue, 15 Oct 2013 19:35:38 +0000 (UTC) Message-ID: <525D9909.4070206@allanjude.com> Date: Tue, 15 Oct 2013 15:35:37 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> <89D8FB48-81BA-47CD-BAB9-BB2D448DE9A2@freebsd.org> In-Reply-To: <89D8FB48-81BA-47CD-BAB9-BB2D448DE9A2@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 19:35:41 -0000 On 2013-10-15 15:33, Tim Kientzle wrote: > Wonderful! This capability is long overdue. > > On Oct 13, 2013, at 3:58 PM, Colin Percival wrote: >> As examples of what such scripts could do: > More examples: > > I've been experimenting with putting "gpart resize" and "growfs" > into rc.d scripts to construct images that can be dd'ed onto some medium > and then automatically grow to fill the medium. I didn't think of that, that is a 'killer app' for rpi and other such devices, or any kind of 'embedded' image really > When cross-installing ports, there are certain operations > (e.g., updating 'info' database) that can really only be > done after the system next boots. > >> I'd like to get this into HEAD in the near future in the hope that I can >> convince re@ that this is a simple enough (and safe enough) change to merge >> before 10.0-RELEASE. > Please. > > Tim > > > _______________________________________________ > 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" -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 20:09:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E8C621A9; Tue, 15 Oct 2013 20:09:36 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A2AD24B6; Tue, 15 Oct 2013 20:09:36 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id wp18so2094369obc.24 for ; Tue, 15 Oct 2013 13:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DSBRA6QPZgOvduK2pIhoc2cRL3CgvCVsL/vWQ9+hPno=; b=FGPxCCtYNzsnTL1gRlLbo7dHvXETVyI6vUuGHQLm4ODqOY4wL7YJ79QQX/zBAOJ6l5 EY0YnhN6WRP8LO6s6OegFK5r15X6e656eyrilLdO0HECCBwFiRbgulAm4+0Zh+8bTGiP /EuymkASZP8mhGPRwUH0p2bHT+JL9jp39Y6jwdZoOYQb0eMWaEBozET3nrA5us/Fv58q YdHE6k42gp7++cAciatWXgRz0zccIPbwdVLA8FBrW8Ei0vgt7mNNTx/vQWttXa11YsWx WdE89mBNxoT0akbTva44sdzky0qFnpHTROYEkS/N0+4mMDgW59IfycIKngto97ti4SKN qhxA== MIME-Version: 1.0 X-Received: by 10.182.225.162 with SMTP id rl2mr97492obc.72.1381867775962; Tue, 15 Oct 2013 13:09:35 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.110.195 with HTTP; Tue, 15 Oct 2013 13:09:35 -0700 (PDT) In-Reply-To: <525B258F.3030403@freebsd.org> References: <525B258F.3030403@freebsd.org> Date: Tue, 15 Oct 2013 13:09:35 -0700 X-Google-Sender-Auth: XQAiI64w5SQZ7yGb66opGjNCl6A Message-ID: Subject: Re: RFC: support for "first boot" rc.d scripts From: Matthew Fleming To: Colin Percival Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD current , freebsd-rc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 20:09:37 -0000 On Sun, Oct 13, 2013 at 3:58 PM, Colin Percival wrote: > Hi all, > > I've attached a very simple patch which makes /etc/rc: > > 1. Skip any rc.d scripts with the "firstboot" keyword if /var/db/firstboot > does not exist, > > 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after running > rc.d > scripts, reboot. > > 3. Delete /var/db/firstboot (and firstboot-reboot) after the first boot. > We use something like this at work. However, our version creates a file after the firstboot scripts have run, and doesn't run if the file exists. Is there a reason to prefer one choice over the other? Naively I'd expect it to be better to run when the file doesn't exist, creating when done; it solves the problem of making sure the magic file exists before first boot, for the other polarity. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 20:57:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E3AB1D7 for ; Tue, 15 Oct 2013 20:57:08 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 0DCAE27DB for ; Tue, 15 Oct 2013 20:57:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=rbXRo06VLoOEhi0ed6bLCnY2dRc=; b=dcrfmhBIROZMHY0Blg yUOtsL8hsrMZHMGpNv7xPurCGbMtQMAbVZ3WJRTU3E480RKyjM6GY8WvvCPKE/0P +JZAoQ7Il+AQ9M6GE8FgCa/JF8NAKyG3aTlRjR1l+3lamxD4B5cMz9ESr6cy59q8 ST/P3HenBRL+J+IHxokF2wPPs= Received: by filter-170.sjc1.sendgrid.net with SMTP id filter-170.30926.525DAC1F7 Tue, 15 Oct 2013 20:57:03 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi19 (SG) with ESMTP id 141bde85bc7.19b4.186a20b for ; Tue, 15 Oct 2013 20:57:03 +0000 (UTC) Received: (qmail 43530 invoked from network); 15 Oct 2013 20:57:02 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 15 Oct 2013 20:57:02 -0000 Received: (qmail 4898 invoked from network); 15 Oct 2013 20:56:10 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 15 Oct 2013 20:56:10 -0000 Message-ID: <525DABE9.2060902@freebsd.org> Date: Tue, 15 Oct 2013 13:56:09 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nick Hibma Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> <525C210A.2000306@freebsd.org> <1381770007.42859.82.camel@revolution.hippie.lan> <525C41D1.3040204@freebsd.org> <6C7D69EB-204B-45B9-AD67-EBC1AB39AB8B@van-laarhoven.org> In-Reply-To: <6C7D69EB-204B-45B9-AD67-EBC1AB39AB8B@van-laarhoven.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wtiYzqTqOmZCGDXeDkMGFyDlujzvoEKFBq1usWpqTQMe9k1MViCPefx0jEJwed4RfuM1OGkHDZPYj8c8z5Twm4XjuohkN4uXIyan1JYA/77VzY= Cc: FreeBSD current , freebsd-rc@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 20:57:08 -0000 On 10/15/13 01:58, Nick Hibma wrote: >> Indeed... the way my patch currently does things, it looks for the >> firstboot sentinel at the start of /etc/rc, which means it *has* to >> be on /. Making the path an rcvar is a good idea (updated patch >> attached) but we still need some way to re-probe for that file after >> mounting extra filesystems. > > In many cases a simple > > test -f /firstboot && bla_enable='YES' || bla_enable='NO' > rm -f /firstboot > > in your specific rc.d script would suffice. [...] > I am not quite sure why we need /firstboot handling in /etc/rc. Your suggestion wouldn't work if you have several scripts doing it; the first one would remove the sentinel and the others wouldn't run. In my EC2 code I have a single script which runs after all the others and removes the sentinel file, but that still means that every script has to be executed on every boot (even if just to check if it should do anything); putting the logic into /etc/rc would allow rcorder to skip those scripts entirely. > Perhaps it is a better idea to make this more generic, to move the rc.d script containing a 'runonce' keyword to a subdirectory as the last step in rc (or make that an rc.d script in itself!). That way you could consider moving it back if you need to re-run it. Or have an rc.d script setup something like a database after installing a package by creating a rc.d runonce script. > > Default dir could be ./run-once relative to the rc.d dir it is in, configurable through runonce_directory . > > Note: The move would need to be done at the very end of rc.d to prevent rcorder returning a different ordering and skipping scripts because of that. I considered this, but decided that the most common requirement use of "run once" would be for "run when the system is first booted", and it would be much simpler to provide just the firstboot functionality. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 21:13:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB98ACA9 for ; Tue, 15 Oct 2013 21:13:13 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 615592922 for ; Tue, 15 Oct 2013 21:13:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=6r8RknqUuvzGPvYiHZqPTfK8nxg=; b=ExxYqZYQFBtIHw+sjI 9aLaOM0k3+T2Ik1AIax+Sx8spgnZ3jzspfj/2UF8D0D8iezL2eKELvjyoWIz8+8v 1arQGqiHU9cQW/DFGwy0dAHz9MJnSZtN4XDpotABPa5XkoXv7G86pVgBOByBLu3I IkA/zo/3/YLhenv44pXcS96qA= Received: by mf95 with SMTP id mf95.18612.525DAFE8D Tue, 15 Oct 2013 21:13:12 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi19 (SG) with ESMTP id 141bdf72468.19b6.78cfc7 for ; Tue, 15 Oct 2013 21:13:12 +0000 (UTC) Received: (qmail 44063 invoked from network); 15 Oct 2013 21:13:11 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 15 Oct 2013 21:13:11 -0000 Received: (qmail 4982 invoked from network); 15 Oct 2013 21:12:18 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 15 Oct 2013 21:12:18 -0000 Message-ID: <525DAFB2.7090105@freebsd.org> Date: Tue, 15 Oct 2013 14:12:18 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Matthew Fleming Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wtiC5aytoRlDlGZt/AIqARa7Z1CZbI1JAGC4I/G9G+C+xj2Ky77ib+wrHy2KQ3wPSLSjWSlLuAYNrbDWISVlG5HurM3Ah1xYSrMdV4Z74Ec4QE= Cc: FreeBSD current , freebsd-rc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 21:13:13 -0000 On 10/15/13 13:09, Matthew Fleming wrote: > We use something like this at work. However, our version creates a file after > the firstboot scripts have run, and doesn't run if the file exists. > > Is there a reason to prefer one choice over the other? Naively I'd expect it to > be better to run when the file doesn't exist, creating when done; it solves the > problem of making sure the magic file exists before first boot, for the other > polarity. I don't see that making sure that the magic file exists is a problem, since you'd also need to make sure you have knobs turned on in /etc/rc.conf and/or extra rc.d scripts installed. In a very marginal sense, deleting a file is safer than creating one, since if the filesystem is full you can delete but not create. It also seems to me that the sensible polarity is that having something extra lying around makes extra things happen rather than inhibiting them. But probably the best argument has to do with upgrading systems -- if you update a 9.2-RELEASE system to 10.1-RELEASE and there's a "first boot" script in that new release, you don't want to have it accidentally get run simply because you failed to create a /firstboot file during the upgrade process. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 21:19:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC55F165; Tue, 15 Oct 2013 21:19:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DD32296C; Tue, 15 Oct 2013 21:19:39 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 612EDB980; Tue, 15 Oct 2013 17:19:38 -0400 (EDT) From: John Baldwin To: freebsd-ia64@freebsd.org, mexas@bris.ac.uk Subject: Re: panic: uma_zfree: Freeing to non free bucket index. Date: Tue, 15 Oct 2013 17:10:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201310140844.r9E8iSYM015098@mech-cluster241.men.bris.ac.uk> In-Reply-To: <201310140844.r9E8iSYM015098@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310151710.02551.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Oct 2013 17:19:38 -0400 (EDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 21:19:39 -0000 On Monday, October 14, 2013 4:44:28 am Anton Shterenlikht wrote: > > BTW, I see in dmesg: > > Starting ddb. > ddb: sysctl: debug.ddb.scripting.scripts: Invalid argument > /etc/rc: WARNING: failed to start ddb > > What is that about? > > > panic: uma_zfree: Freeing to non free bucket index. > cpuid = 0 > KDB: stack backtrace: > db_trace_self(0x9ffc000000158380) at db_trace_self+0x40 > db_trace_self_wrapper(0x9ffc000000607370) at db_trace_self_wrapper+0x70 > kdb_backtrace(0x9ffc000000ed0e10, 0x9ffc00000058e660, 0x40c, 0x9ffc0000010a44a0) at kdb_backtrace+0xc0 > vpanic(0x9ffc000000dfc468, 0xa0000000e26e0fd8, 0x9ffc000000ef9670, 0x9ffc000000ed0bc0) at vpanic+0x260 > kassert_panic(0x9ffc000000dfc468, 0xe000000015e25f90, 0xe000000015e243e0, 0xe00000027ffd5200) at kassert_panic+0x120 > uma_zfree_arg(0xe00000027ffccfc0, 0xe000000015e243e0, 0x0) at uma_zfree_arg+0x2d0 > g_destroy_bio(0xe000000015e243e0, 0x9ffc0000004ad4a0, 0x30a, 0x30a) at g_destroy_bio+0x30 > g_disk_done(0xe000000015e243e0, 0xe000000015e15d10, 0xe000000012672700, 0x9ffc0000006b18c0) at g_disk_done+0x140 > biodone(0xe000000015e243e0, 0x9ffc000000e0e150, 0xe000000010c24030, 0x0, 0x0, 0x0, 0x9ffc000000066890, 0x614) at biodone+0x180 > dadone(0xe000000012672600, 0xe000000012541000, 0xe000000015e243e0, 0x7) at dadone+0x620 > camisr_runqueue(0xe000000011a2dc00, 0xe000000012541054, 0xe000000012541000, 0x135d) at camisr_runqueue+0x6c0 > camisr(0xe000000011a2dc20, 0xe000000011a2dc00, 0x9ffc000000bee9d0, 0xa0000000e26e1548) at camisr+0x260 > intr_event_execute_handlers(0xe0000000111764a0, 0xe00000001118d998, 0xe000000011191c00, 0x0) at intr_event_execute_handlers+0x280 > ithread_loop(0xe000000011192f00, 0xa0000000e26e1550, 0xe000000011192f14, 0xe00000001118d99c) at ithread_loop+0x1b0 > fork_exit(0x9ffc000000e12a90, 0xe000000011192f00, 0xa0000000e26e1550) at fork_exit+0x120 > enter_userland() at enter_userland > KDB: enter: panic > [ thread pid 12 tid 100015 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2c990,gp ;; > db> > > db> scripts > lockinfo=show locks; show alllocks; show lockedvnods > db> run lockinfo > db:0:lockinfo> show locks > db:0:locks> show alllocks > db:0:alllocks> show lockedvnods > Locked vnodes > > 0xe00000001ab39ba8: tag ufs, type VDIR > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags (VI_ACTIVE) > v_object 0xe00000001cd30900 ref 0 pages 0 > lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 100121) > ino 5467932, on dev da5p1 > > 0xe000000015ed3ba8: tag ufs, type VDIR > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags (VI_ACTIVE) > v_object 0xe00000001cd33e00 ref 0 pages 0 > lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 100092) > ino 5467948, on dev da5p1 > > 0xe00000001ab16938: tag ufs, type VREG > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags (VI_ACTIVE) > v_object 0xe00000001cd98a00 ref 0 pages 1 > lock type ufs: EXCL by thread 0xe000000018494000 (pid 41337, cpdup, tid 100137) > ino 5469420, on dev da5p1 > > 0xe00000001b2503b0: tag ufs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 100092) > ino 5469421, on dev da5p1 > > 0xe00000001ab2a760: tag ufs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 100121) > ino 5469422, on dev da5p1 > db> > db> script zzz=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; reset > db> run zzz I think 'reset' is going to reset without doing a dump? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 23:03:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B0DFA75 for ; Tue, 15 Oct 2013 23:03:48 +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 6387E2EAC for ; Tue, 15 Oct 2013 23:03:47 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id 1488F1CE002 for ; Tue, 15 Oct 2013 17:54:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnDyHODGcY61 for ; Tue, 15 Oct 2013 17:54:29 -0500 (CDT) Received: from [10.0.2.15] (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mail.jrv.org (Postfix) with ESMTPSA id 4D1611CE001 for ; Tue, 15 Oct 2013 17:54:28 -0500 (CDT) Message-ID: <525DC662.6030002@jrv.org> Date: Tue, 15 Oct 2013 17:49:06 -0500 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Please shorten ZFS disk names. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 23:03:48 -0000 BLACKIE:/root# uname -a FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M: Sun Oct 13 23:46:54 CDT 2013 root@CLANK.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 This pool is on da{0,1,2,3,4,5,6,7} - I think, only da4 is sure NAME STATE READ WRITE CKSUM z03 ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HSTK ONLINE 0 0 0 da4 ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HTCQ ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300JDT5 ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HTCE ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HTS7 ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300JBN1 ONLINE 0 0 0 diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HTAP ONLINE 0 0 0 another example: BLACKIE:/usr/src# zpool status pool: BLACKIE state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM BLACKIE ONLINE 0 0 0 gptid/3d882ab0-3588-11e3-b6bc-002590c08004 ONLINE 0 0 0 Based on the hardware config that's either ada0p3 or ada1p3. Whichever it is I want to mirror it onto the other but I don't the names to use for src and dst. From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 23:07:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F35DCBB8; Tue, 15 Oct 2013 23:07:50 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CAD2D2ED3; Tue, 15 Oct 2013 23:07:50 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id B5251B9E8; Tue, 15 Oct 2013 23:07:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us B5251B9E8 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Oct 2013 19:07:47 -0400 From: Glen Barber To: "James R. Van Artsdalen" Subject: Re: Please shorten ZFS disk names. Message-ID: <20131015230747.GT23579@glenbarber.us> References: <525DC662.6030002@jrv.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6h64vBu9tReNbGLX" Content-Disposition: inline In-Reply-To: <525DC662.6030002@jrv.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 23:07:51 -0000 --6h64vBu9tReNbGLX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2013 at 05:49:06PM -0500, James R. Van Artsdalen wrote: > BLACKIE:/root# uname -a > FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M: > Sun Oct 13 23:46:54 CDT 2013 =20 > root@CLANK.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > This pool is on da{0,1,2,3,4,5,6,7} - I think, only da4 is sure >=20 > NAME =20 > STATE READ WRITE CKSUM > z03 =20 > ONLINE 0 0 0 > raidz2-0 =20 > ONLINE 0 0 0 > diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HSTK=20 > > [...] > > Based on the hardware config that's either ada0p3 or ada1p3. Whichever > it is I want to mirror it onto the other but I don't the names to use > for src and dst. You can set kern.geom.label.gptid.enable=3D0 in loader.conf(5), which will use the gptid. Glen --6h64vBu9tReNbGLX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSXcrDAAoJELls3eqvi17QD3MP/2O3jw0IbtVj5mVVGJCpIfOf ySh9tUJ2Ds3e3u07hpI/NHPKPOF6QClJGOn4EZ0FRvczIxe0C1esFtx0urW1Yj2p 918EcS2DMOlgdfbIGVaUtuIPG/ru+5D4Af6Druy6vCcYKXp9RpF0aerU9ndQqzn9 8YQD8Pz+FajbVuGL2GjiRNU0B3nL19lnYsPVsJBkLGMWcba+Ix+6IzLa8zJ4KCLd absccCrZtc/s7c8sJlNaJu4t0P1GtvbSpCHOy1olkASlMqSBFiiuaXsS4RiDD56u WquTMmf3BqlY4OQIKFG9YEMhNQv9rJc7Rg7TFcOduUd1T3iTjXkxwxTM4MHgFjma XpZbWexNL482yiMcetlNFdpUJnvW8oVrI/Gvwrl/C1pA8dR/Nk9wXFgAgY/B0tTf eNrh9kS3QilumLaWBIZxgi7HmFSI3bBff7/6u1Mm3zLqFpXdAh/y0WyD3oyqVjhe WjJdJp8uq5C94J3MNU8//x6arG4dIqZlaGVpIQ5nf0THsDQTL+/9HQky1jtJPV6C kvJLkwnO4USNDEKxSA3hiI+t7lP5Izphf1aktP2lkvv/dEKMMuZROJeShl8oF8EP HznPNOV2cCYtzBQZ6Q4AOTzGsniSC/0TXF5niNeBIz1FAW7LcdnAmw7ZYlqbceQo p6S+IwbHZ4okT6v1Y1np =7ZXx -----END PGP SIGNATURE----- --6h64vBu9tReNbGLX-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 15 23:09:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3EAC4D04; Tue, 15 Oct 2013 23:09:48 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14D5C2EF6; Tue, 15 Oct 2013 23:09:48 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 0D270BA32; Tue, 15 Oct 2013 23:09:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 0D270BA32 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 15 Oct 2013 19:09:45 -0400 From: Glen Barber To: "James R. Van Artsdalen" Subject: Re: Please shorten ZFS disk names. Message-ID: <20131015230945.GU23579@glenbarber.us> References: <525DC662.6030002@jrv.org> <20131015230747.GT23579@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="L+ytD9kXoSFEJYhc" Content-Disposition: inline In-Reply-To: <20131015230747.GT23579@glenbarber.us> X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 15 Oct 2013 23:09:48 -0000 --L+ytD9kXoSFEJYhc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2013 at 07:07:47PM -0400, Glen Barber wrote: > > Based on the hardware config that's either ada0p3 or ada1p3. Whichever > > it is I want to mirror it onto the other but I don't the names to use > > for src and dst. >=20 > You can set kern.geom.label.gptid.enable=3D0 in loader.conf(5), which will > use the gptid. >=20 Which will *not* use the gptid... Glen --L+ytD9kXoSFEJYhc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSXcs5AAoJELls3eqvi17QJ/0P/1vOCwjc3EjxdEMIjGNo+R+6 QoyL8vQaCoUtG5j+/kyqJ9FagsAJhuQ4DAT9LpD+ZjjUIlBq9hmzWAYUgXQiTKpv vegp8J900CgTOzQ0bXi69QVBPqql75Dkl27H4S0j9dD1Yg6qVmH/5D7Zkn9pW4y+ BqCvpMezs0VgkxIXHbk1R1QCNHe6yMa6HzOhPhySRFojdgAf3SwStpS8YdSReLb1 LGv1W0biEv54ARXbIb/2EM9aIgQyUqBB47hPDwEpsj9x39E4l2uURtrTWsPJl0qr zMXoQfJIFRgNMGdiYfFH1D0iyhxYsny+nsTvRoaCi87B2i76OEHceP/GMzIJjjsX bAJZILhXMCi22j4vYJGCrkv5kJBn/i8UEWxmtksZk0i3HKKtODQTfxHnu+ZMkkI7 m/jvczXKxXoknMu5Qw6wZSXncsvW6lO/ZR8rTqdb5vaW5IzjxQ1QYpwzY21oxJie zJHl2IjS0ZgBC6fzrgh2FZ2LStY/wihX6rKLIHi0V8oTkn7iVXEPI+rfpGg6McSM 3oJl9GHxjGbGi4L4wb3eklcwn5Ux81klaxcYOuMe1e23+UKSXRBy8nA1JdqS828f /MiwhwLgYdVxTEYBA+wYDZ9bWl2wjigTDfFVjk+InsdXNjQKuVncMdzZaBDfzB2n LHZ0ZoWSE7VM3j8gBxdh =NwE6 -----END PGP SIGNATURE----- --L+ytD9kXoSFEJYhc-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 00:05:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5249A0F for ; Wed, 16 Oct 2013 00:05:30 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id A1A8D21DA for ; Wed, 16 Oct 2013 00:05:30 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id CCD9E3E790 for ; Wed, 16 Oct 2013 00:05:28 +0000 (UTC) Message-ID: <525DD847.4080209@allanjude.com> Date: Tue, 15 Oct 2013 20:05:27 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Please shorten ZFS disk names. References: <525DC662.6030002@jrv.org> <20131015230747.GT23579@glenbarber.us> In-Reply-To: <20131015230747.GT23579@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 00:05:30 -0000 On 2013-10-15 19:07, Glen Barber wrote: > On Tue, Oct 15, 2013 at 05:49:06PM -0500, James R. Van Artsdalen wrote: >> BLACKIE:/root# uname -a >> FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M: >> Sun Oct 13 23:46:54 CDT 2013 >> root@CLANK.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 >> >> This pool is on da{0,1,2,3,4,5,6,7} - I think, only da4 is sure >> >> NAME >> STATE READ WRITE CKSUM >> z03 >> ONLINE 0 0 0 >> raidz2-0 >> ONLINE 0 0 0 >> diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HSTK >> >> [...] >> >> Based on the hardware config that's either ada0p3 or ada1p3. Whichever >> it is I want to mirror it onto the other but I don't the names to use >> for src and dst. > You can set kern.geom.label.gptid.enable=0 in loader.conf(5), which will > use the gptid. > > Glen > In this case, it is the disk_ident that is being used, not the GPT label, so you want to set: kern.geom.label.disk_ident.enable=0 in /boot/loader.conf and then zfs won't see that device alias, and will show the expected device name -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 01:07:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58AAE582 for ; Wed, 16 Oct 2013 01:07:08 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC036248E for ; Wed, 16 Oct 2013 01:07:07 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBF932.dip0.t-ipconnect.de [93.203.249.50]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r9G174OW028418 for ; Wed, 16 Oct 2013 01:07:05 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r9G16uFQ038397 for ; Wed, 16 Oct 2013 03:06:57 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r9G16oUu009317 for ; Wed, 16 Oct 2013 03:06:56 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310160106.r9G16oUu009317@fire.js.berklix.net> Subject: Re: vi drop outs with "Bus error" From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 14 Oct 2013 08:33:35 +0200." <201310140633.r9E6XZFV054096@fire.js.berklix.net> Date: Wed, 16 Oct 2013 03:06:49 +0200 Sender: jhs@berklix.com Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 01:07:08 -0000 Hi, Reference: > From: "Julian H. Stacey" > Date: Mon, 14 Oct 2013 08:33:35 +0200 "Julian H. Stacey" wrote: > Anyone else seeing vi dropping out after a while with "Bus error" & no core ? > > Seen on 10.0-ALPHA4 & now on 10.0-ALPHA5 > (after buildkernel installkernel buildworld installworld ) > > It's not hardware, the laptop is stable & has compiled 594 ports so far, > cd /usr/bin ; ls -l nvi* > -r-xr-xr-x 1 root wheel 402064 Oct 12 02:42 nvi.4* > -r-xr-xr-x 1 root wheel 402432 Oct 12 02:42 nvi.5* > file nvi* > nvi.4: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically \ > linked (uses shared libs), for FreeBSD 10.0 (1000055), stripped > nvi.5: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically \ > linked (uses shared libs), for FreeBSD 10.0 (1000055), stripped I'm no longer seeing drop outs with "Bus error", instead, after xterm -sl 1024 -g 80x24 -j -n lapr -e rlogin -D 10beta1host & vi freezes within the xterm after I do an X11 mouse resize (maybe that same SIGWINCH was causing Bus Error before, as resize I tend to do a lot without remembering :-) Anyone else see it ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 04:06:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AF79A350 for ; Wed, 16 Oct 2013 04:06:04 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F8832D74 for ; Wed, 16 Oct 2013 04:06:04 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 5AA9F42C087F for ; Wed, 16 Oct 2013 06:05:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 15 Oct 2013 22:57:40 -0500 (CDT) From: Bryan Venteicher To: FreeBSD current mailing list Message-ID: <73612885.53105.1381895860349.JavaMail.root@daemoninthecloset.org> In-Reply-To: <56667278.53010.1381894780662.JavaMail.root@daemoninthecloset.org> Subject: amd64 minidump slowness MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_53103_1768140454.1381895860347" X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC29 ([unknown])/8.0.2_GA_5569) Thread-Topic: amd64 minidump slowness Thread-Index: krxmb8oT1gz/OMKPcM9pIMjd6o6Utw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 04:06:04 -0000 ------=_Part_53103_1768140454.1381895860347 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, At $JOB, we have machines with 400GB RAM that even the smallest 15GB amd64 minidump takes well over an hour. The major cause of the slowness is that in minidumpsys(), blk_write() is called PAGE_SIZE at a time. This causes blk_write() to poll the console for the Ctrl-C abort once per page. The attached patch changes blk_write() to be called with a run of physically contiguous pages. This reduced the dump time by over a magnitude. Of course, blk_write() could also be changed to poll the console less frequently (like only on every IO). If anybody else dumps on machines with lots of RAM, it would be nice to know the difference this patch makes. I've got a second set of patches that further reduces the dump time by over half that I'll try to clean up soon. http://people.freebsd.org/~bryanv/patches/minidump.patch ------=_Part_53103_1768140454.1381895860347 Content-Type: text/x-patch; name=minidump.patch Content-Disposition: attachment; filename=minidump.patch Content-Transfer-Encoding: base64 Y29tbWl0IDI1ZjllODJlNGFjOTNlNzFjNmNmMDZmZTJmYWExODk5OTY3ZGI3MjUKQXV0aG9yOiBC cnlhbiBWZW50ZWljaGVyIDxicnlhbnZlbnRlaWNoZXJAZ21haWwuY29tPgpEYXRlOiAgIFN1biBT ZXAgMjkgMTM6NTY6NDIgMjAxMyAtMDUwMAoKICAgIENhbGwgYmxrX3dyaXRlKCkgd2l0aCBhIHJ1 biBvZiBwaHlzaWNhbGx5IGNvbnRpZ3VvdXMgcGFnZXMKICAgIAogICAgUHJldmlvdXNseSwgYmxr X3dyaXRlKCkgd2FzIGJlaW5nIGNhbGxlZCBvbmUgcGFnZSBhdCBhIHRpbWUsIHdoaWNoCiAgICB3 b3VsZCBjYXVzZSBpdCB0byBwb2xsIHRoZSBjb25zb2xlIGZvciBldmVyeSBwYWdlLiBUaGlzIGNo YW5nZSBtYWtlcwogICAgZHVtcGluZyBhIG1hZ25pdHVkZSBmYXN0ZXIsIGFuZCBpcyBlc3BlY2lh bGx5IHVzZWZ1bCBvbiBsYXJnZSBtZW1vcnkKICAgIG1hY2hpbmVzLgoKZGlmZiAtLWdpdCBhL3N5 cy9hbWQ2NC9hbWQ2NC9taW5pZHVtcF9tYWNoZGVwLmMgYi9zeXMvYW1kNjQvYW1kNjQvbWluaWR1 bXBfbWFjaGRlcC5jCmluZGV4IGYxNGM1MzkuLjI2YjJiMzEgMTAwNjQ0Ci0tLSBhL3N5cy9hbWQ2 NC9hbWQ2NC9taW5pZHVtcF9tYWNoZGVwLmMKKysrIGIvc3lzL2FtZDY0L2FtZDY0L21pbmlkdW1w X21hY2hkZXAuYwpAQCAtMjIxLDcgKzIyMSw4IEBAIG1pbmlkdW1wc3lzKHN0cnVjdCBkdW1wZXJp bmZvICpkaSkKIAl2bV9vZmZzZXRfdCB2YTsKIAlpbnQgZXJyb3I7CiAJdWludDY0X3QgYml0czsK LQl1aW50NjRfdCAqcG1sNCwgKnBkcCwgKnBkLCAqcHQsIHBhOworCXVpbnQ2NF90ICpwbWw0LCAq cGRwLCAqcGQsICpwdCwgc3RhcnRfcGEsIHBhOworCXNpemVfdCBzejsKIAlpbnQgaSwgaWksIGos IGssIG4sIGJpdDsKIAlpbnQgcmV0cnlfY291bnQ7CiAJc3RydWN0IG1pbmlkdW1waGRyIG1kaGRy OwpAQCAtNDEyLDE4ICs0MTMsMjkgQEAgbWluaWR1bXBzeXMoc3RydWN0IGR1bXBlcmluZm8gKmRp KQogCX0KIAogCS8qIER1bXAgbWVtb3J5IGNodW5rcyAqLwotCS8qIFhYWCBjbHVzdGVyIGl0IHVw IGFuZCB1c2UgYmxrX2R1bXAoKSAqLwotCWZvciAoaSA9IDA7IGkgPCB2bV9wYWdlX2R1bXBfc2l6 ZSAvIHNpemVvZigqdm1fcGFnZV9kdW1wKTsgaSsrKSB7CisJZm9yIChpID0gMCwgc3RhcnRfcGEg PSAwLCBzeiA9IDA7CisJICAgICBpIDwgdm1fcGFnZV9kdW1wX3NpemUgLyBzaXplb2YoKnZtX3Bh Z2VfZHVtcCk7IGkrKykgewogCQliaXRzID0gdm1fcGFnZV9kdW1wW2ldOwogCQl3aGlsZSAoYml0 cykgewogCQkJYml0ID0gYnNmcShiaXRzKTsKIAkJCXBhID0gKCgodWludDY0X3QpaSAqIHNpemVv Zigqdm1fcGFnZV9kdW1wKSAqIE5CQlkpICsgYml0KSAqIFBBR0VfU0laRTsKLQkJCWVycm9yID0g YmxrX3dyaXRlKGRpLCAwLCBwYSwgUEFHRV9TSVpFKTsKLQkJCWlmIChlcnJvcikKLQkJCQlnb3Rv IGZhaWw7CisJCQlpZiAoc3ogPT0gMCB8fCBzdGFydF9wYSArIHN6ID09IHBhKSB7CisJCQkJaWYg KHN6ID09IDApCisJCQkJCXN0YXJ0X3BhID0gcGE7CisJCQkJc3ogKz0gUEFHRV9TSVpFOworCQkJ fSBlbHNlIHsKKwkJCQllcnJvciA9IGJsa193cml0ZShkaSwgMCwgc3RhcnRfcGEsIHN6KTsKKwkJ CQlpZiAoZXJyb3IpCisJCQkJCWdvdG8gZmFpbDsKKwkJCQlzdGFydF9wYSA9IHBhOworCQkJCXN6 ID0gUEFHRV9TSVpFOworCQkJfQogCQkJYml0cyAmPSB+KDF1bCA8PCBiaXQpOwogCQl9CiAJfQor CWVycm9yID0gYmxrX3dyaXRlKGRpLCAwLCBzdGFydF9wYSwgc3opOworCWlmIChlcnJvcikKKwkJ Z290byBmYWlsOwogCiAJZXJyb3IgPSBibGtfZmx1c2goZGkpOwogCWlmIChlcnJvcikK ------=_Part_53103_1768140454.1381895860347-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 05:42:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41FB498C; Wed, 16 Oct 2013 05:42:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13D6E21DE; Wed, 16 Oct 2013 05:42:18 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id bj1so538006pad.35 for ; Tue, 15 Oct 2013 22:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nVe32dZ/C9Rt5zHqCky1HsIGL0BzLQF0RnfMNqmbrBk=; b=w0Kg0rO0a17AOHRPfvwloK0/FkJXiRyAuGJvgy/GOlZnaPfgHKzdASWDK0Gcqz/4fJ vbsh66dmblNLEt0DRORlV1G8QONV5COYX4CkOLB3Nsof4izS5TJJEU9sZ+En0ZsAB9Uo j28tdVLPjcqB/XHFz9ysQ54xAS7/PZ7jChs7z+CHjQ9W8e93h3izf9e6XxXqkOEQLxom CUF9KqC889lM7sHggkojhZcP19bpfruMj0OsuYPXhX0xD1cHvobThgzbKY3jNMeEETgn krKscCKrPaKUp0pY6PlQzlJV9KwU0PdJteQf2KBBnuICZO+Gyu0zqnOzMFrdaf0chz0V tPRA== MIME-Version: 1.0 X-Received: by 10.66.66.42 with SMTP id c10mr1683855pat.98.1381902137600; Tue, 15 Oct 2013 22:42:17 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.23.101 with HTTP; Tue, 15 Oct 2013 22:42:17 -0700 (PDT) In-Reply-To: <525B3F33.4030103@freebsd.org> References: <0E.82.01315.25778525@cdptpa-oedge03> <20131011221302.GH1611@albert.catwhisker.org> <54.9B.16944.480B8525@cdptpa-oedge02> <20131012022825.GJ1611@albert.catwhisker.org> <525B3F33.4030103@freebsd.org> Date: Tue, 15 Oct 2013 22:42:17 -0700 X-Google-Sender-Auth: 27xeB266SYCOjbId3w0UeDgLi6A Message-ID: Subject: Re: What happened to nslookup? From: Kevin Oberman To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 05:42:18 -0000 On Sun, Oct 13, 2013 at 5:47 PM, Julian Elischer wrote: > On 10/12/13 10:28 AM, David Wolfskill wrote: > >> On Sat, Oct 12, 2013 at 02:14:28AM +0000, Thomas Mueller wrote: >> >>> ... >>> Thanks for info! >>> >> Glad to help. >> >> I saw that bind was removed from the current branch because of security >>> problems, >>> >> It was removed, but I believe that there was a bit more to it than >> "security problems." >> > I think it was just a personal preference that managed to get communicated > as "important", and no-one had the energy or will to argue about it. > (that's the way software projects often work.. loudest and most persistent > voice wins). > > > but didn't know nslookup was part of BIND. >>> >>> Now I see in $PORTSDIR/dns/bind-tools/pkg-**plist >>> >>> bin/dig >>> bin/host >>> bin/nslookup >>> >>> so host is also part of BIND? >>> >> :-} The version of host we had when BIND was part of base was part of >> BIND, yes. Looking in src/usr.bin/host/Makefile, I see: >> >> # $FreeBSD: head/usr.bin/host/Makefile 255949 2013-09-30 17:23:45Z des $ >> >> LDNSDIR= ${.CURDIR}/../../contrib/ldns >> LDNSHOSTDIR= ${.CURDIR}/../../contrib/ldns-**host >> ... >> >> which indicates that this is a re-implementation of "host" as >> provided by contrib/ldns. >> >> I will remember to use "host" in the future. >>> >> I have found it generally easy to use (easier by far than nslookup). >> >> Peace, >> david >> > > nslookup(1) was deprecated about a decade ago because it often provides misleading results when used for DNS troubleshooting. It generally works fine for simply turning a name to an address or vice-versa. People should really use host(1) for simple lookups. It provides the same information and does it in a manner that will not cause misdirection when things are broken. If you REALLY want to dig (sorry) into DNS behavior or problems, learn to use dig(1). It does the same as host(1) or nslookup(1) in it's simplest form but has an extremely large number of options to adjust the query in a variety of ways to allow real analysis of DNS behavior. I'd love to see nslookup simply vanish, but I expect it to be around and causing grief until the day I die (which I hope will still e at least a couple of decades down the road.) -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 06:14:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0CE934E for ; Wed, 16 Oct 2013 06:14:02 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9B39F2391 for ; Wed, 16 Oct 2013 06:14:02 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:cc06:2a39:6ee5:601f] (unknown [IPv6:2601:9:4d00:119:cc06:2a39:6ee5:601f]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 069A039821; Tue, 15 Oct 2013 23:13:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Subject: Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter From: Rui Paulo In-Reply-To: <201310081742.r98HfbBV055077@fire.js.berklix.net> Date: Tue, 15 Oct 2013 23:13:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <589BAB21-30E9-4750-A345-BE7AB1116F48@FreeBSD.org> References: <201310081742.r98HfbBV055077@fire.js.berklix.net> To: "Julian H. Stacey" X-Mailer: Apple Mail (2.1812) Cc: Alfred Perlstein , "freebsd-current@freebsd.org bsd" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 06:14:02 -0000 On 8 Oct 2013, at 10:41, Julian H. Stacey wrote: > I too am seeing > urtwn0: timeout waiting for checksum report Sorry, this is a know problem that I haven't been able to figure out... = It probably exists in the OpenBSD driver as well. Usually retrying = works. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 08:01:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6272A57; Wed, 16 Oct 2013 08:01:09 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B84328AA; Wed, 16 Oct 2013 08:01:09 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VWM2O-0007Ll-3Y ; Wed, 16 Oct 2013 11:01:00 +0300 Date: Wed, 16 Oct 2013 11:01:00 +0300 From: Vitalij Satanivskij To: Dmitriy Makarov Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131016080100.GA27758@hell.ukr.net> References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Justin T. Gibbs" , Steven Hartland , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 08:01:09 -0000 Hello. Patch brocke cache functionality. Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 With subject ZFS L2ARC - incorrect size and abnormal system load on r255173 As patch alredy in head and BETA it's not good. Yesterday we update one machine up to beta1 and forgot about patch. So 12 Hours and cache broken... :(( Dmitriy Makarov wrote: DM> The attached patch by Steven Hartland fixes issue for me too. Thank you! DM> DM> DM> --- Èñõîäíîå ñîîáùåíèå --- DM> Îò êîãî: "Steven Hartland" < killing@multiplay.co.uk > DM> Äàòà: 18 ñåíòÿáðÿ 2013, 01:53:10 DM> DM> ----- Original Message ----- DM> From: "Justin T. Gibbs" < DM> DM> --- DM> Äìèòðèé Ìàêàðîâ DM> _______________________________________________ DM> freebsd-current@freebsd.org mailing list DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current DM> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 08:02:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 12A97B81 for ; Wed, 16 Oct 2013 08:02:30 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog113.obsmtp.com (eu1sys200aog113.obsmtp.com [207.126.144.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6385A28BE for ; Wed, 16 Oct 2013 08:02:29 +0000 (UTC) Received: from mail-we0-f180.google.com ([74.125.82.180]) (using TLSv1) by eu1sys200aob113.postini.com ([207.126.147.11]) with SMTP ID DSNKUl5IDozbxXneN+SNK9ZDnzUf3k61+AId@postini.com; Wed, 16 Oct 2013 08:02:29 UTC Received: by mail-we0-f180.google.com with SMTP id q59so308397wes.39 for ; Wed, 16 Oct 2013 01:02:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to :in-reply-to; bh=oHA9i1H80oXi/8v0NjKqPT6f53tUtyhZonIIQz6jT1E=; b=JScJLDLlHb5QmYLXVWkS9anwDl9EjNvydCJwC2KSYMx1+UZHCRB34421VnXfIsXzh9 1xlhQ9H9wMe6hpyZK6Ok7JiY+4xqvIoqVWjlQZ6/LsNaZ8OuQcJd8Ajjg01s/W1g6xTu 40q94pFC8xo6YguO+cZNGRMusage1ciU1cau+0HBBt4t9LlDV2IOrYTDu5vWg50mlNIM nFgokh5fanVK8HBOP7NdekrhfG3afN7khS7Vf+p2e4hCb3G5ejPZK3UOFSc5v5TzHePW zbmlxvMJbt/JeXrA6V7+0Dsj/EE0HECRdUGIfsR2URCCjdQ9yc3RP8M6tLv/Gn52Yd5t qgPQ== X-Gm-Message-State: ALoCoQk2xGwMVPCPQqsds3+7dygpNlhU8IRfcHcm8RCn7+cVRlgcz/S4/tXwYauSRE2XiafXdYs62gbDgjFfHr4LjB6rJleSC7g93N43t4c31NK44M33w2ZJ4f/P9dqN6F20/VIs49BghO98fuevh/J7NtD5f2s2Dos/5WHeS39ElGmvjEmR9hE= X-Received: by 10.180.38.72 with SMTP id e8mr1183099wik.0.1381910542625; Wed, 16 Oct 2013 01:02:22 -0700 (PDT) X-Received: by 10.180.38.72 with SMTP id e8mr1183091wik.0.1381910542558; Wed, 16 Oct 2013 01:02:22 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id jf2sm3363417wic.2.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 01:02:21 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9G82Ja6010220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Oct 2013 09:02:19 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9G82JvJ010219; Wed, 16 Oct 2013 09:02:19 +0100 (BST) (envelope-from mexas) Date: Wed, 16 Oct 2013 09:02:19 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310160802.r9G82JvJ010219@mech-cluster241.men.bris.ac.uk> To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:02:30 -0000 panic: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182999 deadlock: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/183007 Anton From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 08:15:25 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30D70FB0; Wed, 16 Oct 2013 08:15:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9BA5296C; Wed, 16 Oct 2013 08:15:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9G85iD4087500; Wed, 16 Oct 2013 04:05:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9G85i8U087499; Wed, 16 Oct 2013 08:05:44 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Oct 2013 08:05:44 GMT Message-Id: <201310160805.r9G85i8U087499@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:15:25 -0000 TB --- 2013-10-16 04:39:11 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-16 04:39:11 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-16 04:39:11 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-10-16 04:39:11 - cleaning the object tree TB --- 2013-10-16 04:39:11 - /usr/local/bin/svn stat /src TB --- 2013-10-16 04:39:15 - At svn revision 256557 TB --- 2013-10-16 04:39:16 - building world TB --- 2013-10-16 04:39:16 - CROSS_BUILD_TESTING=YES TB --- 2013-10-16 04:39:16 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-16 04:39:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-16 04:39:16 - SRCCONF=/dev/null TB --- 2013-10-16 04:39:16 - TARGET=powerpc TB --- 2013-10-16 04:39:16 - TARGET_ARCH=powerpc TB --- 2013-10-16 04:39:16 - TZ=UTC TB --- 2013-10-16 04:39:16 - __MAKE_CONF=/dev/null TB --- 2013-10-16 04:39:16 - cd /src TB --- 2013-10-16 04:39:16 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Oct 16 04:39:23 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 16 07:22:30 UTC 2013 TB --- 2013-10-16 07:22:30 - generating LINT kernel config TB --- 2013-10-16 07:22:30 - cd /src/sys/powerpc/conf TB --- 2013-10-16 07:22:30 - /usr/bin/make -B LINT TB --- 2013-10-16 07:22:30 - cd /src/sys/powerpc/conf TB --- 2013-10-16 07:22:30 - /usr/sbin/config -m LINT TB --- 2013-10-16 07:22:30 - building LINT kernel TB --- 2013-10-16 07:22:30 - CROSS_BUILD_TESTING=YES TB --- 2013-10-16 07:22:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-16 07:22:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-16 07:22:30 - SRCCONF=/dev/null TB --- 2013-10-16 07:22:30 - TARGET=powerpc TB --- 2013-10-16 07:22:30 - TARGET_ARCH=powerpc TB --- 2013-10-16 07:22:30 - TZ=UTC TB --- 2013-10-16 07:22:30 - __MAKE_CONF=/dev/null TB --- 2013-10-16 07:22:30 - cd /src TB --- 2013-10-16 07:22:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 16 07:22:30 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Oct 16 07:42:09 UTC 2013 TB --- 2013-10-16 07:42:09 - cd /src/sys/powerpc/conf TB --- 2013-10-16 07:42:09 - /usr/sbin/config -m GENERIC TB --- 2013-10-16 07:42:09 - building GENERIC kernel TB --- 2013-10-16 07:42:09 - CROSS_BUILD_TESTING=YES TB --- 2013-10-16 07:42:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-16 07:42:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-16 07:42:09 - SRCCONF=/dev/null TB --- 2013-10-16 07:42:09 - TARGET=powerpc TB --- 2013-10-16 07:42:09 - TARGET_ARCH=powerpc TB --- 2013-10-16 07:42:09 - TZ=UTC TB --- 2013-10-16 07:42:09 - __MAKE_CONF=/dev/null TB --- 2013-10-16 07:42:09 - cd /src TB --- 2013-10-16 07:42:09 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Oct 16 07:42:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Wed Oct 16 07:58:21 UTC 2013 TB --- 2013-10-16 07:58:21 - cd /src/sys/powerpc/conf TB --- 2013-10-16 07:58:21 - /usr/sbin/config -m GENERIC64 TB --- 2013-10-16 07:58:21 - skipping GENERIC64 kernel TB --- 2013-10-16 07:58:21 - cd /src/sys/powerpc/conf TB --- 2013-10-16 07:58:21 - /usr/sbin/config -m MPC85XX TB --- 2013-10-16 07:58:21 - building MPC85XX kernel TB --- 2013-10-16 07:58:21 - CROSS_BUILD_TESTING=YES TB --- 2013-10-16 07:58:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-16 07:58:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-16 07:58:21 - SRCCONF=/dev/null TB --- 2013-10-16 07:58:21 - TARGET=powerpc TB --- 2013-10-16 07:58:21 - TARGET_ARCH=powerpc TB --- 2013-10-16 07:58:21 - TZ=UTC TB --- 2013-10-16 07:58:21 - __MAKE_CONF=/dev/null TB --- 2013-10-16 07:58:21 - cd /src TB --- 2013-10-16 07:58:21 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Wed Oct 16 07:58:21 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for MPC85XX completed on Wed Oct 16 08:01:20 UTC 2013 TB --- 2013-10-16 08:01:20 - cd /src/sys/powerpc/conf TB --- 2013-10-16 08:01:20 - /usr/sbin/config -m WII TB --- 2013-10-16 08:01:20 - building WII kernel TB --- 2013-10-16 08:01:20 - CROSS_BUILD_TESTING=YES TB --- 2013-10-16 08:01:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-16 08:01:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-16 08:01:20 - SRCCONF=/dev/null TB --- 2013-10-16 08:01:20 - TARGET=powerpc TB --- 2013-10-16 08:01:20 - TARGET_ARCH=powerpc TB --- 2013-10-16 08:01:20 - TZ=UTC TB --- 2013-10-16 08:01:20 - __MAKE_CONF=/dev/null TB --- 2013-10-16 08:01:20 - cd /src TB --- 2013-10-16 08:01:20 - /usr/bin/make -B buildkernel KERNCONF=WII >>> Kernel build for WII started on Wed Oct 16 08:01:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/clock.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/copyinout.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/interrupt.c /src/sys/powerpc/aim/interrupt.c: In function 'powerpc_interrupt': /src/sys/powerpc/aim/interrupt.c:106: error: 'pmc_intr' undeclared (first use in this function) /src/sys/powerpc/aim/interrupt.c:106: error: (Each undeclared identifier is reported only once /src/sys/powerpc/aim/interrupt.c:106: error: for each function it appears in.) *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/WII *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-16 08:05:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-16 08:05:44 - ERROR: failed to build WII kernel TB --- 2013-10-16 08:05:44 - 10488.03 user 1368.17 system 12392.55 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 08:16:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5FCA194 for ; Wed, 16 Oct 2013 08:16:35 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6226B2987 for ; Wed, 16 Oct 2013 08:16:35 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id k11so179014eaj.28 for ; Wed, 16 Oct 2013 01:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=8y3OohQBo3LbrIGqROGtgeNRCETRycv1E4J7vIJ+GdU=; b=aVC94LRoGHqeOouAUlCnzT33RLgpcgpA8KtJzct1j1+ED0l4/zKgb2ALW89xSK8D6m kxpb6K0IlZ3yh+M27zI+MJ/t+O6/aFx4qQP5jgR0QE4VOF2i1IjesVMu5nO/ziNC9iwV qjTD36iLr81qynrVpxUmDlpZdy0tSRP73jMIFJMF172QP6vnKFDKE8hhtXegLSWjAzfw OpqWBlY6KdiP4vacEOvLOCTzThWqpPQ3nHwSPDjz3dyTh3KZf3KCr5OwEylT9dowKHKC DhGP8W+WsMnwbBn9Z6BssEwkzNbl09kVZ0yrlUhAOOyDc2ZqXhLz15lpSV4dlER8ibUz yL8Q== X-Received: by 10.15.45.8 with SMTP id a8mr2637650eew.1.1381911393778; Wed, 16 Oct 2013 01:16:33 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id k7sm176699792eeg.13.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 16 Oct 2013 01:16:33 -0700 (PDT) Date: Wed, 16 Oct 2013 11:16:52 +0300 From: "Sergey V. Dyatko" To: Subject: dig vs drill. ns priority Message-ID: <20131016111652.3aaa4a00@laptop.minsk.domain> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 08:16:35 -0000 Hi, I have desktop with 10-alpha2 (before BIND_* removal) and laptop/another box with alpha3/11-CURRENT All 3 boxes have the same /etc/resolv.conf: # Generated by resolvconf search minsk.domain nameserver 192.168.9.250 nameserver 192.168.9.1 192.168.9.1 haven't named running, I forget to remove it from dhcpd.conf long time ago. today I became interested why my laptop(and box with CURRENT) resolves names so long (drill(1)), i.e. running command `drill domain.tld` give me result after.. ~15sec ( ^t - load: 0.59 cmd: drill 6852 [select] 15.09r 0.00u 0.00s 0% 3956k) tcpdump: 0:50:34.158172 IP (tos 0x0, ttl 64, id 27419, offset 0, flags [none], proto UDP (17), length 68) 192.168.9.150.22223 > 192.168.9.1.53: [udp sum ok] 54459+ A? as2dasdasd.freebsd.org. (40) 10:50:39.162450 IP (tos 0x0, ttl 64, id 27422, offset 0, flags [none], proto UDP (17), length 68) 192.168.9.150.19755 > 192.168.9.1.53: [udp sum ok] 54459+ A? as2dasdasd.freebsd.org. (40) 10:50:44.164578 IP (tos 0x0, ttl 64, id 27425, offset 0, flags [none], proto UDP (17), length 68) 192.168.9.150.41676 > 192.168.9.1.53: [udp sum ok] 54459+ A? as2dasdasd.freebsd.org. (40) 10:50:49.165846 IP (tos 0x0, ttl 64, id 27448, offset 0, flags [none], proto UDP (17), length 68) 192.168.9.150.14580 > 192.168.9.250.53: [udp sum ok] 54459+ A? as2dasdasd.freebsd.org. (40) 10:50:49.242053 IP (tos 0x0, ttl 64, id 55455, offset 0, flags [none], proto UDP (17), length 119) 192.168.9.250.53 > 192.168.9.150.14580: [udp sum ok] 54459 NXDomain q: A? as2dasdasd.freebsd.org. 0/1/0 ns: freebsd.org. SOA ns0.freebsd.org. hostmaster.freebsd.org. 2013101502 3600 900 604800 600 (91) on desktop dig using 1st nameserver from list, according to tcpdumps output. -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 08:50:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BDA6D1D for ; Wed, 16 Oct 2013 08:50:25 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 47A512B66 for ; Wed, 16 Oct 2013 08:50:25 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:37553] helo=localhost) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 4D/5C-15942-F435E525; Wed, 16 Oct 2013 08:50:23 +0000 Date: Wed, 16 Oct 2013 08:50:23 +0000 Message-ID: <4D.5C.15942.F435E525@cdptpa-oedge02> From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: dhclient failure with Realtek 8111E Etnernet on new MSI motherboard X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 08:50:25 -0000 for MSI Z77 MPOWER motherboard on FreeBSD 10.0-BETA1, from /var/run/dmesg.boot: re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: d4:3d:7e:97:17:e2 Ethernet chip data for older motherboard, MSI Z68MA-ED55(B3), FreeBSD 9.2 prerelease amd64, where Realtek 8111E Ethernet works, is re0@pci0:3:0:0: class=0x020000 card=0x76761462 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet When I run " dhclient re0", I can't connect, get DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 20 DHCPOFFER from 192.168.1.1 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 18 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 No DHCPOFFERS received. No working leases in persistent database - sleeping. uname -a shows FreeBSD amelia4 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256437: Mon Oct 14 16:44:23 UTC 2013 root@:/usr/obj/usr/src/sys/SANDY10 amd64 I also get "Memory modified..." error message, meaning the system has become unstable, reboot as soon as I get the messages together. My guess is that this is a bug in the Realtek 8111E driver. This Ethernet on MSI Z77 MPOWER motherboard also fails on OpenBSD 5.3 LiveUSB but succeeds on NetBSD-current (6.99.23) amd64 ,and Linux from the System Rescue CD written to USB stick. I had this problem with 9.2 prerelease, so it apparently hasn't been fixed for 10.0. Should I file a PR? Tom From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 10:04:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 67B0384E for ; Wed, 16 Oct 2013 10:04:32 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0D56210C for ; Wed, 16 Oct 2013 10:04:31 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [193.68.6.1]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id r9G9ih4N090947 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 16 Oct 2013 12:44:44 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <525E600B.1010505@digsys.bg> Date: Wed, 16 Oct 2013 12:44:43 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: What happened to nslookup? References: <0E.82.01315.25778525@cdptpa-oedge03> <20131011221302.GH1611@albert.catwhisker.org> <54.9B.16944.480B8525@cdptpa-oedge02> <20131012022825.GJ1611@albert.catwhisker.org> <525B3F33.4030103@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 10:04:32 -0000 On 16.10.13 08:42, Kevin Oberman wrote: > > nslookup(1) was deprecated about a decade ago because it often provides > misleading results when used for DNS troubleshooting. It generally works > fine for simply turning a name to an address or vice-versa. > > People should really use host(1) for simple lookups. It provides the same > information and does it in a manner that will not cause misdirection when > things are broken. Of course, host(1) is not a replacement for nslookup(1). nslookup is interactive, while host is not. This makes for a big difference in many usage scenarios. The decision to remove bind from base was poor, and not well communicated. Let's hope it will be reverted. Daniel From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 11:55:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 004C9CEF; Wed, 16 Oct 2013 11:55:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61CA02766; Wed, 16 Oct 2013 11:55:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9GBtQR1084440; Wed, 16 Oct 2013 14:55:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9GBtQR1084440 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9GBtQ38084438; Wed, 16 Oct 2013 14:55:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Oct 2013 14:55:26 +0300 From: Konstantin Belousov To: Anton Shterenlikht Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock Message-ID: <20131016115526.GR3865@kib.kiev.ua> References: <201310160802.r9G82JvJ010219@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ep5m4srWGXPl6O+g" Content-Disposition: inline In-Reply-To: <201310160802.r9G82JvJ010219@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 11:55:34 -0000 --Ep5m4srWGXPl6O+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 16, 2013 at 09:02:19AM +0100, Anton Shterenlikht wrote: > panic: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/182999 db> show pginfo 0xe00000027d352600 page 0xe00000027d352600 obj 0xe0000000128fda00 pidx 0x0 phys 0x275dc6000 q 255 hold 0 wire 1 af 0x0 of 0x0 f 0x0 act 0 busy 1 valid 0xff dirty 0x0 AFAIR ia64 uses 8K pages. Please do the following: 1. apply the patch at the end of this message, reproduce the problem and show me both exact panic message from the patched kernel and 'show pginfo addr' again. 2. show me the ls -la output for the file which was accessed through nginx, also what is the filesystem where the file resides on ? --Ep5m4srWGXPl6O+g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSXn6tAAoJEJDCuSvBvK1B1G8P/jYZZautxz7J+0z2omas2EKf HoN/4w7YhyevQnVWaxLkhrbR3uG6Tyy3cMT33vSQ9eiUjWuLbz+ezBKktYZw15N4 Wnc7YdK63OYX0/ZfUnqAwxKo30MN3vYJj+BtcIYnCJID+ktQDRBF4cpJzBqjn2iF Os3geAahzNsPP/iguPUCp+Uf7eG1SlxKBNc17xdMb20Y5feBbq1DZxgUREP3ngHO VDXG4GWxYP4u4+RwI4nTB8W/yBxDWETuV6NmcbgTgjNn0Fxj5QLm5SUQijPYw7w1 HnmW0VxEhrAaqvRICJhRIMdVfiaOUPXT3ZLqPnJpqTkgYcbZNaQ4m2wVaesvHZ7q D2C4a+nmzkSG5DuacPezpAFQoBn61j/Iolw3uPPcUmmJ61+DgnT+gfvi2T8jf4Y9 l1W1/MJXHTfH23irCmMy7IzRfxV6MWtHeuO+BPxqit3BhOefGaQsTOVhxi5yAWi1 BouJlzotkExP6sZeNcTBgNcMlTG1UT9oXL0QVQAFgJeaKx8BUbyhbNRF9rw2PoM+ WT+KK6nBkLRR2ovL+ZkRJULHKbcDRdpZMPBYpVJYZfMihqRqSz63LYCpSJPaKm6p BMZJyEft5nqLMhyuumGKrkDnGz3mWQVhvqme7qGfE32jz5mKhTRWtfi27DJqm+of uf0/XiFgjnABOZRhZSr6 =5+WG -----END PGP SIGNATURE----- --Ep5m4srWGXPl6O+g-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 12:01:49 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AF3F1CA; Wed, 16 Oct 2013 12:01:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC6DE280E; Wed, 16 Oct 2013 12:01:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9GC1gMR086226; Wed, 16 Oct 2013 15:01:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9GC1gMR086226 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9GC1gqq086225; Wed, 16 Oct 2013 15:01:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Oct 2013 15:01:42 +0300 From: Konstantin Belousov To: Anton Shterenlikht Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock Message-ID: <20131016120142.GS3865@kib.kiev.ua> References: <201310160802.r9G82JvJ010219@mech-cluster241.men.bris.ac.uk> <20131016115526.GR3865@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s9pXJW6w71JX4l3T" Content-Disposition: inline In-Reply-To: <20131016115526.GR3865@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 12:01:49 -0000 --s9pXJW6w71JX4l3T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2013 at 02:55:26PM +0300, Konstantin Belousov wrote: > On Wed, Oct 16, 2013 at 09:02:19AM +0100, Anton Shterenlikht wrote: > > panic: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/182999 >=20 > db> show pginfo 0xe00000027d352600 > page 0xe00000027d352600 obj 0xe0000000128fda00 pidx 0x0 phys 0x275dc6000 = q 255 hold 0 wire 1 > af 0x0 of 0x0 f 0x0 act 0 busy 1 valid 0xff dirty 0x0 >=20 > AFAIR ia64 uses 8K pages. >=20 > Please do the following: > 1. apply the patch at the end of this message, reproduce the problem > and show me both exact panic message from the patched kernel and 'show > pginfo addr' again. > 2. show me the ls -la output for the file which was accessed > through nginx, also what is the filesystem where the file resides on ? Sure, I forgot the patch. diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c index 322550b..9d46dc7 100644 --- a/sys/kern/uipc_syscalls.c +++ b/sys/kern/uipc_syscalls.c @@ -2070,7 +2070,7 @@ free_page: } KASSERT(error !=3D 0 || (m->wire_count > 0 && vm_page_is_valid(m, off & PAGE_MASK, xfsize)), - ("wrong page state m %p", m)); + ("wrong page state m %p off %#jx xfsize %d", m, off, xfsize)); VM_OBJECT_WUNLOCK(obj); return (error); } --s9pXJW6w71JX4l3T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSXoAlAAoJEJDCuSvBvK1BPAEP/AzDZwOD7zXNuAdVzhG7bIi4 gRSOTCF+CIAu6ADTHnvgCHKOSyBX6IFnG4/bHVVnbv+pHalzWpdFqO2Ji+5150OK gjCP5rKIlgpzJpV8eklsw3pmcW06hEhyvujfkJnFX8uoJ90M3PMyQNt0GYq1Hm4y vh9elf7QeJmN4GuGDdHxdfzcW3z2FaqnB8S5IijebcwhIrcvMUluO5SnvRMlB99q 9o+q1wxEZRFx4/pGugT+PnGC3iZqBVN8rhbdbnMaOr1dRvQN+3zQJZU41Nfl3Csy CHf8C9HuP6VnDxed2nMRa1lVVvystuYxLQqdpFrLyEuyN3hP0X1M0htrxevXDn+q B7Ua9Jf/taueI+w0TuBkqMqc9p0x+SQa076NAVCpazQ/6xLJJma8xLYgQxPasW53 ej0p9CpD2B5rqO3I2hEXtu7qMbea/w4YVDp4eZVLKHZX7uea4QH/mV136wUc+JA+ lLWOOKa6xwgXQyWPI0mVlbQcfJUxrKiwFiPRAMvZpRAUEcdnuwVfvbVEcPqwynjk I1+gc19abrvHMKQLTzIjJ3o4rChKqkBAinUQkfgQCRX21jgt34sYKi/4mFJGwgp7 PRcHkbzqw5WSglunvjw1gThrPsORTrFuoHb9cVEIu+Z53W2j926BA7xleGuN7uUF 2QVi0BdpW8ATScMTfWPZ =AZIr -----END PGP SIGNATURE----- --s9pXJW6w71JX4l3T-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 12:58:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E53AD6D0; Wed, 16 Oct 2013 12:58:36 +0000 (UTC) (envelope-from prvs=100105a393=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D7762B5B; Wed, 16 Oct 2013 12:58:35 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006420420.msg; Wed, 16 Oct 2013 13:58:28 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 16 Oct 2013 13:58:28 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=100105a393=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <0023A5B16E614B67A2D8A4A63641D1D8@multiplay.co.uk> From: "Steven Hartland" To: "Vitalij Satanivskij" , "Dmitriy Makarov" References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Wed, 16 Oct 2013 13:58:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 12:58:37 -0000 Have you confirmed the ashift changes are the actual cause of this by backing out just those changes and retesting on the same hardware. Also worth checking your disks smart values to confirm there are no visible signs of HW errors. Regards Steve ----- Original Message ----- From: "Vitalij Satanivskij" To: "Dmitriy Makarov" Cc: "Steven Hartland" ; "Justin T. Gibbs" ; "Borja Marcos" ; Sent: Wednesday, October 16, 2013 9:01 AM Subject: Re: ZFS secondarycache on SSD problem on r255173 > Hello. > > Patch brocke cache functionality. > > Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 > > With subject ZFS L2ARC - incorrect size and abnormal system load on r255173 > > As patch alredy in head and BETA it's not good. > > Yesterday we update one machine up to beta1 and forgot about patch. So 12 Hours and cache broken... :(( > > > > Dmitriy Makarov wrote: > DM> The attached patch by Steven Hartland fixes issue for me too. Thank you! > DM> > DM> > DM> --- Èñõîäíîå ñîîáùåíèå --- > DM> Îò êîãî: "Steven Hartland" < killing@multiplay.co.uk > > DM> Äàòà: 18 ñåíòÿáðÿ 2013, 01:53:10 > DM> > DM> ----- Original Message ----- > DM> From: "Justin T. Gibbs" < > DM> > DM> --- > DM> Äìèòðèé Ìàêàðîâ > DM> _______________________________________________ > DM> freebsd-current@freebsd.org mailing list > DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current > DM> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 13:30:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1834463; Wed, 16 Oct 2013 13:30:45 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id AE1842D96; Wed, 16 Oct 2013 13:30:45 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 2D01C1A3DCC; Wed, 16 Oct 2013 06:30:45 -0700 (PDT) Message-ID: <525E9507.2060000@mu.org> Date: Wed, 16 Oct 2013 06:30:47 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Rui Paulo , "Julian H. Stacey" Subject: Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter References: <201310081742.r98HfbBV055077@fire.js.berklix.net> <589BAB21-30E9-4750-A345-BE7AB1116F48@FreeBSD.org> In-Reply-To: <589BAB21-30E9-4750-A345-BE7AB1116F48@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org bsd" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 13:30:45 -0000 On 10/15/13 11:13 PM, Rui Paulo wrote: > On 8 Oct 2013, at 10:41, Julian H. Stacey wrote: > >> I too am seeing >> urtwn0: timeout waiting for checksum report > Sorry, this is a know problem that I haven't been able to figure out... It probably exists in the OpenBSD driver as well. Usually retrying works. > > -- > Rui Paulo > > > I have a "device timeout" problem with urtwn as well, but I haven't had time to hack the driver to self-reset itself. boo :( -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 14:10:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1DE73A0; Wed, 16 Oct 2013 14:10:56 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 785DD21EE; Wed, 16 Oct 2013 14:10:56 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VWRoL-000BRg-Sb ; Wed, 16 Oct 2013 17:10:53 +0300 Date: Wed, 16 Oct 2013 17:10:53 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131016141053.GA43384@hell.ukr.net> References: <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <0023A5B16E614B67A2D8A4A63641D1D8@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0023A5B16E614B67A2D8A4A63641D1D8@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , "Justin T. Gibbs" , freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 14:10:56 -0000 Yes We have 15 servers, all of them have problem while using with patch fo ashift, sh we rollback path (for r255173) and all of them works for a week without that's problem's. Yesterday one of of servers was updated to stable/10 (beta1) wich include patch and after around 12 hours of works l2arc begin et errors like that kstat.zfs.misc.arcstats.l2_cksum_bad kstat.zfs.misc.arcstats.l2_io_error For now patch disabled in ower production. Please note we have very heavy load on zfs pool so 90GB arc and 3x180Gb L2arc have very big hit's on it on it. SSD used for cache's is intel ssd 530 series smart for all devices in in normal states's no bad values on it. Steven Hartland wrote: SH> Have you confirmed the ashift changes are the actual cause of this SH> by backing out just those changes and retesting on the same hardware. SH> SH> Also worth checking your disks smart values to confirm there are no SH> visible signs of HW errors. SH> SH> Regards SH> Steve SH> SH> ----- Original Message ----- SH> From: "Vitalij Satanivskij" SH> To: "Dmitriy Makarov" SH> Cc: "Steven Hartland" ; "Justin T. Gibbs" ; "Borja Marcos" ; SH> SH> Sent: Wednesday, October 16, 2013 9:01 AM SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> SH> SH> > Hello. SH> > SH> > Patch brocke cache functionality. SH> > SH> > Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 SH> > SH> > With subject ZFS L2ARC - incorrect size and abnormal system load on r255173 SH> > SH> > As patch alredy in head and BETA it's not good. SH> > SH> > Yesterday we update one machine up to beta1 and forgot about patch. So 12 Hours and cache broken... :(( SH> > SH> > SH> > SH> > Dmitriy Makarov wrote: SH> > DM> The attached patch by Steven Hartland fixes issue for me too. Thank you! SH> > DM> SH> > DM> SH> > DM> --- Èñõîäíîå ñîîáùåíèå --- SH> > DM> Îò êîãî: "Steven Hartland" < killing@multiplay.co.uk > SH> > DM> Äàòà: 18 ñåíòÿáðÿ 2013, 01:53:10 SH> > DM> SH> > DM> ----- Original Message ----- SH> > DM> From: "Justin T. Gibbs" < SH> > DM> SH> > DM> --- SH> > DM> Äìèòðèé Ìàêàðîâ SH> > DM> _______________________________________________ SH> > DM> freebsd-current@freebsd.org mailing list SH> > DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > DM> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> SH> _______________________________________________ SH> freebsd-current@freebsd.org mailing list SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 14:29:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A90A1A50 for ; Wed, 16 Oct 2013 14:29:16 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A4682311 for ; Wed, 16 Oct 2013 14:29:16 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id i13so690813qae.1 for ; Wed, 16 Oct 2013 07:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=i581Wze8wVOrP6zlqfts41SDJQzp2iG/fogwdJbbfhE=; b=t/mDGZ0LnpsJKRJ30LpyeiSW+MjQS4BPS03YlGd0sTZreUSvNPKYAwng1XYK+kqgmb xMx23i0HtB13jRIIrRnu4lqFdzp6dSF8t0sqtbPCA39gkU+T1PPKslCfJAbbChw5YWBI e/esrin1ZAicJHWrUZqsZMiJLP/ieZBy/VO38= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=i581Wze8wVOrP6zlqfts41SDJQzp2iG/fogwdJbbfhE=; b=UpJRwq84wqX/FlLSOFEva8bKpJr1ze5mMX6bPh/WNlr0VfYZVwmV7M0zCLGQaWHbaZ GPV2/+Yi3tG+7bItLy5FV0lmqKGdZ3R7x43C4d2bW1sixBRQl2gWaVqknRTVYEGsPE1b rMBJIiiW3VhXTe2BR/Nc8Dj5pAG/25ukH3kVDsKGyUCX1wMNNuGSGMbPO2dLHT1nW8gJ zwEHTCkTdPpulTKU5hNtS8yNizN1fUkmSTNk3/EGEgEWowU0U6LDkhTecDPvFyaef9Ch jtLLsfQZcCGv7t03pgiRMPTPJhxKtG/5Bw5lQPN2XBcEwScvPTPRp3HRWZvcycsLKh8z ipOw== X-Gm-Message-State: ALoCoQkEbNu/JtJWtpoWcVHREaJzmkh0a/Bjy7Du5hOR/iR1soLW9wetc3AXtDx+kxDNzAZffGeo X-Received: by 10.49.98.1 with SMTP id ee1mr4229154qeb.28.1381933755604; Wed, 16 Oct 2013 07:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Wed, 16 Oct 2013 07:28:45 -0700 (PDT) From: Eitan Adler Date: Wed, 16 Oct 2013 10:28:45 -0400 Message-ID: Subject: nslookup gave misleading results? To: Kevin Oberman , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 14:29:16 -0000 On Wed, Oct 16, 2013 at 1:42 AM, Kevin Oberman wrote: > nslookup(1) was deprecated about a decade ago because it often provides > misleading results when used for DNS troubleshooting. It generally works > fine for simply turning a name to an address or vice-versa. Can you give a bit more detail on this? In what ways did it give misleading results? -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 14:31:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57DCCC01 for ; Wed, 16 Oct 2013 14:31:58 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog121.obsmtp.com (eu1sys200aog121.obsmtp.com [207.126.144.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 315C62371 for ; Wed, 16 Oct 2013 14:31:24 +0000 (UTC) Received: from mail-wi0-f179.google.com ([209.85.212.179]) (using TLSv1) by eu1sys200aob121.postini.com ([207.126.147.11]) with SMTP ID DSNKUl6jNPrBSzTYgx/4+FJn1lQqly3cwbdY@postini.com; Wed, 16 Oct 2013 14:31:24 UTC Received: by mail-wi0-f179.google.com with SMTP id hm4so865700wib.0 for ; Wed, 16 Oct 2013 07:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=+qbVc/Wde1PArlFnyejvT4hhPgxfo02XKqOvtoTGf4w=; b=VVpE+xYUt190t+vApL5HU9uDYiMJNSopc7FRm0ZsMGkOjdn4bArsrocmwP2b5tB34F Nk0q6cXNda5Bo3AYYkJ75ruqUTj3ksVapJR5HAxwEw/gilZRN1UUZN9GhQsWWpuTu3Ng mcjLFwYwB5LldUQb/XEE3XIsOMDEBcH89veoMmH04Sqo5gRjMuP6+KyMCwbxe1flLr4u oZbDWDuOwT8HNqkO3nSudpL/guVdpGTm/YFKv/VyDdqnzRaeDUtwbLeP7bnm9+KBhicc dL53TNFiitqYb1Ltg2TulsWAdNd0653tJqZc7pB+KAuTLu05qLS1iu11/g00MlAj1jz7 5lNw== X-Gm-Message-State: ALoCoQm68k61NaAXJTmClLhymokY6DyRJTniJZM62sU/radSw8YOi+HHXXLrA4Ck+AGBsSaya9UChLV8mwwTkX6cWuU9eu5D1H/SQmmqgyCMYOrngaKyk5tece+W5ip3mda6OJlS+TB1+9XeMIUjFbUKe+EFXblqHLFKZ69AgfZ0yFk5S71n+QQ= X-Received: by 10.180.72.195 with SMTP id f3mr2540434wiv.51.1381933816122; Wed, 16 Oct 2013 07:30:16 -0700 (PDT) X-Received: by 10.180.72.195 with SMTP id f3mr2540427wiv.51.1381933816012; Wed, 16 Oct 2013 07:30:16 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id b13sm6424064wic.9.2013.10.16.07.30.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Oct 2013 07:30:15 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6) with ESMTP id r9GEUD3X025962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Oct 2013 15:30:13 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.7/8.14.6/Submit) id r9GEUCYo025961; Wed, 16 Oct 2013 15:30:12 +0100 (BST) (envelope-from mexas) Date: Wed, 16 Oct 2013 15:30:12 +0100 (BST) From: Anton Shterenlikht Message-Id: <201310161430.r9GEUCYo025961@mech-cluster241.men.bris.ac.uk> To: kostikbel@gmail.com, mexas@bris.ac.uk Subject: Re: panic: wrong page state m 0xe00000027a9adb40 + savecore deadlock In-Reply-To: <20131016120142.GS3865@kib.kiev.ua> Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:31:58 -0000 >From kostikbel@gmail.com Wed Oct 16 13:02:51 2013 > >On Wed, Oct 16, 2013 at 02:55:26PM +0300, Konstantin Belousov wrote: >> On Wed, Oct 16, 2013 at 09:02:19AM +0100, Anton Shterenlikht wrote: >> > panic: >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/182999 >>=20 >> db> show pginfo 0xe00000027d352600 >> page 0xe00000027d352600 obj 0xe0000000128fda00 pidx 0x0 phys 0x275dc6000 = >q 255 hold 0 wire 1 >> af 0x0 of 0x0 f 0x0 act 0 busy 1 valid 0xff dirty 0x0 >>=20 >> AFAIR ia64 uses 8K pages. >>=20 >> Please do the following: >> 1. apply the patch at the end of this message, reproduce the problem >> and show me both exact panic message from the patched kernel and 'show >> pginfo addr' again. >> 2. show me the ls -la output for the file which was accessed >> through nginx, also what is the filesystem where the file resides on ? >Sure, I forgot the patch. > >diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c >index 322550b..9d46dc7 100644 >--- a/sys/kern/uipc_syscalls.c >+++ b/sys/kern/uipc_syscalls.c >@@ -2070,7 +2070,7 @@ free_page: > } > KASSERT(error !=3D 0 || (m->wire_count > 0 && > vm_page_is_valid(m, off & PAGE_MASK, xfsize)), >- ("wrong page state m %p", m)); >+ ("wrong page state m %p off %#jx xfsize %d", m, off, xfsize)); > VM_OBJECT_WUNLOCK(obj); > return (error); > } The patch didn't apply cleanly. I concluded that my src was older that yours, so I updated to r 256624. Now I don't get this panic! I don't know whether to be happy or not. Anyway, I was on r255488 when the panic happened, and there have been a lot of changes under sys/kern. Specifically related to the patch: # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.eu.freebsd.org/base/head/sys/kern Relative URL: ^/head/sys/kern Repository Root: https://svn0.eu.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 256624 Node Kind: directory Schedule: normal Last Changed Author: mav Last Changed Rev: 256614 Last Changed Date: 2013-10-16 10:56:40 +0100 (Wed, 16 Oct 2013) # svn diff -r 255488 uipc_syscalls.c Index: uipc_syscalls.c =================================================================== --- uipc_syscalls.c (revision 255488) +++ uipc_syscalls.c (working copy) @@ -123,21 +123,13 @@ /* * sendfile(2)-related variables and associated sysctls */ -int nsfbufs; -int nsfbufspeak; -int nsfbufsused; +static SYSCTL_NODE(_kern_ipc, OID_AUTO, sendfile, CTLFLAG_RW, 0, + "sendfile(2) tunables"); static int sfreadahead = 1; +SYSCTL_INT(_kern_ipc_sendfile, OID_AUTO, readahead, CTLFLAG_RW, + &sfreadahead, 0, "Number of sendfile(2) read-ahead MAXBSIZE blocks"); -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, - "Maximum number of sendfile(2) sf_bufs available"); -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, - "Number of sendfile(2) sf_bufs at peak usage"); -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, - "Number of sendfile(2) sf_bufs in use"); -SYSCTL_INT(_kern_ipc, OID_AUTO, sfreadahead, CTLFLAG_RW, &sfreadahead, 0, - "Number of sendfile(2) read-ahead MAXBSIZE blocks"); - static void sfstat_init(const void *unused) { @@ -2076,10 +2068,10 @@ vm_page_free(m); vm_page_unlock(m); } + KASSERT(error != 0 || (m->wire_count > 0 && + vm_page_is_valid(m, off & PAGE_MASK, xfsize)), + ("wrong page state m %p off %#jx xfsize %d", m, off, xfsize)); VM_OBJECT_WUNLOCK(obj); - KASSERT(error != 0 || (m->wire_count > 0 && m->valid == - VM_PAGE_BITS_ALL), - ("wrong page state m %p", m)); return (error); } # Please let me know if there is any other diagnostics you'd like to see. Otherwise, till next panic... Many thanks for your help Anton From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 14:55:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD4E0F81; Wed, 16 Oct 2013 14:55:11 +0000 (UTC) (envelope-from prvs=100105a393=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 224F724B5; Wed, 16 Oct 2013 14:55:10 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006421385.msg; Wed, 16 Oct 2013 15:55:08 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 16 Oct 2013 15:55:08 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=100105a393=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6DE320B20F7844B9ADC34A214AED8055@multiplay.co.uk> From: "Steven Hartland" To: "Vitalij Satanivskij" References: <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <0023A5B16E614B67A2D8A4A63641D1D8@multiplay.co.uk> <20131016141053.GA43384@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Wed, 16 Oct 2013 15:55:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Vitalij Satanivskij , "Justin T. Gibbs" , freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 14:55:11 -0000 I'm not clear what you rolled back there as r255173 has ntothing to do with this. Could you clarify Any errors recorded in /var/log/messages? Could you add code to record the none zero value of zio->io_error in l2arc_read_done as this may give some indication of the underlying issue. Additionally could always put a panic in that code path too and then create a dump so the details can be fully exhamined. In terms of the slowness thats going to be a side effect of the cache failures. Oh could you also confirm that the issue doesn't exist if you 1. Exclude r255753 2. Set vfs.zfs.max_auto_ashift=9 Regards Steve ----- Original Message ----- From: "Vitalij Satanivskij" To: "Steven Hartland" Cc: "Vitalij Satanivskij" ; "Dmitriy Makarov" ; "Justin T. Gibbs" ; "Borja Marcos" ; Sent: Wednesday, October 16, 2013 3:10 PM Subject: Re: ZFS secondarycache on SSD problem on r255173 > Yes > > We have 15 servers, all of them have problem while using with patch fo ashift, sh we rollback path (for r255173) > and all of them works for a week without that's problem's. Yesterday one of of servers was updated to stable/10 (beta1) > > wich include patch and after around 12 hours of works l2arc begin et errors like that > > kstat.zfs.misc.arcstats.l2_cksum_bad > kstat.zfs.misc.arcstats.l2_io_error > > > For now patch disabled in ower production. > > > Please note we have very heavy load on zfs pool so 90GB arc and 3x180Gb L2arc have very big hit's on it on it. > > > SSD used for cache's is intel ssd 530 series smart for all devices in in normal states's > no bad values on it. > > Steven Hartland wrote: > SH> Have you confirmed the ashift changes are the actual cause of this > SH> by backing out just those changes and retesting on the same hardware. > SH> > SH> Also worth checking your disks smart values to confirm there are no > SH> visible signs of HW errors. > SH> > SH> Regards > SH> Steve > SH> > SH> ----- Original Message ----- > SH> From: "Vitalij Satanivskij" > SH> To: "Dmitriy Makarov" > SH> Cc: "Steven Hartland" ; "Justin T. Gibbs" ; "Borja Marcos" ; > SH> > SH> Sent: Wednesday, October 16, 2013 9:01 AM > SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 > SH> > SH> > SH> > Hello. > SH> > > SH> > Patch brocke cache functionality. > SH> > > SH> > Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 > SH> > > SH> > With subject ZFS L2ARC - incorrect size and abnormal system load on r255173 > SH> > > SH> > As patch alredy in head and BETA it's not good. > SH> > > SH> > Yesterday we update one machine up to beta1 and forgot about patch. So 12 Hours and cache broken... :(( > SH> > > SH> > > SH> > > SH> > Dmitriy Makarov wrote: > SH> > DM> The attached patch by Steven Hartland fixes issue for me too. Thank you! > SH> > DM> > SH> > DM> > SH> > DM> --- Èñõîäíîå ñîîáùåíèå --- > SH> > DM> Îò êîãî: "Steven Hartland" < killing@multiplay.co.uk > > SH> > DM> Äàòà: 18 ñåíòÿáðÿ 2013, 01:53:10 > SH> > DM> > SH> > DM> ----- Original Message ----- > SH> > DM> From: "Justin T. Gibbs" < > SH> > DM> > SH> > DM> --- > SH> > DM> Äìèòðèé Ìàêàðîâ > SH> > DM> _______________________________________________ > SH> > DM> freebsd-current@freebsd.org mailing list > SH> > DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> > DM> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > SH> > > SH> > SH> > SH> ================================================ > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any > information contained in it. > SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > SH> or return the E.mail to postmaster@multiplay.co.uk. > SH> > SH> _______________________________________________ > SH> freebsd-current@freebsd.org mailing list > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 15:14:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C003B2F7 for ; Wed, 16 Oct 2013 15:14:24 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE4525C9 for ; Wed, 16 Oct 2013 15:14:24 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 56DED3F264 for ; Wed, 16 Oct 2013 15:14:20 +0000 (UTC) Message-ID: <525EAD4C.10701@allanjude.com> Date: Wed, 16 Oct 2013 11:14:20 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: What happened to nslookup? References: <0E.82.01315.25778525@cdptpa-oedge03> <20131011221302.GH1611@albert.catwhisker.org> <54.9B.16944.480B8525@cdptpa-oedge02> <20131012022825.GJ1611@albert.catwhisker.org> <525B3F33.4030103@freebsd.org> <525E600B.1010505@digsys.bg> In-Reply-To: <525E600B.1010505@digsys.bg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 15:14:24 -0000 On 2013-10-16 05:44, Daniel Kalchev wrote: > > On 16.10.13 08:42, Kevin Oberman wrote: >> >> nslookup(1) was deprecated about a decade ago because it often provides >> misleading results when used for DNS troubleshooting. It generally works >> fine for simply turning a name to an address or vice-versa. >> >> People should really use host(1) for simple lookups. It provides the >> same >> information and does it in a manner that will not cause misdirection >> when >> things are broken. > > Of course, host(1) is not a replacement for nslookup(1). > > nslookup is interactive, while host is not. This makes for a big > difference in many usage scenarios. > > The decision to remove bind from base was poor, and not well > communicated. Let's hope it will be reverted. > > Daniel > _______________________________________________ > 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" Bind 10 requires python. There is a good reason it was removed from base. -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 15:18:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D789463 for ; Wed, 16 Oct 2013 15:18:11 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6559625FC for ; Wed, 16 Oct 2013 15:18:11 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id B5A4D33C49; Wed, 16 Oct 2013 11:11:51 -0400 (EDT) From: Lowell Gilbert To: Eitan Adler Subject: Re: nslookup gave misleading results? References: Date: Wed, 16 Oct 2013 11:11:51 -0400 In-Reply-To: (Eitan Adler's message of "Wed, 16 Oct 2013 10:28:45 -0400") Message-ID: <44a9i9l07c.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Kevin Oberman , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 15:18:11 -0000 Eitan Adler writes: > On Wed, Oct 16, 2013 at 1:42 AM, Kevin Oberman wrote: >> nslookup(1) was deprecated about a decade ago because it often provides >> misleading results when used for DNS troubleshooting. It generally works >> fine for simply turning a name to an address or vice-versa. > > Can you give a bit more detail on this? In what ways did it give > misleading results? A couple of different reasons cited by ISC for why they deprecated it a long time ago: nslookup bundled an internal resolver library, and so it wouldn't always give the same results as other utilities. Also, it always ignored some of the host configuration. -- Lowell Gilbert From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 15:49:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E27D8BA9 for ; Wed, 16 Oct 2013 15:49:58 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF6B327E8 for ; Wed, 16 Oct 2013 15:49:58 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id ar20so1597483iec.26 for ; Wed, 16 Oct 2013 08:49:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=U71djB6Qw6mPdCn0q41AIbsIqzk53fZLT/tPP+9gea0=; b=LOL/6gnLNjNpqaFgpJI6m/rlu8FBgDkDYPnVs9dgGAQCx6DB9GrrW8ZtSd1tLgLfVR aMYJCirACGIQbdWZtM6noJqhBIwK++bLDxghyErHQbGt1k7EvZ8gUxiiaQwd/gpkobYU PUOJ7KPf1Ax8pLQptnpn/5mjMwVMPbRpw2B/s9F5l3AMtvLuhHmnnTeE3pn1jt+Ojfz5 9iQwLelBsp2B+VHLLE+czuEKIJTDvV5nPc93FHpmIPPe38IiTBw7WmaVBR5Q5LN3l9qi +qPtMGUEXJyH8bw9DHUrcEkh3BQJxB3lgq4H1VN/3W2Pf6x/GH3aUpAE2fV9a8y6vHKV X2ng== X-Gm-Message-State: ALoCoQlXKFcMJ6Lx+2oMa7qVnIyKw2iZct78T2ANHto7MJEb6jGFrAmIYu3lOo8bsA3/OELcSNLw X-Received: by 10.43.80.67 with SMTP id zt3mr2273761icb.23.1381938591889; Wed, 16 Oct 2013 08:49:51 -0700 (PDT) Received: from [192.168.2.72] (CPE0080c8f208a5-CM001371173cf8.cpe.net.cable.rogers.com. [99.246.61.82]) by mx.google.com with ESMTPSA id x5sm3890379iga.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Oct 2013 08:49:50 -0700 (PDT) Date: Wed, 16 Oct 2013 11:53:39 -0400 (EDT) From: Graham Todd X-X-Sender: gtodd@ninga.iciti.internal To: Daniel Kalchev Subject: Re: What happened to nslookup? In-Reply-To: <525E600B.1010505@digsys.bg> Message-ID: References: <0E.82.01315.25778525@cdptpa-oedge03> <20131011221302.GH1611@albert.catwhisker.org> <54.9B.16944.480B8525@cdptpa-oedge02> <20131012022825.GJ1611@albert.catwhisker.org> <525B3F33.4030103@freebsd.org> <525E600B.1010505@digsys.bg> 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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 15:49:58 -0000 On Wed, 16 Oct 2013, Daniel Kalchev wrote: > > On 16.10.13 08:42, Kevin Oberman wrote: >> >> nslookup(1) was deprecated about a decade ago because it often provides >> misleading results when used for DNS troubleshooting. It generally >> works fine for simply turning a name to an address or vice-versa. >> >> People should really use host(1) for simple lookups. It provides the >> same information and does it in a manner that will not cause >> misdirection when things are broken. > > Of course, host(1) is not a replacement for nslookup(1). > > nslookup is interactive, while host is not. This makes for a big > difference in many usage scenarios. The version of nslookup on FreeBSD systems I've used had no command line history or editing (even ntpdc has this now), gave results that were not always in line with other tools (ldns, drill, host etc.), and to do a host lookup inside the nslookup shell you had to type ... "host" :-) From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 15:57:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D54B2D52; Wed, 16 Oct 2013 15:57:19 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 888102861; Wed, 16 Oct 2013 15:57:19 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VWTTI-000NbY-83 ; Wed, 16 Oct 2013 18:57:16 +0300 Date: Wed, 16 Oct 2013 18:57:16 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131016155716.GA90462@hell.ukr.net> References: <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <0023A5B16E614B67A2D8A4A63641D1D8@multiplay.co.uk> <20131016141053.GA43384@hell.ukr.net> <6DE320B20F7844B9ADC34A214AED8055@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6DE320B20F7844B9ADC34A214AED8055@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 15:57:20 -0000 Steven Hartland wrote: SH> I'm not clear what you rolled back there as r255173 has ntothing to do SH> with this. Could you clarify r255173 with you patch from email dated Tue, 17 Sep 2013 23:53:12 +0100 with subject Re: ZFS secondarycache on SSD problem on r255173 Errors wich we gets is in arcstats count not in messages, and was desribed some time ago in mails be me and Dmitriy Makarov with subject's ZFS L2ARC - incorrect size and abnormal system load on r255173 On r255173 without patch and with vfs.zfs.max_auto_ashift=9 when added to pool 2 ssd as caches get cache gpt/cache1 ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/cache2 ONLINE 0 0 0 block size: 512B configured, 4096B native Same message we seen with default vfs.zfs.max_auto_ashift Will wait some time to see how it works. SH> Any errors recorded in /var/log/messages? SH> SH> Could you add code to record the none zero value of zio->io_error in SH> l2arc_read_done as this may give some indication of the underlying SH> issue. SH> SH> Additionally could always put a panic in that code path too and then SH> create a dump so the details can be fully exhamined. SH> SH> In terms of the slowness thats going to be a side effect of the cache SH> failures. SH> SH> Oh could you also confirm that the issue doesn't exist if you SH> 1. Exclude r255753 SH> 2. Set vfs.zfs.max_auto_ashift=9 SH> SH> Regards SH> Steve SH> ----- Original Message ----- SH> From: "Vitalij Satanivskij" SH> To: "Steven Hartland" SH> Cc: "Vitalij Satanivskij" ; "Dmitriy Makarov" ; "Justin T. Gibbs" ; "Borja SH> Marcos" ; SH> Sent: Wednesday, October 16, 2013 3:10 PM SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> SH> SH> > Yes SH> > SH> > We have 15 servers, all of them have problem while using with patch fo ashift, sh we rollback path (for r255173) SH> > and all of them works for a week without that's problem's. Yesterday one of of servers was updated to stable/10 (beta1) SH> > SH> > wich include patch and after around 12 hours of works l2arc begin et errors like that SH> > SH> > kstat.zfs.misc.arcstats.l2_cksum_bad SH> > kstat.zfs.misc.arcstats.l2_io_error SH> > SH> > SH> > For now patch disabled in ower production. SH> > SH> > SH> > Please note we have very heavy load on zfs pool so 90GB arc and 3x180Gb L2arc have very big hit's on it on it. SH> > SH> > SH> > SSD used for cache's is intel ssd 530 series smart for all devices in in normal states's SH> > no bad values on it. SH> > SH> > Steven Hartland wrote: SH> > SH> Have you confirmed the ashift changes are the actual cause of this SH> > SH> by backing out just those changes and retesting on the same hardware. SH> > SH> SH> > SH> Also worth checking your disks smart values to confirm there are no SH> > SH> visible signs of HW errors. SH> > SH> SH> > SH> Regards SH> > SH> Steve SH> > SH> SH> > SH> ----- Original Message ----- SH> > SH> From: "Vitalij Satanivskij" SH> > SH> To: "Dmitriy Makarov" SH> > SH> Cc: "Steven Hartland" ; "Justin T. Gibbs" ; "Borja Marcos" ; SH> > SH> SH> > SH> Sent: Wednesday, October 16, 2013 9:01 AM SH> > SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> > SH> SH> > SH> SH> > SH> > Hello. SH> > SH> > SH> > SH> > Patch brocke cache functionality. SH> > SH> > SH> > SH> > Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 SH> > SH> > SH> > SH> > With subject ZFS L2ARC - incorrect size and abnormal system load on r255173 SH> > SH> > SH> > SH> > As patch alredy in head and BETA it's not good. SH> > SH> > SH> > SH> > Yesterday we update one machine up to beta1 and forgot about patch. So 12 Hours and cache broken... :(( SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > Dmitriy Makarov wrote: SH> > SH> > DM> The attached patch by Steven Hartland fixes issue for me too. Thank you! SH> > SH> > DM> SH> > SH> > DM> SH> > SH> > DM> --- Èñõîäíîå ñîîáùåíèå --- SH> > SH> > DM> Îò êîãî: "Steven Hartland" < killing@multiplay.co.uk > SH> > SH> > DM> Äàòà: 18 ñåíòÿáðÿ 2013, 01:53:10 SH> > SH> > DM> SH> > SH> > DM> ----- Original Message ----- SH> > SH> > DM> From: "Justin T. Gibbs" < SH> > SH> > DM> SH> > SH> > DM> --- SH> > SH> > DM> Äìèòðèé Ìàêàðîâ SH> > SH> > DM> _______________________________________________ SH> > SH> > DM> freebsd-current@freebsd.org mailing list SH> > SH> > DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> > DM> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> > SH> > SH> SH> > SH> SH> > SH> ================================================ SH> > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the SH> > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any SH> > information contained in it. SH> > SH> SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> > SH> or return the E.mail to postmaster@multiplay.co.uk. SH> > SH> SH> > SH> _______________________________________________ SH> > SH> freebsd-current@freebsd.org mailing list SH> > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> SH> _______________________________________________ SH> freebsd-current@freebsd.org mailing list SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 19:48:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0D30A22 for ; Wed, 16 Oct 2013 19:48:44 +0000 (UTC) (envelope-from bounces+73574-dfb6-freebsd-current=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 9A13C2645 for ; Wed, 16 Oct 2013 19:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:cc:subject:references:in-reply-to:content-type; s=smtpapi; bh=KU95oUnZahTrd/9XzTR016vTYvw=; b=Y3oOtob8f5h5GZHeQA xUfbZd9ZgfxhTk69qbKGD3WCcaFcsz20/DYg4MfZUaXd8Vg4rRxdGzf/GWYpHp5a yXBv+NtRUrIcCWWUB1l+V4y9dosy1JwHvifkOjR3x3rZSCj4SELVDASrwzm+Y25i 2zJ9mTAbWawwSLn7tGkw6QmIM= Received: by mf105 with SMTP id mf105.22678.525EED9A1 Wed, 16 Oct 2013 19:48:42 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi20 (SG) with ESMTP id 141c2d021e4.6202.1a4c61c for ; Wed, 16 Oct 2013 19:48:42 +0000 (UTC) Received: (qmail 89472 invoked from network); 16 Oct 2013 19:48:40 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 16 Oct 2013 19:48:40 -0000 Received: (qmail 14078 invoked from network); 16 Oct 2013 19:47:44 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 16 Oct 2013 19:47:44 -0000 Message-ID: <525EED60.2000404@freebsd.org> Date: Wed, 16 Oct 2013 12:47:44 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: RFC: support for "first boot" rc.d scripts References: <525B258F.3030403@freebsd.org> <41F1219E-4DCC-4B04-A1DC-40038809556B@van-laarhoven.org> <525C210A.2000306@freebsd.org> <1381770007.42859.82.camel@revolution.hippie.lan> In-Reply-To: <1381770007.42859.82.camel@revolution.hippie.lan> X-Enigmail-Version: 1.5.2 Content-Type: multipart/mixed; boundary="------------060902050507040600000606" X-SG-EID: XhyBwObMhraAR+zdwMupjQ6BIqbhdEfc+6p+uBxS7S/F6tz08zFvYUkvTz9x4wti77TJVDj0wFXJynfFhvosVf2/IWPwmq3uxoSUbD9wC2vIgZ/KCRl15gJ4Nhvn4JN1CrCwVmRiheHh9PdnRc5Lizn1HhPyiVDgDvIemql+JTE= Cc: FreeBSD current , freebsd-rc@FreeBSD.org, Nick Hibma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 19:48:44 -0000 This is a multi-part message in MIME format. --------------060902050507040600000606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/14/13 10:00, Ian Lepore wrote: > The embedded systems we create at $work have readonly root and mfs /var, > but we do have writable storage on another filesystem. It would work > for us (not that we need this feature right now) if there were an rcvar > that pointed to the marker file. Of course to make it work, something > would have to get the alternate filesystem mounted early enough to be > useful (that is something we do already with a custom rc script). New patch attached. This one re-probes for the firstboot sentinel after ${early_late_divider}, so you can set firstboot_sentinel to /path/to/my/writable/storage as long as that's available once the boot process reaches FILESYSTEMS (or NETWORKING, or whatever you set early_late_divider to). I figure that if we can assume all the local rc.d scripts are available at that point we can assume that wherever people decide to put the firstboot sentinel will also be available at that point. Does anyone see any problems with this? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid --------------060902050507040600000606 Content-Type: text/plain; charset=us-ascii; name="firstboot.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="firstboot.patch" Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 256432) +++ etc/defaults/rc.conf (working copy) @@ -619,6 +619,9 @@ accounting_enable="NO" # Turn on process accounting (or NO). ibcs2_enable="NO" # Ibcs2 (SCO) emulation loaded at startup (or NO). ibcs2_loaders="coff" # List of additional Ibcs2 loaders (or NO). +firstboot_sentinel="/firstboot" # Scripts with "firstboot" keyword are run if + # this file exists. Should be on a R/W filesystem so + # the file can be deleted after the boot completes. # Emulation/compatibility services provided by /etc/rc.d/abi sysvipc_enable="NO" # Load System V IPC primitives at startup (or NO). Index: etc/rc =================================================================== --- etc/rc (revision 256432) +++ etc/rc (working copy) @@ -82,10 +82,15 @@ fi fi +# If the firstboot sentinel doesn't exist, we want to skip firstboot scripts. +if ! [ -e ${firstboot_sentinel} ]; then + skip_firstboot="-s firstboot" +fi + # Do a first pass to get everything up to $early_late_divider so that # we can do a second pass that includes $local_startup directories # -files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null` +files=`rcorder ${skip} ${skip_firstboot} /etc/rc.d/* 2>/dev/null` _rc_elem_done=' ' for _rc_elem in ${files}; do @@ -107,7 +112,13 @@ *) find_local_scripts_new ;; esac -files=`rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null` +# The firstboot sentinel might be on a newly mounted filesystem; look for it +# again and unset skip_firstboot if we find it. +if [ -e ${firstboot_sentinel} ]; then + skip_firstboot="" +fi + +files=`rcorder ${skip} ${skip_firstboot} /etc/rc.d/* ${local_rc} 2>/dev/null` for _rc_elem in ${files}; do case "$_rc_elem_done" in *" $_rc_elem "*) continue ;; @@ -116,6 +127,15 @@ run_rc_script ${_rc_elem} ${_boot} done +# Remove the firstboot sentinel, and reboot if it was requested. +if [ -e ${firstboot_sentinel} ]; then + rm ${firstboot_sentinel} + if [ -e ${firstboot_sentinel}-reboot ]; then + rm ${firstboot_sentinel}-reboot + kill -INT 1 + fi +fi + echo '' date exit 0 --------------060902050507040600000606-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 22:42:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8982B9B4 for ; Wed, 16 Oct 2013 22:42:29 +0000 (UTC) (envelope-from gibbs@freebsd.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 343B62FCC for ; Wed, 16 Oct 2013 22:42:28 +0000 (UTC) Received: from [192.168.6.145] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.5) with ESMTP id r9GMgDq1083555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 16:42:24 -0600 (MDT) (envelope-from gibbs@freebsd.org) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ZFS secondarycache on SSD problem on r255173 From: "Justin T. Gibbs" In-Reply-To: <20131016080100.GA27758@hell.ukr.net> Date: Wed, 16 Oct 2013 16:42:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> To: Vitalij Satanivskij X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (aslan.scsiguy.com [70.89.174.89]); Wed, 16 Oct 2013 16:42:24 -0600 (MDT) Cc: freebsd-current@freebsd.org, Steven Hartland , Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 22:42:29 -0000 You'll have to be more specific. I don't have that email or know what = list on which to search. Thanks, Justin On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij wrote: > Hello. >=20 > Patch brocke cache functionality. >=20 > Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 >=20 > With subject ZFS L2ARC - incorrect size and abnormal system load on = r255173 >=20 > As patch alredy in head and BETA it's not good. >=20 > Yesterday we update one machine up to beta1 and forgot about patch. So = 12 Hours and cache broken... :(( >=20 >=20 >=20 > Dmitriy Makarov wrote: > DM> The attached patch by Steven Hartland fixes issue for me too. = Thank you!=20 > DM>=20 > DM>=20 > DM> --- =C8=F1=F5=EE=E4=ED=EE=E5 =F1=EE=EE=E1=F9=E5=ED=E8=E5 ---=20 > DM> =CE=F2 =EA=EE=E3=EE: "Steven Hartland" < killing@multiplay.co.uk >=20= > DM> =C4=E0=F2=E0: 18 =F1=E5=ED=F2=FF=E1=F0=FF 2013, 01:53:10=20 > DM>=20 > DM> ----- Original Message -----=20 > DM> From: "Justin T. Gibbs" <=20 > DM>=20 > DM> ---=20 > DM> =C4=EC=E8=F2=F0=E8=E9 =CC=E0=EA=E0=F0=EE=E2=20 > DM> _______________________________________________ > DM> freebsd-current@freebsd.org mailing list > DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current > DM> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 23:27:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E90D94EB for ; Wed, 16 Oct 2013 23:27:19 +0000 (UTC) (envelope-from gibbs@FreeBSD.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9BCC92209 for ; Wed, 16 Oct 2013 23:27:19 +0000 (UTC) Received: from [192.168.6.145] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.5) with ESMTP id r9GNRHUj083893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 17:27:18 -0600 (MDT) (envelope-from gibbs@FreeBSD.org) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ZFS secondarycache on SSD problem on r255173 From: "Justin T. Gibbs" In-Reply-To: <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> Date: Wed, 16 Oct 2013 17:27:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> To: Vitalij Satanivskij X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (aslan.scsiguy.com [70.89.174.89]); Wed, 16 Oct 2013 17:27:18 -0600 (MDT) Cc: freebsd-current@freebsd.org, Steven Hartland , Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 23:27:20 -0000 I took a quick look at arc.c and see that the trim_map_free() calls = don't take into account ashift. I don't know if that has anything to do = with your problem though. I would expect this would just make the trim = less efficient, but I need to dig further. -- Justin On Oct 16, 2013, at 4:42 PM, "Justin T. Gibbs" = wrote: > You'll have to be more specific. I don't have that email or know what = list on which to search. >=20 > Thanks, > Justin >=20 > On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij = wrote: >=20 >> Hello. >>=20 >> Patch brocke cache functionality. >>=20 >> Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 >>=20 >> With subject ZFS L2ARC - incorrect size and abnormal system load on = r255173 >>=20 >> As patch alredy in head and BETA it's not good. >>=20 >> Yesterday we update one machine up to beta1 and forgot about patch. = So 12 Hours and cache broken... :(( >>=20 >>=20 >>=20 >> Dmitriy Makarov wrote: >> DM> The attached patch by Steven Hartland fixes issue for me too. = Thank you!=20 >> DM>=20 >> DM>=20 >> DM> --- =C8=F1=F5=EE=E4=ED=EE=E5 =F1=EE=EE=E1=F9=E5=ED=E8=E5 ---=20 >> DM> =CE=F2 =EA=EE=E3=EE: "Steven Hartland" < killing@multiplay.co.uk = >=20 >> DM> =C4=E0=F2=E0: 18 =F1=E5=ED=F2=FF=E1=F0=FF 2013, 01:53:10=20 >> DM>=20 >> DM> ----- Original Message -----=20 >> DM> From: "Justin T. Gibbs" <=20 >> DM>=20 >> DM> ---=20 >> DM> =C4=EC=E8=F2=F0=E8=E9 =CC=E0=EA=E0=F0=EE=E2=20 >> DM> _______________________________________________ >> DM> freebsd-current@freebsd.org mailing list >> DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> DM> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 23:34:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B27A767C; Wed, 16 Oct 2013 23:34:30 +0000 (UTC) (envelope-from prvs=100105a393=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 27E902268; Wed, 16 Oct 2013 23:34:29 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006424165.msg; Thu, 17 Oct 2013 00:34:25 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Oct 2013 00:34:25 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=100105a393=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Justin T. Gibbs" , "Vitalij Satanivskij" References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Thu, 17 Oct 2013 00:34:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 23:34:30 -0000 ----- Original Message ----- From: "Justin T. Gibbs" > I took a quick look at arc.c and see that the trim_map_free() > calls don't take into account ashift. I don't know if that > has anything to do with your problem though. I would expect > this would just make the trim less efficient, but I need to > dig further. This is actually done by TRIM_ZIO_END in trim_map_free. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Oct 16 23:42:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2B83B8B7; Wed, 16 Oct 2013 23:42:57 +0000 (UTC) (envelope-from prvs=100105a393=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 959AE22F3; Wed, 16 Oct 2013 23:42:56 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006424213.msg; Thu, 17 Oct 2013 00:42:54 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Oct 2013 00:42:54 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=100105a393=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> From: "Steven Hartland" To: "Justin T. Gibbs" , "Vitalij Satanivskij" References: <1379069539.824504225.3b9xwugp@fmst-6.ukr.net> <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Thu, 17 Oct 2013 00:43:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 16 Oct 2013 23:42:57 -0000 Ohh stupid question what hardware are you running this on, specifically what SSD's and what controller and if relavent what controller Firmware version? I wonder if you might have bad HW / FW, such as older LSI mps Firmware, which is know to causing corruption with some delete methods. Without the ashift fixes, you'll be sending short requests to the disk which will then ignore them, so I can see a potential corrilation there. You could rule this out by disabling ZFS TRIM with vfs.zfs.trim.enabled=0 in /boot/loader.conf Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Thu Oct 17 01:11:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB70AB4E; Thu, 17 Oct 2013 01:11:14 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65E452704; Thu, 17 Oct 2013 01:11:14 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id vb8so1324596obc.3 for ; Wed, 16 Oct 2013 18:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7ukFXg9hyM/mVpnmTxymm7E72yqspuyY8FOpqq5IJ9I=; b=vLOevQPjAD/9XahbysPCQ5bzZwDhRQtMMtxsEufUFjq7RMGj+a88S5nY06X6ESJKbu OKudhDkW/9e4TdMVPP8uOcJxklABTK/fmfUpl5kVNaAmJZc/PLukxsOB3xguoq717I0/ v47+8ZXzcmY6BvF0wOvsJnvbXR9B3UpeXYfyygVy8Wc6G4cmrghff42FEu9nmeBxM0Wb NF23fwvwk+vWtRKE4ppbHyQwyRQSVAGx6g62p0vH86JtR3f99X1+7iR/bz5OZ5ys082p nSiQIy3/zubYYNB0qMbcsB1nBPFfLXN3ajZ6o4c3rHsteNAqUvFKy0B0QECuUeKGhRHQ ZorA== MIME-Version: 1.0 X-Received: by 10.182.80.196 with SMTP id t4mr9606568obx.1.1381972273497; Wed, 16 Oct 2013 18:11:13 -0700 (PDT) Received: by 10.76.13.228 with HTTP; Wed, 16 Oct 2013 18:11:13 -0700 (PDT) In-Reply-To: <7c50c939-bfe7-4fcb-b3ef-5c51d4ae8a9c@email.android.com> References: <52571EF6.8010703@gmail.com> <5257DDD1.4070403@gmail.com> <08D4D879-C866-4BEB-BB1D-9579A32F1975@FreeBSD.org> <7c50c939-bfe7-4fcb-b3ef-5c51d4ae8a9c@email.android.com> Date: Wed, 16 Oct 2013 21:11:13 -0400 Message-ID: Subject: Re: [SOLVED] Re: Can't start iscsid - kldload: can't load iscsi: Exec format error - FreeBSD 10 Alpha 2 From: Outback Dingo To: "Miguel C." Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current , =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 17 Oct 2013 01:11:14 -0000 On Fri, Oct 11, 2013 at 11:52 PM, Miguel C. wrote: > I updated to alpha5 it is indeed removed. > > Thanks > > > "Edward Tomasz Napiera=B3a" wrote: > >Dnia 11 pa=BC 2013 o godz. 13:15 "Mike C." > >napisa=B3(a): > > > >> > >>> On 10/11/13 09:24, Edward Tomasz Napiera=B3a wrote: > >>>> Wiadomo=B6=E6 napisana przez Mike C. w dniu 10 pa=BC 2013, o godz. 2= 3:41: > >>>> Hi, > >>>> > >>>> I'm running Alpha-2 and wanted to test with iscsi but it seems I > >can't > >>>> start iscsid. > >>>> > >>>> > >>>> $ sudo service iscsid onerestart > >>>> kldload: can't load iscsi: Exec format error > >>>> /etc/rc.d/iscsid: WARNING: Unable to load kernel module iscsi > >>>> /etc/rc.d/iscsid: WARNING: failed precmd routine for iscsid > >>>> > >>>> > >>>> dmesg shows: > >>>> interface icl.1 already present in the KLD 'kernel'! > >>>> linker_load_file: Unsupported file type > >>> > >>> Do you have "device ctl" in your kernel config? If so, > >>> either remove it (ctl.ko module is automatically loaded > >>> by ctladm), or add "device iscsi". > >> > >> device ctl # CAM Target Layer > >> > >> Seems that GENERIC has it by default! I'll remove and recompile! > > > >Actually, it got removed from GENERIC in 10 some time ago. > Ive actually noticed what i feel is an anomaly with ctladm... i can literally run ctladm create -b block -o file=3D/luns/LUN0 numerous times...... and create a new LUN every time, using the same file. ctladm devlist LUN Backend Size (Blocks) BS Serial Number Device ID san: ~ # ctladm create -b block -o file=3D/mnt/extent6 LUN created successfully backend: block device type: 0 LUN size: 10485760 bytes blocksize 512 bytes LUN ID: 0 Serial Number: MYSERIAL 0 Device ID; MYDEVID 0 san: ~ # ctladm create -b block -o file=3D/mnt/extent6 LUN created successfully backend: block device type: 0 LUN size: 10485760 bytes blocksize 512 bytes LUN ID: 1 Serial Number: MYSERIAL 1 Device ID; MYDEVID 1 san: ~ # ctladm create -b block -o file=3D/mnt/extent6 LUN created successfully backend: block device type: 0 LUN size: 10485760 bytes blocksize 512 bytes LUN ID: 2 Serial Number: MYSERIAL 2 Device ID; MYDEVID 2 san: ~ # ctladm create -b block -o file=3D/mnt/extent6 LUN created successfully backend: block device type: 0 LUN size: 10485760 bytes blocksize 512 bytes LUN ID: 3 Serial Number: MYSERIAL 3 Device ID; MYDEVID 3 san: ~ # ctladm create -b block -o file=3D/mnt/extent6 LUN created successfully backend: block device type: 0 LUN size: 10485760 bytes blocksize 512 bytes LUN ID: 4 Serial Number: MYSERIAL 4 Device ID; MYDEVID 4 san: ~ # ctladm devlist -v LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 20480 512 MYSERIAL 0 MYDEVID 0 lun_type=3D0 num_threads=3D14 file=3D/mnt/extent6 1 block 20480 512 MYSERIAL 1 MYDEVID 1 lun_type=3D0 num_threads=3D14 file=3D/mnt/extent6 2 block 20480 512 MYSERIAL 2 MYDEVID 2 lun_type=3D0 num_threads=3D14 file=3D/mnt/extent6 3 block 20480 512 MYSERIAL 3 MYDEVID 3 lun_type=3D0 num_threads=3D14 file=3D/mnt/extent6 4 block 20480 512 MYSERIAL 4 MYDEVID 4 lun_type=3D0 num_threads=3D14 file=3D/mnt/extent6 notice the same file is used for each LUN...... it appears that ctladm never checks for a LUN using the same file..... or zpool for that matter....... anyway we can "correct" said behavior ?? > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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 Oct 17 05:59:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5D61E86; Thu, 17 Oct 2013 05:59:46 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89C0E2409; Thu, 17 Oct 2013 05:59:46 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VWgcZ-00049W-Fn ; Thu, 17 Oct 2013 08:59:43 +0300 Date: Thu, 17 Oct 2013 08:59:43 +0300 From: Vitalij Satanivskij To: "Justin T. Gibbs" Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131017055943.GA15954@hell.ukr.net> References: <74C1D072-77BB-4D6C-B78F-C8D2731FA0CF@sarenet.es> <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , freebsd-current@freebsd.org, Steven Hartland , Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 17 Oct 2013 05:59:46 -0000 Hello. Problem description is in - http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045088.html As we find later first begin's problem with errors counter in arcstats than size of l2 grows abnormal. After patch rollback everything is ok. Justin T. Gibbs wrote: JTG> You'll have to be more specific. I don't have that email or know what list on which to search. JTG> JTG> Thanks, JTG> Justin JTG> JTG> On Oct 16, 2013, at 2:01 AM, Vitalij Satanivskij wrote: JTG> JTG> > Hello. JTG> > JTG> > Patch brocke cache functionality. JTG> > JTG> > Look at's Dmitriy's mail from Mon, 07 Oct 2013 21:09:06 +0300 JTG> > JTG> > With subject ZFS L2ARC - incorrect size and abnormal system load on r255173 JTG> > JTG> > As patch alredy in head and BETA it's not good. JTG> > JTG> > Yesterday we update one machine up to beta1 and forgot about patch. So 12 Hours and cache broken... :(( JTG> > JTG> > JTG> > JTG> > Dmitriy Makarov wrote: JTG> > DM> The attached patch by Steven Hartland fixes issue for me too. Thank you! JTG> > DM> JTG> > DM> JTG> > DM> --- Èñõîäíîå ñîîáùåíèå --- JTG> > DM> Îò êîãî: "Steven Hartland" < killing@multiplay.co.uk > JTG> > DM> Äàòà: 18 ñåíòÿáðÿ 2013, 01:53:10 JTG> > DM> JTG> > DM> ----- Original Message ----- JTG> > DM> From: "Justin T. Gibbs" < JTG> > DM> JTG> > DM> --- JTG> > DM> Äìèòðèé Ìàêàðîâ JTG> > DM> _______________________________________________ JTG> > DM> freebsd-current@freebsd.org mailing list JTG> > DM> http://lists.freebsd.org/mailman/listinfo/freebsd-current JTG> > DM> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" JTG> > JTG> JTG> _______________________________________________ JTG> freebsd-current@freebsd.org mailing list JTG> http://lists.freebsd.org/mailman/listinfo/freebsd-current JTG> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 17 06:12:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8288D4F6; Thu, 17 Oct 2013 06:12:51 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38A3B24F9; Thu, 17 Oct 2013 06:12:50 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VWgpE-0004KL-MO ; Thu, 17 Oct 2013 09:12:48 +0300 Date: Thu, 17 Oct 2013 09:12:48 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131017061248.GA15980@hell.ukr.net> References: <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 17 Oct 2013 06:12:51 -0000 Hello. SSD is Intel SSD 530 series (INTEL SSDSC2BW180A4 DC12) Controler is onboard intel sata controler, motherboard is Supermicro X9SRL-F so it's Intel C602 chipset All cache ssd connected to sata 2 ports. System has LSI MPS controler (SAS2308) with firmware version - 16.00.00.00, but only hdd's (36 1TB WD RE4 drives) connected to it. Steven Hartland wrote: SH> Ohh stupid question what hardware are you running this on, SH> specifically what SSD's and what controller and if relavent SH> what controller Firmware version? SH> SH> I wonder if you might have bad HW / FW, such as older LSI SH> mps Firmware, which is know to causing corruption with SH> some delete methods. SH> SH> Without the ashift fixes, you'll be sending short requests SH> to the disk which will then ignore them, so I can see a SH> potential corrilation there. SH> SH> You could rule this out by disabling ZFS TRIM with SH> vfs.zfs.trim.enabled=0 in /boot/loader.conf SH> SH> Regards SH> Steve SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> SH> _______________________________________________ SH> freebsd-current@freebsd.org mailing list SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 17 07:30:29 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D97FDAD; Thu, 17 Oct 2013 07:30:29 +0000 (UTC) (envelope-from prvs=1002643260=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7D4C2900; Thu, 17 Oct 2013 07:30:28 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006426275.msg; Thu, 17 Oct 2013 08:30:24 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Oct 2013 08:30:24 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1002643260=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> From: "Steven Hartland" To: "Vitalij Satanivskij" References: <1379333192.127359970.ma5jnbc5@fmst-6.ukr.net> <1379334340.567465877.0b1lli6r@fmst-6.ukr.net> <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Thu, 17 Oct 2013 08:30:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Vitalij Satanivskij , Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 17 Oct 2013 07:30:29 -0000 Still worth testing with the problem version installed but with trim disabled to see if that clears the issues, if nothing else it will confirm / deny if trim is involved. Regards Steve ----- Original Message ----- From: "Vitalij Satanivskij" To: "Steven Hartland" Cc: "Justin T. Gibbs" ; "Vitalij Satanivskij" ; ; "Borja Marcos" ; "Dmitriy Makarov" Sent: Thursday, October 17, 2013 7:12 AM Subject: Re: ZFS secondarycache on SSD problem on r255173 > Hello. > > SSD is Intel SSD 530 series (INTEL SSDSC2BW180A4 DC12) > > Controler is onboard intel sata controler, motherboard is Supermicro X9SRL-F so it's Intel C602 chipset > > All cache ssd connected to sata 2 ports. > > System has LSI MPS controler (SAS2308) with firmware version - 16.00.00.00, but only hdd's (36 1TB WD RE4 drives) > connected to it. > > > Steven Hartland wrote: > SH> Ohh stupid question what hardware are you running this on, > SH> specifically what SSD's and what controller and if relavent > SH> what controller Firmware version? > SH> > SH> I wonder if you might have bad HW / FW, such as older LSI > SH> mps Firmware, which is know to causing corruption with > SH> some delete methods. > SH> > SH> Without the ashift fixes, you'll be sending short requests > SH> to the disk which will then ignore them, so I can see a > SH> potential corrilation there. > SH> > SH> You could rule this out by disabling ZFS TRIM with > SH> vfs.zfs.trim.enabled=0 in /boot/loader.conf > SH> > SH> Regards > SH> Steve > SH> > SH> ================================================ > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any > information contained in it. > SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > SH> or return the E.mail to postmaster@multiplay.co.uk. > SH> > SH> _______________________________________________ > SH> freebsd-current@freebsd.org mailing list > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Thu Oct 17 07:39:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB6C82CC; Thu, 17 Oct 2013 07:39:28 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6168A2990; Thu, 17 Oct 2013 07:39:28 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VWiB3-0009DU-7L ; Thu, 17 Oct 2013 10:39:25 +0300 Date: Thu, 17 Oct 2013 10:39:25 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131017073925.GA34958@hell.ukr.net> References: <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: satan@ukr.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:39:28 -0000 Just to be sure I understand you clearly, I need to test next configuration: 1) System with ashift patch eg. just latest stable/10 revision 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf So realy only diferens in default system configuration is disabled trim functional ? Steven Hartland wrote: SH> Still worth testing with the problem version installed but SH> with trim disabled to see if that clears the issues, if SH> nothing else it will confirm / deny if trim is involved. SH> SH> Regards SH> Steve SH> SH> ----- Original Message ----- SH> From: "Vitalij Satanivskij" SH> To: "Steven Hartland" SH> Cc: "Justin T. Gibbs" ; "Vitalij Satanivskij" ; ; "Borja Marcos" SH> ; "Dmitriy Makarov" SH> Sent: Thursday, October 17, 2013 7:12 AM SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> SH> SH> > Hello. SH> > SH> > SSD is Intel SSD 530 series (INTEL SSDSC2BW180A4 DC12) SH> > SH> > Controler is onboard intel sata controler, motherboard is Supermicro X9SRL-F so it's Intel C602 chipset SH> > SH> > All cache ssd connected to sata 2 ports. SH> > SH> > System has LSI MPS controler (SAS2308) with firmware version - 16.00.00.00, but only hdd's (36 1TB WD RE4 drives) SH> > connected to it. SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> Ohh stupid question what hardware are you running this on, SH> > SH> specifically what SSD's and what controller and if relavent SH> > SH> what controller Firmware version? SH> > SH> SH> > SH> I wonder if you might have bad HW / FW, such as older LSI SH> > SH> mps Firmware, which is know to causing corruption with SH> > SH> some delete methods. SH> > SH> SH> > SH> Without the ashift fixes, you'll be sending short requests SH> > SH> to the disk which will then ignore them, so I can see a SH> > SH> potential corrilation there. SH> > SH> SH> > SH> You could rule this out by disabling ZFS TRIM with SH> > SH> vfs.zfs.trim.enabled=0 in /boot/loader.conf SH> > SH> SH> > SH> Regards SH> > SH> Steve SH> > SH> SH> > SH> ================================================ SH> > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the SH> > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any SH> > information contained in it. SH> > SH> SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> > SH> or return the E.mail to postmaster@multiplay.co.uk. SH> > SH> SH> > SH> _______________________________________________ SH> > SH> freebsd-current@freebsd.org mailing list SH> > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> From owner-freebsd-current@FreeBSD.ORG Thu Oct 17 08:24:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B3A97F28; Thu, 17 Oct 2013 08:24:36 +0000 (UTC) (envelope-from prvs=1002643260=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 232CC2C29; Thu, 17 Oct 2013 08:24:35 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006426592.msg; Thu, 17 Oct 2013 09:24:33 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Oct 2013 09:24:33 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1002643260=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> From: "Steven Hartland" To: References: <8365CE736DC749DF95D0030A725211F6@multiplay.co.uk> <02549AD9-C456-4E17-927C-B4BCC97F8CC8@freebsd.org> <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Thu, 17 Oct 2013 09:24:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Vitalij Satanivskij , Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 17 Oct 2013 08:24:36 -0000 Correct. ----- Original Message ----- From: "Vitalij Satanivskij" > Just to be sure I understand you clearly, I need to test next configuration: > > 1) System with ashift patch eg. just latest stable/10 revision > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf > > So realy only diferens in default system configuration is disabled trim functional ? > > > > Steven Hartland wrote: > SH> Still worth testing with the problem version installed but > SH> with trim disabled to see if that clears the issues, if > SH> nothing else it will confirm / deny if trim is involved. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Thu Oct 17 11:15:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5647233 for ; Thu, 17 Oct 2013 11:15:02 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A871266C for ; Thu, 17 Oct 2013 11:15:02 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id d10so989265eaj.12 for ; Thu, 17 Oct 2013 04:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZlClm0nWFgvXtu0zeVEpt8100oyzOSKqeXtxhv9AUkg=; b=D5F1Z6QWzPPWLpcec6Y6Glz3K41poZ/nlWu2H3ne9hZ+vNJPJ6Kyomgfz34MnQ2mUH i9JuLpvd629ARvVC27dkutf+9GueTRpnDNs13n9pUISE433XJCjcoKIqSu3itF/thq/j g376UzNFpWnB99oI0Ndow32iD/Dab8YJbYkdULAfRKrgisIWgcaYu8rpzZT1uk5F0TiT BVuzs6W3EpsLbLwOGfPSuF5+W+wi6E9TfDZW1kGBBlYhT9QWh0vWjXtNFXEnEoDcHtnU wI7WqkQMOouXuQGsQDuL/t+eiavCBVa7N6GAABahIEHE3Nt8sHLBNM+TwJztcC5yl/ci 3SXg== X-Received: by 10.15.33.132 with SMTP id c4mr12166200eev.2.1382008500927; Thu, 17 Oct 2013 04:15:00 -0700 (PDT) Received: from mini.home (adfy44.neoplus.adsl.tpnet.pl. [79.184.128.44]) by mx.google.com with ESMTPSA id h45sm191557649eeg.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 04:15:00 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [SOLVED] Can't start iscsid - kldload: can't load iscsi: Exec format error - FreeBSD 10 Alpha 2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Thu, 17 Oct 2013 13:14:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24483E07-AF51-4E90-A374-C3BA5E279AA9@freebsd.org> References: <52571EF6.8010703@gmail.com> <5257DDD1.4070403@gmail.com> <08D4D879-C866-4BEB-BB1D-9579A32F1975@FreeBSD.org> <7c50c939-bfe7-4fcb-b3ef-5c51d4ae8a9c@email.android.com> To: Outback Dingo X-Mailer: Apple Mail (2.1510) Cc: freebsd-current , "Miguel C." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 17 Oct 2013 11:15:02 -0000 Wiadomo=B6=E6 napisana przez Outback Dingo w = dniu 17 pa=BC 2013, o godz. 03:11: [..] > Ive actually noticed what i feel is an anomaly with ctladm... i can = literally > run ctladm create -b block -o file=3D/luns/LUN0 numerous times...... = and create a new LUN > every time, using the same file. >=20 > ctladm devlist > LUN Backend Size (Blocks) BS Serial Number Device ID=20 > san: ~ # ctladm create -b block -o file=3D/mnt/extent6 > LUN created successfully > backend: block > device type: 0 > LUN size: 10485760 bytes > blocksize 512 bytes > LUN ID: 0 > Serial Number: MYSERIAL 0 > Device ID; MYDEVID 0 > san: ~ # ctladm create -b block -o file=3D/mnt/extent6 > LUN created successfully > backend: block > device type: 0 > LUN size: 10485760 bytes > blocksize 512 bytes > LUN ID: 1 > Serial Number: MYSERIAL 1 > Device ID; MYDEVID 1 [..] > notice the same file is used for each LUN...... it appears that ctladm = never checks for a LUN using the same file..... or zpool for that = matter....... anyway we can "correct" said behavior ?? Not really, because in some cases that's exactly what you want. That's = why ctld(8) only warns about it when running with debugging enabled. From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 00:22:03 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9BCBB357; Fri, 18 Oct 2013 00:22:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 565192D6C; Fri, 18 Oct 2013 00:22:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9I0LubE066998; Thu, 17 Oct 2013 20:21:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9I0Luku066990; Fri, 18 Oct 2013 00:21:56 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Oct 2013 00:21:56 GMT Message-Id: <201310180021.r9I0Luku066990@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 00:22:03 -0000 TB --- 2013-10-17 21:40:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-17 21:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-17 21:40:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-10-17 21:40:20 - cleaning the object tree TB --- 2013-10-17 21:40:20 - /usr/local/bin/svn stat /src TB --- 2013-10-17 21:40:25 - At svn revision 256708 TB --- 2013-10-17 21:40:26 - building world TB --- 2013-10-17 21:40:26 - CROSS_BUILD_TESTING=YES TB --- 2013-10-17 21:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-17 21:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-17 21:40:26 - SRCCONF=/dev/null TB --- 2013-10-17 21:40:26 - TARGET=arm TB --- 2013-10-17 21:40:26 - TARGET_ARCH=arm TB --- 2013-10-17 21:40:26 - TZ=UTC TB --- 2013-10-17 21:40:26 - __MAKE_CONF=/dev/null TB --- 2013-10-17 21:40:26 - cd /src TB --- 2013-10-17 21:40:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Oct 17 21:40:35 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/arm.arm/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /src/sbin/route/route.c /src/sbin/route/route.c:1763:21: error: format specifies type 'long' but the argument has type 'long long' [-Werror,-Wformat] printf("%8ld%c\n", rtm->rtm_rmx.rmx_expire - ts.tv_sec, lock(EXPIRE)); ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %8lld 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/route *** Error code 1 Stop. bmake[4]: stopped in /obj/arm.arm/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-18 00:21:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-18 00:21:56 - ERROR: failed to build world TB --- 2013-10-18 00:21:56 - 7900.77 user 1362.10 system 9695.61 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 00:22:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0904C450; Fri, 18 Oct 2013 00:22:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA10C2D6F; Fri, 18 Oct 2013 00:22:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9I0LvLO067065; Thu, 17 Oct 2013 20:21:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9I0Lv9B067064; Fri, 18 Oct 2013 00:21:57 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Oct 2013 00:21:57 GMT Message-Id: <201310180021.r9I0Lv9B067064@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on armv6/arm Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 00:22:08 -0000 TB --- 2013-10-17 21:40:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-17 21:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-17 21:40:20 - starting HEAD tinderbox run for armv6/arm TB --- 2013-10-17 21:40:20 - cleaning the object tree TB --- 2013-10-17 21:40:20 - /usr/local/bin/svn stat /src TB --- 2013-10-17 21:40:25 - At svn revision 256708 TB --- 2013-10-17 21:40:26 - building world TB --- 2013-10-17 21:40:26 - CROSS_BUILD_TESTING=YES TB --- 2013-10-17 21:40:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-17 21:40:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-17 21:40:26 - SRCCONF=/dev/null TB --- 2013-10-17 21:40:26 - TARGET=arm TB --- 2013-10-17 21:40:26 - TARGET_ARCH=armv6 TB --- 2013-10-17 21:40:26 - TZ=UTC TB --- 2013-10-17 21:40:26 - __MAKE_CONF=/dev/null TB --- 2013-10-17 21:40:26 - cd /src TB --- 2013-10-17 21:40:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Oct 17 21:40:35 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/arm.armv6/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -c /src/sbin/route/route.c /src/sbin/route/route.c:1763:21: error: format specifies type 'long' but the argument has type 'long long' [-Werror,-Wformat] printf("%8ld%c\n", rtm->rtm_rmx.rmx_expire - ts.tv_sec, lock(EXPIRE)); ~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %8lld 1 error generated. *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/route *** Error code 1 Stop. bmake[4]: stopped in /obj/arm.armv6/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-18 00:21:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-18 00:21:57 - ERROR: failed to build world TB --- 2013-10-18 00:21:57 - 7906.07 user 1360.92 system 9697.06 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 03:45:08 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E01AB4F9; Fri, 18 Oct 2013 03:45:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99DB627DF; Fri, 18 Oct 2013 03:45:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9I3j6xW034723; Thu, 17 Oct 2013 23:45:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9I3j6V4034714; Fri, 18 Oct 2013 03:45:06 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Oct 2013 03:45:06 GMT Message-Id: <201310180345.r9I3j6V4034714@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 03:45:08 -0000 TB --- 2013-10-18 02:55:47 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-18 02:55:47 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-18 02:55:47 - starting HEAD tinderbox run for mips/mips TB --- 2013-10-18 02:55:47 - cleaning the object tree TB --- 2013-10-18 02:55:47 - /usr/local/bin/svn stat /src TB --- 2013-10-18 02:55:55 - At svn revision 256708 TB --- 2013-10-18 02:55:56 - building world TB --- 2013-10-18 02:55:56 - CROSS_BUILD_TESTING=YES TB --- 2013-10-18 02:55:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-18 02:55:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-18 02:55:56 - SRCCONF=/dev/null TB --- 2013-10-18 02:55:56 - TARGET=mips TB --- 2013-10-18 02:55:56 - TARGET_ARCH=mips TB --- 2013-10-18 02:55:56 - TZ=UTC TB --- 2013-10-18 02:55:56 - __MAKE_CONF=/dev/null TB --- 2013-10-18 02:55:56 - cd /src TB --- 2013-10-18 02:55:56 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Oct 18 02:56:03 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] LC_ALL=C awk '!/^#|^$/ { printf "#define\tK_%s\t%d\n\t{\"%s\", K_%s},\n", toupper($1), ++L, $1, toupper($1); }' < /src/sbin/route/keywords > keywords.h || (rm -f keywords.h; false) rm -f .depend CC='cc ' mkdep -f .depend -a -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 /src/sbin/route/route.c echo route: /obj/mips.mips/src/tmp/usr/lib/libc.a >> .depend cc -O -pipe -G0 -DNS -DINET -DINET6 -I. -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/route/route.c cc1: warnings being treated as errors /src/sbin/route/route.c: In function 'print_getmsg': /src/sbin/route/route.c:1763: warning: format '%8ld' expects type 'long int', but argument 2 has type 'time_t' *** Error code 1 Stop. bmake[5]: stopped in /src/sbin/route *** Error code 1 Stop. bmake[4]: stopped in /obj/mips.mips/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-18 03:45:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-18 03:45:06 - ERROR: failed to build world TB --- 2013-10-18 03:45:06 - 2109.44 user 592.21 system 2958.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 08:01:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 17548AC3; Fri, 18 Oct 2013 08:01:59 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C14C228C5; Fri, 18 Oct 2013 08:01:58 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VX50G-000JmC-Vx ; Fri, 18 Oct 2013 11:01:49 +0300 Date: Fri, 18 Oct 2013 11:01:48 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131018080148.GA75226@hell.ukr.net> References: <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: satan@ukr.net, "Justin T. Gibbs" , freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 08:01:59 -0000 Hello. Yesterday system was rebooted with vfs.zfs.trim.enabled=0 System version 10.0-BETA1 FreeBSD 10.0-BETA1 #6 r256669, without any changes in code Uptime 10:51 up 16:41 sysctl vfs.zfs.trim.enabled vfs.zfs.trim.enabled: 0 Around 2 hours ago errors counter's kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 kstat.zfs.misc.arcstats.l2_io_error: 38254 begin grow from zero values. After remove cache 2013-10-18.10:37:10 zpool remove disk1 gpt/cache0 gpt/cache1 gpt/cache2 and attach again 2013-10-18.10:38:28 zpool add disk1 cache gpt/cache0 gpt/cache1 gpt/cache2 counters stop growing (of couse thay not zeroed) before cache remove kstat.zfs.misc.arcstats.l2_asize was around 280GB hw size of l2 cache is 3x164G => 34 351651821 ada3 GPT (168G) 34 6 - free - (3.0K) 40 8388608 1 zil2 (4.0G) 8388648 343263200 2 cache2 (164G) 351651848 7 - free - (3.5K) Any hypothesis what alse we can test/try etc? Steven Hartland wrote: SH> Correct. SH> ----- Original Message ----- SH> From: "Vitalij Satanivskij" SH> SH> SH> > Just to be sure I understand you clearly, I need to test next configuration: SH> > SH> > 1) System with ashift patch eg. just latest stable/10 revision SH> > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf SH> > SH> > So realy only diferens in default system configuration is disabled trim functional ? SH> > SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> Still worth testing with the problem version installed but SH> > SH> with trim disabled to see if that clears the issues, if SH> > SH> nothing else it will confirm / deny if trim is involved. SH> SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> SH> _______________________________________________ SH> freebsd-current@freebsd.org mailing list SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 12:15:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3A5893CF for ; Fri, 18 Oct 2013 12:15:23 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D6D52B85 for ; Fri, 18 Oct 2013 12:15:23 +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 v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 2EBB46102 for ; Fri, 18 Oct 2013 08:15:15 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=nHUgBa/V4OBwmA4p1jOdoUsPyUMyQrM4kdGmxyJnygqddKdrry/ywgjAXzqv+cMjq jslyYLqQDNGlGlXTLHIKcqBoCL28JeD0Yv4aizY/RjjHNDlYqHAwOPHqFva2VOq Message-ID: <52612651.9000001@protected-networks.net> Date: Fri, 18 Oct 2013 08:15:13 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: FreeBSD Current Subject: gcc kernel build fail @ SVN r256730 X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 12:15:23 -0000 -current kernel compiled with gcc fails with: cc1: warnings being treated as errors /usr/src/sys/geom/label/g_label.c: In function 'g_label_resize': /usr/src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** [g_label.o] Error code 1 From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 12:36:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C9C452F9; Fri, 18 Oct 2013 12:36:21 +0000 (UTC) (envelope-from prvs=1003132fe8=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A9052D43; Fri, 18 Oct 2013 12:36:20 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006442601.msg; Fri, 18 Oct 2013 13:36:12 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 18 Oct 2013 13:36:12 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1003132fe8=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <256B2E5A0BA44DCBB45BB3F3E820E190@multiplay.co.uk> From: "Steven Hartland" To: "Vitalij Satanivskij" References: <4AA28730F331444AB13108ABF0CD68B7@multiplay.co.uk> <1379496242.750778745.m0ksff1m@fmst-6.ukr.net> <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> <20131018080148.GA75226@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Fri, 18 Oct 2013 13:36:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: satan@ukr.net, Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 12:36:21 -0000 Hmm so that rules out a TRIM related issue. I wonder if the increase in ashift has triggered a problem in compression. What are all the values reported by: sysctl -a kstat.zfs.misc.arcstats Regards Steve ----- Original Message ----- From: "Vitalij Satanivskij" To: "Steven Hartland" Cc: ; "Justin T. Gibbs" ; ; "Borja Marcos" ; "Dmitriy Makarov" Sent: Friday, October 18, 2013 9:01 AM Subject: Re: ZFS secondarycache on SSD problem on r255173 > Hello. > > Yesterday system was rebooted with vfs.zfs.trim.enabled=0 > > System version 10.0-BETA1 FreeBSD 10.0-BETA1 #6 r256669, without any changes in code > > Uptime 10:51 up 16:41 > > sysctl vfs.zfs.trim.enabled > vfs.zfs.trim.enabled: 0 > > Around 2 hours ago errors counter's > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 > kstat.zfs.misc.arcstats.l2_io_error: 38254 > > begin grow from zero values. > > After remove cache > 2013-10-18.10:37:10 zpool remove disk1 gpt/cache0 gpt/cache1 gpt/cache2 > > and attach again > > 2013-10-18.10:38:28 zpool add disk1 cache gpt/cache0 gpt/cache1 gpt/cache2 > > counters stop growing (of couse thay not zeroed) > > before cache remove kstat.zfs.misc.arcstats.l2_asize was around 280GB > > hw size of l2 cache is 3x164G > > => 34 351651821 ada3 GPT (168G) > 34 6 - free - (3.0K) > 40 8388608 1 zil2 (4.0G) > 8388648 343263200 2 cache2 (164G) > 351651848 7 - free - (3.5K) > > > Any hypothesis what alse we can test/try etc? > > > > Steven Hartland wrote: > SH> Correct. > SH> ----- Original Message ----- > SH> From: "Vitalij Satanivskij" > SH> > SH> > SH> > Just to be sure I understand you clearly, I need to test next configuration: > SH> > > SH> > 1) System with ashift patch eg. just latest stable/10 revision > SH> > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf > SH> > > SH> > So realy only diferens in default system configuration is disabled trim functional ? > SH> > > SH> > > SH> > > SH> > Steven Hartland wrote: > SH> > SH> Still worth testing with the problem version installed but > SH> > SH> with trim disabled to see if that clears the issues, if > SH> > SH> nothing else it will confirm / deny if trim is involved. > SH> > SH> > SH> ================================================ > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any > information contained in it. > SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > SH> or return the E.mail to postmaster@multiplay.co.uk. > SH> > SH> _______________________________________________ > SH> freebsd-current@freebsd.org mailing list > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > 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 e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 14:45:28 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F181C6AA; Fri, 18 Oct 2013 14:45:27 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A870A2748; Fri, 18 Oct 2013 14:45:27 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VXBIr-000Ics-0X ; Fri, 18 Oct 2013 17:45:25 +0300 Date: Fri, 18 Oct 2013 17:45:24 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131018144524.GA30018@hell.ukr.net> References: <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> <20131018080148.GA75226@hell.ukr.net> <256B2E5A0BA44DCBB45BB3F3E820E190@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <256B2E5A0BA44DCBB45BB3F3E820E190@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , "Justin T. Gibbs" , freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 14:45:28 -0000 Just right now stats not to actual because of some another test. Test is simply all gpart information destroyed from ssd and They used as raw cache devices. Just 2013-10-18.11:30:49 zpool add disk1 cache /dev/ada1 /dev/ada2 /dev/ada3 So sizes at last l2_size and l2_asize in not actual. But heare it is: kstat.zfs.misc.arcstats.hits: 5178174063 kstat.zfs.misc.arcstats.misses: 57690806 kstat.zfs.misc.arcstats.demand_data_hits: 313995744 kstat.zfs.misc.arcstats.demand_data_misses: 37414740 kstat.zfs.misc.arcstats.demand_metadata_hits: 4719242892 kstat.zfs.misc.arcstats.demand_metadata_misses: 9266394 kstat.zfs.misc.arcstats.prefetch_data_hits: 1182495 kstat.zfs.misc.arcstats.prefetch_data_misses: 9951733 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 143752935 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1057939 kstat.zfs.misc.arcstats.mru_hits: 118609738 kstat.zfs.misc.arcstats.mru_ghost_hits: 1895486 kstat.zfs.misc.arcstats.mfu_hits: 4914673425 kstat.zfs.misc.arcstats.mfu_ghost_hits: 14537497 kstat.zfs.misc.arcstats.allocated: 103796455 kstat.zfs.misc.arcstats.deleted: 40168100 kstat.zfs.misc.arcstats.stolen: 20832742 kstat.zfs.misc.arcstats.recycle_miss: 15663428 kstat.zfs.misc.arcstats.mutex_miss: 1456781 kstat.zfs.misc.arcstats.evict_skip: 25960184 kstat.zfs.misc.arcstats.evict_l2_cached: 891379153920 kstat.zfs.misc.arcstats.evict_l2_eligible: 50578438144 kstat.zfs.misc.arcstats.evict_l2_ineligible: 956055729664 kstat.zfs.misc.arcstats.hash_elements: 8693451 kstat.zfs.misc.arcstats.hash_elements_max: 14369414 kstat.zfs.misc.arcstats.hash_collisions: 90967764 kstat.zfs.misc.arcstats.hash_chains: 1891463 kstat.zfs.misc.arcstats.hash_chain_max: 24 kstat.zfs.misc.arcstats.p: 73170954752 kstat.zfs.misc.arcstats.c: 85899345920 kstat.zfs.misc.arcstats.c_min: 42949672960 kstat.zfs.misc.arcstats.c_max: 85899345920 kstat.zfs.misc.arcstats.size: 85899263104 kstat.zfs.misc.arcstats.hdr_size: 1425948696 kstat.zfs.misc.arcstats.data_size: 77769994240 kstat.zfs.misc.arcstats.other_size: 6056233632 kstat.zfs.misc.arcstats.l2_hits: 21725934 kstat.zfs.misc.arcstats.l2_misses: 35876251 kstat.zfs.misc.arcstats.l2_feeds: 130197 kstat.zfs.misc.arcstats.l2_rw_clash: 110181 kstat.zfs.misc.arcstats.l2_read_bytes: 391282009600 kstat.zfs.misc.arcstats.l2_write_bytes: 1098703347712 kstat.zfs.misc.arcstats.l2_writes_sent: 130037 kstat.zfs.misc.arcstats.l2_writes_done: 130037 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 375921 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 331 kstat.zfs.misc.arcstats.l2_evict_reading: 43 kstat.zfs.misc.arcstats.l2_free_on_write: 255730 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 kstat.zfs.misc.arcstats.l2_io_error: 38254 kstat.zfs.misc.arcstats.l2_size: 136696884736 kstat.zfs.misc.arcstats.l2_asize: 131427690496 kstat.zfs.misc.arcstats.l2_hdr_size: 742951208 kstat.zfs.misc.arcstats.l2_compress_successes: 5565311 kstat.zfs.misc.arcstats.l2_compress_zeros: 0 kstat.zfs.misc.arcstats.l2_compress_failures: 0 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 325157131 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 4897854 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 115704249 kstat.zfs.misc.arcstats.l2_write_in_l2: 15114214372 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 63417 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 3291593934 kstat.zfs.misc.arcstats.l2_write_full: 47672 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 130197 kstat.zfs.misc.arcstats.l2_write_pios: 130037 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 369077156457472 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 8015080 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 79825 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.arcstats.duplicate_buffers: 0 kstat.zfs.misc.arcstats.duplicate_buffers_size: 0 kstat.zfs.misc.arcstats.duplicate_reads: 0 Values of --------------------------------- kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 kstat.zfs.misc.arcstats.l2_io_error: 38254 -------------------------------- not growing from last cache reconfiguration, just wait some time to see - maybe problem disapers :) Steven Hartland wrote: SH> Hmm so that rules out a TRIM related issue. I wonder if the SH> increase in ashift has triggered a problem in compression. SH> SH> What are all the values reported by: SH> sysctl -a kstat.zfs.misc.arcstats SH> SH> Regards SH> Steve SH> SH> ----- Original Message ----- SH> From: "Vitalij Satanivskij" SH> To: "Steven Hartland" SH> Cc: ; "Justin T. Gibbs" ; ; "Borja Marcos" ; SH> "Dmitriy Makarov" SH> Sent: Friday, October 18, 2013 9:01 AM SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> SH> SH> > Hello. SH> > SH> > Yesterday system was rebooted with vfs.zfs.trim.enabled=0 SH> > SH> > System version 10.0-BETA1 FreeBSD 10.0-BETA1 #6 r256669, without any changes in code SH> > SH> > Uptime 10:51 up 16:41 SH> > SH> > sysctl vfs.zfs.trim.enabled SH> > vfs.zfs.trim.enabled: 0 SH> > SH> > Around 2 hours ago errors counter's SH> > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 SH> > kstat.zfs.misc.arcstats.l2_io_error: 38254 SH> > SH> > begin grow from zero values. SH> > SH> > After remove cache SH> > 2013-10-18.10:37:10 zpool remove disk1 gpt/cache0 gpt/cache1 gpt/cache2 SH> > SH> > and attach again SH> > SH> > 2013-10-18.10:38:28 zpool add disk1 cache gpt/cache0 gpt/cache1 gpt/cache2 SH> > SH> > counters stop growing (of couse thay not zeroed) SH> > SH> > before cache remove kstat.zfs.misc.arcstats.l2_asize was around 280GB SH> > SH> > hw size of l2 cache is 3x164G SH> > SH> > => 34 351651821 ada3 GPT (168G) SH> > 34 6 - free - (3.0K) SH> > 40 8388608 1 zil2 (4.0G) SH> > 8388648 343263200 2 cache2 (164G) SH> > 351651848 7 - free - (3.5K) SH> > SH> > SH> > Any hypothesis what alse we can test/try etc? SH> > SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> Correct. SH> > SH> ----- Original Message ----- SH> > SH> From: "Vitalij Satanivskij" SH> > SH> SH> > SH> SH> > SH> > Just to be sure I understand you clearly, I need to test next configuration: SH> > SH> > SH> > SH> > 1) System with ashift patch eg. just latest stable/10 revision SH> > SH> > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf SH> > SH> > SH> > SH> > So realy only diferens in default system configuration is disabled trim functional ? SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> > SH> Still worth testing with the problem version installed but SH> > SH> > SH> with trim disabled to see if that clears the issues, if SH> > SH> > SH> nothing else it will confirm / deny if trim is involved. SH> > SH> SH> > SH> SH> > SH> ================================================ SH> > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the SH> > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any SH> > information contained in it. SH> > SH> SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> > SH> or return the E.mail to postmaster@multiplay.co.uk. SH> > SH> SH> > SH> _______________________________________________ SH> > SH> freebsd-current@freebsd.org mailing list SH> > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > _______________________________________________ SH> > freebsd-current@freebsd.org mailing list SH> > http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> SH> _______________________________________________ SH> freebsd-current@freebsd.org mailing list SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 14:57:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21339F4C; Fri, 18 Oct 2013 14:57:01 +0000 (UTC) (envelope-from prvs=1003132fe8=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B16F2854; Fri, 18 Oct 2013 14:57:00 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006443294.msg; Fri, 18 Oct 2013 15:56:57 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 18 Oct 2013 15:56:57 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1003132fe8=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4459A6FAB7B8445C97CCB9EFF34FD4F0@multiplay.co.uk> From: "Steven Hartland" To: "Vitalij Satanivskij" References: <20131016080100.GA27758@hell.ukr.net> <3A44A8F6-8B62-4A23-819D-B91A3E6E5EF9@freebsd.org> <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> <20131018080148.GA75226@hell.ukr.net> <256B2E5A0BA44DCBB45BB3F3E820E190@multiplay.co.uk> <20131018144524.GA30018@hell.ukr.net> Subject: Re: ZFS secondarycache on SSD problem on r255173 Date: Fri, 18 Oct 2013 15:57:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Vitalij Satanivskij , "Justin T. Gibbs" , freebsd-current@freebsd.org, Borja Marcos , Dmitriy Makarov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 14:57:01 -0000 Looking at the l2arc compression code I believe that metadata is always compressed with lz4, even if compression is off on all datasets. This is backed up by what I'm seeing on my system here as it shows a non-zero l2_compress_successes value even though I'm not using compression at all. I think we we may well need the following patch to set the minblock size based on the vdev ashift and not SPA_MINBLOCKSIZE. svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision 256554) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy) @@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr) len = l2hdr->b_asize; cdata = zio_data_buf_alloc(len); csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr->b_tmp_cdata, - cdata, l2hdr->b_asize, (size_t)SPA_MINBLOCKSIZE); + cdata, l2hdr->b_asize, (size_t)(1ULL << l2hdr->b_dev->l2ad_vdev->vdev_ashift)); if (csize == 0) { /* zero block, indicate that there's nothing to write */ Could you try this patch on your system Vitalij see if it has any effect on the number of l2_cksum_bad / l2_io_error? Regards Steve ----- Original Message ----- From: "Vitalij Satanivskij" To: "Steven Hartland" Cc: "Vitalij Satanivskij" ; "Dmitriy Makarov" ; "Justin T. Gibbs" ; "Borja Marcos" ; Sent: Friday, October 18, 2013 3:45 PM Subject: Re: ZFS secondarycache on SSD problem on r255173 > > Just right now stats not to actual because of some another test. > > Test is simply all gpart information destroyed from ssd and > > They used as raw cache devices. Just > 2013-10-18.11:30:49 zpool add disk1 cache /dev/ada1 /dev/ada2 /dev/ada3 > > So sizes at last l2_size and l2_asize in not actual. > > But heare it is: > > kstat.zfs.misc.arcstats.hits: 5178174063 > kstat.zfs.misc.arcstats.misses: 57690806 > kstat.zfs.misc.arcstats.demand_data_hits: 313995744 > kstat.zfs.misc.arcstats.demand_data_misses: 37414740 > kstat.zfs.misc.arcstats.demand_metadata_hits: 4719242892 > kstat.zfs.misc.arcstats.demand_metadata_misses: 9266394 > kstat.zfs.misc.arcstats.prefetch_data_hits: 1182495 > kstat.zfs.misc.arcstats.prefetch_data_misses: 9951733 > kstat.zfs.misc.arcstats.prefetch_metadata_hits: 143752935 > kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1057939 > kstat.zfs.misc.arcstats.mru_hits: 118609738 > kstat.zfs.misc.arcstats.mru_ghost_hits: 1895486 > kstat.zfs.misc.arcstats.mfu_hits: 4914673425 > kstat.zfs.misc.arcstats.mfu_ghost_hits: 14537497 > kstat.zfs.misc.arcstats.allocated: 103796455 > kstat.zfs.misc.arcstats.deleted: 40168100 > kstat.zfs.misc.arcstats.stolen: 20832742 > kstat.zfs.misc.arcstats.recycle_miss: 15663428 > kstat.zfs.misc.arcstats.mutex_miss: 1456781 > kstat.zfs.misc.arcstats.evict_skip: 25960184 > kstat.zfs.misc.arcstats.evict_l2_cached: 891379153920 > kstat.zfs.misc.arcstats.evict_l2_eligible: 50578438144 > kstat.zfs.misc.arcstats.evict_l2_ineligible: 956055729664 > kstat.zfs.misc.arcstats.hash_elements: 8693451 > kstat.zfs.misc.arcstats.hash_elements_max: 14369414 > kstat.zfs.misc.arcstats.hash_collisions: 90967764 > kstat.zfs.misc.arcstats.hash_chains: 1891463 > kstat.zfs.misc.arcstats.hash_chain_max: 24 > kstat.zfs.misc.arcstats.p: 73170954752 > kstat.zfs.misc.arcstats.c: 85899345920 > kstat.zfs.misc.arcstats.c_min: 42949672960 > kstat.zfs.misc.arcstats.c_max: 85899345920 > kstat.zfs.misc.arcstats.size: 85899263104 > kstat.zfs.misc.arcstats.hdr_size: 1425948696 > kstat.zfs.misc.arcstats.data_size: 77769994240 > kstat.zfs.misc.arcstats.other_size: 6056233632 > kstat.zfs.misc.arcstats.l2_hits: 21725934 > kstat.zfs.misc.arcstats.l2_misses: 35876251 > kstat.zfs.misc.arcstats.l2_feeds: 130197 > kstat.zfs.misc.arcstats.l2_rw_clash: 110181 > kstat.zfs.misc.arcstats.l2_read_bytes: 391282009600 > kstat.zfs.misc.arcstats.l2_write_bytes: 1098703347712 > kstat.zfs.misc.arcstats.l2_writes_sent: 130037 > kstat.zfs.misc.arcstats.l2_writes_done: 130037 > kstat.zfs.misc.arcstats.l2_writes_error: 0 > kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 375921 > kstat.zfs.misc.arcstats.l2_evict_lock_retry: 331 > kstat.zfs.misc.arcstats.l2_evict_reading: 43 > kstat.zfs.misc.arcstats.l2_free_on_write: 255730 > kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 > kstat.zfs.misc.arcstats.l2_io_error: 38254 > kstat.zfs.misc.arcstats.l2_size: 136696884736 > kstat.zfs.misc.arcstats.l2_asize: 131427690496 > kstat.zfs.misc.arcstats.l2_hdr_size: 742951208 > kstat.zfs.misc.arcstats.l2_compress_successes: 5565311 > kstat.zfs.misc.arcstats.l2_compress_zeros: 0 > kstat.zfs.misc.arcstats.l2_compress_failures: 0 > kstat.zfs.misc.arcstats.l2_write_trylock_fail: 325157131 > kstat.zfs.misc.arcstats.l2_write_passed_headroom: 4897854 > kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 115704249 > kstat.zfs.misc.arcstats.l2_write_in_l2: 15114214372 > kstat.zfs.misc.arcstats.l2_write_io_in_progress: 63417 > kstat.zfs.misc.arcstats.l2_write_not_cacheable: 3291593934 > kstat.zfs.misc.arcstats.l2_write_full: 47672 > kstat.zfs.misc.arcstats.l2_write_buffer_iter: 130197 > kstat.zfs.misc.arcstats.l2_write_pios: 130037 > kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 369077156457472 > kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 8015080 > kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 79825 > kstat.zfs.misc.arcstats.memory_throttle_count: 0 > kstat.zfs.misc.arcstats.duplicate_buffers: 0 > kstat.zfs.misc.arcstats.duplicate_buffers_size: 0 > kstat.zfs.misc.arcstats.duplicate_reads: 0 > > > Values of > --------------------------------- > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 > kstat.zfs.misc.arcstats.l2_io_error: 38254 > -------------------------------- > > not growing from last cache reconfiguration, just wait some time to see - maybe problem disapers :) > > > > > > > Steven Hartland wrote: > SH> Hmm so that rules out a TRIM related issue. I wonder if the > SH> increase in ashift has triggered a problem in compression. > SH> > SH> What are all the values reported by: > SH> sysctl -a kstat.zfs.misc.arcstats > SH> > SH> Regards > SH> Steve > SH> > SH> ----- Original Message ----- > SH> From: "Vitalij Satanivskij" > SH> To: "Steven Hartland" > SH> Cc: ; "Justin T. Gibbs" ; ; "Borja Marcos" > ; > SH> "Dmitriy Makarov" > SH> Sent: Friday, October 18, 2013 9:01 AM > SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 > SH> > SH> > SH> > Hello. > SH> > > SH> > Yesterday system was rebooted with vfs.zfs.trim.enabled=0 > SH> > > SH> > System version 10.0-BETA1 FreeBSD 10.0-BETA1 #6 r256669, without any changes in code > SH> > > SH> > Uptime 10:51 up 16:41 > SH> > > SH> > sysctl vfs.zfs.trim.enabled > SH> > vfs.zfs.trim.enabled: 0 > SH> > > SH> > Around 2 hours ago errors counter's > SH> > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 > SH> > kstat.zfs.misc.arcstats.l2_io_error: 38254 > SH> > > SH> > begin grow from zero values. > SH> > > SH> > After remove cache > SH> > 2013-10-18.10:37:10 zpool remove disk1 gpt/cache0 gpt/cache1 gpt/cache2 > SH> > > SH> > and attach again > SH> > > SH> > 2013-10-18.10:38:28 zpool add disk1 cache gpt/cache0 gpt/cache1 gpt/cache2 > SH> > > SH> > counters stop growing (of couse thay not zeroed) > SH> > > SH> > before cache remove kstat.zfs.misc.arcstats.l2_asize was around 280GB > SH> > > SH> > hw size of l2 cache is 3x164G > SH> > > SH> > => 34 351651821 ada3 GPT (168G) > SH> > 34 6 - free - (3.0K) > SH> > 40 8388608 1 zil2 (4.0G) > SH> > 8388648 343263200 2 cache2 (164G) > SH> > 351651848 7 - free - (3.5K) > SH> > > SH> > > SH> > Any hypothesis what alse we can test/try etc? > SH> > > SH> > > SH> > > SH> > Steven Hartland wrote: > SH> > SH> Correct. > SH> > SH> ----- Original Message ----- > SH> > SH> From: "Vitalij Satanivskij" > SH> > SH> > SH> > SH> > SH> > SH> > Just to be sure I understand you clearly, I need to test next configuration: > SH> > SH> > > SH> > SH> > 1) System with ashift patch eg. just latest stable/10 revision > SH> > SH> > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf > SH> > SH> > > SH> > SH> > So realy only diferens in default system configuration is disabled trim functional ? > SH> > SH> > > SH> > SH> > > SH> > SH> > > SH> > SH> > Steven Hartland wrote: > SH> > SH> > SH> Still worth testing with the problem version installed but > SH> > SH> > SH> with trim disabled to see if that clears the issues, if > SH> > SH> > SH> nothing else it will confirm / deny if trim is involved. > SH> > SH> > SH> > SH> > SH> > SH> ================================================ > SH> > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. > In the > SH> > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any > SH> > information contained in it. > SH> > SH> > SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > SH> > SH> or return the E.mail to postmaster@multiplay.co.uk. > SH> > SH> > SH> > SH> _______________________________________________ > SH> > SH> freebsd-current@freebsd.org mailing list > SH> > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > SH> > _______________________________________________ > SH> > freebsd-current@freebsd.org mailing list > SH> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > SH> > > SH> > SH> > SH> ================================================ > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any > information contained in it. > SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > SH> or return the E.mail to postmaster@multiplay.co.uk. > SH> > SH> _______________________________________________ > SH> freebsd-current@freebsd.org mailing list > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 18:00:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5465D0; Fri, 18 Oct 2013 18:00:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77E7C249A; Fri, 18 Oct 2013 18:00:21 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so2090258qen.20 for ; Fri, 18 Oct 2013 11:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=rTd67h0ktdRFATINDm8x7hISSmoWFUVLUkUypL168BE=; b=Ht6nnXo8S0sbnedWfgwA178vnf4NxtErU0co3PNex3tZvKiTXF8LUOWNdOAEFVRPDt S6v+QrojMzf0o8cEWZnGOeLcbS+fUnYkDX5g4lgHtjRwN0pZF1JD3xSUFJWNLLM3z1aF kcS5gak4OfRCEAM0kQsDe5/QR0VAbc8fgkXXCi4bBFy3KykO7Jh1hfm1KHzpyI+5FRiE +KfNnG8Vph/QGZ5p3JO4caJJXeMJetaHVTo3f/D/a8MIvLtuLoSzS7bAEi6wIcCTV3Yc BrnKj5BFLDBsz0DpkxaF1lUBofiO2mSmbsVPHJPydwdtbXib5c1MPz+3upGW+9CJBTZB 4mPg== MIME-Version: 1.0 X-Received: by 10.224.157.14 with SMTP id z14mr6403087qaw.90.1382119220640; Fri, 18 Oct 2013 11:00:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 18 Oct 2013 11:00:20 -0700 (PDT) Date: Fri, 18 Oct 2013 11:00:20 -0700 X-Google-Sender-Auth: FZrzP8rMpkhObh7lbHyPnoa3uX8 Message-ID: Subject: [rfc] removing the NDISulator From: Adrian Chadd To: "freebsd-wireless@freebsd.org" , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 18:00:21 -0000 Hi all, I'd like to remove the NDISulator. I've had many requests to update it to the latest NDIS version and support more of the 64 bit wifi drivers. But, to be perfectly honest, I have no desire to keep hacking at this. The world has changed quite a bit - we can port/reimplement drivers from Linux and other BSDs. So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and target to have it removed by 11.0-RELEASE. I'd rather see more of an effort writing new drivers and porting drivers from other operating systems. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 19:39:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 067305BB; Fri, 18 Oct 2013 19:39:32 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCCB029AC; Fri, 18 Oct 2013 19:39:31 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r9IJdUt3004301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Oct 2013 14:39:30 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Fri, 18 Oct 2013 14:39:29 -0500 From: "Teske, Devin" To: Julian Elischer Subject: Re: BE Loader Menu (was Re: rcs) Thread-Topic: BE Loader Menu (was Re: rcs) Thread-Index: AQHOxRG5GlF59UAvJ06VyRjwWpYzrQ== Date: Fri, 18 Oct 2013 19:39:28 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC7ADA3@LTCFISWMSGMB21.FNFIS.com> References: <60177810-8DC4-4EA3-8040-A834B79039D2@orthanc.ca> <52538EDC.2080001@freebsd.org> <52541202.3010707@mu.org> <20131008.170444.74714516.sthaug@nethelp.no> <52542BD4.5070706@FreeBSD.org> <52542E1D.9000000@mu.org> <52555D1C.8010407@freebsd.org> <52558577.5020401@allanjude.com> <52558779.2070203@pcbsd.org> <13CA24D6AB415D428143D44749F57D720FC4B2A3@LTCFISWMSGMB21.FNFIS.com> <5256D08F.5060101@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC50D64@LTCFISWMSGMB21.FNFIS.com> <5256D8E9.10200@freebsd.org> In-Reply-To: <5256D8E9.10200@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56A6A0697349644A87C4935E92246647@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18,2013-10-18,1970-01-01 signatures=0 Cc: Devin Teske , FreeBSD Current , "Teske, Devin" , Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:39:32 -0000 On Oct 10, 2013, at 9:42 AM, Julian Elischer wrote: > On 10/11/13 12:39 AM, Teske, Devin wrote: >> On Oct 10, 2013, at 9:06 AM, Julian Elischer wrote: >>=20 >>> On 10/10/13 1:05 AM, Teske, Devin wrote: >>>> I'm late to the party again ;D (didn't realize the rcs thread had turn= ed BE) >>>>=20 >>>> Both problems can be solved. >>>> The loading of the kernel *after* choosing your boot device is trivial. >>>> We've been doing it at $work for *years* (almost a decade?) >>>>=20 >>>> I can put that in, whenever. Probably at the same time as implementing >>>> the live/dynamic BE menus for selecting the root device. >>> yeah it always pisses me of when the menu comes up after the kernel is = loaded because 99% of the time, I'm in the menu because I want to boot a DI= FFERENT kernel.. >>>=20 >> Same thought I had about 7 years ago. After hearing that others >> (especially you, Julian) think the same thoughts... >>=20 >> I'm happily ready to merge a patch from VICOR to achieve this. > PLEASE!.. put it up for review somewhere... >=20 Done... http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ All new code. Had to make it programmable: http://twitpic.com/dhv2b6 See that the patch adds documentation for loader.conf(5). It also clarifies a horrible description of "start" versus "initialize" in = loader.4th(8). > I wonder if we can we get a reviewboard instance for the project some tim= e? >=20 Do let me know what you think. I went all-out on this one. --=20 Devin P.S. I probably hadn't have put so much thought into this one if it hadn't = been specifically you asking ;D but I think you know that. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 20:54:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 853AC55C; Fri, 18 Oct 2013 20:54:05 +0000 (UTC) (envelope-from swills@mouf.net) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 484A12D43; Fri, 18 Oct 2013 20:54:05 +0000 (UTC) Received: from mouf.net (swills@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id r9IKrtMo049810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Oct 2013 20:54:00 GMT (envelope-from swills@mouf.net) Received: (from swills@localhost) by mouf.net (8.14.5/8.14.5/Submit) id r9IKrtUv049809; Fri, 18 Oct 2013 20:53:55 GMT (envelope-from swills) Date: Fri, 18 Oct 2013 20:53:54 +0000 From: Steve Wills To: Adrian Chadd Subject: Re: [rfc] removing the NDISulator Message-ID: <20131018205352.GA44565@mouf.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Fri, 18 Oct 2013 20:54:00 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.97.8 at mouf.net X-Virus-Status: Clean Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 20:54:05 -0000 I would love to have a native driver for this: none2@pci0:2:0:0: class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4313 802.11b/g/n Wireless LAN Controller' class = network Are there docs or other drivers available that we could look at? Steve On Fri, Oct 18, 2013 at 11:00:20AM -0700, Adrian Chadd wrote: > Hi all, > > I'd like to remove the NDISulator. I've had many requests to update it to > the latest NDIS version and support more of the 64 bit wifi drivers. But, > to be perfectly honest, I have no desire to keep hacking at this. The world > has changed quite a bit - we can port/reimplement drivers from Linux and > other BSDs. > > So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and > target to have it removed by 11.0-RELEASE. > > I'd rather see more of an effort writing new drivers and porting drivers > from other operating systems. > > Thanks, > > > > -adrian > _______________________________________________ > 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 Oct 18 21:03:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 390E27A1; Fri, 18 Oct 2013 21:03:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 180A42DC1; Fri, 18 Oct 2013 21:03:42 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r9IL1NHo033851; Fri, 18 Oct 2013 14:01:23 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r9IL1Nw1033850; Fri, 18 Oct 2013 14:01:23 -0700 (PDT) (envelope-from sgk) Date: Fri, 18 Oct 2013 14:01:23 -0700 From: Steve Kargl To: Steve Wills Subject: Re: [rfc] removing the NDISulator Message-ID: <20131018210123.GA33820@troutmask.apl.washington.edu> References: <20131018205352.GA44565@mouf.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131018205352.GA44565@mouf.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 21:03:42 -0000 On Fri, Oct 18, 2013 at 08:53:54PM +0000, Steve Wills wrote: > I would love to have a native driver for this: > > none2@pci0:2:0:0: > class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4313 802.11b/g/n Wireless LAN Controller' > class = network > > Are there docs or other drivers available that we could look at? > Please, don't top post as it loses context. http://www.broadcom.com/support/802.11/linux_sta.php -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 21:19:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4154B89; Fri, 18 Oct 2013 21:19:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 502622E6C; Fri, 18 Oct 2013 21:19:43 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id l13so3055458qcy.4 for ; Fri, 18 Oct 2013 14:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GcK0YYwJebYhFttu/1LoilDccL5i7B7dWs12Sr2iMbc=; b=zxAOf4xXlUWe4PR1kGSseA/PnByKTxIKpSYtlRPJO5bfXWM2bx6cSqZ2g2gpaHskzo EHg3uf0edknuKEaZkHEVPgdeWWmAlgBpIG1I/J8IeyHrrDyA6mB3UzuwPlrd4ljKMEQx w+4LjW3tUeCtncD0KU7cT7MrgI+/JMxP+Z0n+HivbiDAyjGytIgNNB7j/PDRScbTP7if BDQX+0ttnONQbM7X9KCSsIDe6z0+kLvqwWVWcYS/qw2ptjCUnvNOoUq6euUpbIRqfzy6 Sh8xxCOYzjyEt7YBMuiJ9Y120M7VO36bSv92JK3yut4ihin9/d3DJSjOEz2vAMXKam1R poSg== MIME-Version: 1.0 X-Received: by 10.224.63.199 with SMTP id c7mr7512029qai.74.1382131182489; Fri, 18 Oct 2013 14:19:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 18 Oct 2013 14:19:42 -0700 (PDT) In-Reply-To: <20131018205352.GA44565@mouf.net> References: <20131018205352.GA44565@mouf.net> Date: Fri, 18 Oct 2013 14:19:42 -0700 X-Google-Sender-Auth: puR7MLhvYeacnC7KXvTOjgUt7mk Message-ID: Subject: Re: [rfc] removing the NDISulator From: Adrian Chadd To: Steve Wills Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 21:19:43 -0000 Hi, On 18 October 2013 13:53, Steve Wills wrote: > I would love to have a native driver for this: > > none2@pci0:2:0:0: class=0x028000 card=0x00101028 chip=0x472714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4313 802.11b/g/n Wireless LAN Controller' > class = network > > Are there docs or other drivers available that we could look at? > There's multiple broadcom drivers in/for the linux kernel: * b43, the reverse engineered one, from the community * brcmsmac - the softmac broadcom driver, from broadcom * the STA only binary driver from broadcom, closed source, not in the kernel. I'd really like to see bwi/bwn maintained and have support added for the later hardware. Thanks, -adrian From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 21:26:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E1079E33; Fri, 18 Oct 2013 21:26:30 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id B09AF2EC8; Fri, 18 Oct 2013 21:26:30 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 72D2C5838F; Fri, 18 Oct 2013 16:04:17 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id Trv3U1yb7+MC; Fri, 18 Oct 2013 16:04:17 -0500 (CDT) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 4C9CB5838D; Fri, 18 Oct 2013 16:04:17 -0500 (CDT) Message-ID: <5261A251.4000806@freebsd.org> Date: Fri, 18 Oct 2013 16:04:17 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Steve Kargl , Steve Wills Subject: Re: [rfc] removing the NDISulator References: <20131018205352.GA44565@mouf.net> <20131018210123.GA33820@troutmask.apl.washington.edu> In-Reply-To: <20131018210123.GA33820@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 21:26:31 -0000 On 10/18/13 16:01, Steve Kargl wrote: > On Fri, Oct 18, 2013 at 08:53:54PM +0000, Steve Wills wrote: >> I would love to have a native driver for this: >> >> none2@pci0:2:0:0: >> class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM4313 802.11b/g/n Wireless LAN Controller' >> class = network >> >> Are there docs or other drivers available that we could look at? >> > Please, don't top post as it loses context. > > http://www.broadcom.com/support/802.11/linux_sta.php > Have you looked at bwn(4)? It might just need an additional PCI ID. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 21:51:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5E066C6; Fri, 18 Oct 2013 21:51:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FB1920B7; Fri, 18 Oct 2013 21:51:56 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id x12so3130537qcv.28 for ; Fri, 18 Oct 2013 14:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TKvbT2qXyk86K7kBLHhGuGXAxd6ywhGedwtJPjK1dk0=; b=f4I4naPQieiQ52Ytwu8zy1mPj+m7jHH0iMZJMyTDQIGO9ZXj8H/YL8/+xZoTzDMiV3 lIL9t/3gtiOvjVe9IsG3Z5AIU29VK7T7ls1qVXId6QpzoRmCCQrexCORSx1wReHKRcx2 +MyZOoBebqMP5LhgBG1CCKZSVt/YrdTcvoX0MYqIKMWrgecyZisWVdy3gpxmsF6B5/P/ eguPmgvOuXioS7VT5E/5WrNw4eJZG9V5wd2OSge5zIywZ7hEdWwyEt1QMYUvGbplYAku Ejtwn3nuU18eSgFd9ObF/hX2Z/sDFpB8luNMa/0T5kpeIL65udiIvlfCh4lngMx12GCV V+yg== MIME-Version: 1.0 X-Received: by 10.49.103.161 with SMTP id fx1mr7036566qeb.68.1382133115614; Fri, 18 Oct 2013 14:51:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 18 Oct 2013 14:51:55 -0700 (PDT) In-Reply-To: <5261A251.4000806@freebsd.org> References: <20131018205352.GA44565@mouf.net> <20131018210123.GA33820@troutmask.apl.washington.edu> <5261A251.4000806@freebsd.org> Date: Fri, 18 Oct 2013 14:51:55 -0700 X-Google-Sender-Auth: JQKT1PXwGFWebkNLk0PxQYgtDuE Message-ID: Subject: Re: [rfc] removing the NDISulator From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Steve Wills , "freebsd-wireless@freebsd.org" , Steve Kargl , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 21:51:57 -0000 bwn(4) requires a lot more than just an additional PCI ID. The driver is somewhat architected for all the different RF and PHY modules that plug into the internal bus (the whole SIBA thing) but it does sorely need updating. Thanks, -adrian On 18 October 2013 14:04, Nathan Whitehorn wrote: > On 10/18/13 16:01, Steve Kargl wrote: > >> On Fri, Oct 18, 2013 at 08:53:54PM +0000, Steve Wills wrote: >> >>> I would love to have a native driver for this: >>> >>> none2@pci0:2:0:0: >>> class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00 >>> vendor = 'Broadcom Corporation' >>> device = 'BCM4313 802.11b/g/n Wireless LAN Controller' >>> class = network >>> >>> Are there docs or other drivers available that we could look at? >>> >>> Please, don't top post as it loses context. >> >> http://www.broadcom.com/**support/802.11/linux_sta.php >> >> > Have you looked at bwn(4)? It might just need an additional PCI ID. > -Nathan > From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 22:47:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 10D91669; Fri, 18 Oct 2013 22:47:37 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EE24023E4; Fri, 18 Oct 2013 22:47:36 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 364371A3CDC; Fri, 18 Oct 2013 15:47:35 -0700 (PDT) Message-ID: <5261BA8E.4080803@mu.org> Date: Fri, 18 Oct 2013 15:47:42 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Nathan Whitehorn , Steve Kargl , Steve Wills Subject: Re: [rfc] removing the NDISulator References: <20131018205352.GA44565@mouf.net> <20131018210123.GA33820@troutmask.apl.washington.edu> <5261A251.4000806@freebsd.org> In-Reply-To: <5261A251.4000806@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 22:47:37 -0000 On 10/18/13 2:04 PM, Nathan Whitehorn wrote: > On 10/18/13 16:01, Steve Kargl wrote: >> On Fri, Oct 18, 2013 at 08:53:54PM +0000, Steve Wills wrote: >>> I would love to have a native driver for this: >>> >>> none2@pci0:2:0:0: >>> class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00 >>> vendor = 'Broadcom Corporation' >>> device = 'BCM4313 802.11b/g/n Wireless LAN Controller' >>> class = network >>> >>> Are there docs or other drivers available that we could look at? >>> >> Please, don't top post as it loses context. >> >> http://www.broadcom.com/support/802.11/linux_sta.php >> > > Have you looked at bwn(4)? It might just need an additional PCI ID. > -Nathan > I'm having no love with if_bwn. Any tips on making it work better? I have -current as of ~2 weeks ago. -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Fri Oct 18 23:17:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29E8AFEF; Fri, 18 Oct 2013 23:17:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A96CF256E; Fri, 18 Oct 2013 23:17:24 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id k15so1143105qaq.19 for ; Fri, 18 Oct 2013 16:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bhZ3HiR/1whzInSiDH1wprM12AMXDk6FDNBPpJvPn4s=; b=DJ1KCbehaaSh+VcGZV7VdnbnRAny4YOOqm9xLsFW7K5LRMK+4Tr2rHwm34J48HfMsp iFmuvyc6wQzMdnZksnWEHjGJBckcXwjAwRFGeNirQqmu7IVuL3mEQ4sCxKlc6w50vifU UaV+ZGNmdZ/Z+p+5NBhrQQ5Fi2t5S4KA+aBArpMjsQFVLNF7yUDMJiRDExUxEdk0xrPC zQI+42eXFyjhhphO6UhlinpAEncp5BcszsPUqQL8wxqE9tOo4TXsb2Y/Zf12pScu1jHL kWkbBl+n5PTT4hzDyilglWHcZ3XxvhDqjoSF4M05K+Mus9m0e+cgl8c8mlXH4Hn5gQZ1 pg+Q== MIME-Version: 1.0 X-Received: by 10.224.63.199 with SMTP id c7mr8032699qai.74.1382138243888; Fri, 18 Oct 2013 16:17:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 18 Oct 2013 16:17:23 -0700 (PDT) In-Reply-To: <5261BA8E.4080803@mu.org> References: <20131018205352.GA44565@mouf.net> <20131018210123.GA33820@troutmask.apl.washington.edu> <5261A251.4000806@freebsd.org> <5261BA8E.4080803@mu.org> Date: Fri, 18 Oct 2013 16:17:23 -0700 X-Google-Sender-Auth: -nyOGYUYuxPyWVlBiNvMDOup0VI Message-ID: Subject: Re: [rfc] removing the NDISulator From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Steve Wills , "freebsd-wireless@freebsd.org" , Nathan Whitehorn , Steve Kargl , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 18 Oct 2013 23:17:25 -0000 I don't know how many times i can say "it needs a maintainer" and "it needs updating." So yeah, it needs (a) a maintainer, (b) updating. -adrian On 18 October 2013 15:47, Alfred Perlstein wrote: > On 10/18/13 2:04 PM, Nathan Whitehorn wrote: > >> On 10/18/13 16:01, Steve Kargl wrote: >> >>> On Fri, Oct 18, 2013 at 08:53:54PM +0000, Steve Wills wrote: >>> >>>> I would love to have a native driver for this: >>>> >>>> none2@pci0:2:0:0: >>>> class=0x028000 card=0x00101028 chip=0x472714e4 rev=0x01 hdr=0x00 >>>> vendor = 'Broadcom Corporation' >>>> device = 'BCM4313 802.11b/g/n Wireless LAN Controller' >>>> class = network >>>> >>>> Are there docs or other drivers available that we could look at? >>>> >>>> Please, don't top post as it loses context. >>> >>> http://www.broadcom.com/**support/802.11/linux_sta.php >>> >>> >> Have you looked at bwn(4)? It might just need an additional PCI ID. >> -Nathan >> >> I'm having no love with if_bwn. Any tips on making it work better? > > I have -current as of ~2 weeks ago. > > -- > Alfred Perlstein > > From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 03:23:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F3708E1; Sat, 19 Oct 2013 03:23:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5502E2FFB; Sat, 19 Oct 2013 03:23:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9J3NK2s038122; Fri, 18 Oct 2013 23:23:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9J3NKpL038107; Sat, 19 Oct 2013 03:23:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 03:23:20 GMT Message-Id: <201310190323.r9J3NKpL038107@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 03:23:30 -0000 TB --- 2013-10-19 01:35:56 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 01:35:56 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 01:35:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-10-19 01:35:56 - cleaning the object tree TB --- 2013-10-19 01:35:56 - /usr/local/bin/svn stat /src TB --- 2013-10-19 01:35:59 - At svn revision 256751 TB --- 2013-10-19 01:36:00 - building world TB --- 2013-10-19 01:36:00 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 01:36:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 01:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 01:36:00 - SRCCONF=/dev/null TB --- 2013-10-19 01:36:00 - TARGET=ia64 TB --- 2013-10-19 01:36:00 - TARGET_ARCH=ia64 TB --- 2013-10-19 01:36:00 - TZ=UTC TB --- 2013-10-19 01:36:00 - __MAKE_CONF=/dev/null TB --- 2013-10-19 01:36:00 - cd /src TB --- 2013-10-19 01:36:00 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 01:36:07 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 03:10:06 UTC 2013 TB --- 2013-10-19 03:10:06 - generating LINT kernel config TB --- 2013-10-19 03:10:06 - cd /src/sys/ia64/conf TB --- 2013-10-19 03:10:06 - /usr/bin/make -B LINT TB --- 2013-10-19 03:10:06 - cd /src/sys/ia64/conf TB --- 2013-10-19 03:10:06 - /usr/sbin/config -m LINT TB --- 2013-10-19 03:10:06 - building LINT kernel TB --- 2013-10-19 03:10:06 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 03:10:06 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 03:10:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 03:10:06 - SRCCONF=/dev/null TB --- 2013-10-19 03:10:06 - TARGET=ia64 TB --- 2013-10-19 03:10:06 - TARGET_ARCH=ia64 TB --- 2013-10-19 03:10:06 - TZ=UTC TB --- 2013-10-19 03:10:06 - __MAKE_CONF=/dev/null TB --- 2013-10-19 03:10:06 - cd /src TB --- 2013-10-19 03:10:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 19 03:10:06 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/geom_vfs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/geom_vol_ffs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/journal/g_journal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/journal/g_journal_ufs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 03:23:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 03:23:20 - ERROR: failed to build LINT kernel TB --- 2013-10-19 03:23:20 - 5194.45 user 885.11 system 6443.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 04:49:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 832B45E0; Sat, 19 Oct 2013 04:49:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C5962457; Sat, 19 Oct 2013 04:49:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9J4nbFm064083; Sat, 19 Oct 2013 00:49:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9J4nbDL064082; Sat, 19 Oct 2013 04:49:37 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 04:49:37 GMT Message-Id: <201310190449.r9J4nbDL064082@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 04:49:42 -0000 TB --- 2013-10-19 03:31:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 03:31:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 03:31:17 - starting HEAD tinderbox run for mips64/mips TB --- 2013-10-19 03:31:17 - cleaning the object tree TB --- 2013-10-19 03:31:17 - /usr/local/bin/svn stat /src TB --- 2013-10-19 03:31:20 - At svn revision 256751 TB --- 2013-10-19 03:31:21 - building world TB --- 2013-10-19 03:31:21 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 03:31:21 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 03:31:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 03:31:21 - SRCCONF=/dev/null TB --- 2013-10-19 03:31:21 - TARGET=mips TB --- 2013-10-19 03:31:21 - TARGET_ARCH=mips64 TB --- 2013-10-19 03:31:21 - TZ=UTC TB --- 2013-10-19 03:31:21 - __MAKE_CONF=/dev/null TB --- 2013-10-19 03:31:21 - cd /src TB --- 2013-10-19 03:31:21 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 03:31:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 04:33:38 UTC 2013 TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m ADM5120 TB --- 2013-10-19 04:33:38 - skipping ADM5120 kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m ALCHEMY TB --- 2013-10-19 04:33:38 - skipping ALCHEMY kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AP121 TB --- 2013-10-19 04:33:38 - skipping AP121 kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AP91 TB --- 2013-10-19 04:33:38 - skipping AP91 kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AP93 TB --- 2013-10-19 04:33:38 - skipping AP93 kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AP94 TB --- 2013-10-19 04:33:38 - skipping AP94 kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AP96 TB --- 2013-10-19 04:33:38 - skipping AP96 kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-10-19 04:33:38 - skipping AR71XX_BASE kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AR724X_BASE TB --- 2013-10-19 04:33:38 - skipping AR724X_BASE kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-10-19 04:33:38 - skipping AR91XX_BASE kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AR933X_BASE TB --- 2013-10-19 04:33:38 - skipping AR933X_BASE kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m AR934X_BASE TB --- 2013-10-19 04:33:38 - skipping AR934X_BASE kernel TB --- 2013-10-19 04:33:38 - cd /src/sys/mips/conf TB --- 2013-10-19 04:33:38 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-10-19 04:33:38 - building BERI_DE4_MDROOT kernel TB --- 2013-10-19 04:33:38 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:33:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:33:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:33:38 - SRCCONF=/dev/null TB --- 2013-10-19 04:33:38 - TARGET=mips TB --- 2013-10-19 04:33:38 - TARGET_ARCH=mips64 TB --- 2013-10-19 04:33:38 - TZ=UTC TB --- 2013-10-19 04:33:38 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:33:38 - cd /src TB --- 2013-10-19 04:33:38 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sat Oct 19 04:33:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Sat Oct 19 04:36:05 UTC 2013 TB --- 2013-10-19 04:36:05 - cd /src/sys/mips/conf TB --- 2013-10-19 04:36:05 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-10-19 04:36:05 - building BERI_DE4_SDROOT kernel TB --- 2013-10-19 04:36:05 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:36:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:36:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:36:05 - SRCCONF=/dev/null TB --- 2013-10-19 04:36:05 - TARGET=mips TB --- 2013-10-19 04:36:05 - TARGET_ARCH=mips64 TB --- 2013-10-19 04:36:05 - TZ=UTC TB --- 2013-10-19 04:36:05 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:36:05 - cd /src TB --- 2013-10-19 04:36:05 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Sat Oct 19 04:36:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_SDROOT completed on Sat Oct 19 04:38:31 UTC 2013 TB --- 2013-10-19 04:38:31 - cd /src/sys/mips/conf TB --- 2013-10-19 04:38:31 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-10-19 04:38:31 - building BERI_SIM_MDROOT kernel TB --- 2013-10-19 04:38:31 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:38:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:38:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:38:31 - SRCCONF=/dev/null TB --- 2013-10-19 04:38:31 - TARGET=mips TB --- 2013-10-19 04:38:31 - TARGET_ARCH=mips64 TB --- 2013-10-19 04:38:31 - TZ=UTC TB --- 2013-10-19 04:38:31 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:38:31 - cd /src TB --- 2013-10-19 04:38:31 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Sat Oct 19 04:38:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_MDROOT completed on Sat Oct 19 04:40:57 UTC 2013 TB --- 2013-10-19 04:40:57 - cd /src/sys/mips/conf TB --- 2013-10-19 04:40:57 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-10-19 04:40:57 - building BERI_TEMPLATE kernel TB --- 2013-10-19 04:40:57 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:40:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:40:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:40:57 - SRCCONF=/dev/null TB --- 2013-10-19 04:40:57 - TARGET=mips TB --- 2013-10-19 04:40:57 - TARGET_ARCH=mips64 TB --- 2013-10-19 04:40:57 - TZ=UTC TB --- 2013-10-19 04:40:57 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:40:57 - cd /src TB --- 2013-10-19 04:40:57 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Sat Oct 19 04:40:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_TEMPLATE completed on Sat Oct 19 04:43:17 UTC 2013 TB --- 2013-10-19 04:43:17 - cd /src/sys/mips/conf TB --- 2013-10-19 04:43:17 - /usr/sbin/config -m CARAMBOLA2 TB --- 2013-10-19 04:43:17 - skipping CARAMBOLA2 kernel TB --- 2013-10-19 04:43:17 - cd /src/sys/mips/conf TB --- 2013-10-19 04:43:17 - /usr/sbin/config -m DB120 TB --- 2013-10-19 04:43:17 - skipping DB120 kernel TB --- 2013-10-19 04:43:17 - cd /src/sys/mips/conf TB --- 2013-10-19 04:43:17 - /usr/sbin/config -m DIR-825 TB --- 2013-10-19 04:43:17 - skipping DIR-825 kernel TB --- 2013-10-19 04:43:17 - cd /src/sys/mips/conf TB --- 2013-10-19 04:43:17 - /usr/sbin/config -m ENH200 TB --- 2013-10-19 04:43:17 - skipping ENH200 kernel TB --- 2013-10-19 04:43:17 - cd /src/sys/mips/conf TB --- 2013-10-19 04:43:17 - /usr/sbin/config -m GXEMUL TB --- 2013-10-19 04:43:17 - building GXEMUL kernel TB --- 2013-10-19 04:43:17 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:43:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:43:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:43:17 - SRCCONF=/dev/null TB --- 2013-10-19 04:43:17 - TARGET=mips TB --- 2013-10-19 04:43:17 - TARGET_ARCH=mips64 TB --- 2013-10-19 04:43:17 - TZ=UTC TB --- 2013-10-19 04:43:17 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:43:17 - cd /src TB --- 2013-10-19 04:43:17 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Sat Oct 19 04:43:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GXEMUL completed on Sat Oct 19 04:45:20 UTC 2013 TB --- 2013-10-19 04:45:20 - cd /src/sys/mips/conf TB --- 2013-10-19 04:45:20 - /usr/sbin/config -m GXEMUL32 TB --- 2013-10-19 04:45:20 - skipping GXEMUL32 kernel TB --- 2013-10-19 04:45:20 - cd /src/sys/mips/conf TB --- 2013-10-19 04:45:20 - /usr/sbin/config -m IDT TB --- 2013-10-19 04:45:20 - skipping IDT kernel TB --- 2013-10-19 04:45:20 - cd /src/sys/mips/conf TB --- 2013-10-19 04:45:20 - /usr/sbin/config -m MALTA TB --- 2013-10-19 04:45:20 - skipping MALTA kernel TB --- 2013-10-19 04:45:20 - cd /src/sys/mips/conf TB --- 2013-10-19 04:45:20 - /usr/sbin/config -m MALTA64 TB --- 2013-10-19 04:45:20 - skipping MALTA64 kernel TB --- 2013-10-19 04:45:20 - cd /src/sys/mips/conf TB --- 2013-10-19 04:45:20 - /usr/sbin/config -m OCTEON1 TB --- 2013-10-19 04:45:20 - building OCTEON1 kernel TB --- 2013-10-19 04:45:20 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:45:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:45:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:45:20 - SRCCONF=/dev/null TB --- 2013-10-19 04:45:20 - TARGET=mips TB --- 2013-10-19 04:45:20 - TARGET_ARCH=mips64 TB --- 2013-10-19 04:45:20 - TZ=UTC TB --- 2013-10-19 04:45:20 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:45:20 - cd /src TB --- 2013-10-19 04:45:20 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Sat Oct 19 04:45:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_slice.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_subr.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_vfs.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips64/src/sys/OCTEON1 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 04:49:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 04:49:37 - ERROR: failed to build OCTEON1 kernel TB --- 2013-10-19 04:49:37 - 3506.51 user 816.32 system 4700.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 06:01:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99452D06 for ; Sat, 19 Oct 2013 06:01:47 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6444127E4 for ; Sat, 19 Oct 2013 06:01:47 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:42053] helo=localhost) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 81/4D-19454-84022625; Sat, 19 Oct 2013 06:01:45 +0000 Date: Sat, 19 Oct 2013 06:01:44 +0000 Message-ID: <81.4D.19454.84022625@cdptpa-oedge03> From: "Thomas Mueller" To: freebsd-wireless@freebsd.org References: Subject: Re: [rfc] removing the NDISulator X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Cc: Adrian Chadd , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 06:01:47 -0000 > I'd like to remove the NDISulator. I've had many requests to update it to > the latest NDIS version and support more of the 64 bit wifi drivers. But, > to be perfectly honest, I have no desire to keep hacking at this. The world > has changed quite a bit - we can port/reimplement drivers from Linux and > other BSDs. > So I plan on deorbiting it - I'll mark it deprecated during 11-HEAD and > target to have it removed by 11.0-RELEASE. > I'd rather see more of an effort writing new drivers and porting drivers > from other operating systems. > Thanks, > -adrian I too would like to see more effort writing new Ethernet and wifi drivers and porting from other operating systems. But I would like to keep the NDISulator/NDISwrapper as a fallback. There are still wifi adapters, Ethernet too, where there is no FreeBSD driver (AR9271 for instance), or the FreeBSD driver is buggy. Realtek 8111E on MSI Z77 MPOWER motherboard is one case in point: good with NetBSD-current and Linux but not OpenBSD 5.3 LiveUSB or FreeBSD. I see FreeBSD 10.0-to-be has a bigger selection of drivers than 9.2. I don't see improvements so far in 11-HEAD over 10.0-BETA1, but that's because 11-HEAD is at a very early stage. Regarding NDISulator, I see that it seems nowadays that many MS-Windows driver packages, when unzipped, have setup.exe, some .ini files, some .cab and .hdr files but no .inf and .sys files necessary for the NDISulator. Presumably these files are created/unpacked when the driver is installed in MS-Windows. Tom From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 06:27:50 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AFF1B2B5; Sat, 19 Oct 2013 06:27:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B29528C8; Sat, 19 Oct 2013 06:27:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9J6Rn49071961; Sat, 19 Oct 2013 02:27:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9J6Rm2T071956; Sat, 19 Oct 2013 06:27:48 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 06:27:48 GMT Message-Id: <201310190627.r9J6Rm2T071956@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 06:27:50 -0000 TB --- 2013-10-19 03:35:27 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 03:35:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 03:35:27 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-10-19 03:35:27 - cleaning the object tree TB --- 2013-10-19 03:35:27 - /usr/local/bin/svn stat /src TB --- 2013-10-19 03:35:30 - At svn revision 256751 TB --- 2013-10-19 03:35:31 - building world TB --- 2013-10-19 03:35:31 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 03:35:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 03:35:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 03:35:31 - SRCCONF=/dev/null TB --- 2013-10-19 03:35:31 - TARGET=powerpc TB --- 2013-10-19 03:35:31 - TARGET_ARCH=powerpc TB --- 2013-10-19 03:35:31 - TZ=UTC TB --- 2013-10-19 03:35:31 - __MAKE_CONF=/dev/null TB --- 2013-10-19 03:35:31 - cd /src TB --- 2013-10-19 03:35:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 03:35:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 06:19:41 UTC 2013 TB --- 2013-10-19 06:19:41 - generating LINT kernel config TB --- 2013-10-19 06:19:41 - cd /src/sys/powerpc/conf TB --- 2013-10-19 06:19:41 - /usr/bin/make -B LINT TB --- 2013-10-19 06:19:41 - cd /src/sys/powerpc/conf TB --- 2013-10-19 06:19:41 - /usr/sbin/config -m LINT TB --- 2013-10-19 06:19:41 - building LINT kernel TB --- 2013-10-19 06:19:41 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 06:19:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 06:19:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 06:19:41 - SRCCONF=/dev/null TB --- 2013-10-19 06:19:41 - TARGET=powerpc TB --- 2013-10-19 06:19:41 - TARGET_ARCH=powerpc TB --- 2013-10-19 06:19:41 - TZ=UTC TB --- 2013-10-19 06:19:41 - __MAKE_CONF=/dev/null TB --- 2013-10-19 06:19:41 - cd /src TB --- 2013-10-19 06:19:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 19 06:19:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vol_ffs.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal_ufs.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 06:27:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 06:27:48 - ERROR: failed to build LINT kernel TB --- 2013-10-19 06:27:48 - 8549.85 user 1177.57 system 10341.54 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 06:31:17 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B783555; Sat, 19 Oct 2013 06:31:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2094C2910; Sat, 19 Oct 2013 06:31:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9J6VGGE074418; Sat, 19 Oct 2013 02:31:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9J6VFBt074417; Sat, 19 Oct 2013 06:31:15 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 06:31:15 GMT Message-Id: <201310190631.r9J6VFBt074417@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 06:31:17 -0000 TB --- 2013-10-19 05:13:24 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 05:13:24 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 05:13:24 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-10-19 05:13:24 - cleaning the object tree TB --- 2013-10-19 05:13:24 - /usr/local/bin/svn stat /src TB --- 2013-10-19 05:13:27 - At svn revision 256751 TB --- 2013-10-19 05:13:28 - building world TB --- 2013-10-19 05:13:28 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 05:13:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 05:13:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 05:13:28 - SRCCONF=/dev/null TB --- 2013-10-19 05:13:28 - TARGET=sparc64 TB --- 2013-10-19 05:13:28 - TARGET_ARCH=sparc64 TB --- 2013-10-19 05:13:28 - TZ=UTC TB --- 2013-10-19 05:13:28 - __MAKE_CONF=/dev/null TB --- 2013-10-19 05:13:28 - cd /src TB --- 2013-10-19 05:13:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 05:13:36 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 06:21:30 UTC 2013 TB --- 2013-10-19 06:21:30 - generating LINT kernel config TB --- 2013-10-19 06:21:30 - cd /src/sys/sparc64/conf TB --- 2013-10-19 06:21:30 - /usr/bin/make -B LINT TB --- 2013-10-19 06:21:31 - cd /src/sys/sparc64/conf TB --- 2013-10-19 06:21:31 - /usr/sbin/config -m LINT TB --- 2013-10-19 06:21:31 - building LINT kernel TB --- 2013-10-19 06:21:31 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 06:21:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 06:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 06:21:31 - SRCCONF=/dev/null TB --- 2013-10-19 06:21:31 - TARGET=sparc64 TB --- 2013-10-19 06:21:31 - TARGET_ARCH=sparc64 TB --- 2013-10-19 06:21:31 - TZ=UTC TB --- 2013-10-19 06:21:31 - __MAKE_CONF=/dev/null TB --- 2013-10-19 06:21:31 - cd /src TB --- 2013-10-19 06:21:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 19 06:21:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vol_ffs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal_ufs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 06:31:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 06:31:15 - ERROR: failed to build LINT kernel TB --- 2013-10-19 06:31:15 - 3668.47 user 641.97 system 4671.57 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 08:02:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02916923; Sat, 19 Oct 2013 08:02:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE0D92CF2; Sat, 19 Oct 2013 08:02:29 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9J82Sij021760; Sat, 19 Oct 2013 04:02:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9J82SIN021759; Sat, 19 Oct 2013 08:02:28 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 08:02:28 GMT Message-Id: <201310190802.r9J82SIN021759@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 08:02:30 -0000 TB --- 2013-10-19 04:49:37 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 04:49:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 04:49:37 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-10-19 04:49:37 - cleaning the object tree TB --- 2013-10-19 04:49:37 - /usr/local/bin/svn stat /src TB --- 2013-10-19 04:49:41 - At svn revision 256751 TB --- 2013-10-19 04:49:42 - building world TB --- 2013-10-19 04:49:42 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 04:49:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 04:49:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 04:49:42 - SRCCONF=/dev/null TB --- 2013-10-19 04:49:42 - TARGET=powerpc TB --- 2013-10-19 04:49:42 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 04:49:42 - TZ=UTC TB --- 2013-10-19 04:49:42 - __MAKE_CONF=/dev/null TB --- 2013-10-19 04:49:42 - cd /src TB --- 2013-10-19 04:49:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 04:49:49 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 19 07:58:17 UTC 2013 TB --- 2013-10-19 07:58:17 - generating LINT kernel config TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/bin/make -B LINT TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/sbin/config -m LINT TB --- 2013-10-19 07:58:17 - skipping LINT kernel TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/sbin/config -m GENERIC TB --- 2013-10-19 07:58:17 - skipping GENERIC kernel TB --- 2013-10-19 07:58:17 - cd /src/sys/powerpc/conf TB --- 2013-10-19 07:58:17 - /usr/sbin/config -m GENERIC64 TB --- 2013-10-19 07:58:17 - building GENERIC64 kernel TB --- 2013-10-19 07:58:17 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 07:58:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 07:58:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 07:58:17 - SRCCONF=/dev/null TB --- 2013-10-19 07:58:17 - TARGET=powerpc TB --- 2013-10-19 07:58:17 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 07:58:17 - TZ=UTC TB --- 2013-10-19 07:58:17 - __MAKE_CONF=/dev/null TB --- 2013-10-19 07:58:17 - cd /src TB --- 2013-10-19 07:58:17 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sat Oct 19 07:58:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_subr.c ctfconvert -L VERSION -g geom_subr.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c ctfconvert -L VERSION -g geom_vfs.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 08:02:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 08:02:23 - ERROR: failed to build GENERIC64 kernel TB --- 2013-10-19 08:02:23 - 10018.42 user 1242.15 system 11565.68 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 08:38:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DD780110 for ; Sat, 19 Oct 2013 08:38:26 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 76C112E35 for ; Sat, 19 Oct 2013 08:38:26 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id b10so2509043eae.10 for ; Sat, 19 Oct 2013 01:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=haJmgzo2cJ9HVL55/NlQ90LlwMQAPsR4x1qNrgJlXEk=; b=vFgUn7IL4s0y7rX0DP9lIMxyC9iDaXTRn/nVBp12uh/zhe789WnHNn1P8E/Y3bhO6I BtPZhRCbaEyWW8Niemq5kbEq06Hzyxv77+X+3FERGAjDSKbInkcDm4IcOxxz65c4SkMq AaKgmeTLjOP3dVA0MU+WnwBDvEEbiiGPu5UIwvYeKZnAhO32KIXbfcPtno8qbEsQhU+7 i2546jI5Eg5HIifr/apQl5uIfOh2PyPFrrMD2eaLsZ9FgusfaveUohYq8EqhF6H3UtaL Am0b0h/Qd4TCV0tD3h/671XJrPaU+yi6+7Jty1vNAC5PyuwKyxLM2X3x+AEQkdxlQeKa MkgA== X-Received: by 10.14.2.200 with SMTP id 48mr7737379eef.88.1382171904839; Sat, 19 Oct 2013 01:38:24 -0700 (PDT) Received: from mini.home (aeay151.neoplus.adsl.tpnet.pl. [79.186.24.151]) by mx.google.com with ESMTPSA id r48sm14980898eev.14.2013.10.19.01.38.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 01:38:24 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: gcc kernel build fail @ SVN r256730 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <52612651.9000001@protected-networks.net> Date: Sat, 19 Oct 2013 10:38:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27D6066C-CEEF-48BE-B882-E086E01BEE43@FreeBSD.org> References: <52612651.9000001@protected-networks.net> To: Michael Butler X-Mailer: Apple Mail (2.1510) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 08:38:26 -0000 Wiadomo=B6=E6 napisana przez Michael Butler = w dniu 18 pa=BC 2013, o godz. 14:15: > -current kernel compiled with gcc fails with: >=20 > cc1: warnings being treated as errors > /usr/src/sys/geom/label/g_label.c: In function 'g_label_resize': > /usr/src/sys/geom/label/g_label.c:135: warning: null format string > [-Wformat] > *** [g_label.o] Error code 1 Should be fixed now. Sorry for the breakage. From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 08:55:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5727A39F; Sat, 19 Oct 2013 08:55:57 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C6782EE5; Sat, 19 Oct 2013 08:55:56 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VXSK3-0008lM-5v ; Sat, 19 Oct 2013 11:55:47 +0300 Date: Sat, 19 Oct 2013 11:55:47 +0300 From: Vitalij Satanivskij To: Steven Hartland Subject: Re: ZFS secondarycache on SSD problem on r255173 Message-ID: <20131019085547.GA33582@hell.ukr.net> References: <7059AA6DCC0D46B8B1D33FC883C31643@multiplay.co.uk> <20131017061248.GA15980@hell.ukr.net> <326B470C65A04BC4BC83E118185B935F@multiplay.co.uk> <20131017073925.GA34958@hell.ukr.net> <2AFE1CBD9B124E3AB9E05A4E483CCE03@multiplay.co.uk> <20131018080148.GA75226@hell.ukr.net> <256B2E5A0BA44DCBB45BB3F3E820E190@multiplay.co.uk> <20131018144524.GA30018@hell.ukr.net> <4459A6FAB7B8445C97CCB9EFF34FD4F0@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4459A6FAB7B8445C97CCB9EFF34FD4F0@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Vitalij Satanivskij , Dmitriy Makarov , "Justin T. Gibbs" , Borja Marcos , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 08:55:57 -0000 Ok. Just right now system rebooted with you patch. Trim enabled again. WIll wait some time untile size of used cache grow's. Steven Hartland wrote: SH> Looking at the l2arc compression code I believe that metadata is always SH> compressed with lz4, even if compression is off on all datasets. SH> SH> This is backed up by what I'm seeing on my system here as it shows a SH> non-zero l2_compress_successes value even though I'm not using SH> compression at all. SH> SH> I think we we may well need the following patch to set the minblock SH> size based on the vdev ashift and not SPA_MINBLOCKSIZE. SH> SH> svn diff -x -p sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c SH> Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c SH> =================================================================== SH> --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (revision 256554) SH> +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c (working copy) SH> @@ -5147,7 +5147,7 @@ l2arc_compress_buf(l2arc_buf_hdr_t *l2hdr) SH> len = l2hdr->b_asize; SH> cdata = zio_data_buf_alloc(len); SH> csize = zio_compress_data(ZIO_COMPRESS_LZ4, l2hdr->b_tmp_cdata, SH> - cdata, l2hdr->b_asize, (size_t)SPA_MINBLOCKSIZE); SH> + cdata, l2hdr->b_asize, (size_t)(1ULL << l2hdr->b_dev->l2ad_vdev->vdev_ashift)); SH> SH> if (csize == 0) { SH> /* zero block, indicate that there's nothing to write */ SH> SH> Could you try this patch on your system Vitalij see if it has any effect SH> on the number of l2_cksum_bad / l2_io_error? SH> SH> Regards SH> Steve SH> ----- Original Message ----- SH> From: "Vitalij Satanivskij" SH> To: "Steven Hartland" SH> Cc: "Vitalij Satanivskij" ; "Dmitriy Makarov" ; "Justin T. Gibbs" ; "Borja SH> Marcos" ; SH> Sent: Friday, October 18, 2013 3:45 PM SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> SH> SH> > SH> > Just right now stats not to actual because of some another test. SH> > SH> > Test is simply all gpart information destroyed from ssd and SH> > SH> > They used as raw cache devices. Just SH> > 2013-10-18.11:30:49 zpool add disk1 cache /dev/ada1 /dev/ada2 /dev/ada3 SH> > SH> > So sizes at last l2_size and l2_asize in not actual. SH> > SH> > But heare it is: SH> > SH> > kstat.zfs.misc.arcstats.hits: 5178174063 SH> > kstat.zfs.misc.arcstats.misses: 57690806 SH> > kstat.zfs.misc.arcstats.demand_data_hits: 313995744 SH> > kstat.zfs.misc.arcstats.demand_data_misses: 37414740 SH> > kstat.zfs.misc.arcstats.demand_metadata_hits: 4719242892 SH> > kstat.zfs.misc.arcstats.demand_metadata_misses: 9266394 SH> > kstat.zfs.misc.arcstats.prefetch_data_hits: 1182495 SH> > kstat.zfs.misc.arcstats.prefetch_data_misses: 9951733 SH> > kstat.zfs.misc.arcstats.prefetch_metadata_hits: 143752935 SH> > kstat.zfs.misc.arcstats.prefetch_metadata_misses: 1057939 SH> > kstat.zfs.misc.arcstats.mru_hits: 118609738 SH> > kstat.zfs.misc.arcstats.mru_ghost_hits: 1895486 SH> > kstat.zfs.misc.arcstats.mfu_hits: 4914673425 SH> > kstat.zfs.misc.arcstats.mfu_ghost_hits: 14537497 SH> > kstat.zfs.misc.arcstats.allocated: 103796455 SH> > kstat.zfs.misc.arcstats.deleted: 40168100 SH> > kstat.zfs.misc.arcstats.stolen: 20832742 SH> > kstat.zfs.misc.arcstats.recycle_miss: 15663428 SH> > kstat.zfs.misc.arcstats.mutex_miss: 1456781 SH> > kstat.zfs.misc.arcstats.evict_skip: 25960184 SH> > kstat.zfs.misc.arcstats.evict_l2_cached: 891379153920 SH> > kstat.zfs.misc.arcstats.evict_l2_eligible: 50578438144 SH> > kstat.zfs.misc.arcstats.evict_l2_ineligible: 956055729664 SH> > kstat.zfs.misc.arcstats.hash_elements: 8693451 SH> > kstat.zfs.misc.arcstats.hash_elements_max: 14369414 SH> > kstat.zfs.misc.arcstats.hash_collisions: 90967764 SH> > kstat.zfs.misc.arcstats.hash_chains: 1891463 SH> > kstat.zfs.misc.arcstats.hash_chain_max: 24 SH> > kstat.zfs.misc.arcstats.p: 73170954752 SH> > kstat.zfs.misc.arcstats.c: 85899345920 SH> > kstat.zfs.misc.arcstats.c_min: 42949672960 SH> > kstat.zfs.misc.arcstats.c_max: 85899345920 SH> > kstat.zfs.misc.arcstats.size: 85899263104 SH> > kstat.zfs.misc.arcstats.hdr_size: 1425948696 SH> > kstat.zfs.misc.arcstats.data_size: 77769994240 SH> > kstat.zfs.misc.arcstats.other_size: 6056233632 SH> > kstat.zfs.misc.arcstats.l2_hits: 21725934 SH> > kstat.zfs.misc.arcstats.l2_misses: 35876251 SH> > kstat.zfs.misc.arcstats.l2_feeds: 130197 SH> > kstat.zfs.misc.arcstats.l2_rw_clash: 110181 SH> > kstat.zfs.misc.arcstats.l2_read_bytes: 391282009600 SH> > kstat.zfs.misc.arcstats.l2_write_bytes: 1098703347712 SH> > kstat.zfs.misc.arcstats.l2_writes_sent: 130037 SH> > kstat.zfs.misc.arcstats.l2_writes_done: 130037 SH> > kstat.zfs.misc.arcstats.l2_writes_error: 0 SH> > kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 375921 SH> > kstat.zfs.misc.arcstats.l2_evict_lock_retry: 331 SH> > kstat.zfs.misc.arcstats.l2_evict_reading: 43 SH> > kstat.zfs.misc.arcstats.l2_free_on_write: 255730 SH> > kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 SH> > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 SH> > kstat.zfs.misc.arcstats.l2_io_error: 38254 SH> > kstat.zfs.misc.arcstats.l2_size: 136696884736 SH> > kstat.zfs.misc.arcstats.l2_asize: 131427690496 SH> > kstat.zfs.misc.arcstats.l2_hdr_size: 742951208 SH> > kstat.zfs.misc.arcstats.l2_compress_successes: 5565311 SH> > kstat.zfs.misc.arcstats.l2_compress_zeros: 0 SH> > kstat.zfs.misc.arcstats.l2_compress_failures: 0 SH> > kstat.zfs.misc.arcstats.l2_write_trylock_fail: 325157131 SH> > kstat.zfs.misc.arcstats.l2_write_passed_headroom: 4897854 SH> > kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 115704249 SH> > kstat.zfs.misc.arcstats.l2_write_in_l2: 15114214372 SH> > kstat.zfs.misc.arcstats.l2_write_io_in_progress: 63417 SH> > kstat.zfs.misc.arcstats.l2_write_not_cacheable: 3291593934 SH> > kstat.zfs.misc.arcstats.l2_write_full: 47672 SH> > kstat.zfs.misc.arcstats.l2_write_buffer_iter: 130197 SH> > kstat.zfs.misc.arcstats.l2_write_pios: 130037 SH> > kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 369077156457472 SH> > kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 8015080 SH> > kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 79825 SH> > kstat.zfs.misc.arcstats.memory_throttle_count: 0 SH> > kstat.zfs.misc.arcstats.duplicate_buffers: 0 SH> > kstat.zfs.misc.arcstats.duplicate_buffers_size: 0 SH> > kstat.zfs.misc.arcstats.duplicate_reads: 0 SH> > SH> > SH> > Values of SH> > --------------------------------- SH> > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 SH> > kstat.zfs.misc.arcstats.l2_io_error: 38254 SH> > -------------------------------- SH> > SH> > not growing from last cache reconfiguration, just wait some time to see - maybe problem disapers :) SH> > SH> > SH> > SH> > SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> Hmm so that rules out a TRIM related issue. I wonder if the SH> > SH> increase in ashift has triggered a problem in compression. SH> > SH> SH> > SH> What are all the values reported by: SH> > SH> sysctl -a kstat.zfs.misc.arcstats SH> > SH> SH> > SH> Regards SH> > SH> Steve SH> > SH> SH> > SH> ----- Original Message ----- SH> > SH> From: "Vitalij Satanivskij" SH> > SH> To: "Steven Hartland" SH> > SH> Cc: ; "Justin T. Gibbs" ; ; "Borja Marcos" SH> > ; SH> > SH> "Dmitriy Makarov" SH> > SH> Sent: Friday, October 18, 2013 9:01 AM SH> > SH> Subject: Re: ZFS secondarycache on SSD problem on r255173 SH> > SH> SH> > SH> SH> > SH> > Hello. SH> > SH> > SH> > SH> > Yesterday system was rebooted with vfs.zfs.trim.enabled=0 SH> > SH> > SH> > SH> > System version 10.0-BETA1 FreeBSD 10.0-BETA1 #6 r256669, without any changes in code SH> > SH> > SH> > SH> > Uptime 10:51 up 16:41 SH> > SH> > SH> > SH> > sysctl vfs.zfs.trim.enabled SH> > SH> > vfs.zfs.trim.enabled: 0 SH> > SH> > SH> > SH> > Around 2 hours ago errors counter's SH> > SH> > kstat.zfs.misc.arcstats.l2_cksum_bad: 854359 SH> > SH> > kstat.zfs.misc.arcstats.l2_io_error: 38254 SH> > SH> > SH> > SH> > begin grow from zero values. SH> > SH> > SH> > SH> > After remove cache SH> > SH> > 2013-10-18.10:37:10 zpool remove disk1 gpt/cache0 gpt/cache1 gpt/cache2 SH> > SH> > SH> > SH> > and attach again SH> > SH> > SH> > SH> > 2013-10-18.10:38:28 zpool add disk1 cache gpt/cache0 gpt/cache1 gpt/cache2 SH> > SH> > SH> > SH> > counters stop growing (of couse thay not zeroed) SH> > SH> > SH> > SH> > before cache remove kstat.zfs.misc.arcstats.l2_asize was around 280GB SH> > SH> > SH> > SH> > hw size of l2 cache is 3x164G SH> > SH> > SH> > SH> > => 34 351651821 ada3 GPT (168G) SH> > SH> > 34 6 - free - (3.0K) SH> > SH> > 40 8388608 1 zil2 (4.0G) SH> > SH> > 8388648 343263200 2 cache2 (164G) SH> > SH> > 351651848 7 - free - (3.5K) SH> > SH> > SH> > SH> > SH> > SH> > Any hypothesis what alse we can test/try etc? SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> > SH> Correct. SH> > SH> > SH> ----- Original Message ----- SH> > SH> > SH> From: "Vitalij Satanivskij" SH> > SH> > SH> SH> > SH> > SH> SH> > SH> > SH> > Just to be sure I understand you clearly, I need to test next configuration: SH> > SH> > SH> > SH> > SH> > SH> > 1) System with ashift patch eg. just latest stable/10 revision SH> > SH> > SH> > 2) vfs.zfs.trim.enabled=0 in /boot/loader.conf SH> > SH> > SH> > SH> > SH> > SH> > So realy only diferens in default system configuration is disabled trim functional ? SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > SH> > Steven Hartland wrote: SH> > SH> > SH> > SH> Still worth testing with the problem version installed but SH> > SH> > SH> > SH> with trim disabled to see if that clears the issues, if SH> > SH> > SH> > SH> nothing else it will confirm / deny if trim is involved. SH> > SH> > SH> SH> > SH> > SH> SH> > SH> > SH> ================================================ SH> > SH> > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. SH> > In the SH> > SH> > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any SH> > SH> > information contained in it. SH> > SH> > SH> SH> > SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> > SH> > SH> or return the E.mail to postmaster@multiplay.co.uk. SH> > SH> > SH> SH> > SH> > SH> _______________________________________________ SH> > SH> > SH> freebsd-current@freebsd.org mailing list SH> > SH> > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> > _______________________________________________ SH> > SH> > freebsd-current@freebsd.org mailing list SH> > SH> > http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> > SH> > SH> SH> > SH> SH> > SH> ================================================ SH> > SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the SH> > event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any SH> > information contained in it. SH> > SH> SH> > SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> > SH> or return the E.mail to postmaster@multiplay.co.uk. SH> > SH> SH> > SH> _______________________________________________ SH> > SH> freebsd-current@freebsd.org mailing list SH> > SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> > SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" SH> > SH> SH> SH> ================================================ SH> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. SH> SH> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 SH> or return the E.mail to postmaster@multiplay.co.uk. SH> SH> _______________________________________________ SH> freebsd-current@freebsd.org mailing list SH> http://lists.freebsd.org/mailman/listinfo/freebsd-current SH> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 12:16:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51C9F2F3; Sat, 19 Oct 2013 12:16:44 +0000 (UTC) (envelope-from ftp51246-2575596@sh4-5.1blu.de) Received: from sh4-5.1blu.de (sh4-5.1blu.de [178.254.11.41]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12D0D279A; Sat, 19 Oct 2013 12:16:43 +0000 (UTC) Received: from ftp51246-2575596 by sh4-5.1blu.de with local (Exim 4.76) (envelope-from ) id 1VXVWj-00008K-Tc; Sat, 19 Oct 2013 14:21:05 +0200 Date: Sat, 19 Oct 2013 14:21:05 +0200 From: Matthias Apitz To: Adrian Chadd Subject: Re: [rfc] removing the NDISulator Message-ID: <20131019122105.GA28947@sh4-5.1blu.de> References: <20131018205352.GA44565@mouf.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 7.0-RELEASE (i386) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 12:16:44 -0000 El día Friday, October 18, 2013 a las 02:19:42PM -0700, Adrian Chadd escribió: > I'd really like to see bwi/bwn maintained and have support added for the > later hardware. Hi Adrian, $ pciconf -vl ndis0@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4312 802.11b/g LP-PHY' class = network I'm using NDIS as well in r250588. Is bwi/bwn the point to start to look into for this chip? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 14:57:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 92BEE48B for ; Sat, 19 Oct 2013 14:57:41 +0000 (UTC) (envelope-from johan@bridgenet.se) Received: from smtp-gw11.han.skanova.net (smtp-gw11.han.skanova.net [81.236.55.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2296B2DF3 for ; Sat, 19 Oct 2013 14:57:40 +0000 (UTC) Received-SPF: pass (smtp-gw11.han.skanova.net: domain bridgenet.se designates 212.181.212.146 as permitted sender) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=212.181.212.146; envelope-from=johan@bridgenet.se; helo=mail.bridgenet.se; Received: from mail.bridgenet.se (212.181.212.146) by smtp-gw11.han.skanova.net (8.5.133) id 525514D7004E7019 for freebsd-current@freebsd.org; Sat, 19 Oct 2013 16:56:46 +0200 Received: from mail.bridgenet.se (unknown [10.0.0.5]) by mail.bridgenet.se (Postfix) with ESMTP id 275FB17C37 for ; Sat, 19 Oct 2013 16:56:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bridgenet.se; h= content-transfer-encoding:content-type:content-type:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1382194604; x=1383058605; bh=UjvQhV4pzfHx MvRdle4feQNXDvn41Yw2CGNtV8RE+NY=; b=kCPuSNA6sSWSsBWjr69vzA1sd099 Ss2UKXoYWob4oUCAw1Ob8WUiVxlzp1uKPIR8LhMpb/niVSD8cI/oPfnCauqu8Lf7 UxLdzPpmN0Pf0LJmWSWolqX1fJVWnOZ6UdhPhuEvqhdGBDQxR54qP1g7zVOAcsaP R0an/xJaxFVqgJ0= X-Virus-Scanned: amavisd-new at mail.bridgenet.se Received: from mail.bridgenet.se ([10.0.0.5]) by mail.bridgenet.se (mail.bridgenet.se [10.0.0.5]) (amavisd-new, port 10024) with ESMTP id qXkM3t4rWilV for ; Sat, 19 Oct 2013 16:56:44 +0200 (CEST) Received: from dhcp-208-143.arn.redhat.com (unknown [192.168.0.129]) by mail.bridgenet.se (Postfix) with ESMTPSA id 348BE17C2C for ; Sat, 19 Oct 2013 16:56:42 +0200 (CEST) Message-ID: <52629DA7.7090103@bridgenet.se> Date: Sat, 19 Oct 2013 16:56:39 +0200 From: Johan Broman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 14:57:41 -0000 Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:10:44 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E99ADA38; Sat, 19 Oct 2013 15:10:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF21C2EF3; Sat, 19 Oct 2013 15:10:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9JFAg6X011197; Sat, 19 Oct 2013 11:10:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9JFAgHI011188; Sat, 19 Oct 2013 15:10:42 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 15:10:42 GMT Message-Id: <201310191510.r9JFAgHI011188@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 15:10:44 -0000 TB --- 2013-10-19 13:21:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 13:21:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 13:21:21 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-10-19 13:21:21 - cleaning the object tree TB --- 2013-10-19 13:22:28 - /usr/local/bin/svn stat /src TB --- 2013-10-19 13:22:31 - At svn revision 256765 TB --- 2013-10-19 13:22:32 - building world TB --- 2013-10-19 13:22:32 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 13:22:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 13:22:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 13:22:32 - SRCCONF=/dev/null TB --- 2013-10-19 13:22:32 - TARGET=ia64 TB --- 2013-10-19 13:22:32 - TARGET_ARCH=ia64 TB --- 2013-10-19 13:22:32 - TZ=UTC TB --- 2013-10-19 13:22:32 - __MAKE_CONF=/dev/null TB --- 2013-10-19 13:22:32 - cd /src TB --- 2013-10-19 13:22:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 13:22:39 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 14:57:26 UTC 2013 TB --- 2013-10-19 14:57:26 - generating LINT kernel config TB --- 2013-10-19 14:57:26 - cd /src/sys/ia64/conf TB --- 2013-10-19 14:57:26 - /usr/bin/make -B LINT TB --- 2013-10-19 14:57:26 - cd /src/sys/ia64/conf TB --- 2013-10-19 14:57:26 - /usr/sbin/config -m LINT TB --- 2013-10-19 14:57:26 - building LINT kernel TB --- 2013-10-19 14:57:26 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 14:57:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 14:57:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 14:57:26 - SRCCONF=/dev/null TB --- 2013-10-19 14:57:26 - TARGET=ia64 TB --- 2013-10-19 14:57:26 - TARGET_ARCH=ia64 TB --- 2013-10-19 14:57:26 - TZ=UTC TB --- 2013-10-19 14:57:26 - __MAKE_CONF=/dev/null TB --- 2013-10-19 14:57:26 - cd /src TB --- 2013-10-19 14:57:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 19 14:57:26 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/geom_vfs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/geom_vol_ffs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/journal/g_journal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/journal/g_journal_ufs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 15:10:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 15:10:42 - ERROR: failed to build LINT kernel TB --- 2013-10-19 15:10:42 - 5192.27 user 891.86 system 6560.48 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:23:26 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48BC5DFE; Sat, 19 Oct 2013 15:23:26 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 25FAF2F93; Sat, 19 Oct 2013 15:23:25 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6A69940522; Sat, 19 Oct 2013 15:23:21 +0000 (UTC) Message-ID: <5262A3EE.4050600@allanjude.com> Date: Sat, 19 Oct 2013 11:23:26 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> In-Reply-To: <52629DA7.7090103@bridgenet.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Devin Teske X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 15:23:26 -0000 On 2013-10-19 10:56, Johan Broman wrote: > Hi! > > Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I > have 4 SATA drives in my server. I select all four of them in a RAIDZ1 > setup. I hit enter to continue the installation and the zpool is > created, but I'm then returned to the zpool selection screen again. It > turned out that two of the drives had previously been used in a > (Linux) software mirror setup and because of this they got activated > in /dev/raid/r0. Because of this I ended up in an endless bsdinstall > loop. > > Removing the raid device using the graid command resolved the situation. > > Now maybe this is working as designed, but there was no warning/alert > to the fact that the devices couldn't be used. Perhaps a warning > should be rasied in this situation? > > Thanks for all the great work on the new installer, really looking > forward to FreeBSD 10! > > Cheers > Johan > _______________________________________________ > 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" Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:31:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EFC2A265 for ; Sat, 19 Oct 2013 15:31:37 +0000 (UTC) (envelope-from johan@bridgenet.se) Received: from smtp-gw11.han.skanova.net (smtp-gw11.han.skanova.net [81.236.55.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE242FFF for ; Sat, 19 Oct 2013 15:31:36 +0000 (UTC) Received-SPF: pass (smtp-gw11.han.skanova.net: domain bridgenet.se designates 212.181.212.146 as permitted sender) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=212.181.212.146; envelope-from=johan@bridgenet.se; helo=mail.bridgenet.se; Received: from mail.bridgenet.se (212.181.212.146) by smtp-gw11.han.skanova.net (8.5.133) id 525514D7004E7E09 for freebsd-current@freebsd.org; Sat, 19 Oct 2013 17:31:35 +0200 Received: from mail.bridgenet.se (unknown [10.0.0.5]) by mail.bridgenet.se (Postfix) with ESMTP id 9168E17E8E for ; Sat, 19 Oct 2013 17:31:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bridgenet.se; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:to:mime-version:user-agent:from:from :date:date:message-id; s=dkim; t=1382196693; x=1383060694; bh=Ea N++hv4wzERiP7IcWS+mVSx49oTxkEly7kNOOAmMP4=; b=Smc0kRz7wKwW255dhf ABvowFE14p4+ggQkOjuplVFWV+0Xa4RmhEHZanfaj3ebN4YJYvao6TTj+LLx2qGt j/YXV17DF01LQVaxkHX22rAcGrFGizJoXgu4FxSZCxofMQTpD3y6h1VQF6O9GZLx RoPw2FXcDgghESTEOtF6yXAfk= X-Virus-Scanned: amavisd-new at mail.bridgenet.se Received: from mail.bridgenet.se ([10.0.0.5]) by mail.bridgenet.se (mail.bridgenet.se [10.0.0.5]) (amavisd-new, port 10024) with ESMTP id dxfzUM1-ANI0 for ; Sat, 19 Oct 2013 17:31:33 +0200 (CEST) Received: from dhcp-208-143.arn.redhat.com (unknown [192.168.0.129]) by mail.bridgenet.se (Postfix) with ESMTPSA id 633D517E82 for ; Sat, 19 Oct 2013 17:31:32 +0200 (CEST) Message-ID: <5262A5D0.3050604@bridgenet.se> Date: Sat, 19 Oct 2013 17:31:28 +0200 From: Johan Broman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> In-Reply-To: <5262A3EE.4050600@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 15:31:38 -0000 On 19/10/13 17:23, Allan Jude wrote: > On 2013-10-19 10:56, Johan Broman wrote: >> Hi! >> >> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >> setup. I hit enter to continue the installation and the zpool is >> created, but I'm then returned to the zpool selection screen again. It >> turned out that two of the drives had previously been used in a >> (Linux) software mirror setup and because of this they got activated >> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >> loop. >> >> Removing the raid device using the graid command resolved the situation. >> >> Now maybe this is working as designed, but there was no warning/alert >> to the fact that the devices couldn't be used. Perhaps a warning >> should be rasied in this situation? >> >> Thanks for all the great work on the new installer, really looking >> forward to FreeBSD 10! >> >> Cheers >> Johan >> _______________________________________________ >> 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" > Errors like that normally generate a msgbox dialog with the error output > from whichever command failed. I'll have to dig into it and see where > that problem is. I've seen other people have problems creating ZFS > arrays after graid, but in that case it was an incomplete graid label > causing a device to be locked but not appear in the graid status output. > Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:34:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 15898731 for ; Sat, 19 Oct 2013 15:34:50 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id E6241205D for ; Sat, 19 Oct 2013 15:34:49 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id AB62D40558 for ; Sat, 19 Oct 2013 15:34:48 +0000 (UTC) Message-ID: <5262A69D.5070601@allanjude.com> Date: Sat, 19 Oct 2013 11:34:53 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> In-Reply-To: <5262A5D0.3050604@bridgenet.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 15:34:50 -0000 On 2013-10-19 11:31, Johan Broman wrote: > > > On 19/10/13 17:23, Allan Jude wrote: >> On 2013-10-19 10:56, Johan Broman wrote: >>> Hi! >>> >>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>> setup. I hit enter to continue the installation and the zpool is >>> created, but I'm then returned to the zpool selection screen again. It >>> turned out that two of the drives had previously been used in a >>> (Linux) software mirror setup and because of this they got activated >>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>> loop. >>> >>> Removing the raid device using the graid command resolved the >>> situation. >>> >>> Now maybe this is working as designed, but there was no warning/alert >>> to the fact that the devices couldn't be used. Perhaps a warning >>> should be rasied in this situation? >>> >>> Thanks for all the great work on the new installer, really looking >>> forward to FreeBSD 10! >>> >>> Cheers >>> Johan >>> _______________________________________________ >>> 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" >> Errors like that normally generate a msgbox dialog with the error output >> from whichever command failed. I'll have to dig into it and see where >> that problem is. I've seen other people have problems creating ZFS >> arrays after graid, but in that case it was an incomplete graid label >> causing a device to be locked but not appear in the graid status output. >> > > Ah ok. A msgbox did appear but the drives that had the problem (ada2 > and ada3) wasn't visible in the output. (not sure if the box itself > has a size limit or maybe I was just unable to scroll down and see the > errors?). The only visible output was that it was able to create > labels on ada0 and ada1. > > /Johan > _______________________________________________ > 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" Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:43:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB50CC48 for ; Sat, 19 Oct 2013 15:43:30 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7550220BC for ; Sat, 19 Oct 2013 15:43:30 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r9JFhJhE012653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Oct 2013 10:43:19 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sat, 19 Oct 2013 10:43:18 -0500 From: "Teske, Devin" To: Allan Jude Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Topic: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Index: AQHOzOHuoyZqOu2cyEmJYHyn2Q5Miw== Date: Sat, 19 Oct 2013 15:43:18 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> In-Reply-To: <5262A69D.5070601@allanjude.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <394EC62C45E45248A266C82FB398A468@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18,2013-10-18,1970-01-01 signatures=0 Cc: "" , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 15:43:30 -0000 On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: > On 2013-10-19 11:31, Johan Broman wrote: >>=20 >>=20 >> On 19/10/13 17:23, Allan Jude wrote: >>> On 2013-10-19 10:56, Johan Broman wrote: >>>> Hi! >>>>=20 >>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>>> setup. I hit enter to continue the installation and the zpool is >>>> created, but I'm then returned to the zpool selection screen again. It >>>> turned out that two of the drives had previously been used in a >>>> (Linux) software mirror setup and because of this they got activated >>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>> loop. >>>>=20 >>>> Removing the raid device using the graid command resolved the >>>> situation. >>>>=20 >>>> Now maybe this is working as designed, but there was no warning/alert >>>> to the fact that the devices couldn't be used. Perhaps a warning >>>> should be rasied in this situation? >>>>=20 >>>> Thanks for all the great work on the new installer, really looking >>>> forward to FreeBSD 10! >>>>=20 >>>> Cheers >>>> Johan >>>> _______________________________________________ >>>> 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" >>> Errors like that normally generate a msgbox dialog with the error output >>> from whichever command failed. I'll have to dig into it and see where >>> that problem is. I've seen other people have problems creating ZFS >>> arrays after graid, but in that case it was an incomplete graid label >>> causing a device to be locked but not appear in the graid status output. >>>=20 >>=20 >> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >> and ada3) wasn't visible in the output. (not sure if the box itself >> has a size limit or maybe I was just unable to scroll down and see the >> errors?). The only visible output was that it was able to create >> labels on ada0 and ada1. >>=20 >> /Johan >> _______________________________________________ >> 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" > Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to > add a scrollbar but turns out that is not possible. >=20 > The only indication that there is more message to read, is a small 'xx%' > in the bottom right. We might have to look at breaking that output up or > something. >=20 The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:52:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 312C6DE2 for ; Sat, 19 Oct 2013 15:52:06 +0000 (UTC) (envelope-from johan@bridgenet.se) Received: from smtp-gw11.han.skanova.net (smtp-gw11.han.skanova.net [81.236.55.20]) by mx1.freebsd.org (Postfix) with ESMTP id B0FD02130 for ; Sat, 19 Oct 2013 15:52:05 +0000 (UTC) Received-SPF: pass (smtp-gw11.han.skanova.net: domain bridgenet.se designates 212.181.212.146 as permitted sender) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=212.181.212.146; envelope-from=johan@bridgenet.se; helo=mail.bridgenet.se; Received: from mail.bridgenet.se (212.181.212.146) by smtp-gw11.han.skanova.net (8.5.133) id 525514D7004E8539 for freebsd-current@freebsd.org; Sat, 19 Oct 2013 17:52:04 +0200 Received: from mail.bridgenet.se (unknown [10.0.0.5]) by mail.bridgenet.se (Postfix) with ESMTP id 03C0217FF0 for ; Sat, 19 Oct 2013 17:52:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bridgenet.se; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:to:mime-version:user-agent:from:from :date:date:message-id; s=dkim; t=1382197921; x=1383061922; bh=SW GtfUZEELBseAw9DqkTwCTr299P2UJotRV0TQJN4qQ=; b=xeHIVqT7Fv0jt70Qb1 r62ZIQr5QcJ8VWY9tvK97TMZjoFNWdHmPHTl5wxPp1ECtDLBoqLjZ3nZALS8o7XR ywj9LsKRGac3Y5yR4bbYIjX5hnLXcgGKw5EFc/HXF89mxNY5QA3jEal3U+O18UrO PxoROxzRrglRKebk65Q7YIZ2A= X-Virus-Scanned: amavisd-new at mail.bridgenet.se Received: from mail.bridgenet.se ([10.0.0.5]) by mail.bridgenet.se (mail.bridgenet.se [10.0.0.5]) (amavisd-new, port 10024) with ESMTP id c70d90pKs4aJ for ; Sat, 19 Oct 2013 17:52:01 +0200 (CEST) Received: from dhcp-208-143.arn.redhat.com (unknown [192.168.0.129]) by mail.bridgenet.se (Postfix) with ESMTPSA id B3F8517FE5 for ; Sat, 19 Oct 2013 17:52:00 +0200 (CEST) Message-ID: <5262AA9C.7030504@bridgenet.se> Date: Sat, 19 Oct 2013 17:51:56 +0200 From: Johan Broman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 15:52:06 -0000 On 19/10/13 17:43, Teske, Devin wrote: > > On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: > >> On 2013-10-19 11:31, Johan Broman wrote: >>> >>> >>> On 19/10/13 17:23, Allan Jude wrote: >>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>> Hi! >>>>> >>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>>>> setup. I hit enter to continue the installation and the zpool is >>>>> created, but I'm then returned to the zpool selection screen again. It >>>>> turned out that two of the drives had previously been used in a >>>>> (Linux) software mirror setup and because of this they got activated >>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>>> loop. >>>>> >>>>> Removing the raid device using the graid command resolved the >>>>> situation. >>>>> >>>>> Now maybe this is working as designed, but there was no warning/alert >>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>> should be rasied in this situation? >>>>> >>>>> Thanks for all the great work on the new installer, really looking >>>>> forward to FreeBSD 10! >>>>> >>>>> Cheers >>>>> Johan >>>>> _______________________________________________ >>>>> 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" >>>> Errors like that normally generate a msgbox dialog with the error output >>>> from whichever command failed. I'll have to dig into it and see where >>>> that problem is. I've seen other people have problems creating ZFS >>>> arrays after graid, but in that case it was an incomplete graid label >>>> causing a device to be locked but not appear in the graid status output. >>>> >>> >>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>> and ada3) wasn't visible in the output. (not sure if the box itself >>> has a size limit or maybe I was just unable to scroll down and see the >>> errors?). The only visible output was that it was able to create >>> labels on ada0 and ada1. >>> >>> /Johan >>> _______________________________________________ >>> 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" >> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to >> add a scrollbar but turns out that is not possible. >> >> The only indication that there is more message to read, is a small 'xx%' >> in the bottom right. We might have to look at breaking that output up or >> something. >> > > > The only reason for a msgbox widget to scroll is if it is displayed at > maximum height or width of the screen and it *still* has more data > to display than can be presented at-once. > > If... however... the msgbox widget is *not* full-height or full-width > yet... it is requiring you to scroll -- then we've found a bug. > > Can we get a screen shot? > Hmmm. Can't believe I didn't do a PgDn. Then again....it was pretty late last night when I tested it...tired brain. :) I'll recreate the mirror and see if I can provide a screen shot! /Johan From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 15:55:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1EB68FFE for ; Sat, 19 Oct 2013 15:55:11 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCCD62154 for ; Sat, 19 Oct 2013 15:55:10 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r9JFt8mY012253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Oct 2013 10:55:08 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sat, 19 Oct 2013 10:55:07 -0500 From: "Teske, Devin" To: "Teske, Devin" Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Topic: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Index: AQHOzOHuoyZqOu2cyEmJYHyn2Q5Mi5n8gTYA Date: Sat, 19 Oct 2013 15:55:06 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <38E612C921EDD14A8140848C3E7F400C@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18,2013-10-18,1970-01-01 signatures=0 Cc: "" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 15:55:11 -0000 On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: >=20 > On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: >=20 >> On 2013-10-19 11:31, Johan Broman wrote: >>>=20 >>>=20 >>> On 19/10/13 17:23, Allan Jude wrote: >>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>> Hi! >>>>>=20 >>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>>>> setup. I hit enter to continue the installation and the zpool is >>>>> created, but I'm then returned to the zpool selection screen again. It >>>>> turned out that two of the drives had previously been used in a >>>>> (Linux) software mirror setup and because of this they got activated >>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>>> loop. >>>>>=20 >>>>> Removing the raid device using the graid command resolved the >>>>> situation. >>>>>=20 >>>>> Now maybe this is working as designed, but there was no warning/alert >>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>> should be rasied in this situation? >>>>>=20 >>>>> Thanks for all the great work on the new installer, really looking >>>>> forward to FreeBSD 10! >>>>>=20 >>>>> Cheers >>>>> Johan >>>>> _______________________________________________ >>>>> 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" >>>> Errors like that normally generate a msgbox dialog with the error outp= ut >>>> from whichever command failed. I'll have to dig into it and see where >>>> that problem is. I've seen other people have problems creating ZFS >>>> arrays after graid, but in that case it was an incomplete graid label >>>> causing a device to be locked but not appear in the graid status outpu= t. >>>>=20 >>>=20 >>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>> and ada3) wasn't visible in the output. (not sure if the box itself >>> has a size limit or maybe I was just unable to scroll down and see the >>> errors?). The only visible output was that it was able to create >>> labels on ada0 and ada1. >>>=20 >>> /Johan >>> _______________________________________________ >>> 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" >> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to >> add a scrollbar but turns out that is not possible. >>=20 >> The only indication that there is more message to read, is a small 'xx%' >> in the bottom right. We might have to look at breaking that output up or >> something. >>=20 >=20 >=20 > The only reason for a msgbox widget to scroll is if it is displayed at > maximum height or width of the screen and it *still* has more data > to display than can be presented at-once. >=20 I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig AP= I. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this AP= I. > If... however... the msgbox widget is *not* full-height or full-width > yet... it is requiring you to scroll -- then we've found a bug. >=20 > Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). --=20 Devin --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 16:27:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F2C4323F for ; Sat, 19 Oct 2013 16:27:47 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CBD1F22CC for ; Sat, 19 Oct 2013 16:27:46 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id BAFDC40638; Sat, 19 Oct 2013 16:27:43 +0000 (UTC) Message-ID: <5262B304.3090605@allanjude.com> Date: Sat, 19 Oct 2013 12:27:48 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Teske, Devin" Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 16:27:48 -0000 On 2013-10-19 11:55, Teske, Devin wrote: > On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: > >> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: >> >>> On 2013-10-19 11:31, Johan Broman wrote: >>>> >>>> On 19/10/13 17:23, Allan Jude wrote: >>>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>>> Hi! >>>>>> >>>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>>>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>>>>> setup. I hit enter to continue the installation and the zpool is >>>>>> created, but I'm then returned to the zpool selection screen again. It >>>>>> turned out that two of the drives had previously been used in a >>>>>> (Linux) software mirror setup and because of this they got activated >>>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>>>> loop. >>>>>> >>>>>> Removing the raid device using the graid command resolved the >>>>>> situation. >>>>>> >>>>>> Now maybe this is working as designed, but there was no warning/alert >>>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>>> should be rasied in this situation? >>>>>> >>>>>> Thanks for all the great work on the new installer, really looking >>>>>> forward to FreeBSD 10! >>>>>> >>>>>> Cheers >>>>>> Johan >>>>>> _______________________________________________ >>>>>> 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" >>>>> Errors like that normally generate a msgbox dialog with the error output >>>>> from whichever command failed. I'll have to dig into it and see where >>>>> that problem is. I've seen other people have problems creating ZFS >>>>> arrays after graid, but in that case it was an incomplete graid label >>>>> causing a device to be locked but not appear in the graid status output. >>>>> >>>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>>> and ada3) wasn't visible in the output. (not sure if the box itself >>>> has a size limit or maybe I was just unable to scroll down and see the >>>> errors?). The only visible output was that it was able to create >>>> labels on ada0 and ada1. >>>> >>>> /Johan >>>> _______________________________________________ >>>> 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" >>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to >>> add a scrollbar but turns out that is not possible. >>> >>> The only indication that there is more message to read, is a small 'xx%' >>> in the bottom right. We might have to look at breaking that output up or >>> something. >>> >> >> The only reason for a msgbox widget to scroll is if it is displayed at >> maximum height or width of the screen and it *still* has more data >> to display than can be presented at-once. >> > I should clarify... > > The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. > That being said, msgbox widgets automatically scale their size to fit the > content being displayed. So whenever a msgbox is thrown up using this > API... the widget will never scroll unless the box can't be made big enough > to hold the entire content (either the screen resolution or terminal size is > too small; we maxed out the size of the widget; and there's still hidden > content). > > But... > > While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. > > > >> If... however... the msgbox widget is *not* full-height or full-width >> yet... it is requiring you to scroll -- then we've found a bug. >> >> Can we get a screen shot? > So we really need to nail down precisely which error box this is so that > we can address whether the issue is in-fact an instance of using the old > error-box handling instead of the auto-sizing API. > > So... > > With this described API, you should never have to scroll a box unless it > can't fit all the data *and* you should be able to immediately identify when > that becomes the case... > > 1. The widget spans the entire width of the screen. > > 2. The widget spans the entire height of the screen. > > 3. Both 1 and 2. > > It's in *those* cases that you should then *EXPECT* to find that the > region can scroll with cursor keys and page up/down (look for the > scroll percentage in the widget as Allan suggested. > > I don't want to see the scroll percentage doohickey *unless* the widget > is auto-sized to full-width or full-height. Meaning, there's either a bug in > the API or someone fell into a trap (there are a couple). the error output msgbox is huge, probably 100+ lines (the screen is what, 24 lines high, and with the ok button, top and bottom reserved space etc, can display maybe 18 lines at once) It contains all the shell output from everything we do, creating the gparts, setting up gnop, all of the redundant destroys etc. I don't think the TINY little % in the bottom right is really enough of an indicator to the user that they CAN scroll, let alone HOW to scroll (IIRC the arrow keys do not work, must use page down) -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 16:36:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 73C5173E; Sat, 19 Oct 2013 16:36:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F26D234C; Sat, 19 Oct 2013 16:36:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9JGasjT041607; Sat, 19 Oct 2013 12:36:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9JGas4g041597; Sat, 19 Oct 2013 16:36:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 16:36:54 GMT Message-Id: <201310191636.r9JGas4g041597@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 16:36:56 -0000 TB --- 2013-10-19 15:17:14 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 15:17:14 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 15:17:14 - starting HEAD tinderbox run for mips64/mips TB --- 2013-10-19 15:17:14 - cleaning the object tree TB --- 2013-10-19 15:18:47 - /usr/local/bin/svn stat /src TB --- 2013-10-19 15:18:50 - At svn revision 256765 TB --- 2013-10-19 15:18:51 - building world TB --- 2013-10-19 15:18:51 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 15:18:51 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 15:18:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 15:18:51 - SRCCONF=/dev/null TB --- 2013-10-19 15:18:51 - TARGET=mips TB --- 2013-10-19 15:18:51 - TARGET_ARCH=mips64 TB --- 2013-10-19 15:18:51 - TZ=UTC TB --- 2013-10-19 15:18:51 - __MAKE_CONF=/dev/null TB --- 2013-10-19 15:18:51 - cd /src TB --- 2013-10-19 15:18:51 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 15:18:58 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 16:20:57 UTC 2013 TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m ADM5120 TB --- 2013-10-19 16:20:57 - skipping ADM5120 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m ALCHEMY TB --- 2013-10-19 16:20:57 - skipping ALCHEMY kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP121 TB --- 2013-10-19 16:20:57 - skipping AP121 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP91 TB --- 2013-10-19 16:20:57 - skipping AP91 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP93 TB --- 2013-10-19 16:20:57 - skipping AP93 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP94 TB --- 2013-10-19 16:20:57 - skipping AP94 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AP96 TB --- 2013-10-19 16:20:57 - skipping AP96 kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR71XX_BASE TB --- 2013-10-19 16:20:57 - skipping AR71XX_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR724X_BASE TB --- 2013-10-19 16:20:57 - skipping AR724X_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR91XX_BASE TB --- 2013-10-19 16:20:57 - skipping AR91XX_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR933X_BASE TB --- 2013-10-19 16:20:57 - skipping AR933X_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m AR934X_BASE TB --- 2013-10-19 16:20:57 - skipping AR934X_BASE kernel TB --- 2013-10-19 16:20:57 - cd /src/sys/mips/conf TB --- 2013-10-19 16:20:57 - /usr/sbin/config -m BERI_DE4_MDROOT TB --- 2013-10-19 16:20:57 - building BERI_DE4_MDROOT kernel TB --- 2013-10-19 16:20:57 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:20:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:20:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:20:57 - SRCCONF=/dev/null TB --- 2013-10-19 16:20:57 - TARGET=mips TB --- 2013-10-19 16:20:57 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:20:57 - TZ=UTC TB --- 2013-10-19 16:20:57 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:20:57 - cd /src TB --- 2013-10-19 16:20:57 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_MDROOT >>> Kernel build for BERI_DE4_MDROOT started on Sat Oct 19 16:20:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_MDROOT completed on Sat Oct 19 16:23:25 UTC 2013 TB --- 2013-10-19 16:23:25 - cd /src/sys/mips/conf TB --- 2013-10-19 16:23:25 - /usr/sbin/config -m BERI_DE4_SDROOT TB --- 2013-10-19 16:23:25 - building BERI_DE4_SDROOT kernel TB --- 2013-10-19 16:23:25 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:23:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:23:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:23:25 - SRCCONF=/dev/null TB --- 2013-10-19 16:23:25 - TARGET=mips TB --- 2013-10-19 16:23:25 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:23:25 - TZ=UTC TB --- 2013-10-19 16:23:25 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:23:25 - cd /src TB --- 2013-10-19 16:23:25 - /usr/bin/make -B buildkernel KERNCONF=BERI_DE4_SDROOT >>> Kernel build for BERI_DE4_SDROOT started on Sat Oct 19 16:23:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_DE4_SDROOT completed on Sat Oct 19 16:25:52 UTC 2013 TB --- 2013-10-19 16:25:52 - cd /src/sys/mips/conf TB --- 2013-10-19 16:25:52 - /usr/sbin/config -m BERI_SIM_MDROOT TB --- 2013-10-19 16:25:52 - building BERI_SIM_MDROOT kernel TB --- 2013-10-19 16:25:52 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:25:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:25:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:25:52 - SRCCONF=/dev/null TB --- 2013-10-19 16:25:52 - TARGET=mips TB --- 2013-10-19 16:25:52 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:25:52 - TZ=UTC TB --- 2013-10-19 16:25:52 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:25:52 - cd /src TB --- 2013-10-19 16:25:52 - /usr/bin/make -B buildkernel KERNCONF=BERI_SIM_MDROOT >>> Kernel build for BERI_SIM_MDROOT started on Sat Oct 19 16:25:52 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_SIM_MDROOT completed on Sat Oct 19 16:28:15 UTC 2013 TB --- 2013-10-19 16:28:15 - cd /src/sys/mips/conf TB --- 2013-10-19 16:28:15 - /usr/sbin/config -m BERI_TEMPLATE TB --- 2013-10-19 16:28:15 - building BERI_TEMPLATE kernel TB --- 2013-10-19 16:28:15 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:28:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:28:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:28:15 - SRCCONF=/dev/null TB --- 2013-10-19 16:28:15 - TARGET=mips TB --- 2013-10-19 16:28:15 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:28:15 - TZ=UTC TB --- 2013-10-19 16:28:15 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:28:15 - cd /src TB --- 2013-10-19 16:28:15 - /usr/bin/make -B buildkernel KERNCONF=BERI_TEMPLATE >>> Kernel build for BERI_TEMPLATE started on Sat Oct 19 16:28:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BERI_TEMPLATE completed on Sat Oct 19 16:30:36 UTC 2013 TB --- 2013-10-19 16:30:36 - cd /src/sys/mips/conf TB --- 2013-10-19 16:30:36 - /usr/sbin/config -m CARAMBOLA2 TB --- 2013-10-19 16:30:36 - skipping CARAMBOLA2 kernel TB --- 2013-10-19 16:30:36 - cd /src/sys/mips/conf TB --- 2013-10-19 16:30:36 - /usr/sbin/config -m DB120 TB --- 2013-10-19 16:30:36 - skipping DB120 kernel TB --- 2013-10-19 16:30:36 - cd /src/sys/mips/conf TB --- 2013-10-19 16:30:36 - /usr/sbin/config -m DIR-825 TB --- 2013-10-19 16:30:36 - skipping DIR-825 kernel TB --- 2013-10-19 16:30:36 - cd /src/sys/mips/conf TB --- 2013-10-19 16:30:36 - /usr/sbin/config -m ENH200 TB --- 2013-10-19 16:30:36 - skipping ENH200 kernel TB --- 2013-10-19 16:30:36 - cd /src/sys/mips/conf TB --- 2013-10-19 16:30:36 - /usr/sbin/config -m GXEMUL TB --- 2013-10-19 16:30:36 - building GXEMUL kernel TB --- 2013-10-19 16:30:36 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:30:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:30:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:30:36 - SRCCONF=/dev/null TB --- 2013-10-19 16:30:36 - TARGET=mips TB --- 2013-10-19 16:30:36 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:30:36 - TZ=UTC TB --- 2013-10-19 16:30:36 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:30:36 - cd /src TB --- 2013-10-19 16:30:36 - /usr/bin/make -B buildkernel KERNCONF=GXEMUL >>> Kernel build for GXEMUL started on Sat Oct 19 16:30:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GXEMUL completed on Sat Oct 19 16:32:39 UTC 2013 TB --- 2013-10-19 16:32:39 - cd /src/sys/mips/conf TB --- 2013-10-19 16:32:39 - /usr/sbin/config -m GXEMUL32 TB --- 2013-10-19 16:32:39 - skipping GXEMUL32 kernel TB --- 2013-10-19 16:32:39 - cd /src/sys/mips/conf TB --- 2013-10-19 16:32:39 - /usr/sbin/config -m IDT TB --- 2013-10-19 16:32:39 - skipping IDT kernel TB --- 2013-10-19 16:32:39 - cd /src/sys/mips/conf TB --- 2013-10-19 16:32:39 - /usr/sbin/config -m MALTA TB --- 2013-10-19 16:32:39 - skipping MALTA kernel TB --- 2013-10-19 16:32:39 - cd /src/sys/mips/conf TB --- 2013-10-19 16:32:39 - /usr/sbin/config -m MALTA64 TB --- 2013-10-19 16:32:39 - skipping MALTA64 kernel TB --- 2013-10-19 16:32:39 - cd /src/sys/mips/conf TB --- 2013-10-19 16:32:39 - /usr/sbin/config -m OCTEON1 TB --- 2013-10-19 16:32:39 - building OCTEON1 kernel TB --- 2013-10-19 16:32:39 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:32:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:32:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:32:39 - SRCCONF=/dev/null TB --- 2013-10-19 16:32:39 - TARGET=mips TB --- 2013-10-19 16:32:39 - TARGET_ARCH=mips64 TB --- 2013-10-19 16:32:39 - TZ=UTC TB --- 2013-10-19 16:32:39 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:32:39 - cd /src TB --- 2013-10-19 16:32:39 - /usr/bin/make -B buildkernel KERNCONF=OCTEON1 >>> Kernel build for OCTEON1 started on Sat Oct 19 16:32:39 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_kern.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_slice.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_subr.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/geom_vfs.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0xffffffff80100000 -march=octeon -mabi=64 -msoft-float -ffreestanding -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/mips.mips64/src/sys/OCTEON1 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 16:36:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 16:36:54 - ERROR: failed to build OCTEON1 kernel TB --- 2013-10-19 16:36:54 - 3507.10 user 826.03 system 4780.34 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 17:07:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F5126D0 for ; Sat, 19 Oct 2013 17:07:45 +0000 (UTC) (envelope-from johan@bridgenet.se) Received: from smtp-gw11.han.skanova.net (smtp-gw11.han.skanova.net [81.236.55.20]) by mx1.freebsd.org (Postfix) with ESMTP id 02CE825A8 for ; Sat, 19 Oct 2013 17:07:44 +0000 (UTC) Received-SPF: pass (smtp-gw11.han.skanova.net: domain bridgenet.se designates 212.181.212.146 as permitted sender) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=212.181.212.146; envelope-from=johan@bridgenet.se; helo=mail.bridgenet.se; Received: from mail.bridgenet.se (212.181.212.146) by smtp-gw11.han.skanova.net (8.5.133) id 525514D7004EA237 for freebsd-current@freebsd.org; Sat, 19 Oct 2013 19:07:42 +0200 Received: from mail.bridgenet.se (unknown [10.0.0.5]) by mail.bridgenet.se (Postfix) with ESMTP id C685D1787B for ; Sat, 19 Oct 2013 19:07:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bridgenet.se; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:to:mime-version:user-agent:from:from :date:date:message-id; s=dkim; t=1382202459; x=1383066460; bh=TY 3wyT72mG4qYaEb23ocgWBpPRRmxQgH9PCOHSbYY4w=; b=QfPImyD2Vky2OA4dRg LCc7/8F+36afP+IR3qB/o6ZAWxsocpQ0ukn0AtuH0GjPDrOFzVk+7OxzCbFv7kDE RvIsf5+tEFU6DsRD5oms1uZvvwln3nD8qMv9QM4uxDEdXf4Ir21G3Pob8irJnZYl 3E9Ja8Tfpy9xBLzWUhNQGCXmU= X-Virus-Scanned: amavisd-new at mail.bridgenet.se Received: from mail.bridgenet.se ([10.0.0.5]) by mail.bridgenet.se (mail.bridgenet.se [10.0.0.5]) (amavisd-new, port 10024) with ESMTP id rDcd5YqzURvL for ; Sat, 19 Oct 2013 19:07:39 +0200 (CEST) Received: from dhcp-208-143.arn.redhat.com (unknown [192.168.0.129]) by mail.bridgenet.se (Postfix) with ESMTPSA id 58B1B1786F for ; Sat, 19 Oct 2013 19:07:38 +0200 (CEST) Message-ID: <5262BC56.4050004@bridgenet.se> Date: Sat, 19 Oct 2013 19:07:34 +0200 From: Johan Broman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> <5262B304.3090605@allanjude.com> In-Reply-To: <5262B304.3090605@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 17:07:45 -0000 On 19/10/13 18:27, Allan Jude wrote: > On 2013-10-19 11:55, Teske, Devin wrote: >> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: >> >>> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: >>> >>>> On 2013-10-19 11:31, Johan Broman wrote: >>>>> >>>>> On 19/10/13 17:23, Allan Jude wrote: >>>>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>>>>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>>>>>> setup. I hit enter to continue the installation and the zpool is >>>>>>> created, but I'm then returned to the zpool selection screen again. It >>>>>>> turned out that two of the drives had previously been used in a >>>>>>> (Linux) software mirror setup and because of this they got activated >>>>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>>>>> loop. >>>>>>> >>>>>>> Removing the raid device using the graid command resolved the >>>>>>> situation. >>>>>>> >>>>>>> Now maybe this is working as designed, but there was no warning/alert >>>>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>>>> should be rasied in this situation? >>>>>>> >>>>>>> Thanks for all the great work on the new installer, really looking >>>>>>> forward to FreeBSD 10! >>>>>>> >>>>>>> Cheers >>>>>>> Johan >>>>>>> _______________________________________________ >>>>>>> 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" >>>>>> Errors like that normally generate a msgbox dialog with the error output >>>>>> from whichever command failed. I'll have to dig into it and see where >>>>>> that problem is. I've seen other people have problems creating ZFS >>>>>> arrays after graid, but in that case it was an incomplete graid label >>>>>> causing a device to be locked but not appear in the graid status output. >>>>>> >>>>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>>>> and ada3) wasn't visible in the output. (not sure if the box itself >>>>> has a size limit or maybe I was just unable to scroll down and see the >>>>> errors?). The only visible output was that it was able to create >>>>> labels on ada0 and ada1. >>>>> >>>>> /Johan >>>>> _______________________________________________ >>>>> 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" >>>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to >>>> add a scrollbar but turns out that is not possible. >>>> >>>> The only indication that there is more message to read, is a small 'xx%' >>>> in the bottom right. We might have to look at breaking that output up or >>>> something. >>>> >>> >>> The only reason for a msgbox widget to scroll is if it is displayed at >>> maximum height or width of the screen and it *still* has more data >>> to display than can be presented at-once. >>> >> I should clarify... >> >> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. >> That being said, msgbox widgets automatically scale their size to fit the >> content being displayed. So whenever a msgbox is thrown up using this >> API... the widget will never scroll unless the box can't be made big enough >> to hold the entire content (either the screen resolution or terminal size is >> too small; we maxed out the size of the widget; and there's still hidden >> content). >> >> But... >> >> While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. >> >> >> >>> If... however... the msgbox widget is *not* full-height or full-width >>> yet... it is requiring you to scroll -- then we've found a bug. >>> >>> Can we get a screen shot? >> So we really need to nail down precisely which error box this is so that >> we can address whether the issue is in-fact an instance of using the old >> error-box handling instead of the auto-sizing API. >> >> So... >> >> With this described API, you should never have to scroll a box unless it >> can't fit all the data *and* you should be able to immediately identify when >> that becomes the case... >> >> 1. The widget spans the entire width of the screen. >> >> 2. The widget spans the entire height of the screen. >> >> 3. Both 1 and 2. >> >> It's in *those* cases that you should then *EXPECT* to find that the >> region can scroll with cursor keys and page up/down (look for the >> scroll percentage in the widget as Allan suggested. >> >> I don't want to see the scroll percentage doohickey *unless* the widget >> is auto-sized to full-width or full-height. Meaning, there's either a bug in >> the API or someone fell into a trap (there are a couple). > > the error output msgbox is huge, probably 100+ lines (the screen is > what, 24 lines high, and with the ok button, top and bottom reserved > space etc, can display maybe 18 lines at once) > > It contains all the shell output from everything we do, creating the > gparts, setting up gnop, all of the redundant destroys etc. > > I don't think the TINY little % in the bottom right is really enough of > an indicator to the user that they CAN scroll, let alone HOW to scroll > (IIRC the arrow keys do not work, must use page down) > I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. I have screen shots (taken with my phone) of the msgbox and "ps auxwww" output. Let me know what kind of debug info you would like. I've put the screen shots here: http://212.181.212.146/bsdinstall /Johan From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 17:28:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 109122BF for ; Sat, 19 Oct 2013 17:28:19 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD40026DA for ; Sat, 19 Oct 2013 17:28:18 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r9JHSBpb018483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Oct 2013 12:28:11 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sat, 19 Oct 2013 12:28:10 -0500 From: "Teske, Devin" To: Allan Jude Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Topic: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Index: AQHOzOHuoyZqOu2cyEmJYHyn2Q5Miw== Date: Sat, 19 Oct 2013 17:28:09 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC7F01D@LTCFISWMSGMB21.FNFIS.com> References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> <5262B304.3090605@allanjude.com> In-Reply-To: <5262B304.3090605@allanjude.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <56C826DDD3077C4593C30FEA61EAC1AC@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18,2013-10-18,1970-01-01 signatures=0 Cc: " Current" , Thomas Dickey , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 17:28:19 -0000 On Oct 19, 2013, at 9:27 AM, Allan Jude wrote: > On 2013-10-19 11:55, Teske, Devin wrote: >> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: >>=20 >>> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: >>>=20 >>>> On 2013-10-19 11:31, Johan Broman wrote: >>>>>=20 >>>>> On 19/10/13 17:23, Allan Jude wrote: >>>>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>>>> Hi! >>>>>>>=20 >>>>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1.= I >>>>>>> have 4 SATA drives in my server. I select all four of them in a RAI= DZ1 >>>>>>> setup. I hit enter to continue the installation and the zpool is >>>>>>> created, but I'm then returned to the zpool selection screen again.= It >>>>>>> turned out that two of the drives had previously been used in a >>>>>>> (Linux) software mirror setup and because of this they got activated >>>>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>>>>> loop. >>>>>>>=20 >>>>>>> Removing the raid device using the graid command resolved the >>>>>>> situation. >>>>>>>=20 >>>>>>> Now maybe this is working as designed, but there was no warning/ale= rt >>>>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>>>> should be rasied in this situation? >>>>>>>=20 >>>>>>> Thanks for all the great work on the new installer, really looking >>>>>>> forward to FreeBSD 10! >>>>>>>=20 >>>>>>> Cheers >>>>>>> Johan >>>>>>> _______________________________________________ >>>>>>> freebsd-current@freebsd.org mailing list >>>>>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.o= rg/mailman/listinfo/freebsd-current&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A= &r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DAnourZYCpeybP9= aMxTFH%2B4GBOf0xikQ2jpEi%2BPFWcKo%3D%0A&s=3Dfec708d91fa0976a0e297ef36288511= 68f36e9cb34727dc7935e26ae190e90da >>>>>>> To unsubscribe, send any mail to >>>>>>> "freebsd-current-unsubscribe@freebsd.org" >>>>>> Errors like that normally generate a msgbox dialog with the error ou= tput >>>>>> from whichever command failed. I'll have to dig into it and see where >>>>>> that problem is. I've seen other people have problems creating ZFS >>>>>> arrays after graid, but in that case it was an incomplete graid label >>>>>> causing a device to be locked but not appear in the graid status out= put. >>>>>>=20 >>>>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>>>> and ada3) wasn't visible in the output. (not sure if the box itself >>>>> has a size limit or maybe I was just unable to scroll down and see the >>>>> errors?). The only visible output was that it was able to create >>>>> labels on ada0 and ada1. >>>>>=20 >>>>> /Johan >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org= /mailman/listinfo/freebsd-current&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r= =3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DAnourZYCpeybP9aM= xTFH%2B4GBOf0xikQ2jpEi%2BPFWcKo%3D%0A&s=3Dfec708d91fa0976a0e297ef3628851168= f36e9cb34727dc7935e26ae190e90da >>>>> To unsubscribe, send any mail to >>>>> "freebsd-current-unsubscribe@freebsd.org" >>>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to >>>> add a scrollbar but turns out that is not possible. >>>>=20 >>>> The only indication that there is more message to read, is a small 'xx= %' >>>> in the bottom right. We might have to look at breaking that output up = or >>>> something. >>>>=20 >>>=20 >>> The only reason for a msgbox widget to scroll is if it is displayed at >>> maximum height or width of the screen and it *still* has more data >>> to display than can be presented at-once. >>>=20 >> I should clarify... >>=20 >> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig= API. >> That being said, msgbox widgets automatically scale their size to fit the >> content being displayed. So whenever a msgbox is thrown up using this >> API... the widget will never scroll unless the box can't be made big eno= ugh >> to hold the entire content (either the screen resolution or terminal siz= e is >> too small; we maxed out the size of the widget; and there's still hidden >> content). >>=20 >> But... >>=20 >> While all of bsdconfig uses this API, hardly any of bsdinstall uses this= API. >>=20 >>=20 >>=20 >>> If... however... the msgbox widget is *not* full-height or full-width >>> yet... it is requiring you to scroll -- then we've found a bug. >>>=20 >>> Can we get a screen shot? >> So we really need to nail down precisely which error box this is so that >> we can address whether the issue is in-fact an instance of using the old >> error-box handling instead of the auto-sizing API. >>=20 >> So... >>=20 >> With this described API, you should never have to scroll a box unless it >> can't fit all the data *and* you should be able to immediately identify = when >> that becomes the case... >>=20 >> 1. The widget spans the entire width of the screen. >>=20 >> 2. The widget spans the entire height of the screen. >>=20 >> 3. Both 1 and 2. >>=20 >> It's in *those* cases that you should then *EXPECT* to find that the >> region can scroll with cursor keys and page up/down (look for the >> scroll percentage in the widget as Allan suggested. >>=20 >> I don't want to see the scroll percentage doohickey *unless* the widget >> is auto-sized to full-width or full-height. Meaning, there's either a bu= g in >> the API or someone fell into a trap (there are a couple). >=20 > the error output msgbox is huge, probably 100+ lines (the screen is > what, 24 lines high, and with the ok button, top and bottom reserved > space etc, can display maybe 18 lines at once) >=20 OK, so we're probably talking about the log file view on-errror. Not the other big msgbox widget ... the disk info viewer. Both of those I believe suffer from the same problem because they are using the msgbox widget. > It contains all the shell output from everything we do, creating the > gparts, setting up gnop, all of the redundant destroys etc. >=20 Ok, yes, then we're definitely talking about the log file viewer. > I don't think the TINY little % in the bottom right is really enough of > an indicator to the user that they CAN scroll, let alone HOW to scroll > (IIRC the arrow keys do not work, must use page down) >=20 The keybindigs for the msgbox indeed ignore up/down arrows. However... I think we can overcome that by switching from the msgbox widget to instead the textbox widget. However... here's the problem... Despite the fact that when you say "man dialog" and look at the definition of textbox, and it has exactly every keybinding you'd ever expect to find... You can *only* use the textbox widget with a file. Sad news... it doesn't support "-" as a file to read from stdin. Worse news... attempts to use /dev/stdin as a hack have failed. So for the log view on-error... we can just switch over to using the f_dialog_textbox() API call and I'm sure everything will be much better. But for the disk info screen where we are programmatically providing the input via code that generates a realtime message, the textbox widget won't work for us (sad face). I should write Thomas Dickey and ask him if he could add "-" as a path to read from stdin (might require some buffering). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 18:15:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 939A5EEA; Sat, 19 Oct 2013 18:15:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A6D72966; Sat, 19 Oct 2013 18:15:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9JIF3aw041745; Sat, 19 Oct 2013 14:15:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9JIF2gD041734; Sat, 19 Oct 2013 18:15:02 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 18:15:02 GMT Message-Id: <201310191815.r9JIF2gD041734@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 18:15:04 -0000 TB --- 2013-10-19 15:22:09 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 15:22:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 15:22:09 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-10-19 15:22:09 - cleaning the object tree TB --- 2013-10-19 15:23:19 - /usr/local/bin/svn stat /src TB --- 2013-10-19 15:23:22 - At svn revision 256765 TB --- 2013-10-19 15:23:23 - building world TB --- 2013-10-19 15:23:23 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 15:23:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 15:23:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 15:23:23 - SRCCONF=/dev/null TB --- 2013-10-19 15:23:23 - TARGET=powerpc TB --- 2013-10-19 15:23:23 - TARGET_ARCH=powerpc TB --- 2013-10-19 15:23:23 - TZ=UTC TB --- 2013-10-19 15:23:23 - __MAKE_CONF=/dev/null TB --- 2013-10-19 15:23:23 - cd /src TB --- 2013-10-19 15:23:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 15:23:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 18:07:00 UTC 2013 TB --- 2013-10-19 18:07:00 - generating LINT kernel config TB --- 2013-10-19 18:07:00 - cd /src/sys/powerpc/conf TB --- 2013-10-19 18:07:00 - /usr/bin/make -B LINT TB --- 2013-10-19 18:07:00 - cd /src/sys/powerpc/conf TB --- 2013-10-19 18:07:00 - /usr/sbin/config -m LINT TB --- 2013-10-19 18:07:00 - building LINT kernel TB --- 2013-10-19 18:07:00 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 18:07:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 18:07:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 18:07:00 - SRCCONF=/dev/null TB --- 2013-10-19 18:07:00 - TARGET=powerpc TB --- 2013-10-19 18:07:00 - TARGET_ARCH=powerpc TB --- 2013-10-19 18:07:00 - TZ=UTC TB --- 2013-10-19 18:07:00 - __MAKE_CONF=/dev/null TB --- 2013-10-19 18:07:00 - cd /src TB --- 2013-10-19 18:07:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 19 18:07:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vol_ffs.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal_ufs.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 18:15:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 18:15:02 - ERROR: failed to build LINT kernel TB --- 2013-10-19 18:15:02 - 8553.16 user 1185.34 system 10373.16 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 18:17:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC074B8; Sat, 19 Oct 2013 18:17:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3175297E; Sat, 19 Oct 2013 18:17:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9JIH66T043138; Sat, 19 Oct 2013 14:17:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9JIH6eZ043137; Sat, 19 Oct 2013 18:17:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 18:17:06 GMT Message-Id: <201310191817.r9JIH6eZ043137@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 18:17:07 -0000 TB --- 2013-10-19 16:57:39 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 16:57:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 16:57:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-10-19 16:57:39 - cleaning the object tree TB --- 2013-10-19 16:58:36 - /usr/local/bin/svn stat /src TB --- 2013-10-19 16:58:39 - At svn revision 256765 TB --- 2013-10-19 16:58:40 - building world TB --- 2013-10-19 16:58:40 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:58:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:58:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:58:40 - SRCCONF=/dev/null TB --- 2013-10-19 16:58:40 - TARGET=sparc64 TB --- 2013-10-19 16:58:40 - TARGET_ARCH=sparc64 TB --- 2013-10-19 16:58:40 - TZ=UTC TB --- 2013-10-19 16:58:40 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:58:40 - cd /src TB --- 2013-10-19 16:58:40 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 16:58:47 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Oct 19 18:07:00 UTC 2013 TB --- 2013-10-19 18:07:00 - generating LINT kernel config TB --- 2013-10-19 18:07:00 - cd /src/sys/sparc64/conf TB --- 2013-10-19 18:07:00 - /usr/bin/make -B LINT TB --- 2013-10-19 18:07:00 - cd /src/sys/sparc64/conf TB --- 2013-10-19 18:07:00 - /usr/sbin/config -m LINT TB --- 2013-10-19 18:07:00 - building LINT kernel TB --- 2013-10-19 18:07:00 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 18:07:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 18:07:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 18:07:00 - SRCCONF=/dev/null TB --- 2013-10-19 18:07:00 - TARGET=sparc64 TB --- 2013-10-19 18:07:00 - TARGET_ARCH=sparc64 TB --- 2013-10-19 18:07:00 - TZ=UTC TB --- 2013-10-19 18:07:00 - __MAKE_CONF=/dev/null TB --- 2013-10-19 18:07:00 - cd /src TB --- 2013-10-19 18:07:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Oct 19 18:07:00 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vol_ffs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/journal/g_journal_ufs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/sparc64.sparc64/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 18:17:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 18:17:06 - ERROR: failed to build LINT kernel TB --- 2013-10-19 18:17:06 - 3673.41 user 652.46 system 4767.04 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 18:52:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3CDD5888; Sat, 19 Oct 2013 18:52:53 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F220A2AF4; Sat, 19 Oct 2013 18:52:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r9JIqfQ1010068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Oct 2013 13:52:41 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sat, 19 Oct 2013 13:52:40 -0500 From: "Teske, Devin" To: Johan Broman Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Topic: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Index: AQHOzOHuoyZqOu2cyEmJYHyn2Q5Miw== Date: Sat, 19 Oct 2013 18:52:39 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC7F4AD@LTCFISWMSGMB21.FNFIS.com> References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> <5262B304.3090605@allanjude.com> <5262BC56.4050004@bridgenet.se> In-Reply-To: <5262BC56.4050004@bridgenet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <6FE45813BAE963468DA617204D5B4A66@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18,2013-10-18,1970-01-01 signatures=0 Cc: Devin Teske , " Current" , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 18:52:53 -0000 On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: >=20 >=20 > On 19/10/13 18:27, Allan Jude wrote: >> On 2013-10-19 11:55, Teske, Devin wrote: >>> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: >>>=20 >>>> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: >>>>=20 >>>>> On 2013-10-19 11:31, Johan Broman wrote: >>>>>>=20 >>>>>> On 19/10/13 17:23, Allan Jude wrote: >>>>>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>>>>> Hi! >>>>>>>>=20 >>>>>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1= . I >>>>>>>> have 4 SATA drives in my server. I select all four of them in a RA= IDZ1 >>>>>>>> setup. I hit enter to continue the installation and the zpool is >>>>>>>> created, but I'm then returned to the zpool selection screen again= . It >>>>>>>> turned out that two of the drives had previously been used in a >>>>>>>> (Linux) software mirror setup and because of this they got activat= ed >>>>>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinsta= ll >>>>>>>> loop. >>>>>>>>=20 >>>>>>>> Removing the raid device using the graid command resolved the >>>>>>>> situation. >>>>>>>>=20 >>>>>>>> Now maybe this is working as designed, but there was no warning/al= ert >>>>>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>>>>> should be rasied in this situation? >>>>>>>>=20 >>>>>>>> Thanks for all the great work on the new installer, really looking >>>>>>>> forward to FreeBSD 10! >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>> Johan >>>>>>>> _______________________________________________ >>>>>>>> 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" >>>>>>> Errors like that normally generate a msgbox dialog with the error o= utput >>>>>>> from whichever command failed. I'll have to dig into it and see whe= re >>>>>>> that problem is. I've seen other people have problems creating ZFS >>>>>>> arrays after graid, but in that case it was an incomplete graid lab= el >>>>>>> causing a device to be locked but not appear in the graid status ou= tput. >>>>>>>=20 >>>>>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>>>>> and ada3) wasn't visible in the output. (not sure if the box itself >>>>>> has a size limit or maybe I was just unable to scroll down and see t= he >>>>>> errors?). The only visible output was that it was able to create >>>>>> labels on ada0 and ada1. >>>>>>=20 >>>>>> /Johan >>>>>> _______________________________________________ >>>>>> 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" >>>>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried = to >>>>> add a scrollbar but turns out that is not possible. >>>>>=20 >>>>> The only indication that there is more message to read, is a small 'x= x%' >>>>> in the bottom right. We might have to look at breaking that output up= or >>>>> something. >>>>>=20 >>>>=20 >>>> The only reason for a msgbox widget to scroll is if it is displayed at >>>> maximum height or width of the screen and it *still* has more data >>>> to display than can be presented at-once. >>>>=20 >>> I should clarify... >>>=20 >>> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfi= g API. >>> That being said, msgbox widgets automatically scale their size to fit t= he >>> content being displayed. So whenever a msgbox is thrown up using this >>> API... the widget will never scroll unless the box can't be made big en= ough >>> to hold the entire content (either the screen resolution or terminal si= ze is >>> too small; we maxed out the size of the widget; and there's still hidden >>> content). >>>=20 >>> But... >>>=20 >>> While all of bsdconfig uses this API, hardly any of bsdinstall uses thi= s API. >>>=20 >>>=20 >>>=20 >>>> If... however... the msgbox widget is *not* full-height or full-width >>>> yet... it is requiring you to scroll -- then we've found a bug. >>>>=20 >>>> Can we get a screen shot? >>> So we really need to nail down precisely which error box this is so that >>> we can address whether the issue is in-fact an instance of using the old >>> error-box handling instead of the auto-sizing API. >>>=20 >>> So... >>>=20 >>> With this described API, you should never have to scroll a box unless it >>> can't fit all the data *and* you should be able to immediately identify= when >>> that becomes the case... >>>=20 >>> 1. The widget spans the entire width of the screen. >>>=20 >>> 2. The widget spans the entire height of the screen. >>>=20 >>> 3. Both 1 and 2. >>>=20 >>> It's in *those* cases that you should then *EXPECT* to find that the >>> region can scroll with cursor keys and page up/down (look for the >>> scroll percentage in the widget as Allan suggested. >>>=20 >>> I don't want to see the scroll percentage doohickey *unless* the widget >>> is auto-sized to full-width or full-height. Meaning, there's either a b= ug in >>> the API or someone fell into a trap (there are a couple). >>=20 >> the error output msgbox is huge, probably 100+ lines (the screen is >> what, 24 lines high, and with the ok button, top and bottom reserved >> space etc, can display maybe 18 lines at once) >>=20 >> It contains all the shell output from everything we do, creating the >> gparts, setting up gnop, all of the redundant destroys etc. >>=20 >> I don't think the TINY little % in the bottom right is really enough of >> an indicator to the user that they CAN scroll, let alone HOW to scroll >> (IIRC the arrow keys do not work, must use page down) >>=20 >=20 > I recreated the graid mirror on ada2 and ada3 and reran the installation.= I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indi= cation that the action failed and I'm returned to the ZFS setup screen if I= hit OK. >=20 > I have screen shots (taken with my phone) of the msgbox and "ps auxwww" o= utput. Let me know what kind of debug info you would like. I've put the scr= een shots here: >=20 > http://212.181.212.146/bsdinstall >=20 It looks like one of the commands that is used to partition the disks is producing an error status on exit but ... no error? Double-check me on this, but... 1. It looks to me like this is what you're seeing (code-wise): >From http://svnweb.freebsd.org/base/head/usr.sbin/bsdinstall/scripts/zfsboo= t?revision=3D256553&view=3Dmarkup 989 if ! error=3D$( zfs_create_boot "$ZFSBOOT_POOL_NAME" \ 990 "$vdev_type" $real_disks 2>&1 ) 991 then 992 f_dialog_msgbox "$error" 993 f_interactive || f_die 994 continue 995 fi 2. That looks like our guy; f_dialog_msgbox() will use the currently-active dialog title. NOTE: This should probably be changed to be more clear in several ways. First, drop stdout to /dev/null keeping only stderr. Second, probably use ${error:-Unknown error has occurred} so that if some program returns error but doesn't produce an error message... we have some sensible fallback; Last, but not least, change the title to "Error" and put some prefix before the error text (with aforementioned fallback). 3. Diving into the "zfs_create_boot" function... and further, the "zfs_create_diskpart" function... There are any number of reasons why you would get thrown back to the ZFS Configuration menu. A few are listed below: Inability to write to $BSDINSTALL_TMPETC/fstab You've specified an invalid swapsize. NB: Therein lies another problem ... we don't catch the error from f_expand_number and then tell you why a custom swap size is perhaps invalid. "gpart create -s gpt $disk" failed "gpart destroy -F $disk" failed NB: This is irrespective of whether you chose MBR or GPT; it's a bug that should be fixed (we shouldn't return failure on the pre-cursory destruction of existing data. etc... So thank you !! looks like I've got some patching to do to improve the debugging. --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 19:49:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6A92636D; Sat, 19 Oct 2013 19:49:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC67F2D1C; Sat, 19 Oct 2013 19:49:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9JJnKsE090251; Sat, 19 Oct 2013 15:49:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9JJnKdv090250; Sat, 19 Oct 2013 19:49:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 19 Oct 2013 19:49:20 GMT Message-Id: <201310191949.r9JJnKdv090250@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 19:49:22 -0000 TB --- 2013-10-19 16:36:54 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-19 16:36:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-19 16:36:54 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-10-19 16:36:54 - cleaning the object tree TB --- 2013-10-19 16:38:32 - /usr/local/bin/svn stat /src TB --- 2013-10-19 16:38:37 - At svn revision 256765 TB --- 2013-10-19 16:38:38 - building world TB --- 2013-10-19 16:38:38 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 16:38:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 16:38:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 16:38:38 - SRCCONF=/dev/null TB --- 2013-10-19 16:38:38 - TARGET=powerpc TB --- 2013-10-19 16:38:38 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 16:38:38 - TZ=UTC TB --- 2013-10-19 16:38:38 - __MAKE_CONF=/dev/null TB --- 2013-10-19 16:38:38 - cd /src TB --- 2013-10-19 16:38:38 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 19 16:38:45 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Oct 19 19:45:29 UTC 2013 TB --- 2013-10-19 19:45:29 - generating LINT kernel config TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/bin/make -B LINT TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/sbin/config -m LINT TB --- 2013-10-19 19:45:29 - skipping LINT kernel TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/sbin/config -m GENERIC TB --- 2013-10-19 19:45:29 - skipping GENERIC kernel TB --- 2013-10-19 19:45:29 - cd /src/sys/powerpc/conf TB --- 2013-10-19 19:45:29 - /usr/sbin/config -m GENERIC64 TB --- 2013-10-19 19:45:29 - building GENERIC64 kernel TB --- 2013-10-19 19:45:29 - CROSS_BUILD_TESTING=YES TB --- 2013-10-19 19:45:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-19 19:45:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-19 19:45:29 - SRCCONF=/dev/null TB --- 2013-10-19 19:45:29 - TARGET=powerpc TB --- 2013-10-19 19:45:29 - TARGET_ARCH=powerpc64 TB --- 2013-10-19 19:45:29 - TZ=UTC TB --- 2013-10-19 19:45:29 - __MAKE_CONF=/dev/null TB --- 2013-10-19 19:45:29 - cd /src TB --- 2013-10-19 19:45:29 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Sat Oct 19 19:45:29 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_subr.c ctfconvert -L VERSION -g geom_subr.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/geom_vfs.c ctfconvert -L VERSION -g geom_vfs.o cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/geom/label/g_label.c cc1: warnings being treated as errors /src/sys/geom/label/g_label.c: In function 'g_label_resize': /src/sys/geom/label/g_label.c:135: warning: null format string [-Wformat] *** Error code 1 Stop. bmake[1]: stopped in /obj/powerpc.powerpc64/src/sys/GENERIC64 *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-19 19:49:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-19 19:49:20 - ERROR: failed to build GENERIC64 kernel TB --- 2013-10-19 19:49:20 - 10023.24 user 1246.77 system 11545.66 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 20:21:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F619DF0; Sat, 19 Oct 2013 20:21:04 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 455682EC1; Sat, 19 Oct 2013 20:21:04 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r9JKKt2P031812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 19 Oct 2013 15:20:55 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Sat, 19 Oct 2013 15:20:54 -0500 From: "Teske, Devin" To: Johan Broman Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Topic: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Index: AQHOzOHuoyZqOu2cyEmJYHyn2Q5Miw== Date: Sat, 19 Oct 2013 20:20:53 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC7F916@LTCFISWMSGMB21.FNFIS.com> References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> <5262B304.3090605@allanjude.com> <5262BC56.4050004@bridgenet.se> In-Reply-To: <5262BC56.4050004@bridgenet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <98CC1E95FACE1748A0F85028DD3546A2@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18,2013-10-18,1970-01-01 signatures=0 Cc: Devin Teske , " Current" , "Teske, Devin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 20:21:04 -0000 On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: > I recreated the graid mirror on ada2 and ada3 and reran the installation.= I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indi= cation that the action failed and I'm returned to the ZFS setup screen if I= hit OK. >=20 > I have screen shots (taken with my phone) of the msgbox and "ps auxwww" o= utput. Let me know what kind of debug info you would like. I've put the scr= een shots here: >=20 > http://212.181.212.146/bsdinstall I've added a patch to fix debugging in the zfsboot script... http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ Feedback welcome. Johan,... Can you see if the patch sheds some better light as to what's failing? The patch won't fix the problem, but it should give us an accurate error message so that we can learn what precisely is returning an error status. Thanks in advance. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Oct 19 20:27:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F888F73 for ; Sat, 19 Oct 2013 20:27:27 +0000 (UTC) (envelope-from johan@bridgenet.se) Received: from smtp-gw11.han.skanova.net (smtp-gw11.han.skanova.net [81.236.55.20]) by mx1.freebsd.org (Postfix) with ESMTP id BD15B2EF2 for ; Sat, 19 Oct 2013 20:27:26 +0000 (UTC) Received-SPF: pass (smtp-gw11.han.skanova.net: domain bridgenet.se designates 212.181.212.146 as permitted sender) identity=mailfrom; receiver=smtp-gw11.han.skanova.net; client_ip=212.181.212.146; envelope-from=johan@bridgenet.se; helo=mail.bridgenet.se; Received: from mail.bridgenet.se (212.181.212.146) by smtp-gw11.han.skanova.net (8.5.133) id 525514D7004EF76F for freebsd-current@freebsd.org; Sat, 19 Oct 2013 22:27:23 +0200 Received: from mail.bridgenet.se (unknown [10.0.0.5]) by mail.bridgenet.se (Postfix) with ESMTP id B61E317890 for ; Sat, 19 Oct 2013 22:27:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bridgenet.se; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:to:mime-version:user-agent:from:from :date:date:message-id; s=dkim; t=1382214440; x=1383078441; bh=5w JaPnVzS9TmZCqYasDEmVWrLPzOsbTKBrV/YCTBvFc=; b=VGypGTPsY0yA/kS2wD JvRTOSpFTpcV96uvytmU6RqiG08XeMUkV47frms9BEZiWJ5OrXdqTqv/0DkvzbAZ zuJwN+CqMjgllOJ796Y4w5IOb3AZKcrT1A6+HDXair/FJ3wOEaYBNemCw49hlrW+ BrLQAtai471s6+Nk2rkDUbT14= X-Virus-Scanned: amavisd-new at mail.bridgenet.se Received: from mail.bridgenet.se ([10.0.0.5]) by mail.bridgenet.se (mail.bridgenet.se [10.0.0.5]) (amavisd-new, port 10024) with ESMTP id fVX9LjYpk_Zm for ; Sat, 19 Oct 2013 22:27:20 +0200 (CEST) Received: from dhcp-208-143.arn.redhat.com (unknown [192.168.0.129]) by mail.bridgenet.se (Postfix) with ESMTPSA id D5D4B17881 for ; Sat, 19 Oct 2013 22:27:19 +0200 (CEST) Message-ID: <5262EB23.7090605@bridgenet.se> Date: Sat, 19 Oct 2013 22:27:15 +0200 From: Johan Broman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI References: <52629DA7.7090103@bridgenet.se> <5262A3EE.4050600@allanjude.com> <5262A5D0.3050604@bridgenet.se> <5262A69D.5070601@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC7E9DE@LTCFISWMSGMB21.FNFIS.com> <13CA24D6AB415D428143D44749F57D720FC7EAEC@LTCFISWMSGMB21.FNFIS.com> <5262B304.3090605@allanjude.com> <5262BC56.4050004@bridgenet.se> <13CA24D6AB415D428143D44749F57D720FC7F4AD@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D720FC7F4AD@LTCFISWMSGMB21.FNFIS.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: 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, 19 Oct 2013 20:27:27 -0000 On 19/10/13 20:52, Teske, Devin wrote: > > On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: > >> >> >> On 19/10/13 18:27, Allan Jude wrote: >>> On 2013-10-19 11:55, Teske, Devin wrote: >>>> On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: >>>> >>>>> On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: >>>>> >>>>>> On 2013-10-19 11:31, Johan Broman wrote: >>>>>>> >>>>>>> On 19/10/13 17:23, Allan Jude wrote: >>>>>>>> On 2013-10-19 10:56, Johan Broman wrote: >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I >>>>>>>>> have 4 SATA drives in my server. I select all four of them in a RAIDZ1 >>>>>>>>> setup. I hit enter to continue the installation and the zpool is >>>>>>>>> created, but I'm then returned to the zpool selection screen again. It >>>>>>>>> turned out that two of the drives had previously been used in a >>>>>>>>> (Linux) software mirror setup and because of this they got activated >>>>>>>>> in /dev/raid/r0. Because of this I ended up in an endless bsdinstall >>>>>>>>> loop. >>>>>>>>> >>>>>>>>> Removing the raid device using the graid command resolved the >>>>>>>>> situation. >>>>>>>>> >>>>>>>>> Now maybe this is working as designed, but there was no warning/alert >>>>>>>>> to the fact that the devices couldn't be used. Perhaps a warning >>>>>>>>> should be rasied in this situation? >>>>>>>>> >>>>>>>>> Thanks for all the great work on the new installer, really looking >>>>>>>>> forward to FreeBSD 10! >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Johan >>>>>>>>> _______________________________________________ >>>>>>>>> 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" >>>>>>>> Errors like that normally generate a msgbox dialog with the error output >>>>>>>> from whichever command failed. I'll have to dig into it and see where >>>>>>>> that problem is. I've seen other people have problems creating ZFS >>>>>>>> arrays after graid, but in that case it was an incomplete graid label >>>>>>>> causing a device to be locked but not appear in the graid status output. >>>>>>>> >>>>>>> Ah ok. A msgbox did appear but the drives that had the problem (ada2 >>>>>>> and ada3) wasn't visible in the output. (not sure if the box itself >>>>>>> has a size limit or maybe I was just unable to scroll down and see the >>>>>>> errors?). The only visible output was that it was able to create >>>>>>> labels on ada0 and ada1. >>>>>>> >>>>>>> /Johan >>>>>>> _______________________________________________ >>>>>>> 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" >>>>>> Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to >>>>>> add a scrollbar but turns out that is not possible. >>>>>> >>>>>> The only indication that there is more message to read, is a small 'xx%' >>>>>> in the bottom right. We might have to look at breaking that output up or >>>>>> something. >>>>>> >>>>> >>>>> The only reason for a msgbox widget to scroll is if it is displayed at >>>>> maximum height or width of the screen and it *still* has more data >>>>> to display than can be presented at-once. >>>>> >>>> I should clarify... >>>> >>>> The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. >>>> That being said, msgbox widgets automatically scale their size to fit the >>>> content being displayed. So whenever a msgbox is thrown up using this >>>> API... the widget will never scroll unless the box can't be made big enough >>>> to hold the entire content (either the screen resolution or terminal size is >>>> too small; we maxed out the size of the widget; and there's still hidden >>>> content). >>>> >>>> But... >>>> >>>> While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. >>>> >>>> >>>> >>>>> If... however... the msgbox widget is *not* full-height or full-width >>>>> yet... it is requiring you to scroll -- then we've found a bug. >>>>> >>>>> Can we get a screen shot? >>>> So we really need to nail down precisely which error box this is so that >>>> we can address whether the issue is in-fact an instance of using the old >>>> error-box handling instead of the auto-sizing API. >>>> >>>> So... >>>> >>>> With this described API, you should never have to scroll a box unless it >>>> can't fit all the data *and* you should be able to immediately identify when >>>> that becomes the case... >>>> >>>> 1. The widget spans the entire width of the screen. >>>> >>>> 2. The widget spans the entire height of the screen. >>>> >>>> 3. Both 1 and 2. >>>> >>>> It's in *those* cases that you should then *EXPECT* to find that the >>>> region can scroll with cursor keys and page up/down (look for the >>>> scroll percentage in the widget as Allan suggested. >>>> >>>> I don't want to see the scroll percentage doohickey *unless* the widget >>>> is auto-sized to full-width or full-height. Meaning, there's either a bug in >>>> the API or someone fell into a trap (there are a couple). >>> >>> the error output msgbox is huge, probably 100+ lines (the screen is >>> what, 24 lines high, and with the ok button, top and bottom reserved >>> space etc, can display maybe 18 lines at once) >>> >>> It contains all the shell output from everything we do, creating the >>> gparts, setting up gnop, all of the redundant destroys etc. >>> >>> I don't think the TINY little % in the bottom right is really enough of >>> an indicator to the user that they CAN scroll, let alone HOW to scroll >>> (IIRC the arrow keys do not work, must use page down) >>> >> >> I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. >> >> I have screen shots (taken with my phone) of the msgbox and "ps auxwww" output. Let me know what kind of debug info you would like. I've put the screen shots here: >> >> http://212.181.212.146/bsdinstall >> > > It looks like one of the commands that is used to partition > the disks is producing an error status on exit but ... no error? > > Double-check me on this, but... > > 1. It looks to me like this is what you're seeing (code-wise): > > From http://svnweb.freebsd.org/base/head/usr.sbin/bsdinstall/scripts/zfsboot?revision=256553&view=markup > > 989 if ! error=$( zfs_create_boot "$ZFSBOOT_POOL_NAME" \ > 990 "$vdev_type" $real_disks 2>&1 ) > 991 then > 992 f_dialog_msgbox "$error" > 993 f_interactive || f_die > 994 continue > 995 fi > Yep, that looks like it. So maybe the command appears to go ok and hence no stderr output? > 2. That looks like our guy; f_dialog_msgbox() will use the > currently-active dialog title. > > NOTE: This should probably be changed to be more clear in > several ways. First, drop stdout to /dev/null keeping only stderr. > Second, probably use ${error:-Unknown error has occurred} > so that if some program returns error but doesn't produce an > error message... we have some sensible fallback; Last, but not > least, change the title to "Error" and put some prefix before the > error text (with aforementioned fallback). Ah yes. Makes sense to have a fallback. > > 3. Diving into the "zfs_create_boot" function... and further, the > "zfs_create_diskpart" function... > > There are any number of reasons why you would get thrown > back to the ZFS Configuration menu. A few are listed below: > > Inability to write to $BSDINSTALL_TMPETC/fstab > > You've specified an invalid swapsize. > NB: Therein lies another problem ... we don't catch the error > from f_expand_number and then tell you why a custom swap > size is perhaps invalid. > > "gpart create -s gpt $disk" failed > "gpart destroy -F $disk" failed > NB: This is irrespective of whether you chose MBR or GPT; it's > a bug that should be fixed (we shouldn't return failure on the > pre-cursory destruction of existing data. > > etc... > > So thank you !! looks like I've got some patching to do to > improve the debugging. > np! :) Cheers Johan