From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 00:25:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8382D1065674 for ; Sun, 9 Oct 2011 00:25:35 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D4EB08FC0A for ; Sun, 9 Oct 2011 00:25:34 +0000 (UTC) Received: by wyj26 with SMTP id 26so6949353wyj.13 for ; Sat, 08 Oct 2011 17:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n22bA/eu/W5wiArcjqq3O12FkrDCKFyvxDLTwlzVUuU=; b=V/uz8SzNxV7XLcVnv00KMX9D97bYrUID/toSw7hL5tGDcXYoDjPepm933KM7hr7iw5 3nclh4Hf4/BI5oGin1oXD+Kdo8DsP+DtANgCVO5YNMRo3sCmqWbjbIFsfh3h+U0u9jmY bhEOoKTAq3SBiQsAyAngERMGRrc/jobI+CqJE= MIME-Version: 1.0 Received: by 10.216.163.194 with SMTP id a44mr4283366wel.1.1318119933654; Sat, 08 Oct 2011 17:25:33 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sat, 8 Oct 2011 17:25:33 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sat, 8 Oct 2011 17:25:33 -0700 (PDT) In-Reply-To: References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> Date: Sun, 9 Oct 2011 10:55:33 +1030 Message-ID: From: Matt Thyer To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Garrett Cooper , Glen Barber , freebsd-current@freebsd.org, "Thomas K." Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 00:25:35 -0000 On Oct 9, 2011 8:52 AM, "Warren Block" wrote: > > On Sat, 8 Oct 2011, Glen Barber wrote: > >> On 10/8/11 5:40 PM, Warren Block wrote: >>> >>> On Sat, 8 Oct 2011, Glen Barber wrote: >>> >>>> On 10/8/11 2:21 PM, Garrett Cooper wrote: >>>>>> >>>>>> Are there any general structural differences between FreeBSD 8 and 9 >>>>>> memstick >>>>>> images which could be at fault here? >>>>>> >>>>> >>>>> The new memstick image uses GPT instead of MBR partitioning. >>>> >>>> >>>> GPT should have no impact on booting from the memory stick, as far as I >>>> am aware. >>> >>> >>> Memory stick should not be a problem, but some of the Lenovo notebooks >>> hate GPT, even with a PMBR: >>> http://forums.freebsd.org/showthread.php?t=26304 >>> http://forums.freebsd.org/showthread.php?t=26759 >>> >> >> Ugh, that's annoying. I'm half-tempted to note this in the new >> installer chapter, but I don't like the idea of such edge cases as these >> to effectively turn that page into a pseudo-HCL. > > > There are already a couple of notes about having to use MBR with XP and other older operating systems. But instead of updating them, I'd rather see somebody with one of the affected systems contact somebody with influence at Lenovo and say "hey, the FreeBSD guys are talking about making your broken GPT support famous" followed quickly by a BIOS update. > I believe this is actually a case of the memstick image being an improperly formatted GPT as there is no backup partition table at the end of the volume. The only sensible answer is to not use GPT for the memstick image. I not said this,loud enough yet but this is a show stopper for 9.0-RELEASE and must be fixed. We can't have a major release that modern systems cannot install with one of now most popular install methods. As a first step, Andriy Gapon has provided a quick patch for makefs(8) so it can create filesystems with UFS labels (as bsdinstall relys on labels). If you want to fix your memstick, create a copy of the partition table at the end of the volume and it should boot. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 00:31:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB80E106566B for ; Sun, 9 Oct 2011 00:31:16 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACD98FC08 for ; Sun, 9 Oct 2011 00:31:15 +0000 (UTC) X-AuditID: 1209190e-b7f4a6d0000008e5-02-4e90eb5330ad Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A9.99.02277.35BE09E4; Sat, 8 Oct 2011 20:31:15 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p990VFIJ018783; Sat, 8 Oct 2011 20:31:15 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p990VCZL028308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Oct 2011 20:31:15 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p990VCTc016429; Sat, 8 Oct 2011 20:31:12 -0400 (EDT) Date: Sat, 8 Oct 2011 20:31:12 -0400 (EDT) From: Benjamin Kaduk To: Roar Pettersen In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrhv8eoKfwZtLChZz3nxgsri+z8yB yWPGp/ksHjtn3WUPYIrisklJzcksSy3St0vgypjw5BtLwVfWiq8HXjI1MN5h6WLk5JAQMJF4 9GYRI4QtJnHh3nq2LkYuDiGBfYwSB2cdY4Jw1jNKbHk0mx3C2c8kcf3TeyaQFiGBeonnhy4z g9gsAloSTfcWg41iE1CRmPlmIxuILSKgLtH9ZDoriM0sIC/x/8plsF5hAW2JCy+XgfVyCgRK bD7xA8jm4OAVsJdYuCsLYnyAxI1py8BaRQV0JFbvnwJ2Na+AoMTJmU9YIEZaSpz7c51tAqPg LCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgSFKack3w7GrweV DjEKcDAq8fBufDHBT4g1say4MvcQoyQHk5Iob9xLoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR 3pbtQDnelMTKqtSifJiUNAeLkjjv6h0OfkIC6YklqdmpqQWpRTBZGQ4OJQnejldAjYJFqemp FWmZOSUIaSYOTpDhPEDDu0BqeIsLEnOLM9Mh8qcYFaXEeeeDJARAEhmleXC9sDTyilEc6BVh 3iaQKh5gCoLrfgU0mAlo8GnjfpDBJYkIKakGRo6GI2l71JPkZqQEuB0Iftk36+fMLX/12Xy+ bF/1+crKcwqbZd92SlVtWyjPOXtr/Ptb7/7Nvzkp/ZeV9xPLm+6p+jk3dz/L8f+SwaNzTVa+ 4p/XmdvP34T8TV42rV7wgFFz5QXvpdfmuSyw7f9lotzWo5kl//KYuqMpq6VuntP9sy3b3zeG 31diKc5INNRiLipOBAAOhlny/gIAAA== Cc: freebsd-current@freebsd.org Subject: Re: 9.0-BETA 3 lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 00:31:16 -0000 On Sat, 8 Oct 2011, Roar Pettersen wrote: > Hello ! > > > Just did a new build of world & kernel, and the error message have changed a > bit : > > > lock order reversal: > 1st 0xddf0c4cc bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 > 2nd 0xc4996200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 Hi Roar, Both of these look to be "well-known" (i.e. trivially reproduced) LORs. No one seems to have been willing to step up to disable the warnings for them or otherwise eliminate them, though, so they still pop up and surprise people. Thanks for taking the time to report them, and sorry that they've been sitting untouched for so long. -Ben Kaduk [0] http://ipv4.sources.zabbadoz.net/freebsd/lor.html From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 00:34:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCC29106566B; Sun, 9 Oct 2011 00:34:00 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id A959D8FC14; Sun, 9 Oct 2011 00:34:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LSR00500W8NF700@smtpauth1.wiscmail.wisc.edu>; Sat, 08 Oct 2011 19:33:59 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-76-208-71-153.dsl.mdsnwi.sbcglobal.net [76.208.71.153]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LSR00LUSW8M8O00@smtpauth1.wiscmail.wisc.edu>; Sat, 08 Oct 2011 19:33:59 -0500 (CDT) Date: Sat, 08 Oct 2011 19:33:57 -0500 From: Nathan Whitehorn In-reply-to: To: Matt Thyer Message-id: <4E90EBF5.4090101@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.71.153 X-Spam-PmxInfo: Server=avs-11, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.9.2414, SenderIP=76.208.71.153 References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 Cc: Warren Block , Garrett Cooper , freebsd-current@freebsd.org, "Thomas K." , Glen Barber Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 00:34:01 -0000 On 10/08/11 19:25, Matt Thyer wrote: > On Oct 9, 2011 8:52 AM, "Warren Block" wrote: >> On Sat, 8 Oct 2011, Glen Barber wrote: >> >>> On 10/8/11 5:40 PM, Warren Block wrote: >>>> On Sat, 8 Oct 2011, Glen Barber wrote: >>>> >>>>> On 10/8/11 2:21 PM, Garrett Cooper wrote: >>>>>>> Are there any general structural differences between FreeBSD 8 and 9 >>>>>>> memstick >>>>>>> images which could be at fault here? >>>>>>> >>>>>> The new memstick image uses GPT instead of MBR partitioning. >>>>> >>>>> GPT should have no impact on booting from the memory stick, as far as I >>>>> am aware. >>>> >>>> Memory stick should not be a problem, but some of the Lenovo notebooks >>>> hate GPT, even with a PMBR: >>>> http://forums.freebsd.org/showthread.php?t=26304 >>>> http://forums.freebsd.org/showthread.php?t=26759 >>>> >>> Ugh, that's annoying. I'm half-tempted to note this in the new >>> installer chapter, but I don't like the idea of such edge cases as these >>> to effectively turn that page into a pseudo-HCL. >> >> There are already a couple of notes about having to use MBR with XP and > other older operating systems. But instead of updating them, I'd rather see > somebody with one of the affected systems contact somebody with influence at > Lenovo and say "hey, the FreeBSD guys are talking about making your broken > GPT support famous" followed quickly by a BIOS update. > I believe this is actually a case of the memstick image being an improperly > formatted GPT as there is no backup partition table at the end of the > volume. > > The only sensible answer is to not use GPT for the memstick image. > > I not said this,loud enough yet but this is a show stopper for 9.0-RELEASE > and must be fixed. > > We can't have a major release that modern systems cannot install with one of > now most popular install methods. > > As a first step, Andriy Gapon has provided a quick patch for makefs(8) so it > can create filesystems with UFS labels (as bsdinstall relys on labels). > > If you want to fix your memstick, create a copy of the partition table at > the end of the volume and it should boot. It is being fixed, pending Andriy's change getting into the tree, which should be soon, and will end up being used for the next build (which I believe is RC1). There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 01:20:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6A11065674; Sun, 9 Oct 2011 01:20:02 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A5FF8FC18; Sun, 9 Oct 2011 01:20:01 +0000 (UTC) Received: by wyj26 with SMTP id 26so6987811wyj.13 for ; Sat, 08 Oct 2011 18:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pv2iTdDNvW16Sdv7EO0/em/TRSJfG3l082pdCKgPLAc=; b=Zc4oap0S3yw5y+8fE6xl1Kn1FTBASaIz5ax5o02Y7TBL8zCHU3ocCJf2akkHD3bduz DKDsNIS+LVuMrGSO6dABPfxqHBgIZ80VTN6T0E9TvtidCMzIkmOk7wHFfowzn1fY7SrB 9S2UvOwrJ8+gKtSW46vsO/w1CzD7z1oTpYRNk= MIME-Version: 1.0 Received: by 10.216.230.167 with SMTP id j39mr4330381weq.31.1318123200405; Sat, 08 Oct 2011 18:20:00 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sat, 8 Oct 2011 18:19:59 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sat, 8 Oct 2011 18:19:59 -0700 (PDT) In-Reply-To: <4E90EBF5.4090101@freebsd.org> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> Date: Sun, 9 Oct 2011 11:49:59 +1030 Message-ID: From: Matt Thyer To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Warren Block , Glen Barber , freebsd-current@freebsd.org, "Thomas K." , Garrett Cooper Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 01:20:02 -0000 On Oct 9, 2011 11:04 AM, "Nathan Whitehorn" wrote: > > On 10/08/11 19:25, Matt Thyer wrote: >> >> I believe this is actually a case of the memstick image being an improperly >> formatted GPT as there is no backup partition table at the end of the >> volume. >> >> The only sensible answer is to not use GPT for the memstick image. >> >> I've not said this loud enough yet but this is a show stopper for >> 9.0-RELEASE and must be fixed. >> >> We can't have a major release that modern systems cannot install with one of >> the now most popular install methods. >> >> As a first step, Andriy Gapon has provided a quick patch for makefs(8) so it >> can create filesystems with UFS labels (as bsdinstall relys on labels). >> >> If you want to fix your memstick, create a copy of the partition table at >> the end of the volume and it should boot. > > > It is being fixed, pending Andriy's change getting into the tree, which should be soon, and will end up being used for the next build (which I believe is RC1). > > There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. > -Nathan > I don't think there have been any reports of failure to boot properly formatted GPT yet. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 01:28:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA289106566B; Sun, 9 Oct 2011 01:28:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC228FC0A; Sun, 9 Oct 2011 01:28:56 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p991Stgr010551; Sat, 8 Oct 2011 19:28:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p991Std1010548; Sat, 8 Oct 2011 19:28:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 8 Oct 2011 19:28:55 -0600 (MDT) From: Warren Block To: Matt Thyer In-Reply-To: Message-ID: References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 08 Oct 2011 19:28:55 -0600 (MDT) Cc: Garrett Cooper , Glen Barber , freebsd-current@freebsd.org, "Thomas K." , Nathan Whitehorn Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 01:28:56 -0000 On Sun, 9 Oct 2011, Matt Thyer wrote: > On Oct 9, 2011 11:04 AM, "Nathan Whitehorn" wrote: > > > > On 10/08/11 19:25, Matt Thyer wrote: > >> > > > There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist > them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. > > > I don't think there have been any reports of failure to boot properly formatted GPT yet. Lenovo T420S and T520, from the links above. Install GPT on the hard drive, try to boot. http://forums.freebsd.org/showthread.php?t=26304 http://forums.freebsd.org/showthread.php?t=26759 http://forum.thinkpads.com/viewtopic.php?f=9&t=98078 From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 02:00:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A88C106566C for ; Sun, 9 Oct 2011 02:00:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B918A8FC08 for ; Sun, 9 Oct 2011 02:00:41 +0000 (UTC) Received: by gyf2 with SMTP id 2so5804555gyf.13 for ; Sat, 08 Oct 2011 19:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nuusLMcp63haUVo0EUaplNxpA9yNuO+C3/FOsb/XLFM=; b=pOegFljieOB0JO+1OoIht/Zhi/2baX4/2Vy5mu107DSeYrYUc2kd7vfsxDSimWXts0 5m4kTADXkqrCbbRXIP+1Lo7ynutQPun37yuxYdKEfDcGQf8gMLfRTljj0w9fPMgdEfdf e3AMWGxOgKVlbAqX15NLlq75TAJqbwJk2xsyo= MIME-Version: 1.0 Received: by 10.236.197.104 with SMTP id s68mr17963358yhn.20.1318125640942; Sat, 08 Oct 2011 19:00:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sat, 8 Oct 2011 19:00:40 -0700 (PDT) In-Reply-To: <4E90B4B1.7000009@FreeBSD.org> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> Date: Sun, 9 Oct 2011 10:00:40 +0800 X-Google-Sender-Auth: nRdNnrOQPCDI8TkPceg0r-uVtOo Message-ID: From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-current@freebsd.org, "Thomas K." Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 02:00:42 -0000 On 9 October 2011 04:38, Glen Barber wrote: > > GPT should have no impact on booting from the memory stick, as far as I > am aware. I've already emailed -current with an example where GPT+memstick == fail. Some theories include that GPT/EFT on USB is what the BIOS expects when doing BIOS reflashing, and gets confused when something else is there. Adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 02:15:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516A6106564A for ; Sun, 9 Oct 2011 02:15:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 137A38FC0A for ; Sun, 9 Oct 2011 02:15:53 +0000 (UTC) Received: (qmail 75251 invoked by uid 0); 8 Oct 2011 22:15:53 -0400 Received: from unknown (HELO schism.local) (gjb@76.124.49.145) by 0 with SMTP; 8 Oct 2011 22:15:53 -0400 Message-ID: <4E9103D3.4000706@FreeBSD.org> Date: Sat, 08 Oct 2011 22:15:47 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC78E49659272F50F1D5DFF8C" Cc: Garrett Cooper , freebsd-current@freebsd.org, "Thomas K." Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 02:15:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC78E49659272F50F1D5DFF8C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/8/11 10:00 PM, Adrian Chadd wrote: > On 9 October 2011 04:38, Glen Barber wrote: >> >> GPT should have no impact on booting from the memory stick, as far as = I >> am aware. >=20 > I've already emailed -current with an example where GPT+memstick =3D=3D= fail. > Some theories include that GPT/EFT on USB is what the BIOS expects > when doing BIOS reflashing, and gets confused when something else is > there. Yep, and I also recall you bringing this up in IRC. Though, at that time (well, up until a few hours ago), I wasn't aware of the Lenovo issue Warren mentioned. So, that said, I happily stand corrected. I am now aware of a few GPT memstick issues. :) --=20 Glen Barber | gjb@FreeBSD.org FreeBSD Documentation Project --------------enigC78E49659272F50F1D5DFF8C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBCAAGBQJOkQPYAAoJEFJPDDeguUajmy8H/AzUgwIcb6A7V1Ui5OUy/EoS nFSKEJAo6PuQS5VfE3wakj7Gg7P9DgPG1lb2QItTOZufb4a9pb8m0ivFJ8VkyDxN 4paUM+wl3Pu0eJLPFjfquckij5/Xd+RMEXCYCE07ojZRvCMxyPC/4kPL3tCIqXh5 sclc2yvwWvNcIm+taFEYurDPp+hm13Y3wxKxpnYjpAHh9m1Cy1zNlO8R32KoU7y0 NrLN3HF/+6YyGmAqceDHUnVxBvs5hN9ynHIQ4WFc4D7B931ZtxmLjBqjuqL+ZW0Q +iyjOdZ1c9nsxuqqH7lMpth/lZaUF2aRWYXqVgxIc9dCPE1YUIlDnajkYQzjRlk= =/Wwp -----END PGP SIGNATURE----- --------------enigC78E49659272F50F1D5DFF8C-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 02:29:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B88F2106564A; Sun, 9 Oct 2011 02:29:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 63C808FC1B; Sun, 9 Oct 2011 02:29:14 +0000 (UTC) Received: by gyf2 with SMTP id 2so5812081gyf.13 for ; Sat, 08 Oct 2011 19:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vnlMOoH8rBwOL7XKLBYOD0Fj0wZzAZkAptYbEYO31F0=; b=BsPI4VDhFtZoo6fizbvWXqObOH2npRo79Akv04HDmmhdOc51a/FCRsjZ8KUXDlS57w tcHA9m8iUVwBLMUelwkT0C+23oSWniPhbTnPj3O7jwtINpt3WUKsmoMNqyhTz2u2Cekf le5Gk3GJQ28kxpqs6FGfTGaLqzy/6MCIa89+w= MIME-Version: 1.0 Received: by 10.236.187.70 with SMTP id x46mr17718900yhm.71.1318127353661; Sat, 08 Oct 2011 19:29:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sat, 8 Oct 2011 19:29:13 -0700 (PDT) In-Reply-To: <4E9103D3.4000706@FreeBSD.org> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E9103D3.4000706@FreeBSD.org> Date: Sun, 9 Oct 2011 10:29:13 +0800 X-Google-Sender-Auth: 1yOXcDSAd7PuNoiMuMNMMsEWmKY Message-ID: From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current@freebsd.org, "Thomas K." Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 02:29:14 -0000 On 9 October 2011 10:15, Glen Barber wrote: > Yep, and I also recall you bringing this up in IRC. =A0Though, at that > time (well, up until a few hours ago), I wasn't aware of the Lenovo > issue Warren mentioned. > > So, that said, I happily stand corrected. =A0I am now aware of a few GPT > memstick issues. :) Can we please flip off GPT partitions for memstick images?: ) Adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 02:41:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22B4106566C for ; Sun, 9 Oct 2011 02:41:42 +0000 (UTC) (envelope-from fwd@gothschlampen.com) Received: from keus02.synserver.de (www.hassblog.de [212.40.171.22]) by mx1.freebsd.org (Postfix) with ESMTP id 22B078FC0A for ; Sun, 9 Oct 2011 02:41:41 +0000 (UTC) Received: by keus02.synserver.de (Postfix, from userid 1000) id 8739A15A1E6; Sun, 9 Oct 2011 04:41:40 +0200 (CEST) Date: Sun, 9 Oct 2011 04:41:40 +0200 From: "Thomas K." To: Glen Barber Message-ID: <20111009024140.GA13517@vs2.gothschlampen.com> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E90B4B1.7000009@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 02:41:42 -0000 On Sat, Oct 08, 2011 at 04:38:09PM -0400, Glen Barber wrote: > Thomas, can you please zero out the beginning of the 1024 bytes of your > memory stick, as follows (please take care to note the actual device for > your memory stick, and change '/dev/da0' below, as appropriate): > > dd if=/dev/zero of=/dev/da0 bs=1024 count=1 > > Then re-write the memory stick per the instructions in the Handbook. > Newly added to this section of the Handbook was a note to ensure the > device is _not_ mounted (either manually, or automatically). So you want me to clear the first 1K bytes, and then write the whole image back to the pen drive, did I get this right? If so, I don't understand what we're trying to archive here, maybe you could explain? Anyway, I read it wrong the first time and did the following: I just cleared the first 1K of the stick as it was (with BETA3 image on it), and then put it in when rebooting the box and pressing F12 to get to the boot device list. Without the GPT it showed up in the list, but of course was unbootable when choosen. I then wrote back the 1K with "dd if=FreeBSD-9... of=/dev/sde bs=1024 count=1" and verified the stick to be ok with a cmp(1) of the device file vs. the image file, so the pendrive is in the fresh state it should be. When plugging it in under Linux I get the following: ================================================================================ [232309.636200] usb 1-1.1: new high speed USB device number 5 using ehci_hcd [232309.730109] scsi9 : usb-storage 1-1.1:1.0 [232310.729101] scsi 9:0:0:0: Direct-Access Ut165 USB2FlashStorage 0.00 PQ: 0 ANSI: 2 [232310.904549] sd 9:0:0:0: Attached scsi generic sg5 type 0 [232310.905449] sd 9:0:0:0: [sde] 3948544 512-byte logical blocks: (2.02 GB/1.88 GiB) [232310.906657] sd 9:0:0:0: [sde] Write Protect is off [232310.906663] sd 9:0:0:0: [sde] Mode Sense: 00 00 00 00 [232310.907303] sd 9:0:0:0: [sde] Asking for cache data failed [232310.907308] sd 9:0:0:0: [sde] Assuming drive cache: write through [232310.909803] sd 9:0:0:0: [sde] Asking for cache data failed [232310.909808] sd 9:0:0:0: [sde] Assuming drive cache: write through [232311.031811] GPT:Primary header thinks Alt. header is not at the end of the disk. [232311.031825] GPT:1339319 != 3948543 [232311.031827] GPT:Alternate GPT header not at the end of the disk. [232311.031829] GPT:1339319 != 3948543 [232311.031830] GPT: Use GNU Parted to correct GPT errors. [232311.031845] sde: sde1 sde2 [232311.034154] sd 9:0:0:0: [sde] Asking for cache data failed [232311.034160] sd 9:0:0:0: [sde] Assuming drive cache: write through [232311.034165] sd 9:0:0:0: [sde] Attached SCSI removable disk [232312.081344] ufs was compiled with read-only support, can't be mounted as read-write ================================================================================ Notice the GPT stuff. Of course that's because there can't possibly be an alternative GPT header at the end of the disk unless it's size is the same as the image size. As suggested I fixed it with parted and tried to boot from it again. No joy. I'm starting to believe this box just doesn't know GPT and the BIOS can't handle it at all. This is an Acer AX3960 Core i7 from maybe 6 months ago. Does anyone if the other BSDs have images using GPT, so I might verify? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 02:50:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814ED106566B for ; Sun, 9 Oct 2011 02:50:49 +0000 (UTC) (envelope-from fwd@gothschlampen.com) Received: from keus02.synserver.de (www.hassblog.de [212.40.171.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7D58FC0A for ; Sun, 9 Oct 2011 02:50:48 +0000 (UTC) Received: by keus02.synserver.de (Postfix, from userid 1000) id 321A315A27A; Sun, 9 Oct 2011 04:50:48 +0200 (CEST) Date: Sun, 9 Oct 2011 04:50:48 +0200 From: "Thomas K." To: Warren Block Message-ID: <20111009025047.GB13517@vs2.gothschlampen.com> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Garrett Cooper , Glen Barber , Matt Thyer , Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 02:50:49 -0000 On Sat, Oct 08, 2011 at 07:28:55PM -0600, Warren Block wrote: > On Sun, 9 Oct 2011, Matt Thyer wrote: > >On Oct 9, 2011 11:04 AM, "Nathan Whitehorn" wrote: > >> > >> On 10/08/11 19:25, Matt Thyer wrote: > >>> > >> > >There is also the interesting question of actually installing to GPT on the hard disk, which is the default in 9.0. Does this not work on some systems? If so, do we want to blacklist > >them and use a different default partition scheme? Can we identify systems that violate regular PC boot standards and reject GPT? Any data on any of these points would be appreciated. > >> > >I don't think there have been any reports of failure to boot properly formatted GPT yet. > > Lenovo T420S and T520, from the links above. Install GPT on the > hard drive, try to boot. > > http://forums.freebsd.org/showthread.php?t=26304 > http://forums.freebsd.org/showthread.php?t=26759 > http://forum.thinkpads.com/viewtopic.php?f=9&t=98078 As I used parted from Linux to fix the alternate GPT, i.e. put it not at the end of the image data but on the end of the disk, and it still did not appear in the boot device list, the Acer AX3960 should probably be on the list as well. Being a Core i7 2600k system maybe 6 months old, it's rather recent hardware, but doesn't boot from the memstick image. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 04:44:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 069AB106566C; Sun, 9 Oct 2011 04:44:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 83CBC8FC0A; Sun, 9 Oct 2011 04:44:55 +0000 (UTC) Received: by qadz30 with SMTP id z30so4541806qad.13 for ; Sat, 08 Oct 2011 21:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RHzXaQIBcMFy0tzZ3dH9+qHoWniFWOQIem667a7lYps=; b=KCThHuJPutqRIvNrF24jwUc2srvkxhvFkDVsavaqns+ENYb8iMCufioq+h0BcWSK2p PK8FOPLHORyLpZ6HQpa8Nza+QR9CdKL6D7E53G/KCA3zyqKhI4uTOQIF5rZUaWGxflTp 6y5HiY6ohlOjcBJvsXS3qcD0/VciA6W91hKYc= MIME-Version: 1.0 Received: by 10.224.213.2 with SMTP id gu2mr2540108qab.85.1318135493771; Sat, 08 Oct 2011 21:44:53 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Sat, 8 Oct 2011 21:44:53 -0700 (PDT) In-Reply-To: <20111009025047.GB13517@vs2.gothschlampen.com> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> <20111009025047.GB13517@vs2.gothschlampen.com> Date: Sat, 8 Oct 2011 21:44:53 -0700 Message-ID: From: Garrett Cooper To: "Thomas K." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Warren Block , Glen Barber , Matt Thyer , Nathan Whitehorn , freebsd-current@freebsd.org Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 04:44:56 -0000 On Sat, Oct 8, 2011 at 7:50 PM, Thomas K. wrote: > On Sat, Oct 08, 2011 at 07:28:55PM -0600, Warren Block wrote: >> On Sun, 9 Oct 2011, Matt Thyer wrote: >> >On Oct 9, 2011 11:04 AM, "Nathan Whitehorn" wr= ote: >> >> >> >> On 10/08/11 19:25, Matt Thyer wrote: >> >>> >> >> >> >There is also the interesting question of actually installing to GPT on= the hard disk, which is the default in 9.0. Does this not work on some sys= tems? If so, do we want to blacklist >> >them and use a different default partition scheme? Can we identify syst= ems that violate regular PC boot standards and reject GPT? Any data on any = of these points would be appreciated. >> >> >> >I don't think there have been any reports of failure to boot properly f= ormatted GPT yet. >> >> Lenovo T420S and T520, from the links above. =A0Install GPT on the >> hard drive, try to boot. >> >> http://forums.freebsd.org/showthread.php?t=3D26304 >> http://forums.freebsd.org/showthread.php?t=3D26759 >> http://forum.thinkpads.com/viewtopic.php?f=3D9&t=3D98078 > > As I used parted from Linux to fix the alternate GPT, i.e. put it not at = the > end of the image data but on the end of the disk, and it still did not ap= pear > in the boot device list, the Acer AX3960 should probably be on the list > as well. > > Being a Core i7 2600k system maybe 6 months old, it's rather recent hardw= are, > but doesn't boot from the memstick image. MBR format would be a better idea considering that there are a number of catches to using GPT (as noted on the list), and we're probably not anywhere near producing 2TB+ images (yet :)..), and to quote Monty Python MBR: "I'm not dead yet!". If it comes to that day and age, we could provide a script or standalone command that would do the gpart foo to write out the partition table and just copy the image to the first partition, correct? Seems like more OSes should run into this issue producing GPT partitioned media than just us.. -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 05:45:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7596106564A for ; Sun, 9 Oct 2011 05:45:40 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 58D708FC0C for ; Sun, 9 Oct 2011 05:45:40 +0000 (UTC) Received: (qmail 9586 invoked by uid 0); 9 Oct 2011 01:45:39 -0400 Received: from unknown (HELO schism.local) (gjb@76.124.49.145) by 0 with SMTP; 9 Oct 2011 01:45:39 -0400 Message-ID: <4E913502.5020307@FreeBSD.org> Date: Sun, 09 Oct 2011 01:45:38 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Thomas K." References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <20111009024140.GA13517@vs2.gothschlampen.com> In-Reply-To: <20111009024140.GA13517@vs2.gothschlampen.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 05:45:40 -0000 On 10/8/11 10:41 PM, Thomas K. wrote: > On Sat, Oct 08, 2011 at 04:38:09PM -0400, Glen Barber wrote: > >> Thomas, can you please zero out the beginning of the 1024 bytes of your >> memory stick, as follows (please take care to note the actual device for >> your memory stick, and change '/dev/da0' below, as appropriate): >> >> dd if=/dev/zero of=/dev/da0 bs=1024 count=1 >> >> Then re-write the memory stick per the instructions in the Handbook. >> Newly added to this section of the Handbook was a note to ensure the >> device is _not_ mounted (either manually, or automatically). > > So you want me to clear the first 1K bytes, and then write the whole > image back to the pen drive, did I get this right? If so, I don't understand > what we're trying to archive here, maybe you could explain? > Mostly what I was getting at here was ensuring the first blocks of the memory stick did not contain "actual data." Though, I fear other forces may be at play here with GPT... -- Glen Barber | gjb@FreeBSD.org FreeBSD Documentation Project From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 06:03:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6156106564A; Sun, 9 Oct 2011 06:03:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 636438FC17; Sun, 9 Oct 2011 06:03:08 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4690308gge.13 for ; Sat, 08 Oct 2011 23:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dT8GXaqLbUU1omoMPMh3hxaPb/tmcDEcZqWWqD5PDJ0=; b=T20pQKEiQOd27ehn9cEH4RKmtik7FBIhjz6Wlpr9c1FLWNCNZaVC4/Qx0HXIDUl0/O 7bXaV++4znft8DmUrnIbfLn2/xoXnxK4elMkQkWttlb2kYb/ecvNUlrBqt9bhcNud8dc 8bdRJcPt+ZgKO7j0j288majfARhxhCU+S/KD0= MIME-Version: 1.0 Received: by 10.236.197.69 with SMTP id s45mr17881364yhn.54.1318140187811; Sat, 08 Oct 2011 23:03:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sat, 8 Oct 2011 23:03:07 -0700 (PDT) In-Reply-To: <4E913502.5020307@FreeBSD.org> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <20111009024140.GA13517@vs2.gothschlampen.com> <4E913502.5020307@FreeBSD.org> Date: Sun, 9 Oct 2011 14:03:07 +0800 X-Google-Sender-Auth: W96lVmSi3JfWzJKabaHplml3CGg Message-ID: From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current@freebsd.org, "Thomas K." Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 06:03:08 -0000 On 9 October 2011 13:45, Glen Barber wrote: > Mostly what I was getting at here was ensuring the first blocks of the > memory stick did not contain "actual data." =A0Though, I fear other force= s > may be at play here with GPT... > There are. We've lost this round; let's just throw MBR back onto the memstick images and then focus these boot related issues to fixing the bootloader. :) Adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 06:17:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3051065673; Sun, 9 Oct 2011 06:17:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE978FC0C; Sun, 9 Oct 2011 06:17:15 +0000 (UTC) Received: by iaby12 with SMTP id y12so1134261iab.13 for ; Sat, 08 Oct 2011 23:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7NUb46BMT9j4KePRLs9DBedIaVXFGu9e+sUWyX1omo4=; b=OxwBIoIG5tS1IaWawc2Xdd3oDOBt6sqHdeqDGHJ6nK+i+wyAqTivpNNoQGKG38VUau WcXL7ex8ae8mQ7kFz/jNVyTIX5WLMS5yQBaD3rYEXWzpDsNrmWQW7MPJrAZGMf9PRBDx 83ekN5QU2zSyrLtyf5j2IaJvHVdPmZ3/7pfic= MIME-Version: 1.0 Received: by 10.231.45.9 with SMTP id c9mr6050618ibf.73.1318141034858; Sat, 08 Oct 2011 23:17:14 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Sat, 8 Oct 2011 23:17:14 -0700 (PDT) In-Reply-To: References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <20111009024140.GA13517@vs2.gothschlampen.com> <4E913502.5020307@FreeBSD.org> Date: Sat, 8 Oct 2011 23:17:14 -0700 Message-ID: From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , Glen Barber , freebsd-current@freebsd.org, "Thomas K." Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 06:17:15 -0000 On Sat, Oct 8, 2011 at 11:03 PM, Adrian Chadd wrote: > On 9 October 2011 13:45, Glen Barber wrote: > >> Mostly what I was getting at here was ensuring the first blocks of the >> memory stick did not contain "actual data." =A0Though, I fear other forc= es >> may be at play here with GPT... >> > > There are. > > We've lost this round; let's just throw MBR back onto the memstick > images and then focus these boot related issues to fixing the > bootloader. :) Another data point. It appears USB related. I have built a GPT system on a SATA drive on a Lenovo T520. Works just fine. Always has. I copied the system onto a USB drive of the same size, not with dd of the disk, but by using gpart(8) to set up the disk including pmbr and gptmbr, just like I did on the SATA drive and then used dd to copy y\the partitions. I did this just to avoid issues with the"final block" as, while both drives are 750GB, they are different models Well, the Lenovo refuses to boot from the USB drive. It does not show up in the list of possible boot devices. I looks like this is an issue with GPT on USB devices, though I could well be missing another explanation. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 07:30:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0A8106564A; Sun, 9 Oct 2011 07:30:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D14E18FC08; Sun, 9 Oct 2011 07:30:24 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 994364AC1C; Sun, 9 Oct 2011 11:30:22 +0400 (MSD) Date: Sun, 9 Oct 2011 11:30:10 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <69804562.20111009113010@serebryakov.spb.ru> To: perryh@pluto.rain.com, "Andrey V. Elsukov" In-Reply-To: <4e91a8e2.Y3OdfyAUkARsSbU8%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> <1993293883.20111008125543@serebryakov.spb.ru> <4e91a8e2.Y3OdfyAUkARsSbU8%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: daniel@digsys.bg, lev@freebsd.org, ivoras@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: MBR, GPT and their co-existence with other GEOM classes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 07:30:25 -0000 Hello, Perryh. You wrote 9 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 18:00:02: > To install FreeBSD on a gmirrored disk, use MBR (or "dangerously > dedicated" BSD label) instead of GPT. (This is one reason why > BSD label and MBR should not be considered obsolete.) MBR doesn't check size of provider on taste. It should be fixed too. So, I see three changes which should be done in geom_gpart land: (1) GPT sub-moudle gpart should check rank of provider and issue big warning if rank isn't 1 (it is not low-level disk) on creation. (2) Documentation should be changed to explain (1) in more details. (3) MBR sub-module of gpart should check size of provider and refuse to "see" MBR if provider is several sectors larger, than recorded in MBR. It will prevent it to pickup failed component of gmirror directly. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 07:32:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32880106566C; Sun, 9 Oct 2011 07:32:05 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DFFFD8FC13; Sun, 9 Oct 2011 07:32:04 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 699204AC1C; Sun, 9 Oct 2011 11:32:03 +0400 (MSD) Date: Sun, 9 Oct 2011 11:31:51 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <384454873.20111009113151@serebryakov.spb.ru> To: perryh@pluto.rain.com, "Andrey V. Elsukov" , , , , In-Reply-To: <69804562.20111009113010@serebryakov.spb.ru> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> <1993293883.20111008125543@serebryakov.spb.ru> <4e91a8e2.Y3OdfyAUkARsSbU8%perryh@pluto.rain.com> <69804562.20111009113010@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: MBR, GPT and their co-existence with other GEOM classes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 07:32:05 -0000 Hello, Lev. You wrote 9 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 11:30:10: >> To install FreeBSD on a gmirrored disk, use MBR (or "dangerously >> dedicated" BSD label) instead of GPT. (This is one reason why >> BSD label and MBR should not be considered obsolete.) > MBR doesn't check size of provider on taste. It should be fixed too. > So, I see three changes which should be done in geom_gpart land: Four, to be precise. > (1) GPT sub-moudle gpart should check rank of provider and issue big > warning if rank isn't 1 (it is not low-level disk) on creation. > (2) Documentation should be changed to explain (1) in more details. > (3) MBR sub-module of gpart should check size of provider and > refuse to "see" MBR if provider is several sectors larger, than > recorded in MBR. It will prevent it to pickup failed component of > gmirror directly. (4) The same check as described in (3) should be done by BSD sub-module of gpart. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 07:37:23 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A13BE106564A; Sun, 9 Oct 2011 07:37:23 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6318FC15; Sun, 9 Oct 2011 07:37:23 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 38A745DC4; Sun, 9 Oct 2011 07:37:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p997bLQZ032969; Sun, 9 Oct 2011 07:37:21 GMT (envelope-from phk@phk.freebsd.dk) To: lev@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 08 Oct 2011 14:31:28 +0400." <1644928028.20111008143128@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 09 Oct 2011 07:37:21 +0000 Message-ID: <32968.1318145841@critter.freebsd.dk> Cc: Warren Block , Garrett Cooper , Glen Barber , "Andrey V. Elsukov" , Benjamin Kaduk , Arnaud Lacombe , freebsd-current@FreeBSD.org Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 07:37:23 -0000 In message <1644928028.20111008143128@serebryakov.spb.ru>, Lev Serebryakov writ es: >Hello, Poul-Henning. >You wrote 8 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 14:07:29: > >>> It seems, that GPT will be incompatible with any pure-software >>> mirror or mirror-like RAID. >> Unless you do what other implementations have done: Play nice with >> GPT and store your metadata in a GPT partition. > So, every other GEOM class should have special knowledge about GPT? >It doesn't look like "topology-agnostic" GEOM way :) That's mostly because GPT by design does not try to play nice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 07:40:00 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A303A106566B; Sun, 9 Oct 2011 07:40:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 64E4E8FC1F; Sun, 9 Oct 2011 07:40:00 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 65BA24AC1C; Sun, 9 Oct 2011 11:39:59 +0400 (MSD) Date: Sun, 9 Oct 2011 11:39:47 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <351747006.20111009113947@serebryakov.spb.ru> To: "Poul-Henning Kamp" In-Reply-To: <32968.1318145841@critter.freebsd.dk> References: Your message of "Sat, 08 Oct 2011 14:31:28 +0400." <1644928028.20111008143128@serebryakov.spb.ru> <32968.1318145841@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org, freebsd-current@FreeBSD.org, "Andrey V. Elsukov" Subject: Re: aliasing (or renaming) kern.geom.debugflags X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 07:40:00 -0000 Hello, Poul-Henning. You wrote 9 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 11:37:21: >> So, every other GEOM class should have special knowledge about GPT? >>It doesn't look like "topology-agnostic" GEOM way :) > That's mostly because GPT by design does not try to play nice. I understand that... See my proposal in other thread (renamed to "MBR, GPT and their co-existence with other GEOM classes"). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 08:25:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2D5106564A for ; Sun, 9 Oct 2011 08:25:34 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12EAF8FC08 for ; Sun, 9 Oct 2011 08:25:33 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8176592bkb.13 for ; Sun, 09 Oct 2011 01:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=IMbizom3jdLjvx6EpCl5epiKzNv0WYhD81jYbi1ztkQ=; b=ViZvvyLUbobHVo7BMbesJousrxM43dF0cICDUrGAuZxD4vBpufgjY/47aF4aYUdrc5 ErdWZqn5QjPROWCemQgp49XgUPUIxOHaDe4MTSIb6ZixUOjcjOPqOZjG0eF9FcGaZ1Nu 4J88+bmhUkPyv6bLtqqXZtquVSP/VozthyarE= Received: by 10.223.61.146 with SMTP id t18mr23527537fah.34.1318148732813; Sun, 09 Oct 2011 01:25:32 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id f25sm23706809faf.7.2011.10.09.01.25.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Oct 2011 01:25:31 -0700 (PDT) From: Mikolaj Golub To: Bob Finch References: X-Comment-To: Bob Finch Sender: Mikolaj Golub Date: Sun, 09 Oct 2011 11:25:29 +0300 In-Reply-To: (Bob Finch's message of "Wed, 5 Oct 2011 19:39:56 -0700") Message-ID: <86ty7ibmh2.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: 9.0-BETA3 lock order reversal in mount_smbfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 08:25:34 -0000 On Wed, 5 Oct 2011 19:39:56 -0700 Bob Finch wrote: BF> Attempting to mount a remote SMB share with mount_smbfs fails: BF> freebsd9b3# uname -a BF> FreeBSD freebsd9b3 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Sat Sep 24 20:46:57 UTC 2011 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 BF> freebsd9b3# mount_smbfs -I smbhost -U xxx -W domain //smbhost/xxx /mnt BF> Password: BF> mount_smbfs: unable to open connection: syserr = No such file or directory BF> and displays the following kernel messages: BF> smb_co_lock: recursive lock for object 1 BF> lock order reversal: BF> 1st 0xc2ef4608 smb_vc (smb_vc) @ /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:325 BF> 2nd 0xc2ffbc28 smbsm (smbsm) @ /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:348 BF> KDB: stack backtrace: BF> db_trace_self_wrapper(c0eff6ac,626d732f,2e2f7366,2e2e2f2e,74656e2f,...) at db_trace_self_wrapper+0x26 BF> kdb_backtrace(c0a42bdb,c0f0300f,c29697b0,c29696e0,c76d298c,...) at kdb_backtrace+0x2a BF> _witness_debugger(c0f0300f,c2ffbc28,c2ff93df,c29696e0,c2ff9320,...) at _witness_debugger+0x25 BF> witness_checkorder(c2ffbc28,9,c2ff9320,15c,c2ffbc48,...) at witness_checkorder+0x839 BF> __lockmgr_args(c2ffbc28,80000,c2ffbc48,0,0,...) at __lockmgr_args+0x824 BF> smb_co_lock(c2ffbc20,80000,2,2,c76d2b30,...) at smb_co_lock+0x73 BF> smb_co_gone(c2ef4600,c76d2b88,c76d2b88,c76d2aac,c2ad5b00,...) at smb_co_gone+0x34 BF> smb_sm_lookup(c76d2ad8,c76d2b14,c76d2b88,c76d2b30,c29f041c,...) at smb_sm_lookup+0xf0 BF> smb_usr_lookup(c29f0400,c76d2b88,c76d2b94,c76d2b90,c76d2b7c,...) at smb_usr_lookup+0x98 BF> nsmb_dev_ioctl(c2f76700,82fc6e6a,c29f0400,3,c2fce8a0,...) at nsmb_dev_ioctl+0x1d9 BF> giant_ioctl(c2f76700,82fc6e6a,c29f0400,3,c2fce8a0,...) at giant_ioctl+0x75 BF> devfs_ioctl_f(c2d417a8,82fc6e6a,c29f0400,c2c05e00,c2fce8a0,...) at devfs_ioctl_f+0x10b BF> kern_ioctl(c2fce8a0,3,82fc6e6a,c29f0400,6d2cec,...) at kern_ioctl+0x21d BF> sys_ioctl(c2fce8a0,c76d2cec,c0f493b6,c0eebb0e,246,...) at sys_ioctl+0x134 BF> syscall(c76d2d28) at syscall+0x284 BF> Xint0x80_syscall() at Xint0x80_syscall+0x21 BF> --- syscall (54, FreeBSD ELF32, sys_ioctl), eip = 0x28193283, esp = 0xbfbfe35c, ebp = 0xbfbfe688 --- The LOR appears after the problem (the connection gone) happened, on error handling. So although it indicates that there is something wrong with our smb locking this does not look like a cause of your issue. BF> Anything further I can do to help debug this problem? Is this specific for 9.0-BETA3? Have you tried mounting the share with the same parameters on another systems? I think it could be useful to tcpdump the session and look at it in wireshark, which understands the SMB protocol. Also you might want to rebuild the kernel with this options in /etc/src.conf: DEBUG_FLAGS= -g -DSMB_SOCKET_DEBUG -DSMB_IOD_DEBUG -DNB_DEBUG -DSMB_VNODE_DEBUG which will add many debugging messages. This might be helpful for troubleshooting. -- Mikolaj Golub From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 09:24:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 416011065670 for ; Sun, 9 Oct 2011 09:24:22 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost01.isp.att.net (fmailhost01.isp.att.net [204.127.217.101]) by mx1.freebsd.org (Postfix) with ESMTP id 314048FC0C for ; Sun, 9 Oct 2011 09:24:21 +0000 (UTC) Date: Sun, 9 Oct 2011 09:24:20 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-187-7.sdf.bellsouth.net[68.210.187.7]) by isp.att.net (frfwmhc01) with SMTP id <20111009092420H0100n3gd1e>; Sun, 9 Oct 2011 09:24:20 +0000 X-Originating-IP: [68.210.187.7] From: "Thomas Mueller" To: freebsd-current@freebsd.org Message-Id: <20111009092422.416011065670@hub.freebsd.org> Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 09:24:22 -0000 One issue that has not come up on the emailing list is that dd, designed to work with memsticks of various capacities, can not make the backup gpt at the end of the memstick. Partition is just big enough to hold the data, and I ran out of inodes at times due to the installer writing to /tmp on the memstick. Maybe a script to put a backup GPT at the end on the memstick, and make the second partition fill the space available so as not to be too tightly squeezed? Tom From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 11:03:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F32831065670 for ; Sun, 9 Oct 2011 11:03:49 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2A38FC08 for ; Sun, 9 Oct 2011 11:03:49 +0000 (UTC) Received: by wyj26 with SMTP id 26so7459074wyj.13 for ; Sun, 09 Oct 2011 04:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wq6AwwaeTP4QZ/xixQQvXdOCJd/Gp3MEWFen4T1irb4=; b=lfwzZLEUXp3AvxNeMSWhnVcPD4LXVnhmfoHipTHAryL2Iifq0RdJV05+Oo3scwO3Xp 9QyDG0EqqgRWJUJ7MPXhskUlRRNUXj5eScm39Hgnoed29rUeYkFt9d+NswmhDbNvmwEf qhxMl7pd7bwkRcBB4CCAwg4RMx0W/1Vxq5sGo= MIME-Version: 1.0 Received: by 10.216.230.167 with SMTP id j39mr4748335weq.31.1318158228732; Sun, 09 Oct 2011 04:03:48 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sun, 9 Oct 2011 04:03:48 -0700 (PDT) In-Reply-To: <20111009092422.416011065670@hub.freebsd.org> References: <20111009092422.416011065670@hub.freebsd.org> Date: Sun, 9 Oct 2011 21:33:48 +1030 Message-ID: From: Matt Thyer To: Thomas Mueller Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 11:03:50 -0000 On 9 October 2011 19:54, Thomas Mueller wrote: > One issue that has not come up on the emailing list is that dd, designed to > work with memsticks of various capacities, can not make the backup gpt at > the end of the memstick. > > Partition is just big enough to hold the data, and I ran out of inodes at > times due to the installer writing to /tmp on the memstick. > > Maybe a script to put a backup GPT at the end on the memstick, and make the > second partition fill the space available so as not to be too tightly > squeezed? > A script is a kludge. As we have no need for larger than 2TiB install images we should use the POLA and continue to support dd writing our memstick images which means don't use GPT for them. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 11:10:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24E80106564A; Sun, 9 Oct 2011 11:10:59 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 46D448FC0A; Sun, 9 Oct 2011 11:10:57 +0000 (UTC) Received: by wwn22 with SMTP id 22so2674253wwn.1 for ; Sun, 09 Oct 2011 04:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dfhJcgkwZUE2WoiWrRij+Xa7s0WufAefZwBkGXUH38=; b=U7JltWoN5ybrNdRAbRwuJboVyHjPJYGCxWR8G1+Rb3TVDc/Mxw3fQXI6GULADf7+bP VtRBXd1JEbRBrGoQIFEDP6VX/sDV5hwHyWFNkdXU3eqK1O/P4Fm4kN81gWSxc0ka/3HO aiXz25PL4+nFLO9LMoQ4OCT1enbq7IOnGLPmk= MIME-Version: 1.0 Received: by 10.216.25.196 with SMTP id z46mr4900640wez.16.1318158653123; Sun, 09 Oct 2011 04:10:53 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sun, 9 Oct 2011 04:10:53 -0700 (PDT) In-Reply-To: <20111009025047.GB13517@vs2.gothschlampen.com> References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> <20111009025047.GB13517@vs2.gothschlampen.com> Date: Sun, 9 Oct 2011 21:40:53 +1030 Message-ID: From: Matt Thyer To: "Thomas K." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Warren Block , Glen Barber , freebsd-current@freebsd.org, Garrett Cooper , Nathan Whitehorn Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 11:10:59 -0000 On 9 October 2011 13:20, Thomas K. wrote: > On Sat, Oct 08, 2011 at 07:28:55PM -0600, Warren Block wrote: > > On Sun, 9 Oct 2011, Matt Thyer wrote: > > >On Oct 9, 2011 11:04 AM, "Nathan Whitehorn" > wrote: > > >> > > >> On 10/08/11 19:25, Matt Thyer wrote: > > >>> > > >> > > >There is also the interesting question of actually installing to GPT on > the hard disk, which is the default in 9.0. Does this not work on some > systems? If so, do we want to blacklist > > >them and use a different default partition scheme? Can we identify > systems that violate regular PC boot standards and reject GPT? Any data on > any of these points would be appreciated. > > >> > > >I don't think there have been any reports of failure to boot properly > formatted GPT yet. > > > > Lenovo T420S and T520, from the links above. Install GPT on the > > hard drive, try to boot. > > > > http://forums.freebsd.org/showthread.php?t=26304 > > http://forums.freebsd.org/showthread.php?t=26759 > > http://forum.thinkpads.com/viewtopic.php?f=9&t=98078 > > As I used parted from Linux to fix the alternate GPT, i.e. put it not at > the > end of the image data but on the end of the disk, and it still did not > appear > in the boot device list, the Acer AX3960 should probably be on the list > as well. > > Being a Core i7 2600k system maybe 6 months old, it's rather recent > hardware, > but doesn't boot from the memstick image. > > > Regards, > Thomas > Failure to boot the FreeBSD 9.0-BETA{2|3} memstick images does not indicate a problem with a PCs BIOS/UEFI as these images are not properly formatted. If we were able to come up with examples of BIOS/UEFI that cannot boot from GPT partitioned volumes there would not be a problem as long as bsdinstall still supports partitioning volumes with MSDOS/MBR partitioning schemes. The big problem is being able to launch the installation process to start with which is yet another reason to have the memstick image non-GPT even if you could work out a script/kludge etc to be able to write a properly formatted GPT memstick. The solution to this issue is obvious. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 11:14:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2065106566C; Sun, 9 Oct 2011 11:14:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50EEB8FC08; Sun, 9 Oct 2011 11:14:26 +0000 (UTC) Received: by ywp17 with SMTP id 17so5879857ywp.13 for ; Sun, 09 Oct 2011 04:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2hyx4b4c9uSF0eoCCLNftIfSuAhYT2z+7MTTxDXGMhY=; b=oawztXOHWCjmUOoDOU7LRmMemwwdbECkngrpDLKNyymvpV1fG2+FcJc/xx2oFxfcct 303/qMK8Hs0HuggAJ9Gqm8YUkN5HHhEBT2mzYDuS1TyF43wDpPYAV5VeDXybjJA8cQA/ mqPoVKgMneoO5QfcBeqcSZEvVN2ydCSXmM1/s= MIME-Version: 1.0 Received: by 10.236.197.69 with SMTP id s45mr18610738yhn.54.1318158865657; Sun, 09 Oct 2011 04:14:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 9 Oct 2011 04:14:25 -0700 (PDT) In-Reply-To: References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> <20111009025047.GB13517@vs2.gothschlampen.com> Date: Sun, 9 Oct 2011 19:14:25 +0800 X-Google-Sender-Auth: P2hdpHvVtQObBmm_QvQ-ooC7i68 Message-ID: From: Adrian Chadd To: Matt Thyer Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Block , "Thomas K." , Garrett Cooper , Glen Barber , freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 11:14:26 -0000 On 9 October 2011 19:10, Matt Thyer wrote: > Failure to boot the FreeBSD 9.0-BETA{2|3} memstick images does not indicate > a problem with a PCs BIOS/UEFI as these images are not properly formatted. Accepted. > If we were able to come up with examples of BIOS/UEFI that cannot boot from > GPT partitioned volumes there would not be a problem as long as bsdinstall > still supports partitioning volumes with MSDOS/MBR partitioning schemes. > > The big problem is being able to launch the installation process to start > with which is yet another reason to have the memstick image non-GPT even if > you could work out a script/kludge etc to be able to write a properly > formatted GPT memstick. > > The solution to this issue is obvious. Yes, it's "the current solution has a lot of unknown-how broken stuff about it, let's revert it for 9.0 and then use the 10.0 release cycle to do further research and testing." :-) adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 11:20:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B41371065738; Sun, 9 Oct 2011 11:20:18 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BBC228FC0C; Sun, 9 Oct 2011 11:20:17 +0000 (UTC) Received: by wwe3 with SMTP id 3so7405979wwe.31 for ; Sun, 09 Oct 2011 04:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWRz0a8RABZVz1iRQsc8JErw0OgeRDygICn5S3w+o/E=; b=S6kmbLA/54zmJOF7vyIg5ET5fG4QbiYoG+CzPAO+ZDERZvt80OaW3s3+C9oDqSmqpj EpeyTZXcsHtSjEQ9tn584PD2r9CycsJFB2ICdBBlLBWEV097iZD2ROeqK2HCebACplP/ +ggwBRJMQNCcrLDy8vdKc8rgHOiK2RNlf6gek= MIME-Version: 1.0 Received: by 10.216.230.167 with SMTP id j39mr4761927weq.31.1318159216631; Sun, 09 Oct 2011 04:20:16 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Sun, 9 Oct 2011 04:20:16 -0700 (PDT) In-Reply-To: References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> <20111009025047.GB13517@vs2.gothschlampen.com> Date: Sun, 9 Oct 2011 21:50:16 +1030 Message-ID: From: Matt Thyer To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Warren Block , "Thomas K." , Garrett Cooper , Glen Barber , freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 11:20:18 -0000 On 9 October 2011 21:44, Adrian Chadd wrote: > On 9 October 2011 19:10, Matt Thyer wrote: > > > Failure to boot the FreeBSD 9.0-BETA{2|3} memstick images does not > indicate > > a problem with a PCs BIOS/UEFI as these images are not properly > formatted. > > Accepted. > > > If we were able to come up with examples of BIOS/UEFI that cannot boot > from > > GPT partitioned volumes there would not be a problem as long as > bsdinstall > > still supports partitioning volumes with MSDOS/MBR partitioning schemes. > > > > The big problem is being able to launch the installation process to start > > with which is yet another reason to have the memstick image non-GPT even > if > > you could work out a script/kludge etc to be able to write a properly > > formatted GPT memstick. > > > > The solution to this issue is obvious. > > Yes, it's "the current solution has a lot of unknown-how broken stuff > about it, let's revert it for 9.0 and then use the 10.0 release cycle > to do further research and testing." > Unfortunately there is no reasonable revert path here. bsdinstall is the way forward and I agree it should be the installer for 9.0-RELEASE. Currently bsdinstall relies on labels and that's a good thing (intelligent design choice). Work is already underway to make the memstick issue with UFS labels and MSDOS/MBR partitioning and when that's done this issue will be solved. So it's not a matter of reverting, it's a matter of forging ahead and delaying the release as this is a show stopper. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 11:36:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A3A6106564A; Sun, 9 Oct 2011 11:36:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87AB18FC0C; Sun, 9 Oct 2011 11:36:09 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4771858gge.13 for ; Sun, 09 Oct 2011 04:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aMZIolWSfdqejGgLmKGrGyuYJ9h7EdtBQNtoV6/aVLc=; b=SK6CxO3KXhL7udVh8f/2exEMBs5iZvd6Nc8jgtykwsFr8wn6sJ6GqZlmaK/id5nESp XTKQfMnPEbS81PavvgDPEJUSIiO37/aVT34JV97jdpj0bcB7AoroDfELzftXELkOTEU7 2thc3FRYQkalWqUFU4Vhpd912ZOFM0umaGFUo= MIME-Version: 1.0 Received: by 10.236.187.70 with SMTP id x46mr18935528yhm.71.1318160168833; Sun, 09 Oct 2011 04:36:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 9 Oct 2011 04:36:08 -0700 (PDT) In-Reply-To: References: <20111008155252.GA24223.edited@vs2.gothschlampen.com> <4E90B4B1.7000009@FreeBSD.org> <4E90C801.4060108@FreeBSD.org> <4E90EBF5.4090101@freebsd.org> <20111009025047.GB13517@vs2.gothschlampen.com> Date: Sun, 9 Oct 2011 19:36:08 +0800 X-Google-Sender-Auth: t3la6SqwzZKilfr5Ohpx1dKWtow Message-ID: From: Adrian Chadd To: Matt Thyer Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Block , "Thomas K." , Garrett Cooper , Glen Barber , freebsd-current@freebsd.org, Nathan Whitehorn Subject: Re: Memstick image differences between 8.x and 9.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 11:36:10 -0000 Oh, I wasn't suggesting reverting bsdinstall before 9.0. That'll make it a bit annoying to install on USB flash drives for some devices. It may be worthwhile to do at a later date though. I do find myself doing USB 9.0 installs just to test out the release without destroying a physical disk. But yes, I'm really only advocating MBR for memstick USB images. adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 12:05:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03DC7106566B; Sun, 9 Oct 2011 12:05:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id AAD718FC0A; Sun, 9 Oct 2011 12:05:21 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4780327gge.13 for ; Sun, 09 Oct 2011 05:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=E6Oe2+11Crs1KE6vYIkDAWzHMvbbM27zc1NKhsIKMUI=; b=Pl5H6ecIJBa4mWBjamu3Zty01XmQEnIlda3imKJXjQrYKuWGu1KBAvnHTBnaNVlJKY aOZriTO16EZyjH3+/hmp5+Su8iBnA5P0tWbm8qgdpHQhVo66h4w8yKpLTyjpK2tYk6JB UEiQa8F5TOgbuFipAx5eUoNfZ61akxsNKkTnE= MIME-Version: 1.0 Received: by 10.236.191.161 with SMTP id g21mr19372125yhn.3.1318161921172; Sun, 09 Oct 2011 05:05:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 9 Oct 2011 05:05:21 -0700 (PDT) Date: Sun, 9 Oct 2011 20:05:21 +0800 X-Google-Sender-Auth: Of5c_DR9S8IsegxmS1ULlRtm9mQ Message-ID: From: Adrian Chadd To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Is there a step by step howto for dtrace on 9.0 ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 12:05:22 -0000 Hi, the subject says it all - does anyone have a step by step howto for doing userland and kernel dtrace on 9.0? Thanks, Adrian From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 12:23:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203B9106564A; Sun, 9 Oct 2011 12:23:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id D24168FC0C; Sun, 9 Oct 2011 12:23:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RCsPJ-00042z-C3>; Sun, 09 Oct 2011 14:23:05 +0200 Received: from e178020034.adsl.alicedsl.de ([85.178.20.34] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RCsPJ-0004QT-74>; Sun, 09 Oct 2011 14:23:05 +0200 Message-ID: <4E919228.8010708@zedat.fu-berlin.de> Date: Sun, 09 Oct 2011 14:23:04 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current , freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.20.34 Cc: Subject: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 12:23:08 -0000 Since the change of one of my boxes to FreeBSD 10.0 and some accindetally build of ports without the suggested settings for UNAME_r before building ports, I think I've messed up with some ports and need some advice how to fixate the problem. Some develish motivation drove me today building gcc46/gotoblas and gcc fails to build with the below shown message. But this is not the only port that rushes into problems. Thing is: I do not know wether I messed up the system or this is simply the very often mentioned problem due to the two-digit versioning of the most recent CURRENT. Except ANJUTA, which complains about a non-working subversion module due to some lack in a libgdbm port (which also won't build) everything works fine and I can stand this for the next one or two weeks to wait for a general fixation, but it would be a good attempt, I think, to start fixating my messed up system now, if there is any real mess I did. Any advice? Thanks in advance. Oliver P.S.: On FreeBSD 9.0-BETA3 everything runs well, except the usual little horror with legacy gcc 4.2 versus CLANG. So I expect the problems to be real 10.0-issues. === rm -f include-fixed/README cp .././../gcc-4.6-20111007/gcc/../fixincludes/README-fixinc include-fixed/README chmod a+r include-fixed/README echo timestamp > stmp-int-hdrs rm gcov.pod fsf-funding.pod cpp.pod gcc.pod gfdl.pod gmake[3]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' mkdir x86_64-portbld-freebsd10.0/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in x86_64-portbld-freebsd10.0/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking for gawk... gawk checking build system type... x86_64-portbld-freebsd10.0 checking host system type... x86_64-portbld-freebsd10.0 checking for x86_64-portbld-freebsd10.0-ar... /usr/local/x86_64-portbld-freebsd10.0/bin/ar checking for x86_64-portbld-freebsd10.0-lipo... lipo checking for x86_64-portbld-freebsd10.0-nm... /usr/ports/lang/gcc46/work/build/./gcc/nm checking for x86_64-portbld-freebsd10.0-ranlib... /usr/local/x86_64-portbld-freebsd10.0/bin/ranlib checking for x86_64-portbld-freebsd10.0-strip... /usr/local/x86_64-portbld-freebsd10.0/bin/strip checking whether ln -s works... yes checking for x86_64-portbld-freebsd10.0-gcc... /usr/ports/lang/gcc46/work/build/./gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./gcc/ -B/usr/local/x86_64-portbld-freebsd10.0/bin/ -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd10.0/include -isystem /usr/local/x86_64-portbld-freebsd10.0/sys-include checking for suffix of object files... configure: error: in `/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [bootstrap-lean] Error 2 *** Error code 1 Stop in /usr/ports/lang/gcc46. *** Error code 1 Stop in /usr/ports/lang/gcc46. ===>>> make failed for lang/gcc46 ===>>> Aborting update ===>>> Update for lang/gcc46 failed ===>>> Aborting update From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 12:33:11 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5E541065670; Sun, 9 Oct 2011 12:33:11 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2593E8FC08; Sun, 9 Oct 2011 12:33:10 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8411028bkb.13 for ; Sun, 09 Oct 2011 05:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GhoSDZwGcqkbXAEXtx45o4rBHPDixRX3bNQHayZlSAk=; b=LXcPpKkmMW8kRahalYlrm1T8Yq+el+W3QmTG7sPwXn1SQpjsACgEAt60cDkPCR2RuJ 1n8KSeVcO/VMZIc2w+mrPmjXqFfj7qGdxF7bvs8UeXzlwjnz2m/HCQ5qwZJMrn2ge+kI JtwgROOjYVIe7GrZB9L3f7MRr24eesBTo4jZg= MIME-Version: 1.0 Received: by 10.223.5.3 with SMTP id 3mr24821830fat.4.1318163589857; Sun, 09 Oct 2011 05:33:09 -0700 (PDT) Received: by 10.223.116.137 with HTTP; Sun, 9 Oct 2011 05:33:09 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Oct 2011 20:33:09 +0800 Message-ID: From: Paul Ambrose To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Is there a step by step howto for dtrace on 9.0 ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 12:33:12 -0000 the wiki DTrace (http://wiki.freebsd.org/DTrace) is available and enough for being a HOWTO. 2011/10/9 Adrian Chadd > > Hi, > > the subject says it all - does anyone have a step by step howto for > doing userland and kernel dtrace on 9.0? > > Thanks, > > > Adrian > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 13:13:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C117F106566C; Sun, 9 Oct 2011 13:13:39 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7A77B8FC18; Sun, 9 Oct 2011 13:13:38 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 62D0628426; Sun, 9 Oct 2011 15:13:37 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 6AD8C28423; Sun, 9 Oct 2011 15:13:36 +0200 (CEST) Message-ID: <4E919DFF.8090607@quip.cz> Date: Sun, 09 Oct 2011 15:13:35 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8DA627.60003@quip.cz> <711721489.20111006175611@serebryakov.spb.ru> In-Reply-To: <711721489.20111006175611@serebryakov.spb.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 13:13:39 -0000 Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 6 октÑÐ±Ñ€Ñ 2011 г., 16:59:19: [...] >> The current state is simply wrong, because user can do something what >> cannot work and is not documented anywhere. > It is Ok in UNIX way, in general. You should be able to shoot your > leg, it is good :) I am sorry for my late reply. Foot shooting is OK, if somebody wants to shoot his foot, but I don't want to shoot my foot if I am aiming at my head :) > But if geom_label doesn't reduce its provider to count its own > metadata, it looks like a bug! As Ivan Voras explained, it is not a bug, it is just a matter of mixing two things thant can't coexist together. So the problem is that it is not mentioned anywhere in the FreeBSD docs. (Thank you Ivan for your explanation!) And as somebody else already mentioned in this thread, it should be documented in manpages and Handbook and gpart should show warning message if user is trying to put GPT on non real disk devices. As is mentioned in the thread "Memstick image differences between 8.x and 9.x", the GPT brings more problems by requirement of second table at the end of the device (so disk image cannot be easily written by dd on bigger disk) From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 16:03:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C18106566C; Sun, 9 Oct 2011 16:03:15 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6368FC0A; Sun, 9 Oct 2011 16:03:14 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.5/8.14.5) with ESMTP id p99FmpF4018785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Oct 2011 08:48:52 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201110091548.p99FmpF4018785@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 09 Oct 2011 08:48:46 -0700 To: "Hartmann, O." , freebsd-current , freebsd-ports@freebsd.org From: Manfred Antar In-Reply-To: <4E919228.8010708@zedat.fu-berlin.de> References: <4E919228.8010708@zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=unavailable version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: p99FmpF4018785 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 16:03:15 -0000 At 05:23 AM 10/9/2011, Hartmann, O. wrote: >Since the change of one of my boxes to FreeBSD 10.0 and some >accindetally build of ports without the suggested settings for UNAME_r >before building ports, I think I've messed up with some ports and need >some advice how to fixate the problem. > >Some develish motivation drove me today building gcc46/gotoblas and gcc >fails to build with the below shown message. But this is not the only >port that rushes into problems. > >Thing is: I do not know wether I messed up the system or this is simply >the very often mentioned problem due to the two-digit versioning of the >most recent CURRENT. > >Except ANJUTA, which complains about a non-working subversion module due >to some lack in a libgdbm port (which also won't build) everything works >fine and I can stand this for the next one or two weeks to wait for a >general fixation, but it would be a good attempt, I think, to start >fixating my messed up system now, if there is any real mess I did. > >Any advice? > > >Thanks in advance. > >Oliver > >P.S.: On FreeBSD 9.0-BETA3 everything runs well, except the usual little >horror with legacy gcc 4.2 versus CLANG. So I expect the problems to be >real 10.0-issues. > >=== > > >checking for suffix of object files... configure: error: in >`/usr/ports/lang/gcc46/work/build/x86_64-portbld-freebsd10.0/libgcc': >configure: error: cannot compute suffix of object files: cannot compile >See `config.log' for more details. >gmake[2]: *** [configure-stage1-target-libgcc] Error 1 >gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build' >gmake[1]: *** [stage1-bubble] Error 2 >gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' >gmake: *** [bootstrap-lean] Error 2 >*** Error code 1 > >Stop in /usr/ports/lang/gcc46. >*** Error code 1 > >Stop in /usr/ports/lang/gcc46. > >===>>> make failed for lang/gcc46 >===>>> Aborting update > >===>>> Update for lang/gcc46 failed >===>>> Aborting update > >_______________________________________________ Did you rebuild ports/devel/binutils after change to 10.0 current. I was having same problem with gcc45 , then i rebuilt binutils with uname_r 9.0-Current and it went away. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 16:21:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75741106566C; Sun, 9 Oct 2011 16:21:00 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7538FC08; Sun, 9 Oct 2011 16:21:00 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 1B65A6160; Sun, 9 Oct 2011 12:20:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1318177259; bh=cQIorFbQ2HfGYa/tQWkPWGH/ZRBFuauJjavhaQe2C7U=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HFYiyFgsIY0L87sjgwJ8/UnYAdFzQNhFPUTdov0qu3yyUScGYR4OonCGlCjtCDqx/ vATqjbiztT0EMoD+6bp+YWSbzP2F9BLcYntWlGWvvnmGJz0ckDAK7OkRYZNGC/3 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Po1mbmOx8cl8K6kafr6tIboXv5Px6MgZvehzShT8uxT9fEbwMUCATuFNww35pqAfL sP40dQ32SW36p2DH97HqvYm0CEbyLorJCGX5icpbHsZfZejaLpmqCdmyFx1oK91 Message-ID: <4E91C9E8.20205@protected-networks.net> Date: Sun, 09 Oct 2011 12:20:56 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Manfred Antar References: <4E919228.8010708@zedat.fu-berlin.de> <201110091548.p99FmpF4018785@pozo.com> In-Reply-To: <201110091548.p99FmpF4018785@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-ports@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 16:21:00 -0000 On 10/09/11 11:48, Manfred Antar wrote: > Did you rebuild ports/devel/binutils after change to 10.0 current. > I was having same problem with gcc45 , then i rebuilt binutils with uname_r 9.0-Current and it went away. The most recent update to gcc46 also missed the shared library version bump of mpfr to mpfr.so.5, imb From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 16:29:35 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2478B106564A; Sun, 9 Oct 2011 16:29:35 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB3588FC08; Sun, 9 Oct 2011 16:29:34 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id p99GTNC2031234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2011 01:29:27 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 10 Oct 2011 01:29:22 +0900 Message-ID: From: Hajimu UMEMOTO To: Doug Barton In-Reply-To: <4E8F8FE4.5040201@FreeBSD.org> References: <201110071615.p97GFlVK069165@repoman.freebsd.org> <4E8F8FE4.5040201@FreeBSD.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 10 Oct 2011 01:29:28 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: FreeBSD Current , "freebsd-ports@FreeBSD.org" Subject: Re: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 16:29:35 -0000 Hi, >>>>> On Fri, 07 Oct 2011 16:48:52 -0700 >>>>> Doug Barton said: dougb> In case anyone wants to take this on, this port fails to install on 10.0 dougb> because it uses its own version of libtool. I took a quick look but dougb> there wasn't a solution obvious enough for me. :) I didn't have 10-current box, yet. So, I've just upgraded my 9-current box to today's current, and tried to rebuild cyrus-sasl2 port on it. However, I couldn't reproduce the problem. It built just fine, here. Any thought? Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 17:32:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44FB41065670 for ; Sun, 9 Oct 2011 17:32:49 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0CF128FC14 for ; Sun, 9 Oct 2011 17:32:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:Sender:From:Date; bh=JfLbItEfnTZ+M4khpX6qasPJhEHpgd5748OyOLZBZOs=; b=Xfp/4T+GhcFd6uD7zL6biw1lDfV+fr7zK5tcIyac+cFAzB/v4a0edk96iokQyPiK5BJud6suyXuPP8DcgeHh9zOHoTh38o4BkR+hUy+3WOoV+4fNSVoThY0URk1bGtsD23n78H/68KtE5F/02JXt2DoQZYX0v5+EpaOlft7VoGo=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:31646 helo=[192.168.200.4]) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RCxF1-000GTX-5J for freebsd-current@freebsd.org; Sun, 09 Oct 2011 12:32:48 -0500 Date: Sun, 9 Oct 2011 12:32:34 -0500 (CDT) From: Larry Rosenman Sender: ler@lrosenman.dyndns.org To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Score: -1.8 (-) X-LERCTR-Spam-Score: -1.8 (-) X-Spam-Report: SpamScore (-1.8/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1 X-LERCTR-Spam-Report: SpamScore (-1.8/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1 Subject: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 17:32:49 -0000 I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? Output below. ========================================================================================= (cd lib; make DEBUG="-O2" CFGF="-DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DFREEBSDV=9000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR=\"9.0-BETA3\"") clang -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DFREEBSDV=9000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR="9.0-BETA3" -I/usr/src/sys -O2 -c ckkv.c In file included from ckkv.c:43: In file included from ./../lsof.h:195: In file included from ./../dlsof.h:190: In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36: /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function 'KASSERT' is invalid in C99 [-Wimplicit-function-declaration] KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp)); ^ /usr/src/sys/sys/buf.h:388:33: warning: expression result unused [-Wunused-value] KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp)); ^~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/buf.h:389:41: warning: expression result unused [-Wunused-value] KASSERT(bp->b_bufobj->bo_ops != NULL, ("bwrite: no bo_ops bp=%p", bp)); ^~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/buf.h:391:7: warning: expression result unused [-Wunused-value] ("bwrite: no bop_write bp=%p", bp)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/buf.h:399:33: warning: expression result unused [-Wunused-value] KASSERT(bp->b_bufobj != NULL, ("bstrategy: no bufobj bp=%p", bp)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/buf.h:401:7: warning: expression result unused [-Wunused-value] ("bstrategy: no bo_ops bp=%p", bp)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/sys/sys/buf.h:403:7: warning: expression result unused [-Wunused-value] ("bstrategy: no bop_strategy bp=%p", bp)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ckkv.c:43: In file included from ./../lsof.h:195: In file included from ./../dlsof.h:432: In file included from /usr/include/string.h:45: /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' int ffs(int) __pure2; ^ /usr/include/machine/cpufunc.h:140:24: note: expanded from: #define ffs(x) __builtin_ffs(x) ^ /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int (unsigned int)' 7 warnings and 1 error generated. *** Error code 1 Stop in /usr/home/abe/src/lsof485d/lib. *** Error code 1 Stop in /usr/home/abe/src/lsof485d. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 18:57:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B15106566B for ; Sun, 9 Oct 2011 18:57:57 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo103.cox.net (eastrmfepo103.cox.net [68.230.241.215]) by mx1.freebsd.org (Postfix) with ESMTP id 219658FC08 for ; Sun, 9 Oct 2011 18:57:56 +0000 (UTC) Received: from eastrmimpo110.cox.net ([68.230.241.223]) by eastrmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20111009185751.XLHJ3815.eastrmfepo103.cox.net@eastrmimpo110.cox.net> for ; Sun, 9 Oct 2011 14:57:51 -0400 Received: from serene.no-ip.org ([98.164.86.236]) by eastrmimpo110.cox.net with bizsmtp id iixl1h00755wwzE02ixoL2; Sun, 09 Oct 2011 14:57:51 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020204.4E91EEAF.000F,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=2lDt+3Ehhkmq3Qye6YCr36r8zWAQhLDa7m4fIMlTmVE= c=1 sm=1 a=AhQrMfm5ZIUA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=uAbGmPAyUfLL1M3oYAsfuA==:17 a=5n-WxztdAAAA:8 a=kviXuzpPAAAA:8 a=tnOUAYgqfGDxjvka6vkA:9 a=CjuIK1q_8ugA:10 a=zHqGhn9gijkA:10 a=4vB-4DCPJfMA:10 a=uAbGmPAyUfLL1M3oYAsfuA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id p99IvetJ006525 for ; Sun, 9 Oct 2011 13:57:41 -0500 (CDT) (envelope-from conrads@cox.net) Date: Sun, 9 Oct 2011 13:57:35 -0500 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-ID: <20111009135735.3f5fe1c1@cox.net> In-Reply-To: <201110091548.p99FmpF4018785@pozo.com> References: <4E919228.8010708@zedat.fu-berlin.de> <201110091548.p99FmpF4018785@pozo.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 18:57:57 -0000 On Sun, 09 Oct 2011 08:48:46 -0700 Manfred Antar wrote: > Did you rebuild ports/devel/binutils after change to 10.0 current. > I was having same problem with gcc45 , then i rebuilt binutils with > uname_r 9.0-Current and it went away. Actually, binutils built just fine for me just now without setting UNAME_r under current. -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 20:17:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3FBE1065672 for ; Sun, 9 Oct 2011 20:17:45 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id CE9968FC19 for ; Sun, 9 Oct 2011 20:17:44 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id DE0041CC69; Sun, 9 Oct 2011 13:38:03 -0300 (BRT) Received: from 187.64.44.39 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sun, 9 Oct 2011 13:38:03 -0300 Message-ID: Date: Sun, 9 Oct 2011 13:38:03 -0300 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: flash for 9-beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 20:17:46 -0000 On Sat, October 8, 2011 18:28, Garrett Cooper wrote: > On Sat, Oct 8, 2011 at 2:21 PM, Greg Miller wrote: >> On 10/8/11, Nenhum_de_Nos wrote: >>> as recently had issues in this regard, to install it can I just use http://www.freebsd.org/doc/handbook/desktop-browsers.html or there is another guide ? >> >> I've just noticed that I never actually added the symbolic link, but I've otherwise followed the 8.x instructions you linked to in the handbook, and my Flash is working nicely on 9.0B3. > > Every time you update the port, you must re-run nspluginwrapper. Seems like the port itself is sort of broken by not doing this by default with the post-install script. > -Garrett well, I'll try it when I get home. I did the symlink and FF 7 didn't find any plugins. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 20:17:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 060721065673 for ; Sun, 9 Oct 2011 20:17:46 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id D21B88FC20 for ; Sun, 9 Oct 2011 20:17:44 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 865561CC6B; Sun, 9 Oct 2011 13:39:56 -0300 (BRT) Received: from 187.64.44.39 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Sun, 9 Oct 2011 13:39:56 -0300 Message-ID: <0c062e2fefcf6a8bc2c436281780cec0.squirrel@eternamente.info> In-Reply-To: <4E90D6CC.1030500@FreeBSD.org> References: <8e42ff5adc4823b6a46fb59704a2bca5.squirrel@eternamente.info> <4E90D6CC.1030500@FreeBSD.org> Date: Sun, 9 Oct 2011 13:39:56 -0300 From: "Nenhum_de_Nos" Cc: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: flash for 9-beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 20:17:46 -0000 On Sat, October 8, 2011 20:03, Doug Barton wrote: > On 10/08/2011 14:53, Warren Block wrote: >> nspluginwrapper needs to be run as the end user. > > The pkg-message tells them to do that. ops, haven't seen it though. all the ports cleaned by the "clean" part of the command got on my way :( thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 01:18:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF6FD106567F for ; Mon, 10 Oct 2011 01:18:35 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [216.101.162.50]) by mx1.freebsd.org (Postfix) with ESMTP id 67B318FC12 for ; Mon, 10 Oct 2011 01:18:35 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.5/8.14.5) with ESMTP id p9A1IJ0K005636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Oct 2011 18:18:19 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201110100118.p9A1IJ0K005636@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 09 Oct 2011 18:18:13 -0700 To: "Conrad J. Sabatier" , freebsd-current@freebsd.org From: Manfred Antar In-Reply-To: <20111009135735.3f5fe1c1@cox.net> References: <4E919228.8010708@zedat.fu-berlin.de> <201110091548.p99FmpF4018785@pozo.com> <20111009135735.3f5fe1c1@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-101.4 required=5.0 tests=ALL_TRUSTED,MISSING_MID, RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=unavailable version=3.3.2, No X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: p9A1IJ0K005636 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Cc: Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 01:18:36 -0000 At 11:57 AM 10/9/2011, Conrad J. Sabatier wrote: >On Sun, 09 Oct 2011 08:48:46 -0700 >Manfred Antar wrote: > >> Did you rebuild ports/devel/binutils after change to 10.0 current. >> I was having same problem with gcc45 , then i rebuilt binutils with >> uname_r 9.0-Current and it went away. > >Actually, binutils built just fine for me just now without setting >UNAME_r under current. > >-- >Conrad J. Sabatier >conrads@cox.net Built fine for me too. But when I tried to compile gcc45 no go recompiled binutils with uname_r 9.0-CURRENT, And gcc45 built fine. so my assumption was that something gets messed up with the binutils and gcc45 when built with current. ======================== || null@pozo.com || || Ph. (415) 681-6235 || ======================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 01:26:32 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8927D106566B; Mon, 10 Oct 2011 01:26:32 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58AFD8FC08; Mon, 10 Oct 2011 01:26:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9A1QWAT042241; Mon, 10 Oct 2011 01:26:32 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9A1QV3M042240; Mon, 10 Oct 2011 01:26:31 GMT (envelope-from jwd) Date: Mon, 10 Oct 2011 01:26:31 +0000 From: John To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20111010012631.GA45500@FreeBSD.org> References: <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8DA627.60003@quip.cz> <711721489.20111006175611@serebryakov.spb.ru> <4E919DFF.8090607@quip.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E919DFF.8090607@quip.cz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, lev@FreeBSD.org, Ivan Voras , freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 01:26:32 -0000 ----- Miroslav Lachman's Original Message ----- > Lev Serebryakov wrote: > >Hello, Miroslav. > >You wrote 6 ?????????????? 2011 ??., 16:59:19: > > [...] > > >>The current state is simply wrong, because user can do something what > >>cannot work and is not documented anywhere. > > It is Ok in UNIX way, in general. You should be able to shoot your > > leg, it is good :) > > I am sorry for my late reply. > Foot shooting is OK, if somebody wants to shoot his foot, but I don't > want to shoot my foot if I am aiming at my head :) > > > But if geom_label doesn't reduce its provider to count its own > > metadata, it looks like a bug! > > As Ivan Voras explained, it is not a bug, it is just a matter of mixing > two things thant can't coexist together. So the problem is that it is > not mentioned anywhere in the FreeBSD docs. (Thank you Ivan for your > explanation!) > And as somebody else already mentioned in this thread, it should be > documented in manpages and Handbook and gpart should show warning > message if user is trying to put GPT on non real disk devices. > > As is mentioned in the thread "Memstick image differences between 8.x > and 9.x", the GPT brings more problems by requirement of second table at > the end of the device (so disk image cannot be easily written by dd on > bigger disk) This also seem to prevent something useful like: # camcontrol inquiry da0 pass2: Fixed Direct Access SCSI-5 device pass2: Serial Number 3TB1BKGX00009036W9EN pass2: 600.000MB/s transfers, Command Queueing Enabled # camcontrol inquiry da25 pass27: Fixed Direct Access SCSI-5 device pass27: Serial Number 3TB1BKGX00009036W9EN pass27: 600.000MB/s transfers, Command Queueing Enabled # gmultipath label ZFS0 da0 da25 # gpart create -s gpt $device # gpart add -s 128 -t freebsd-boot $device # Create 64K boot partition # gpart add -s 4m -t freebsd-ufs -l mb$dev $device # small partition # gpart add -t freebsd-zfs -l $dev $device # Remaining space for zfs It seems like protecting your partitions with multiple paths would be a good thing. I've been experimenting with this and end up with corrupt partitions. Am I missing something? -john From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 01:48:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3780C1065680 for ; Mon, 10 Oct 2011 01:48:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E6FDD8FC0C for ; Mon, 10 Oct 2011 01:48:05 +0000 (UTC) Received: by yxk36 with SMTP id 36so6218030yxk.13 for ; Sun, 09 Oct 2011 18:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=bvzanRtCxvD0cMet+68b5w6nTexKY060WwdiHuoRSu8=; b=UYnMxjmxlH26a9FT//2kDj6Ortm1Z0XwjLbikJllTk0yw3mTrO1LXcAcxfESL4HEX5 0NRJ9F72WkJ8S4+/1LYYdd4DjGj6hPWPZ2kM/98wDiaid/ODegUOTVnsDNKxF2coTIE+ n4AtUwXV+BehCxtvM24J/G56GArtVe+8cSPZc= Received: by 10.150.8.12 with SMTP id 12mr4581778ybh.16.1318211285025; Sun, 09 Oct 2011 18:48:05 -0700 (PDT) Received: from [10.119.125.77] ([166.205.138.5]) by mx.google.com with ESMTPS id o7sm47771966anp.18.2011.10.09.18.48.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Oct 2011 18:48:04 -0700 (PDT) References: <4E919228.8010708@zedat.fu-berlin.de> <201110091548.p99FmpF4018785@pozo.com> <20111009135735.3f5fe1c1@cox.net> <201110100118.p9A1IJ0K005636@pozo.com> In-Reply-To: <201110100118.p9A1IJ0K005636@pozo.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: Garrett Cooper Date: Sun, 9 Oct 2011 18:47:56 -0700 To: Manfred Antar Cc: "Conrad J. Sabatier" , "freebsd-current@freebsd.org" Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 01:48:06 -0000 On Oct 9, 2011, at 6:18 PM, Manfred Antar wrote: > At 11:57 AM 10/9/2011, Conrad J. Sabatier wrote: >> On Sun, 09 Oct 2011 08:48:46 -0700 >> Manfred Antar wrote: >>=20 >>> Did you rebuild ports/devel/binutils after change to 10.0 current. >>> I was having same problem with gcc45 , then i rebuilt binutils with >>> uname_r 9.0-Current and it went away. >>=20 >> Actually, binutils built just fine for me just now without setting >> UNAME_r under current. >>=20 >> --=20 >> Conrad J. Sabatier >> conrads@cox.net >=20 > Built fine for me too. But when I tried to compile gcc45 no go > recompiled binutils with uname_r 9.0-CURRENT, And gcc45 built fine. > so my assumption was that something gets messed up with the binutils and g= cc45 when built with with current. Some branding info is indeed embedded in the Gnu toolchain (look at gcc -dum= pspecs, etc). -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 01:54:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69393106564A for ; Mon, 10 Oct 2011 01:54:19 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id 083518FC0C for ; Mon, 10 Oct 2011 01:54:18 +0000 (UTC) Received: from eastrmimpo110.cox.net ([68.230.241.223]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20111010015413.NCPU12239.eastrmfepo102.cox.net@eastrmimpo110.cox.net>; Sun, 9 Oct 2011 21:54:13 -0400 Received: from serene.no-ip.org ([98.164.86.236]) by eastrmimpo110.cox.net with bizsmtp id ipu51h00255wwzE02pu9m1; Sun, 09 Oct 2011 21:54:13 -0400 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020B.4E925045.000C,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=2lDt+3Ehhkmq3Qye6YCr36r8zWAQhLDa7m4fIMlTmVE= c=1 sm=1 a=xqAeBGMQ-cYA:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=uAbGmPAyUfLL1M3oYAsfuA==:17 a=5n-WxztdAAAA:8 a=kviXuzpPAAAA:8 a=enq6Egla1qhBHisNjucA:9 a=CjuIK1q_8ugA:10 a=zHqGhn9gijkA:10 a=4vB-4DCPJfMA:10 a=uAbGmPAyUfLL1M3oYAsfuA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from cox.net (localhost [127.0.0.1]) by serene.no-ip.org (8.14.5/8.14.5) with ESMTP id p9A1s0lr068326; Sun, 9 Oct 2011 20:54:00 -0500 (CDT) (envelope-from conrads@cox.net) Date: Sun, 9 Oct 2011 20:53:55 -0500 From: "Conrad J. Sabatier" To: Manfred Antar Message-ID: <20111009205355.4c8bdb1a@cox.net> In-Reply-To: <201110100118.p9A1IJ0K005636@pozo.com> References: <4E919228.8010708@zedat.fu-berlin.de> <201110091548.p99FmpF4018785@pozo.com> <20111009135735.3f5fe1c1@cox.net> <201110100118.p9A1IJ0K005636@pozo.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 01:54:19 -0000 On Sun, 09 Oct 2011 18:18:13 -0700 Manfred Antar wrote: > At 11:57 AM 10/9/2011, Conrad J. Sabatier wrote: > >On Sun, 09 Oct 2011 08:48:46 -0700 > >Manfred Antar wrote: > > > >> Did you rebuild ports/devel/binutils after change to 10.0 current. > >> I was having same problem with gcc45 , then i rebuilt binutils with > >> uname_r 9.0-Current and it went away. > > > >Actually, binutils built just fine for me just now without setting > >UNAME_r under current. > > Built fine for me too. But when I tried to compile gcc45 no go > recompiled binutils with uname_r 9.0-CURRENT, And gcc45 built fine. > so my assumption was that something gets messed up with the binutils > and gcc45 when built with current. Yes, I see what you mean. Getting the same thing here. -- Conrad J. Sabatier conrads@cox.net From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 06:51:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C014E106566B for ; Mon, 10 Oct 2011 06:51:03 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA278FC14 for ; Mon, 10 Oct 2011 06:51:03 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RD9hT-0001U1-Oj>; Mon, 10 Oct 2011 08:50:59 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RD9hT-00018T-Mf>; Mon, 10 Oct 2011 08:50:59 +0200 Message-ID: <4E9295D3.8080201@zedat.fu-berlin.de> Date: Mon, 10 Oct 2011 08:50:59 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Manfred Antar References: <4E919228.8010708@zedat.fu-berlin.de> <201110091548.p99FmpF4018785@pozo.com> <20111009135735.3f5fe1c1@cox.net> <201110100118.p9A1IJ0K005636@pozo.com> In-Reply-To: <201110100118.p9A1IJ0K005636@pozo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: "Conrad J. Sabatier" , freebsd-current@freebsd.org Subject: Re: FreeBSD 10.0-CURRENT: messed up the ports and system (gcc46 won't compile) and need to repair - how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 06:51:03 -0000 On 10/10/11 03:18, Manfred Antar wrote: > At 11:57 AM 10/9/2011, Conrad J. Sabatier wrote: >> On Sun, 09 Oct 2011 08:48:46 -0700 >> Manfred Antar wrote: >> >>> Did you rebuild ports/devel/binutils after change to 10.0 current. >>> I was having same problem with gcc45 , then i rebuilt binutils with >>> uname_r 9.0-Current and it went away. >> >> Actually, binutils built just fine for me just now without setting >> UNAME_r under current. >> >> -- >> Conrad J. Sabatier >> conrads@cox.net > > Built fine for me too. But when I tried to compile gcc45 no go > recompiled binutils with uname_r 9.0-CURRENT, And gcc45 built fine. > so my assumption was that something gets messed up with the binutils and gcc45 when built with current. Managed it. Somehow I maneged to build the binutils without setting the UNAME_r kludge. I confused myself and the system. Thanks. I think, watching this is a very good opportunity to learn by doing, how things work. Oliver From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 08:09:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82E6A106564A for ; Mon, 10 Oct 2011 08:09:36 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 19C8A8FC1D for ; Mon, 10 Oct 2011 08:09:35 +0000 (UTC) Received: by wwe3 with SMTP id 3so8222103wwe.31 for ; Mon, 10 Oct 2011 01:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qi/xBsuQDM/oc0qs7aCcXGHlQi0OSDMHeYtbQElidMc=; b=Mz7CoY+eG6XxpBpuNmk/ozeJPwpVrZvWKe+9hGyUBwdPrB9uqYFsMyqCgjCmy9JRgP WbgB+LWbTUr+SVi4MFXh7kNUonMl8zlxwB41UWRjRbb2qLCm/IBmURF3ZuUMGKIS4fyL 7Wzxy+Lw1saQVyWkpzlh/kSJu3KcghhJ1MfNU= MIME-Version: 1.0 Received: by 10.227.25.197 with SMTP id a5mr2071325wbc.71.1318232674363; Mon, 10 Oct 2011 00:44:34 -0700 (PDT) Sender: r.c.ladan@gmail.com Received: by 10.180.109.233 with HTTP; Mon, 10 Oct 2011 00:44:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Oct 2011 09:44:34 +0200 X-Google-Sender-Auth: fluXfu9ABP80wLsKRfWaLw-JKIY Message-ID: From: =?ISO-8859-1?Q?Ren=E9_Ladan?= To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 08:09:36 -0000 2011/10/9 Larry Rosenman : > I had gotten a PR about sysutils/lsof not compiling with clang. That could be mine, ports/160544 ? > =A0I had > Vic Abell check it out, and the problem is NOT with lsof per se, but > with the system headers. > > Is there a project afoot to update the system headers to make them clang > compilable? > So I get the same errors as you for 9.0 (also with BETA3) on amd64, but for 9.0 on i386 from 2011-08-19 it builds fine: http://rene-ladan.nl:8080/tb/logs/9-FreeBSD-clang/lsof-4.85D_1,5.log Ren=E9 From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 15:28:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDEF11065672; Mon, 10 Oct 2011 15:28:22 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 298D98FC15; Mon, 10 Oct 2011 15:28:21 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.3 required=5.0 tests=ALL_TRUSTED, BAYES_40,SPF_SOFTFAIL Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 190942649; Mon, 10 Oct 2011 17:28:19 +0200 Received-SPF: softfail receiver=mailfe01.swip.net; client-ip=188.126.198.129; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: Adrian Chadd Date: Mon, 10 Oct 2011 17:25:18 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201110101725.18195.hselasky@freebsd.org> Cc: Garrett Cooper , freebsd-current Subject: Re: USB storage corruption/panic when doing file IO and unplugging (another, non-storage) device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 15:28:22 -0000 On Friday 07 October 2011 08:32:40 Adrian Chadd wrote: > On 7 October 2011 13:55, Garrett Cooper wrote: > >> Has anyone seen this before? > >> > >> This is _not_ plug/unplug the active storage device, or another > >> storage device. This is when doing IO on a storage device (whether the > >> root device or a media device) whilst plug/unplug a non-storage USB > >> device (wifi chipsets w/ no driver.) > > > > Yeah. Ran into it earlier on in the 9.x cycle with twa unplugging > > a USB keyboard when I was rebooting a machine; the panic was fixed in > > twa, not ukbd. I suppose my question is: does this only happen with > > USB, or is firewire affected, and why aren't the devices being > > properly masked against interrupts [in the same queue??] [by > > newbus???]? > > Let's wait for hps to get back to us. This seems like something he can > replicate very quickly. Hi, Could you send me the backtrace of the panic. USB is a broadcast system and connecting and disconnecting devices might cause interference. Make sure your driver is self powered. I have not seen this issue before. I'm using a USB disk every day. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 15:33:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F401065670; Mon, 10 Oct 2011 15:33:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF3D8FC0A; Mon, 10 Oct 2011 15:33:47 +0000 (UTC) Received: by ywp17 with SMTP id 17so6892212ywp.13 for ; Mon, 10 Oct 2011 08:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DnZMwywubAeQYZVs3lLwn7pACAZlzsDP4/EF26EmBVM=; b=i8bkRZRjdUo7wK+C4WYDPocxBYgzxhuzkLVO1QepyeL0YZQ9wx3C+IsvJvjuaig8Rv 6B9WJ11peg/i6oRuwDHKK/KWy54xpSBBEQxYHO44GdLTqXxw9ZE4gPOkb8Pd6uPGqTUT MbEtwIQHsPtZ4YqyD6SD1mmFSaigN+LAsszuQ= MIME-Version: 1.0 Received: by 10.236.197.69 with SMTP id s45mr24541926yhn.54.1318260827479; Mon, 10 Oct 2011 08:33:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Mon, 10 Oct 2011 08:33:47 -0700 (PDT) In-Reply-To: <201110101725.18195.hselasky@freebsd.org> References: <201110101725.18195.hselasky@freebsd.org> Date: Mon, 10 Oct 2011 23:33:47 +0800 X-Google-Sender-Auth: zAhRaoqL7t2GPPFydgs-ihTul_A Message-ID: From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd-current Subject: Re: USB storage corruption/panic when doing file IO and unplugging (another, non-storage) device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 15:33:48 -0000 ok, I'll do some more detailed testing in the next few days. Adrian From owner-freebsd-current@FreeBSD.ORG Sat Oct 8 03:01:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 552C010656AA; Sat, 8 Oct 2011 03:01:56 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id CFB988FC17; Sat, 8 Oct 2011 03:01:55 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p9831jRf044546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 20:01:46 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p9831jnt044545; Fri, 7 Oct 2011 20:01:45 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01736; Fri, 7 Oct 11 19:53:13 PDT Date: Sat, 08 Oct 2011 02:52:21 -0700 From: perryh@pluto.rain.com To: lev@freebsd.org Message-Id: <4e901d55.j0M8m+Tba3WC+Wrp%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1646032486.20111007112802@serebryakov.spb.ru> In-Reply-To: <1646032486.20111007112802@serebryakov.spb.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2011 16:17:20 +0000 Cc: daniel@digsys.bg, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Oct 2011 03:01:56 -0000 Lev Serebryakov wrote: > GPT must have backup copy in last sector by standard ... In that case, shouldn't it refuse to install on any provider that is not in fact a disk, so as not to create configurations that cannot work properly? > MBR doesn;t have any additional metadata. How adding one will help it? It would add robustness, for cases like the one that started this thread. If MBR put a GEOM metadata block at the end of its provider, it would fix the tasting race when an MBR is installed on a glabelled (or gmirrored) drive. From owner-freebsd-current@FreeBSD.ORG Sun Oct 9 07:21:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33FA106566C; Sun, 9 Oct 2011 07:21:25 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 70A478FC16; Sun, 9 Oct 2011 07:21:25 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p997LDhw041194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Oct 2011 00:21:14 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p997LDXa041193; Sun, 9 Oct 2011 00:21:13 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA06278; Sun, 9 Oct 11 00:00:55 PDT Date: Sun, 09 Oct 2011 07:00:02 -0700 From: perryh@pluto.rain.com To: lev@freebsd.org Message-Id: <4e91a8e2.Y3OdfyAUkARsSbU8%perryh@pluto.rain.com> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8D9136.6040200@digsys.bg> <672948039.20111006175334@serebryakov.spb.ru> <4e8f076e.XGNH7dUgsC/mhr1j%perryh@pluto.rain.com> <1822982078.20111007234412@serebryakov.spb.ru> <4E8F5D82.7050906@digsys.bg> <1993293883.20111008125543@serebryakov.spb.ru> In-Reply-To: <1993293883.20111008125543@serebryakov.spb.ru> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2011 16:20:51 +0000 Cc: daniel@digsys.bg, freebsd-current@freebsd.org, ivoras@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Oct 2011 07:21:25 -0000 Lev Serebryakov wrote: > >> GPT _must_ be placed twice -- at first and last sectors > >> (really, more than one sectors). By standard. Secondary > >> copy must be at end of disk. Period. > > Then, "by standard" GPT cannot coexist with GLABEL. Such setup > > should be disallowed, or at least big nasty message that you > > have just shoot yourself in the leg should be output. (period) > Ok, maybe adding check to geom_part, that it is used on rank-1 > provider (whole disk) is not so bad idea. But it then raise > question how to install FreeBSD on software mirror, what is > useful. To install FreeBSD on a gmirrored disk, use MBR (or "dangerously dedicated" BSD label) instead of GPT. (This is one reason why BSD label and MBR should not be considered obsolete.) If you want to use gmirror and *have* to use GPT, e.g. if you have a (hypothetical) BIOS which will not boot from MBR, mirror the individual partitions instead of the whole disk. Granted that is more trouble, both to set up initially and to replace a failed drive. From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 02:51:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EB89106568D; Mon, 10 Oct 2011 02:51:37 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 01EDB8FC0C; Mon, 10 Oct 2011 02:51:36 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p9A2pYow054158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Oct 2011 19:51:35 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p9A2pYEk054157; Sun, 9 Oct 2011 19:51:34 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA09602; Sun, 9 Oct 11 19:05:28 PDT Date: Mon, 10 Oct 2011 02:04:34 -0700 From: perryh@pluto.rain.com To: jwd@freebsd.org Message-Id: <4e92b522.f71Y8d/d4QhvelRN%perryh@pluto.rain.com> References: <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <4E8CD662.90202@quip.cz> <4E8DA627.60003@quip.cz> <711721489.20111006175611@serebryakov.spb.ru> <4E919DFF.8090607@quip.cz> <20111010012631.GA45500@FreeBSD.org> In-Reply-To: <20111010012631.GA45500@FreeBSD.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2011 16:21:00 +0000 Cc: 000.fbsd@quip.cz, lev@freebsd.org, ivoras@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 02:51:37 -0000 John wrote: > > ... gpart should show warning message if user is trying to put > > GPT on non real disk devices. ... > This also seem to prevent something useful like: > > # camcontrol inquiry da0 > pass2: Fixed Direct Access SCSI-5 device > pass2: Serial Number 3TB1BKGX00009036W9EN > pass2: 600.000MB/s transfers, Command Queueing Enabled > # camcontrol inquiry da25 > pass27: Fixed Direct Access SCSI-5 device > pass27: Serial Number 3TB1BKGX00009036W9EN > pass27: 600.000MB/s transfers, Command Queueing Enabled > > # gmultipath label ZFS0 da0 da25 > # gpart create -s gpt $device > # gpart add -s 128 -t freebsd-boot $device # Create 64K boot partition > # gpart add -s 4m -t freebsd-ufs -l mb$dev $device # small partition > # gpart add -t freebsd-zfs -l $dev $device # Remaining space for zfs > > It seems like protecting your partitions with multiple > paths would be a good thing. I've been experimenting with > this and end up with corrupt partitions. The setting of $device is not shown, but I suppose it is the name of the multipath provider. I'm not familiar with gmultipath, but it would not surprise me if (like most GEOMs) it were putting its metadata in the last block(s) of its providers and therefore encountering the same issues as gmirror and glabel. In that case, the best fix may be to define the multipathing per-partition instead of per-device (if that is possible), or to use MBR/BSD instead of GPT for partitioning. From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 19:05:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4342F1065674; Mon, 10 Oct 2011 19:05:16 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id E78EF8FC16; Mon, 10 Oct 2011 19:05:15 +0000 (UTC) Received: from orion.SpringDaemons.com (207.47.0.2.static.nextweb.net [207.47.0.2]) by mx0.deglitch.com (Postfix) with ESMTPA id 32FDB8FC2D; Mon, 10 Oct 2011 23:05:10 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 9E2135C36; Mon, 10 Oct 2011 12:04:19 -0700 (PDT) Date: Mon, 10 Oct 2011 12:04:19 -0700 From: Stanislav Sedov To: Chris Rees Message-Id: <20111010120419.9cfee3e9.stas@FreeBSD.org> In-Reply-To: References: <20111007230336.GB3051@laptop.levsha.me> <20111007164411.554ac9c0.stas@FreeBSD.org> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Mykola Dzham , current@freebsd.org, Stanislav Sedov , pp@gmail.com, "portmgr@freebsd.org" , jilles@freebsd.org Subject: Re: ports on 10.0-CURRENT: r226027 is incorrect fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 19:05:16 -0000 On Sat, 8 Oct 2011 18:35:13 +0100 Chris Rees mentioned: > > Last I heard, portmgr explicitly disapproved of this fix-- have I missed > something??? Erwin specifically said not to do it. > > Since when can anyone just commit stuff to bsd.port.mk, regardless of its > location? > > This is a bad solution, please revert it or I will when I get back. We're > going to end up being asked to support it on ports@ otherwise. > You certianly missed something, including the rationale behind the portmgr@ descision of not committing to the ports tree (!) bsd.port.mk. Go find some useful work to do like deleting old ports or whatever. You might want to consider deleting all mine ports, as I'm not going to support them anymore (after you backed out this fix without approval I don't have a working ports tree anymore on any of my 3 workstations). -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 20:33:39 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8C211065675; Mon, 10 Oct 2011 20:33:39 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFF48FC14; Mon, 10 Oct 2011 20:33:39 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RDMXa-00079I-Ef>; Mon, 10 Oct 2011 22:33:38 +0200 Received: from e178037012.adsl.alicedsl.de ([85.178.37.12] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RDMXa-00027J-BM>; Mon, 10 Oct 2011 22:33:38 +0200 Message-ID: <4E9356A1.9000503@zedat.fu-berlin.de> Date: Mon, 10 Oct 2011 22:33:37 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stanislav Sedov References: <20111007230336.GB3051@laptop.levsha.me> <20111007164411.554ac9c0.stas@FreeBSD.org> <20111010120419.9cfee3e9.stas@FreeBSD.org> In-Reply-To: <20111010120419.9cfee3e9.stas@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.37.12 Cc: current@freebsd.org, Chris Rees , "portmgr@freebsd.org" Subject: Re: ports on 10.0-CURRENT: r226027 is incorrect fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 20:33:39 -0000 On 10/10/11 21:04, Stanislav Sedov wrote: > On Sat, 8 Oct 2011 18:35:13 +0100 > Chris Rees mentioned: > >> Last I heard, portmgr explicitly disapproved of this fix-- have I missed >> something??? Erwin specifically said not to do it. >> >> Since when can anyone just commit stuff to bsd.port.mk, regardless of its >> location? >> >> This is a bad solution, please revert it or I will when I get back. We're >> going to end up being asked to support it on ports@ otherwise. >> > You certianly missed something, including the rationale behind the portmgr@ > descision of not committing to the ports tree (!) bsd.port.mk. Go find > some useful work to do like deleting old ports or whatever. You might want > to consider deleting all mine ports, as I'm not going to support them anymore > (after you backed out this fix without approval I don't have a working ports > tree anymore on any of my 3 workstations). > Hello? Is there need for this barbarian rude tone? Regards, oh From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 20:59:30 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EBDCF1065673; Mon, 10 Oct 2011 20:59:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DA92C150EAE; Mon, 10 Oct 2011 20:59:08 +0000 (UTC) Message-ID: <4E935C9C.2090502@FreeBSD.org> Date: Mon, 10 Oct 2011 13:59:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: FreeBSD Current , "freebsd-ports@FreeBSD.org" X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Patch for ports on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:59:31 -0000 Until the pointy-haireds come up with a better solution, here is a patch that incorporates work that others have done into a manageable form so that those interested in working with ports on 10-current have some tools to work with: http://dougbarton.us/bam.patch You need to do the equivalent of 'portmaster -o devel/libtool-fixed libtool' to get the fixed version. In addition to the OSVERSION check I added knobs to selectively disable the 2 parts of the fix to aid in development and testing. Also, make sure that you have the latest /usr/share/mk/bsd.port.mk with the similar fix backed out. Hopefully there will be a better fix soon, but until there is, I hope that this helps. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 21:30:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 821B5106566C for ; Mon, 10 Oct 2011 21:30:43 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 579BC8FC08 for ; Mon, 10 Oct 2011 21:30:43 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 087741CC6A; Mon, 10 Oct 2011 18:30:37 -0300 (BRT) Received: from 189.59.75.37 (proxying for 10.12.1.211, 10.12.0.132) (SquirrelMail authenticated user matheus) by 109.169.62.232 with HTTP; Mon, 10 Oct 2011 18:30:37 -0300 Message-ID: In-Reply-To: <0c062e2fefcf6a8bc2c436281780cec0.squirrel@eternamente.info> References: <8e42ff5adc4823b6a46fb59704a2bca5.squirrel@eternamente.info> <4E90D6CC.1030500@FreeBSD.org> <0c062e2fefcf6a8bc2c436281780cec0.squirrel@eternamente.info> Date: Mon, 10 Oct 2011 18:30:37 -0300 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: flash for 9-beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 21:30:43 -0000 On Sun, October 9, 2011 13:39, Nenhum_de_Nos wrote: > > On Sat, October 8, 2011 20:03, Doug Barton wrote: >> On 10/08/2011 14:53, Warren Block wrote: >>> nspluginwrapper needs to be run as the end user. >> >> The pkg-message tells them to do that. > > ops, haven't seen it though. all the ports cleaned by the "clean" part of > the command got on my way :( I did, no good though. FF still says no plugins. is it FF 7 compatible ? matheus > thanks, > > matheus > > -- > We will call you cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style > _______________________________________________ > 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" > -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:01:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22060106566C for ; Mon, 10 Oct 2011 22:01:42 +0000 (UTC) (envelope-from nalitoja@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC9088FC08 for ; Mon, 10 Oct 2011 22:01:41 +0000 (UTC) Received: by qadz30 with SMTP id z30so5708348qad.13 for ; Mon, 10 Oct 2011 15:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version:content-type; bh=IVGPOCNTcFP7T0iz8qBMLPeX0YWCV63thYRZTPMv2mg=; b=AJNUZpniydT4mQguV10xoWt5K/UG6h4stUC5/LXloyymExiLxN/6KpXRDQwcIXgYP2 33dZGITlkO7JOPwSEw0vXsoyrDMttyZOxrqPJcXgQOp3oj4WVDLJJx/Cz7R9KPdmAa2u 89QOl0nQUz4aE201m3mFeasL+OBY/OYLKzRpg= Received: by 10.224.218.198 with SMTP id hr6mr12615954qab.49.1318284100871; Mon, 10 Oct 2011 15:01:40 -0700 (PDT) Received: from nil (politkovskaja.torservers.net. [77.247.181.165]) by mx.google.com with ESMTPS id hn8sm16675692qab.2.2011.10.10.15.01.32 (version=SSLv3 cipher=OTHER); Mon, 10 Oct 2011 15:01:40 -0700 (PDT) From: Nali Toja To: Doug Barton In-Reply-To: <4E935C9C.2090502@FreeBSD.org> (Doug Barton's message of "Mon, 10 Oct 2011 13:59:08 -0700") Date: Mon, 10 Oct 2011 22:00:42 +0000 Message-ID: <86ipnw4id1.fsf@gmail.com> References: <4E935C9C.2090502@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: FreeBSD Current , "freebsd-ports@FreeBSD.org" Subject: Re: Patch for ports on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 22:01:42 -0000 Doug Barton writes: > Until the pointy-haireds come up with a better solution, here is a patch > that incorporates work that others have done into a manageable form so > that those interested in working with ports on 10-current have some > tools to work with: > > http://dougbarton.us/bam.patch [...] > +.if ${OSVERSION} >= 1000000 && !defined(NO_LIBTOOL_FIXED) The issue does not lie in OSVERSION but in OSREL. So, why not be smarter and detect if a user has UNAME_r workaround in environment by .if ${OSREL:R} >= 10 && !defined(NO_FOO_FIX) From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:05:07 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id E446D106566C; Mon, 10 Oct 2011 22:05:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id A570814F33B; Mon, 10 Oct 2011 22:05:07 +0000 (UTC) Message-ID: <4E936C13.2060605@FreeBSD.org> Date: Mon, 10 Oct 2011 15:05:07 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nali Toja References: <4E935C9C.2090502@FreeBSD.org> <86ipnw4id1.fsf@gmail.com> In-Reply-To: <86ipnw4id1.fsf@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "freebsd-ports@FreeBSD.org" Subject: Re: Patch for ports on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 22:05:08 -0000 On 10/10/2011 15:00, Nali Toja wrote: > Doug Barton writes: > >> Until the pointy-haireds come up with a better solution, here is a patch >> that incorporates work that others have done into a manageable form so >> that those interested in working with ports on 10-current have some >> tools to work with: >> >> http://dougbarton.us/bam.patch > [...] >> +.if ${OSVERSION} >= 1000000 && !defined(NO_LIBTOOL_FIXED) > > The issue does not lie in OSVERSION but in OSREL. So, why not be smarter > and detect if a user has UNAME_r workaround in environment Because by doing it the way I did it the user can apply both fixes, or either fix individually by using the right combination of knobs. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:11:11 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CF749106566B; Mon, 10 Oct 2011 22:11:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 518E5150C1A; Mon, 10 Oct 2011 22:11:11 +0000 (UTC) Message-ID: <4E936D7E.6040203@FreeBSD.org> Date: Mon, 10 Oct 2011 15:11:10 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <201110071615.p97GFlVK069165@repoman.freebsd.org> <4E8F8FE4.5040201@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "freebsd-ports@FreeBSD.org" Subject: Re: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 22:11:11 -0000 On 10/09/2011 09:29, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Fri, 07 Oct 2011 16:48:52 -0700 >>>>>> Doug Barton said: > > dougb> In case anyone wants to take this on, this port fails to install on 10.0 > dougb> because it uses its own version of libtool. I took a quick look but > dougb> there wasn't a solution obvious enough for me. :) > > I didn't have 10-current box, yet. So, I've just upgraded my > 9-current box to today's current, and tried to rebuild cyrus-sasl2 > port on it. However, I couldn't reproduce the problem. It built just > fine, here. Any thought? So I was able to confirm that the patch which had previously been in /usr/share/mk/bsd.port.mk was what caused it to fail. Hopefully that information will be helpful to those working on improving the generic fix. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:12:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F432106564A; Mon, 10 Oct 2011 22:12:58 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA808FC16; Mon, 10 Oct 2011 22:12:58 +0000 (UTC) Received: by gyf2 with SMTP id 2so7409600gyf.13 for ; Mon, 10 Oct 2011 15:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XfUuVZCmUGEfd1748JoVYqJi/c5+/JhukduRLH7Tl3s=; b=MMX5YSzgr3fpscC3wY0zb1LBpVkL/KeAMTpiDCT+rhSoZlsYj5F+9osZF2ugi3gFaW 53szxkLialT3m/HoBJ3x1yR2d+ChAHbDczYMaVS+35U0MQF7W9B235BvfkLNbfoVXbPh VWFPgW0Bv+UYZvCsJWgWkqIrBBbMPU1hn5c7w= MIME-Version: 1.0 Received: by 10.150.239.21 with SMTP id m21mr8094398ybh.75.1318284777552; Mon, 10 Oct 2011 15:12:57 -0700 (PDT) Received: by 10.151.145.18 with HTTP; Mon, 10 Oct 2011 15:12:57 -0700 (PDT) In-Reply-To: <4E935C9C.2090502@FreeBSD.org> References: <4E935C9C.2090502@FreeBSD.org> Date: Mon, 10 Oct 2011 15:12:57 -0700 Message-ID: From: Xin LI To: Doug Barton Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , "freebsd-ports@FreeBSD.org" Subject: Re: Patch for ports on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 22:12:58 -0000 On Mon, Oct 10, 2011 at 1:59 PM, Doug Barton wrote: > Until the pointy-haireds come up with a better solution, here is a patch > that incorporates work that others have done into a manageable form so > that those interested in working with ports on 10-current have some > tools to work with: > > http://dougbarton.us/bam.patch > > You need to do the equivalent of 'portmaster -o devel/libtool-fixed > libtool' to get the fixed version. In addition to the OSVERSION check I > added knobs to selectively disable the 2 parts of the fix to aid in > development and testing. Also, make sure that you have the latest > /usr/share/mk/bsd.port.mk with the similar fix backed out. > > Hopefully there will be a better fix soon, but until there is, I hope > that this helps. Thanks! This is better than nothing at very least. (By the way Python seems to be using a different way of getting FreeBSD version and for some reason that causes problem for certain applications) Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:16:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1006D106564A for ; Mon, 10 Oct 2011 22:16:10 +0000 (UTC) (envelope-from oz@nixil.net) Received: from nixil.net (nixil.net [161.58.222.1]) by mx1.freebsd.org (Postfix) with ESMTP id C477F8FC0C for ; Mon, 10 Oct 2011 22:16:09 +0000 (UTC) Received: from demigorgon.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by nixil.net (8.14.4/8.13.6) with ESMTP id p9ALcAaI056841 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 10 Oct 2011 15:38:13 -0600 (MDT) Message-ID: <4E9365C2.2020909@nixil.net> Date: Mon, 10 Oct 2011 15:38:10 -0600 From: Phil Oleson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110401 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <8e42ff5adc4823b6a46fb59704a2bca5.squirrel@eternamente.info> <4E90D6CC.1030500@FreeBSD.org> <0c062e2fefcf6a8bc2c436281780cec0.squirrel@eternamente.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nixil.net [161.58.222.1]); Mon, 10 Oct 2011 15:38:13 -0600 (MDT) X-Virus-Scanned: clamav-milter 0.97.2 at nixil.net X-Virus-Status: Clean Subject: Re: flash for 9-beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 22:16:10 -0000 On 10/10/11 15:30, Nenhum_de_Nos wrote: > > On Sun, October 9, 2011 13:39, Nenhum_de_Nos wrote: >> >> On Sat, October 8, 2011 20:03, Doug Barton wrote: >>> On 10/08/2011 14:53, Warren Block wrote: >>>> nspluginwrapper needs to be run as the end user. >>> >>> The pkg-message tells them to do that. >> >> ops, haven't seen it though. all the ports cleaned by the "clean" part of >> the command got on my way :( > > I did, no good though. > > FF still says no plugins. > > is it FF 7 compatible ? > > matheus > I ran into this recently. Though I have not figured out a more correct fix.. add this to your .bashrc: export MOZ_PLUGIN_PATH=/usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/symlinks/firefox or.. .cshrc setenv MOZ_PLUGIN_PATH /usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/symlinks/firefox and flash will work with the newer firefox. -Phil. From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:41:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB5241065670; Mon, 10 Oct 2011 22:41:23 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 562F78FC08; Mon, 10 Oct 2011 22:41:23 +0000 (UTC) Received: by ywp17 with SMTP id 17so7372058ywp.13 for ; Mon, 10 Oct 2011 15:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QXFOoj7phuQzQAmzI25dFrMqQzEFqei1dxVZfdjlmP0=; b=KJpwficPnHv2DhoCxHN82rSSP/Dl9M1OLZuWPGldBYD7uTB6W5zTRb/UjpEI3wvEjW sdnfwRewD9j+iB+hKtSsGKgHuS0qUdSrb/Y0AYXS+owz6ZCsEbzzs218SamYdnLih9yT Zl2ASzo7fKjhiumVe7GsNj6D/9dLqRM3/2434= MIME-Version: 1.0 Received: by 10.151.6.3 with SMTP id j3mr8050480ybi.90.1318285015577; Mon, 10 Oct 2011 15:16:55 -0700 (PDT) Received: by 10.151.145.18 with HTTP; Mon, 10 Oct 2011 15:16:55 -0700 (PDT) In-Reply-To: <4E9356A1.9000503@zedat.fu-berlin.de> References: <20111007230336.GB3051@laptop.levsha.me> <20111007164411.554ac9c0.stas@FreeBSD.org> <20111010120419.9cfee3e9.stas@FreeBSD.org> <4E9356A1.9000503@zedat.fu-berlin.de> Date: Mon, 10 Oct 2011 15:16:55 -0700 Message-ID: From: Xin LI To: "Hartmann, O." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Stanislav Sedov , current@freebsd.org, Chris Rees , "portmgr@freebsd.org" Subject: Re: ports on 10.0-CURRENT: r226027 is incorrect fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 22:41:23 -0000 On Mon, Oct 10, 2011 at 1:33 PM, Hartmann, O. wrote: > On 10/10/11 21:04, Stanislav Sedov wrote: >> On Sat, 8 Oct 2011 18:35:13 +0100 >> Chris Rees mentioned: >> >>> Last I heard, portmgr explicitly disapproved of this fix-- have I misse= d >>> something??? Erwin specifically said not to do it. >>> >>> Since when can anyone just commit stuff to bsd.port.mk, regardless of i= ts >>> location? >>> >>> This is a bad solution, please revert it or I will when I get back. We'= re >>> going to end up being asked to support it on ports@ otherwise. >>> >> You certianly missed something, including the rationale behind the portm= gr@ >> descision of not committing to the ports tree (!) bsd.port.mk. =C2=A0Go = find >> some useful work to do like deleting old ports or whatever. =C2=A0You mi= ght want >> to consider deleting all mine ports, as I'm not going to support them an= ymore >> (after you backed out this fix without approval I don't have a working p= orts >> tree anymore on any of my 3 workstations). >> > Hello? Is there need for this barbarian rude tone? Can everyone calm down a little bit, step back and think twice before making reactions? Stop it, as this hurts the project as a family. Cheers, --=20 Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-current@FreeBSD.ORG Mon Oct 10 22:57:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490A8106564A; Mon, 10 Oct 2011 22:57:05 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id EC6248FC0A; Mon, 10 Oct 2011 22:57:04 +0000 (UTC) Received: from orion.SpringDaemons.com (207.47.0.2.static.nextweb.net [207.47.0.2]) by mx0.deglitch.com (Postfix) with ESMTPA id 4B4CC8FC2D; Tue, 11 Oct 2011 02:57:03 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id E01135C36; Mon, 10 Oct 2011 15:56:09 -0700 (PDT) Date: Mon, 10 Oct 2011 15:56:09 -0700 From: Stanislav Sedov To: Stanislav Sedov Message-Id: <20111010155609.9c053aa8.stas@FreeBSD.org> In-Reply-To: <20111010120419.9cfee3e9.stas@FreeBSD.org> References: <20111007230336.GB3051@laptop.levsha.me> <20111007164411.554ac9c0.stas@FreeBSD.org> <20111010120419.9cfee3e9.stas@FreeBSD.org> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Mykola Dzham , current@freebsd.org, Stanislav Sedov , pp@gmail.com, "portmgr@freebsd.org" , jilles@freebsd.org, Chris Rees Subject: Re: ports on 10.0-CURRENT: r226027 is incorrect fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Oct 2011 22:57:05 -0000 On Mon, 10 Oct 2011 12:04:19 -0700 Stanislav Sedov mentioned: > On Sat, 8 Oct 2011 18:35:13 +0100 > Chris Rees mentioned: > > > > > Last I heard, portmgr explicitly disapproved of this fix-- have I missed > > something??? Erwin specifically said not to do it. > > > > Since when can anyone just commit stuff to bsd.port.mk, regardless of its > > location? > > > > This is a bad solution, please revert it or I will when I get back. We're > > going to end up being asked to support it on ports@ otherwise. > > > > You certianly missed something, including the rationale behind the portmgr@ > descision of not committing to the ports tree (!) bsd.port.mk. Go find > some useful work to do like deleting old ports or whatever. You might want > to consider deleting all mine ports, as I'm not going to support them anymore > (after you backed out this fix without approval I don't have a working ports > tree anymore on any of my 3 workstations). > Quoting myself. Sorry to all if this sounded rude, I might have overreacted. I didn't meant to be personal, it's just the whole situation is disappointing. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 03:00:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5FD1065670 for ; Tue, 11 Oct 2011 03:00:17 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id DBC618FC0C for ; Tue, 11 Oct 2011 03:00:16 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id F153E1CC69; Tue, 11 Oct 2011 00:00:01 -0300 (BRT) Received: from 187.114.195.61 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Tue, 11 Oct 2011 00:00:01 -0300 Message-ID: <8e26f2944efcfe0a48a83d065e19eff5.squirrel@eternamente.info> In-Reply-To: <4E9365C2.2020909@nixil.net> References: <8e42ff5adc4823b6a46fb59704a2bca5.squirrel@eternamente.info> <4E90D6CC.1030500@FreeBSD.org> <0c062e2fefcf6a8bc2c436281780cec0.squirrel@eternamente.info> <4E9365C2.2020909@nixil.net> Date: Tue, 11 Oct 2011 00:00:01 -0300 From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: flash for 9-beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 03:00:17 -0000 On Mon, October 10, 2011 18:38, Phil Oleson wrote: > On 10/10/11 15:30, Nenhum_de_Nos wrote: >> >> On Sun, October 9, 2011 13:39, Nenhum_de_Nos wrote: >>> >>> On Sat, October 8, 2011 20:03, Doug Barton wrote: >>>> On 10/08/2011 14:53, Warren Block wrote: >>>>> nspluginwrapper needs to be run as the end user. >>>> >>>> The pkg-message tells them to do that. >>> >>> ops, haven't seen it though. all the ports cleaned by the "clean" part >>> of >>> the command got on my way :( >> >> I did, no good though. >> >> FF still says no plugins. >> >> is it FF 7 compatible ? >> >> matheus >> > > I ran into this recently. Though I have not figured out a more correct > fix.. add this to your .bashrc: > > export > MOZ_PLUGIN_PATH=/usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/symlinks/firefox > > or.. .cshrc > > setenv MOZ_PLUGIN_PATH > /usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/symlinks/firefox > > and flash will work with the newer firefox. > > -Phil. thanks Phil, but no good to me :/ Both dirs don't exist, and I tried exporting to browser_plugins dir also ... thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 04:31:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B048106566C for ; Tue, 11 Oct 2011 04:31:55 +0000 (UTC) (envelope-from alexz@visp.ru) Received: from mail.visp.ru (srv1.visp.ru [91.215.204.2]) by mx1.freebsd.org (Postfix) with ESMTP id 101568FC12 for ; Tue, 11 Oct 2011 04:31:54 +0000 (UTC) Received: from 91-215-205-255.static.visp.ru ([91.215.205.255] helo=zagrebin) by mail.visp.ru with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RDU0P-0009sJ-2n; Tue, 11 Oct 2011 08:31:53 +0400 From: "Alexander Zagrebin" To: References: <4E8D8451.6060103@freebsd.org> <4E8E0376.1020403@FreeBSD.org> <1558168222.20111006235816@serebryakov.spb.ru> In-Reply-To: <1558168222.20111006235816@serebryakov.spb.ru> Date: Tue, 11 Oct 2011 08:31:52 +0400 Keywords: freebsd-current Message-ID: <21F45A0979464BEDB6DDE84EE25BE53B@vosz.local> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17514 Thread-Index: AcyEYoIGKG3Qn4r8TwGTigMiHhFORADagvqw Cc: freebsd-current@freebsd.org Subject: RE: subversion-freebsd dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 04:31:55 -0000 Hi! > >> On a newly installed development machine I installed > subversion-freebsd > >> from ports and ended up with a huge dependency chain. > > If you're just using it for FreeBSD you can un-check all > the OPTIONS. If > > you might want to use the http:// protocol to check > something out the > > neon option works well and is fairly painless. > It doesn't help to remove tcl build dependency, as sqlite3 is > unconditional dependency :( There is the "sqlite-autoconf-3070800.tar.gz" on the SQLite download page. This source code builds fine without tcl installed. But FreeBSD port still uses sqlite-src-XXX.zip which marked as "Legacy Source Code Distribution Formats (Not Recommended)" So it seems that tcl dependency may be avoided. -- Alexander Zagrebin From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 06:36:04 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D46D1065676; Tue, 11 Oct 2011 06:36:04 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (grizzly.droso.net [IPv6:2a01:4f8:100:9424::3]) by mx1.freebsd.org (Postfix) with ESMTP id DF37E8FC0A; Tue, 11 Oct 2011 06:36:03 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 11A7C7954D; Tue, 11 Oct 2011 08:36:03 +0200 (CEST) Date: Tue, 11 Oct 2011 08:36:03 +0200 From: Erwin Lansing To: ports@FreeBSD.org, current@FreeBSD.org Message-ID: <20111011063602.GO68552@droso.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Operating-System: FreeBSD/amd64 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: portmgr@FreeBSD.org Subject: Update on ports on 10.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 06:36:04 -0000 Since the release has been pushed back some more since the last mail, we do have some time to test a possible fix for the issues we're seeing with libtool on FreeBSD 10.0. However, fixing libtool is only part of the problem as hundreds, if not thousands, of ports roll their own detection and need to be fixed individually. We are currently running a fixed libtool (ports/161404) to assess how many ports are fixed by this patch and how many need to be patches manually before deciding how to move forward. Other options include the big find/grep/awk solution that has been posted several times and fiddling with uname to go to FreeBSD 9.99 for a while, while ports can be fixed. Hopefully, we can move forward in a day or two, but needless to say this needs a lot of testing both on 10.0 and earlier releases so we are sure we don't break backwards compatability, especially on 9.0 that is soon to be released. For those that cannot wait a few days, several patches have been proposed on the lists, of which dougb's seems most complete, so I recommend applying one of those locally. Please note that these are not tested widely and may break when the final fix is committed. To conclude with some "fun" facts, only 232 ports break on HEAD currently. Unfortunately, some of these are pretty high profile and prevent almost 19.000 other ports from building, leaving only slighty more than 3000 ports to build successfully. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the future erwin@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 08:19:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B1B1065672; Tue, 11 Oct 2011 08:19:13 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 735878FC0C; Tue, 11 Oct 2011 08:19:12 +0000 (UTC) Received: by wwe3 with SMTP id 3so9566187wwe.31 for ; Tue, 11 Oct 2011 01:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=xdgFdulHMoPHnOTH4gEeX5rr4vY54uoYD026PrSCAP4=; b=i3VBDl+8ciWQnEZyGWkdFfZUFM2haBEtq+d2HIbzU++zbY/QJJ+xeH9j4/aBqUI76U k8hb/NcFXZu7dkiGeeo4xE9DN2lBW8p2mpiwNEAUEDjoqnKAF9cjwU89WOkDZqGFAcom 2I/a6azJOKHMB6kC006JdyXvZQCfZDI2b/IaU= Received: by 10.227.23.210 with SMTP id s18mr8852507wbb.9.1318319540485; Tue, 11 Oct 2011 00:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.155.77 with HTTP; Tue, 11 Oct 2011 00:52:00 -0700 (PDT) In-Reply-To: <7710238591.20111006223449@serebryakov.spb.ru> References: <4E8D8451.6060103@freebsd.org> <07E6E2C5-D471-40AC-87E2-EF77B3CFB0F8@gmail.com> <7710238591.20111006223449@serebryakov.spb.ru> From: Christer Solskogen Date: Tue, 11 Oct 2011 09:52:00 +0200 Message-ID: To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , "freebsd-current@freebsd.org" , Andre Oppermann Subject: Re: subversion-freebsd dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 08:19:13 -0000 2011/10/6 Lev Serebryakov : > =A0 Huh? It is something new for me (maintainer). What is "recommended" > method? I'm not sure how Subversion 1.6.x is about this, but in 1.7 you can just drop sqlite.c from sqlite-source over to Subversion's sqlite-amalgamation/ directory. http://svn.apache.org/repos/asf/subversion/trunk/INSTALL --=20 chs, From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 09:45:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5708106566C; Tue, 11 Oct 2011 09:45:00 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1EF8FC13; Tue, 11 Oct 2011 09:45:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RDYtP-0000CH-Q7>; Tue, 11 Oct 2011 11:44:59 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RDYtP-0003Kr-O6>; Tue, 11 Oct 2011 11:44:59 +0200 Message-ID: <4E94101B.3040602@zedat.fu-berlin.de> Date: Tue, 11 Oct 2011 11:44:59 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ports@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: FreeBSD-9.0-BETA3/amd64 (CLANG): Assertion failed: (mblength != (size_t)-1 && mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 09:45:00 -0000 On my lab's server, a FreeBSD 9 box (9.0-BETA3 FreeBSD 9.0-BETA3 #40 r226245: Tue Oct 11 10:01:29 CEST 2011), I receive for some ports while compiling this error: Abort trap (core dumped) Assertion failed: (mblength != (size_t)-1 && mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. This just happened after the last update and reboot (did make world). Is this a bug? If yes, should I do a PR or is it already known? If not a bug, what is it? Oliver From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 10:06:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2FB1065768 for ; Tue, 11 Oct 2011 10:06:05 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id EE1B68FC14 for ; Tue, 11 Oct 2011 10:06:04 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1RDZDo-0005QH-88>; Tue, 11 Oct 2011 12:06:04 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1RDZDo-000580-61>; Tue, 11 Oct 2011 12:06:04 +0200 Message-ID: <4E94150C.30703@zedat.fu-berlin.de> Date: Tue, 11 Oct 2011 12:06:04 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Subject: FreeBSD 9.0/10.0 amd64 (CLANG): mysterious client crahses when typing left/right arrow key X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 10:06:05 -0000 Since yesterday after a make world on both FreeBSD versions I realize a strange behaviour in several GTK clients (gq for instance, freshly installed yesterday) and Firefox and Thunderbird (they have not been recompiled now for days). This behaviour occured earlier this year on FreeBSD 9.0-CURRENT, around July. I tried to install FreeBSD Current compiled with CLANG on a Core-i5 driven notebook with option --mtune=native, --mtune=i7 or even avoid using --mtune= and then it occured that the whole system was crap, since typing of TAB key immediately exited the shell or typing the arrow keys resulted in the same. This happened NOT when system got compiled with --mtune=core2 on that Core-i5 driven Notebook (Dell Latitude E6510)! I didn't test this behaviour on that notebook yet, but whill this night. The notebook have had a GENERIC kernel that time when the problem occured, now I use on all boxes custom kernel and these lines seem to be specificially for the terminal emulation: # Console options options MAXCONS=8 # maximum No. of consoles options SC_ALT_MOUSE_IMAGE # simplified mouse cursor in text mode options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=cp850 options SC_DISABLE_KDBKEY # disable `debug' key options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=512 # number of history buffer lines #options SC_MOUSE_CHAR=0x3 # char code for text mode mouse cursor options SC_PIXEL_MODE # add support for the raster text mode options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_RED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) #options SC_CUT_SPACES2TABS # convert leading spaces into tabs #options SC_CUT_SEPCHARS=\"x09\" # set of characters that delimit words # (default is single space - \"x20\") #options SC_TWOBUTTON_MOUSE # Enable experimental features of the syscons terminal emulator (teken). options TEKEN_UTF8 # UTF-8 output handling #options TEKEN_CONS25 # cons25-style terminal emulation # Enable VESA #options X86BIOS #options VESA Any idea? Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 10:46:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB20106564A; Tue, 11 Oct 2011 10:46:13 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56D9F8FC13; Tue, 11 Oct 2011 10:46:11 +0000 (UTC) Received: by wyj26 with SMTP id 26so10734347wyj.13 for ; Tue, 11 Oct 2011 03:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KD29SQU6QaWZoe9Zr3mf8Y/mxEO4MB4AKiGHZnubkZw=; b=sc1vSI2ZbwCOsBabSiaTuuRMYx84tcIZyb60d3sawfCvf/cpNgOjw1AX8kshrdGKs8 6arByZJB+MeOk9PbJo3p4Wf09vJq/7lP+76yvJk0t6EsVhz8Z1JQZQILwW/i+U3G4nDt C16xourg08aLEzYUxChOt62jIerddptKYOi0U= MIME-Version: 1.0 Received: by 10.216.143.222 with SMTP id l72mr7580732wej.46.1318328242628; Tue, 11 Oct 2011 03:17:22 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Tue, 11 Oct 2011 03:17:22 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Tue, 11 Oct 2011 03:17:22 -0700 (PDT) In-Reply-To: <20111011063602.GO68552@droso.net> References: <20111011063602.GO68552@droso.net> Date: Tue, 11 Oct 2011 20:47:22 +1030 Message-ID: From: Matt Thyer To: Erwin Lansing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, current@freebsd.org, portmgr@freebsd.org Subject: Re: Update on ports on 10.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:46:14 -0000 On Oct 11, 2011 5:07 PM, "Erwin Lansing" wrote: > > Since the release has been pushed back some more since the last mail, we > do have some time to test a possible fix for the issues we're seeing > with libtool on FreeBSD 10.0. [snip] > to move forward. Other options include the big find/grep/awk solution > that has been posted several times and fiddling with uname to go to > FreeBSD 9.99 for a while, while ports can be fixed. I would vote for a prominent message in the places people who run -CURRENT are meant to pay attention to (this mailing list and UPDATING and the ports equivalents). The message should point people to a web site (wiki?) with the latest news on how to report and provide patches for fixes with guidance on typical solutions. After all, this is -CURRENT and it's users are meant to be contributing fixes and are not expected to require their hands to be held. This I believe would be a good method to leverage the community so as to distribute the fixup problem. In particular the hack of 9.99 is likely to cause more problems and should be avoided. My 2=A2 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:00:49 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDE71065676; Tue, 11 Oct 2011 12:00:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7A98FC24; Tue, 11 Oct 2011 12:00:49 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a106:2522:e412:93aa] (unknown [IPv6:2001:7b8:3a7:0:a106:2522:e412:93aa]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 442C55C37; Tue, 11 Oct 2011 14:00:48 +0200 (CEST) Message-ID: <4E942FF1.9000805@FreeBSD.org> Date: Tue, 11 Oct 2011 14:00:49 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Larry Rosenman References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------050500050106010307010605" Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@FreeBSD.ORG Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:00:49 -0000 This is a multi-part message in MIME format. --------------050500050106010307010605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2011-10-09 19:32, Larry Rosenman wrote: > I had gotten a PR about sysutils/lsof not compiling with clang. I had > Vic Abell check it out, and the problem is NOT with lsof per se, but > with the system headers. > > Is there a project afoot to update the system headers to make them clang > compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. ... > In file included from ckkv.c:43: > In file included from ./../lsof.h:195: > In file included from ./../dlsof.h:190: > In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36: > /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function 'KASSERT' is invalid in C99 > [-Wimplicit-function-declaration] > KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp)); > ^ > /usr/src/sys/sys/buf.h:388:33: warning: expression result unused [-Wunused-value] > KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp)); > ^~~~~~~~~~~~~~~~~~~~~~~~~ These are more or less harmless warnings, as long as nobody calls a function that uses KASSERT. They occur because lsof's headers don't include and before . ... > In file included from ckkv.c:43: > In file included from ./../lsof.h:195: > In file included from ./../dlsof.h:432: > In file included from /usr/include/string.h:45: > /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' > int ffs(int) __pure2; > ^ > /usr/include/machine/cpufunc.h:140:24: note: expanded from: > #define ffs(x) __builtin_ffs(x) > ^ > /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int (unsigned int)' This is because the amd64 system headers redefine ffs to __builtin_ffs, after which it conflicts with the declaration in /usr/include/strings.h. On i386, ffs is not redefined, but I have no idea why. In any case, gcc does not complain about the incompatible redeclaration, which may be a bug, or just stupid luck, depending on your POV. :) I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. --------------050500050106010307010605 Content-Type: text/plain; name="clangports-sysutils-lsof-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clangports-sysutils-lsof-1.diff" Index: sysutils/lsof/files/patch-Configure =================================================================== RCS file: sysutils/lsof/files/patch-Configure diff -N sysutils/lsof/files/patch-Configure --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sysutils/lsof/files/patch-Configure 11 Oct 2011 11:44:44 -0000 @@ -0,0 +1,72 @@ +--- Configure.orig 2011-08-15 18:15:56.000000000 +0200 ++++ Configure 2011-10-11 13:30:37.000000000 +0200 +@@ -1428,7 +1428,7 @@ + 3.5*) + LSOF_VERS=3050 + ;; +- 3*) ++ 3.*) + LSOF_VERS=3050 + echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for FreeBSD 3.5" +@@ -1481,7 +1481,7 @@ + LSOF_TSTBIGF=" " + LSOF_VERS=4110 + ;; +- 4*) ++ 4.*) + LSOF_VERS=4100 + echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for FreeBSD 4.10" +@@ -1510,7 +1510,7 @@ + LSOF_TSTBIGF=" " + LSOF_VERS=5050 + ;; +- 5*) ++ 5.*) + LSOF_VERS=5050 + echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for FreeBSD 5.5" +@@ -1535,7 +1535,7 @@ + LSOF_TSTBIGF=" " + LSOF_VERS=6040 + ;; +- 6*) ++ 6.*) + LSOF_VERS=6000 + echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for FreeBSD 6.0" +@@ -1560,7 +1560,7 @@ + LSOF_TSTBIGF=" " + LSOF_VERS=7040 + ;; +- 7*) ++ 7.*) + LSOF_VERS=7000 + echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for FreeBSD 7.0" +@@ -1577,10 +1577,14 @@ + LSOF_TSTBIGF=" " + LSOF_VERS=8020 + ;; +- 9*) ++ 9.*) + LSOF_TSTBIGF=" " + LSOF_VERS=9000 + ;; ++ 10.*) ++ LSOF_TSTBIGF=" " ++ LSOF_VERS=10000 ++ ;; + *) + echo Unknown FreeBSD release: `uname -r` + echo Assuming FreeBSD 2.x +@@ -1684,7 +1688,7 @@ + LSOF_CFGF="$LSOF_CFGF -DHASVMLOCKH" + fi # } + ;; +- 4000|4010|4020|4030|4040|4050|4060|4070|4080|4090|4100|4110|5000|5010|5020|5030|5040|5050|6000|6010|6020|6030|6040|7000|7010|7020|7030|7040|8000|8010|8020|9000) ++ 4000|4010|4020|4030|4040|4050|4060|4070|4080|4090|4100|4110|5000|5010|5020|5030|5040|5050|6000|6010|6020|6030|6040|7000|7010|7020|7030|7040|8000|8010|8020|9000|10000) + if test -r ${LSOF_INCLUDE}/nfs/rpcv2.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASRPCV2H" Index: sysutils/lsof/files/patch-dialects-freebsd-dlsof.h =================================================================== RCS file: sysutils/lsof/files/patch-dialects-freebsd-dlsof.h diff -N sysutils/lsof/files/patch-dialects-freebsd-dlsof.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sysutils/lsof/files/patch-dialects-freebsd-dlsof.h 11 Oct 2011 11:44:44 -0000 @@ -0,0 +1,12 @@ +--- dialects/freebsd/dlsof.h.orig 2011-08-15 18:15:57.000000000 +0200 ++++ dialects/freebsd/dlsof.h 2011-10-11 13:34:59.000000000 +0200 +@@ -88,6 +88,9 @@ + # endif /* defined(NEEDS_BOOLEAN_T) */ + + #include ++#ifdef ffs ++#undef ffs ++#endif + + # if defined(HAS_VM_MEMATTR_T) + #undef vm_memattr_t --------------050500050106010307010605-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:09:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B009F106564A; Tue, 11 Oct 2011 12:09:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB9E8FC0A; Tue, 11 Oct 2011 12:09:47 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a106:2522:e412:93aa] (unknown [IPv6:2001:7b8:3a7:0:a106:2522:e412:93aa]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A78905C37; Tue, 11 Oct 2011 14:09:46 +0200 (CEST) Message-ID: <4E94320B.1070408@FreeBSD.org> Date: Tue, 11 Oct 2011 14:09:47 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "O. Hartmann" References: <4E94101B.3040602@zedat.fu-berlin.de> In-Reply-To: <4E94101B.3040602@zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-ports@freebsd.org Subject: Re: FreeBSD-9.0-BETA3/amd64 (CLANG): Assertion failed: (mblength != (size_t)-1 && mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 12:09:47 -0000 On 2011-10-11 11:44, O. Hartmann wrote: > On my lab's server, a FreeBSD 9 box (9.0-BETA3 FreeBSD 9.0-BETA3 #40 > r226245: Tue Oct 11 10:01:29 CEST 2011), I receive for some ports while > compiling this error: > > Abort trap (core dumped) > Assertion failed: (mblength != (size_t)-1&& mblength != (size_t)-2), > function inittables_mb, file > /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. > > This just happened after the last update and reboot (did make world). Is > this a bug? If yes, should I do a PR or is it already known? If not a > bug, what is it? Looks like a problem in GNU sort, caused by something unknown. Can you figure out what input it asserts on? Which specific ports cause it? From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:52:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7088E1065673 for ; Tue, 11 Oct 2011 12:52:12 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2905E8FC16 for ; Tue, 11 Oct 2011 12:52:11 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id p9BCpfJk011326; Tue, 11 Oct 2011 08:51:41 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.2.2-FCS FastPath queued) with ESMTP id SOK86122; Tue, 11 Oct 2011 08:51:40 -0400 (EDT) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id p9BCpeNe007688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Oct 2011 08:51:40 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: Date: Tue, 11 Oct 2011 08:51:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B59D754-9062-4499-9873-7C2167622032@gromit.dlib.vt.edu> To: Olivier Smedts X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020202.4E943BDD.003A,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: freebsd-current@freebsd.org Subject: Re: Strange ZFS filesystem corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 12:52:12 -0000 On Oct 4, 2011, at 12:09 PM, Olivier Smedts wrote: > 2011/10/3 Paul Mather : >> I know ZFS does not have a fsck utility ("because it doesn't need = one":), but does anyone know of any way of fixing this corruption short = of destroying the pool, creating a new one, and restoring from backup? = Is there some way of exporting and re-importing the pool that has the = side-effect of doing some kind of fsck-like repairing of subtle = corruption like this? >=20 > But there is the ZFS debugger, "zdb" ! >=20 > I can't really help you with that because I never had a corrupted > zpool, but if you search on the lists for up to a year or so, you'll > find some useful commands to inspect and destroy corrupted objects. >=20 >=20 > Usage: zdb [-CumdibcsDvhL] poolname [object...] > zdb [-div] dataset [object...] > zdb -m [-L] poolname [vdev [metaslab...]] > zdb -R poolname vdev:offset:size[:flags] > zdb -S poolname > zdb -l [-u] device > zdb -C >=20 > Dataset name must include at least one separator character '/' or = '@' > If dataset name is specified, only that dataset is dumped > If object numbers are specified, only those objects are dumped >=20 > Options to control amount of output: > -u uberblock > -d dataset(s) > -i intent logs > -C config (or cachefile if alone) > -h pool history > -b block statistics > -m metaslabs > -c checksum all metadata (twice for all data) blocks > -s report stats on zdb's I/O > -D dedup statistics > -S simulate dedup to measure effect > -v verbose (applies to all others) > -l dump label contents > -L disable leak tracking (do not load spacemaps) > -R read and display block from a device >=20 > Below options are intended for use with other options (except -l): > -A ignore assertions (-A), enable panic recovery (-AA) or both = (-AAA) > -F attempt automatic rewind within safe range of transaction = groups > -U -- use alternate cachefile > -X attempt extreme rewind (does not work with dataset) > -e pool is exported/destroyed/has altroot/not in a cachefile > -p -- use one or more with -e to specify path to vdev = dir > -P print numbers parsable > -t -- highest txg to use when searching for uberblocks > Specify an option more than once (e.g. -bb) to make only that option = verbose > Default is to dump everything non-verbosely I tried your suggestion and ran the command "zdb -ccv backups" to try = and check the consistency of the troublesome "backups" pool. This is = what I ended up with: =3D=3D=3D=3D=3D Traversing all blocks to verify checksums and verify nothing leaked ... [[...]] leaked space: vdev 0, offset 0x900b5557600, size 82944 leaked space: vdev 0, offset 0x900b556e400, size 23040 leaked space: vdev 0, offset 0x900b5553a00, size 9216 leaked space: vdev 0, offset 0x900b5540800, size 23040 leaked space: vdev 0, offset 0x900b550ea00, size 16896 leaked space: vdev 0, offset 0x900b54e2c00, size 9216 leaked space: vdev 0, offset 0x900b50f5600, size 6144 leaked space: vdev 0, offset 0x900b558dc00, size 70656 leaked space: vdev 0, offset 0x900b5580400, size 44544 leaked space: vdev 0, offset 0x900b55bd000, size 82944 leaked space: vdev 0, offset 0x900b55d6200, size 15360 leaked space: vdev 0, offset 0x900b55dd400, size 33792 leaked space: vdev 0, offset 0x900b55d2c00, size 6144 leaked space: vdev 0, offset 0x900b55a0800, size 95232 leaked space: vdev 0, offset 0x900b55f5400, size 6144 leaked space: vdev 0, offset 0x900b5716c00, size 6144 leaked space: vdev 0, offset 0x900b56e8400, size 6144 leaked space: vdev 0, offset 0x900b573b800, size 6144 leaked space: vdev 0, offset 0x900b5748a00, size 10752 leaked space: vdev 0, offset 0x900b58b5e00, size 3072 leaked space: vdev 0, offset 0x900b589de00, size 6144 leaked space: vdev 0, offset 0x900b575fe00, size 7680 leaked space: vdev 0, offset 0x900b5734600, size 15360 leaked space: vdev 0, offset 0x900b55e8200, size 43008 leaked space: vdev 0, offset 0x900b58ca200, size 27648 leaked space: vdev 0, offset 0x900b591d600, size 3072 leaked space: vdev 0, offset 0x900b591fa00, size 12288 leaked space: vdev 0, offset 0x900b5904a00, size 6144 leaked space: vdev 0, offset 0x900b594f400, size 53760 leaked space: vdev 0, offset 0x900b5939200, size 3072 leaked space: vdev 0, offset 0x900b5960800, size 4608 leaked space: vdev 0, offset 0x900b5966e00, size 3072 leaked space: vdev 0, offset 0x900b5963200, size 9216 leaked space: vdev 0, offset 0x900b595de00, size 4608 leaked space: vdev 0, offset 0x900b5928400, size 3072 leaked space: vdev 0, offset 0x900c9a93200, size 4608 leaked space: vdev 0, offset 0x900c9a8d800, size 21504 leaked space: vdev 0, offset 0x900c9afa400, size 3072 leaked space: vdev 0, offset 0x900c9af4a00, size 21504 leaked space: vdev 0, offset 0x900b5977000, size 9216 leaked space: vdev 0, offset 0x900b58b7000, size 75264 leaked space: vdev 0, offset 0x900b5575600, size 38400 leaked space: vdev 0, offset 0x900b4b24a00, size 18432 leaked space: vdev 0, offset 0x900b37a4400, size 6144 leaked space: vdev 0, offset 0x9004e2e5600, size 1536 leaked space: vdev 0, offset 0x9003d14cc00, size 1536 leaked space: vdev 0, offset 0x9002ef99200, size 39936 leaked space: vdev 0, offset 0x90027485400, size 12288 leaked space: vdev 0, offset 0x9001010d600, size 39936 block traversal size 7227697021440 !=3D alloc 7479385864704 (leaked = 251688843264) bp count: 66257621 bp logical: 7189198687232 avg: 108503 bp physical: 4780682987008 avg: 72152 compression: = 1.50 bp allocated: 7227697021440 avg: 109084 compression: = 0.99 bp deduped: 0 ref>1: 0 deduplication: = 1.00 SPA allocated: 7479385864704 used: 62.55% =3D=3D=3D=3D=3D (On a different pool that I checked using zdb I got the message "No = leaks (block sum matches space maps exactly)" followed by several lines = of pool statistics, which, I presume is the message you get when the = pool is okay.) I'm presuming from the above that the space leaks mean the pool is = corrupted, and that zdb has detected but not corrected this corruption. = I assume that ZFS's way of fixing corruption is not a fsck but a = "destroy the pool and restore it from backup?" Does that sound about = right? Cheers, Paul. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:16:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4EF8106566B for ; Tue, 11 Oct 2011 13:16:20 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 571528FC14 for ; Tue, 11 Oct 2011 13:16:19 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p9BDG7jw078109 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 11 Oct 2011 16:16:12 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E944197.7050803@digsys.bg> Date: Tue, 11 Oct 2011 16:16:07 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> In-Reply-To: <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: gptzfsboot error using HP Smart Array P410i Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 13:16:21 -0000 Has this issue been resolved somehow? Sane method to build gptzfsboot that will run on HP's P410i? Daniel From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:31:26 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209D91065670; Tue, 11 Oct 2011 13:31:26 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id DACD98FC0A; Tue, 11 Oct 2011 13:31:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=UxjmSVQ7qw3ujJphMVcHPgEMTxreq8TK20TWtY0y0b4=; b=G/zzVrUR0kELRBdN97arkmMf0Qh6F61F97XppUYNsiw6WlmkJpauzRnrWHWJiQiLmf9nNPkC980IX/Q4V7IHUJXIzkMorDGyERwH89YohHUpu9OSm49IM10HJqLSQ08Fpba6yBvNYVoZDnBWE/xDEbUOqpKqohSHO1hTVCUhK5c=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:63444 helo=[192.168.200.4]) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDcQS-000EfS-U1; Tue, 11 Oct 2011 08:31:25 -0500 Date: Tue, 11 Oct 2011 08:31:18 -0500 (CDT) From: Larry Rosenman Sender: ler@lrosenman.dyndns.org To: Dimitry Andric In-Reply-To: <4E942FF1.9000805@FreeBSD.org> Message-ID: References: <4E942FF1.9000805@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: =?ISO-8859-15?Q?Ren=E9_Ladan?= , freebsd-current@FreeBSD.ORG Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:31:26 -0000 On Tue, 11 Oct 2011, Dimitry Andric wrote: > On 2011-10-09 19:32, Larry Rosenman wrote: >> I had gotten a PR about sysutils/lsof not compiling with clang. I had >> Vic Abell check it out, and the problem is NOT with lsof per se, but >> with the system headers. >> >> Is there a project afoot to update the system headers to make them clang >> compilable? > > The problem isn't that clang can't compile the system headers, but > normally these don't get included from userspace. And they certainly > won't work as expected when you define _KERNEL in userspace, as the lsof > port foolishly does. It probably can't be avoided in such a tool, though. > > > ... >> In file included from ckkv.c:43: >> In file included from ./../lsof.h:195: >> In file included from ./../dlsof.h:190: >> In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36: >> /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function >> 'KASSERT' is invalid in C99 >> [-Wimplicit-function-declaration] >> KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp)); >> ^ >> /usr/src/sys/sys/buf.h:388:33: warning: expression result unused >> [-Wunused-value] >> KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp)); >> ^~~~~~~~~~~~~~~~~~~~~~~~~ > > These are more or less harmless warnings, as long as nobody calls a > function that uses KASSERT. They occur because lsof's headers don't > include and before . > > ... >> In file included from ckkv.c:43: >> In file included from ./../lsof.h:195: >> In file included from ./../dlsof.h:432: >> In file included from /usr/include/string.h:45: >> /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' >> int ffs(int) __pure2; >> ^ >> /usr/include/machine/cpufunc.h:140:24: note: expanded from: >> #define ffs(x) __builtin_ffs(x) >> ^ >> /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type >> 'int (unsigned int)' > > This is because the amd64 system headers redefine ffs to __builtin_ffs, > after which it conflicts with the declaration in /usr/include/strings.h. > On i386, ffs is not redefined, but I have no idea why. > > In any case, gcc does not complain about the incompatible redeclaration, > which may be a bug, or just stupid luck, depending on your POV. :) > > I've attached a fix for the lsof port, which also makes it build on > 10.0-CURRENT (this was easy to fix here, as lsof uses its own > hand-rolled configuration script). Let me know if it works for you. > Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. I will NOT accept the change. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:51:46 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D82E5106564A; Tue, 11 Oct 2011 13:51:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99A278FC0A; Tue, 11 Oct 2011 13:51:46 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:a106:2522:e412:93aa] (unknown [IPv6:2001:7b8:3a7:0:a106:2522:e412:93aa]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C8A965C37; Tue, 11 Oct 2011 15:51:45 +0200 (CEST) Message-ID: <4E9449F2.2000801@FreeBSD.org> Date: Tue, 11 Oct 2011 15:51:46 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Larry Rosenman References: <4E942FF1.9000805@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@FreeBSD.ORG Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:51:46 -0000 On 2011-10-11 15:31, Larry Rosenman wrote: > On Tue, 11 Oct 2011, Dimitry Andric wrote: ... >> I've attached a fix for the lsof port, which also makes it build on >> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >> hand-rolled configuration script). Let me know if it works for you. >> > Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. > > We need to get clang/system headers to allow warning free compilation > just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 13:59:28 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9DFB106568F; Tue, 11 Oct 2011 13:59:28 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9028FC08; Tue, 11 Oct 2011 13:59:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3meuUQ+PhhaCluVyC4hZ/j76sNGKY+XVrq9gfiBUEIA=; b=l0bd+oX6NYIQPaQ1ybHn9qjmgojTqQ5AlraYfJgroPczkeuIrU12l+fNbn3AEpGLX9lAWtCrSxfemE41/fAf/kP/dKtq1tvZHpacqQVcHmGIBpQiCIek798UnRWI680BankLF0MwViJJzuSDTLNNtUQBnC5gIhpkegRigcwYrBw=; Received: from [32.97.110.60] (port=27009 helo=[9.41.58.142]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDcrb-000ExW-7b; Tue, 11 Oct 2011 08:59:27 -0500 Message-ID: <4E944BA5.4080506@lerctr.org> Date: Tue, 11 Oct 2011 08:59:01 -0500 From: Larry Rosenman Organization: LERCTR Consulting User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dimitry Andric References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> In-Reply-To: <4E9449F2.2000801@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@FreeBSD.ORG Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:59:28 -0000 On 10/11/2011 8:51 AM, Dimitry Andric wrote: > On 2011-10-11 15:31, Larry Rosenman wrote: >> On Tue, 11 Oct 2011, Dimitry Andric wrote: > ... >>> I've attached a fix for the lsof port, which also makes it build on >>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >>> hand-rolled configuration script). Let me know if it works for you. >>> >> Unless the headers are fixed, Vic Abell (lsof Author) will NOT >> support it. >> >> We need to get clang/system headers to allow warning free compilation >> just like GCC does. > > The system headers compile without warning, if you use them as intended > (e.g. from the kernel), which lsof obviously doesn't do. There is no > easy workaround here, except by modifying lsof. > > For example, the warning about KASSERT is because lsof's headers don't > include the required headers for this macro. And gcc is apparently not > smart enough to generate warnings for this. :) > > In any case, isn't lsof's dlsof.h header full of special cases already? > What does it matter to add another one? > > Besides, even if you fix it in the system headers now, at compile time > you cannot be sure if the user has the correct version of them installed > anyway, so you would still have to work around the problem. We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. Period. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 15:39:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53115106566C; Tue, 11 Oct 2011 15:39:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id BF8128FC15; Tue, 11 Oct 2011 15:39:03 +0000 (UTC) Received: by qyk10 with SMTP id 10so3661361qyk.13 for ; Tue, 11 Oct 2011 08:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=pzc69SWXRBzynQ7ZQ2LAtoTxPcKpOGSWsG0kIHpOo4g=; b=O6kCzQlg8OpPYXPLj5qJlSM331vDVu3k03mVDDFJqAkI5tjORCrTcr4/Dhxa7E/Ma6 RSAsXAZmIzrJi+dvYRKXv5esiyhjzmFsUD1jgq1FpJseAyozhL1/nPwez8qBQLziRf8X 9VHsS2IvLnSx8CyzE7Ddpcr6EM5zbdODldvbs= Received: by 10.68.17.134 with SMTP id o6mr46162243pbd.52.1318347542679; Tue, 11 Oct 2011 08:39:02 -0700 (PDT) Received: from c-24-6-49-154.hsd1.ca.comcast.net (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id z1sm33389pbl.5.2011.10.11.08.39.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 08:39:01 -0700 (PDT) Date: Tue, 11 Oct 2011 08:38:59 -0700 (PDT) From: Garrett Cooper To: Christer Solskogen In-Reply-To: Message-ID: References: <4E8D8451.6060103@freebsd.org> <07E6E2C5-D471-40AC-87E2-EF77B3CFB0F8@gmail.com> <7710238591.20111006223449@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="967339439-805635513-1318347541=:4348" Cc: Garrett Cooper , lev@freebsd.org, Andre Oppermann , "freebsd-current@freebsd.org" Subject: Re: subversion-freebsd dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 15:39:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --967339439-805635513-1318347541=:4348 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 11 Oct 2011, Christer Solskogen wrote: > 2011/10/6 Lev Serebryakov : >>   Huh? It is something new for me (maintainer). What is "recommended" >> method? > > I'm not sure how Subversion 1.6.x is about this, but in 1.7 you can > just drop sqlite.c from sqlite-source over to Subversion's > sqlite-amalgamation/ directory. > http://svn.apache.org/repos/asf/subversion/trunk/INSTALL Talk to bapt@; he had a PR out which used the amalgamation sources (I couldn't seem to find it yesterday when I looked through the PR database). -Garrett --967339439-805635513-1318347541=:4348-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 16:00:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C2DF106566C for ; Tue, 11 Oct 2011 16:00:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E153F8FC19 for ; Tue, 11 Oct 2011 16:00:42 +0000 (UTC) Received: by iaby12 with SMTP id y12so5127408iab.13 for ; Tue, 11 Oct 2011 09:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FkEzA5/DQzSfq0Uhol0uRhYpBG+eBl0OSgFwOzZVWbk=; b=j3N3CQ8cvchHo/dp1OxQFfYMyReQ/cD3Uypy4477Hb5PJ2AaM6me14aBnXIyzAWUJI 8KgI4TL+iTt+nPynj4gTn2UuFfeGW7Ha0PD+sMRu1yx1poJ6PTLwanuTZFcnkxlbKdc9 GlgCld/CiEA0aCcX2sNw72NrMazWL5/ZSaEtg= MIME-Version: 1.0 Received: by 10.231.45.9 with SMTP id c9mr10483928ibf.73.1318348842195; Tue, 11 Oct 2011 09:00:42 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Tue, 11 Oct 2011 09:00:42 -0700 (PDT) In-Reply-To: <4E944BA5.4080506@lerctr.org> References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> Date: Tue, 11 Oct 2011 09:00:42 -0700 Message-ID: From: Kevin Oberman To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:00:43 -0000 On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman wrote: > On 10/11/2011 8:51 AM, Dimitry Andric wrote: >> >> On 2011-10-11 15:31, Larry Rosenman wrote: >>> >>> On Tue, 11 Oct 2011, Dimitry Andric wrote: >> >> ... >>>> >>>> I've attached a fix for the lsof port, which also makes it build on >>>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >>>> hand-rolled configuration script). =A0Let me know if it works for you. >>>> >>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support >>> it. >>> >>> We need to get clang/system headers to allow warning free compilation >>> just like GCC does. >> >> The system headers compile without warning, if you use them as intended >> (e.g. from the kernel), which lsof obviously doesn't do. =A0There is no >> easy workaround here, except by modifying lsof. >> >> For example, the warning about KASSERT is because lsof's headers don't >> include the required headers for this macro. =A0And gcc is apparently no= t >> smart enough to generate warnings for this. :) >> >> In any case, isn't lsof's dlsof.h header full of special cases already? >> What does it matter to add another one? >> >> Besides, even if you fix it in the system headers now, at compile time >> you cannot be sure if the user has the correct version of them installed >> anyway, so you would still have to work around the problem. > > We will NOT support clang as the compiler for lsof unless the system head= ers > work the same way as gcc's do. > > Period. Are asking that clang become bug compatible with gcc or that gcc be fixed to present the same errors as clang does? As a casual observer I really don't expect either to happen soon. (I suspect gcc being fixed SLIGHTLY more likely.) By it's very nature lsof does a lot of the sort of kernel interaction that is normally considered to be unacceptable and requires lots of kludges and hacks to do them. I am simply baffled as to why this issue is so different other then that it is dependent on the compiler used and not the differences between kernels and kernel interfaces. On the other hand, I have not done real kernel programming in years...not since I was writing kernel code in assembly for VMS about 20 years ago, so maybe I am missing some subtleties about this. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 16:07:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F619106564A; Tue, 11 Oct 2011 16:07:40 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1117B8FC08; Tue, 11 Oct 2011 16:07:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=pcql4jSTv3J38rnNggKMsnZft7JmMlo1ZFiw37SDesQ=; b=G4X7PG8g7WynSxibgRU/V6DXTSmVHzTi/SHFQjHcuyWnBHllK4n6pTj+d1K4C6zbnhtWanqkE5rVTiRjvt59ITNFGpNeMuHd3lAbKpe1NaMjMj5DUbeRTlFlVVkZ3zzMEggBAJuk7DqiVIDh4SRgD81LDlAUuS2sOrFMuxPGBUg=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:18876 helo=[192.168.200.4]) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDere-000GFi-Vf; Tue, 11 Oct 2011 11:07:39 -0500 Date: Tue, 11 Oct 2011 11:07:29 -0500 (CDT) From: Larry Rosenman Sender: ler@lrosenman.dyndns.org To: Kevin Oberman In-Reply-To: Message-ID: References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: =?ISO-8859-15?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:07:40 -0000 On Tue, 11 Oct 2011, Kevin Oberman wrote: > On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman wrote: >> On 10/11/2011 8:51 AM, Dimitry Andric wrote: >>> >>> On 2011-10-11 15:31, Larry Rosenman wrote: >>>> >>>> On Tue, 11 Oct 2011, Dimitry Andric wrote: >>> >>> ... >>>>> >>>>> I've attached a fix for the lsof port, which also makes it build on >>>>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >>>>> hand-rolled configuration script). Let me know if it works for you. >>>>> >>>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support >>>> it. >>>> >>>> We need to get clang/system headers to allow warning free compilation >>>> just like GCC does. >>> >>> The system headers compile without warning, if you use them as intended >>> (e.g. from the kernel), which lsof obviously doesn't do. There is no >>> easy workaround here, except by modifying lsof. >>> >>> For example, the warning about KASSERT is because lsof's headers don't >>> include the required headers for this macro. And gcc is apparently not >>> smart enough to generate warnings for this. :) >>> >>> In any case, isn't lsof's dlsof.h header full of special cases already? >>> What does it matter to add another one? >>> >>> Besides, even if you fix it in the system headers now, at compile time >>> you cannot be sure if the user has the correct version of them installed >>> anyway, so you would still have to work around the problem. >> >> We will NOT support clang as the compiler for lsof unless the system headers >> work the same way as gcc's do. >> >> Period. > > Are asking that clang become bug compatible with gcc or that gcc be > fixed to present the same errors as clang does? As a casual observer I > really don't expect either to happen soon. (I suspect gcc being fixed > SLIGHTLY more likely.) No, just asking that the same headers not generate ERRORS where gcc doesn't Extra Warnings are fine. the big one here is the _builtin_ffs() one about signed vs unsigned. > > By it's very nature lsof does a lot of the sort of kernel interaction > that is normally considered to be unacceptable and requires lots of > kludges and hacks to do them. I am simply baffled as to why this issue > is so different other then that it is dependent on the compiler used > and not the differences between kernels and kernel interfaces. It's not. It's just that this seems(!) to be a trivial issue to fix for the folks adding/wanting clang to process all ports. > > On the other hand, I have not done real kernel programming in > years...not since I was writing kernel code in assembly for VMS about > 20 years ago, so maybe I am missing some subtleties about this. > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:20:51 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AC111065674 for ; Tue, 11 Oct 2011 12:20:51 +0000 (UTC) (envelope-from poyopoyo@puripuri.plala.or.jp) Received: from msa03b.plala.or.jp (msa03.plala.or.jp [IPv6:2400:7800:0:5010::3]) by mx1.freebsd.org (Postfix) with ESMTP id BA1E38FC0C for ; Tue, 11 Oct 2011 12:20:50 +0000 (UTC) Received: from i220-220-100-225.s02.a026.ap.plala.or.jp ([220.220.100.225]) by msa03b.plala.or.jp with ESMTP id <20111011122049.MXRW5763.msa03b.plala.or.jp@i220-220-100-225.s02.a026.ap.plala.or.jp> for ; Tue, 11 Oct 2011 21:20:49 +0900 Date: Tue, 11 Oct 2011 21:20:48 +0900 Message-ID: <86sjmzra73.wl%poyopoyo@puripuri.plala.or.jp> From: poyopoyo@puripuri.plala.or.jp To: freebsd-current@FreeBSD.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-VirusScan: Outbound; msa03b; Tue, 11 Oct 2011 21:20:49 +0900 X-Mailman-Approved-At: Tue, 11 Oct 2011 16:37:59 +0000 Cc: Subject: MPSAFE tty and lastcomm output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:20:51 -0000 Hi, Does anyone see this on -CURRENT (and stable/9)? It doesn't look so smart output to me. I was aware of this issue first back in Aug 2009. == $ tty; lastcomm tty|head -1 /dev/pts/12 tty - user pts/12 0.002 secs Tue Oct 11 20:41 == OK, As this was run on pts/12, nothing is wrong. == $ script /dev/null tty; lastcomm tty|head -1; lastcomm tty|head -1 Script started, output file is /dev/null /dev/pts/13 Script done, output file is /dev/null tty - user pts/13 0.001 secs Tue Oct 11 20:46 tty - user #C:0x8b 0.001 secs Tue Oct 11 20:46 == Please look at the second entry of lastcomm. These two entries should describe the identical tty(1) process, and a tty field in the second entry does not look good. It looks stored accounting information is correct, but lastcomm failed to represent device name gently after it has been destroyed. Funnier case: == $ jot 1000|while read n; do script /dev/null tty < /dev/tty & done > /dev/null 2>&1 ; wait; lastcomm tty|head == And you'll see variety of output. Some devices are still alive and others has been destroyed. Without head(1) you'll see a swarm of them, of course. (After this one-liner, my tty always goes mad and have to reset(1) to be back sane. This is another issue though.) -- kuro From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 12:45:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B80F106564A; Tue, 11 Oct 2011 12:45:26 +0000 (UTC) (envelope-from mail2kandrew@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 418EB8FC0A; Tue, 11 Oct 2011 12:45:24 +0000 (UTC) Received: by wwe3 with SMTP id 3so9936090wwe.31 for ; Tue, 11 Oct 2011 05:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lzOG2ElYEnfMjJ4tdSUw491pEiGr+vyW062mAB+oEMU=; b=aFxpH9UMvxXPSU/sSbH6LTnNSZg0C3LBqSf7Z/3ocnplALAgzbeOGFd0xF5pYpNe6T Kc09ayw+Ag5IVg6BDfC1qDPFzpr1f753Qcl5m2H8B/dSVhenSDbAzgkPzGQ2iOm82of4 Ed0dSr77P9d94LlG65WMYo+xfSSS9EbKmuv1g= MIME-Version: 1.0 Received: by 10.216.229.84 with SMTP id g62mr7687738weq.23.1318335586383; Tue, 11 Oct 2011 05:19:46 -0700 (PDT) Received: by 10.216.35.10 with HTTP; Tue, 11 Oct 2011 05:19:46 -0700 (PDT) In-Reply-To: <4E94320B.1070408@FreeBSD.org> References: <4E94101B.3040602@zedat.fu-berlin.de> <4E94320B.1070408@FreeBSD.org> Date: Tue, 11 Oct 2011 15:19:46 +0300 Message-ID: From: Andrew Kryzhyk To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 11 Oct 2011 16:38:42 +0000 Cc: FreeBSD Current , "O. Hartmann" , freebsd-ports@freebsd.org Subject: Re: FreeBSD-9.0-BETA3/amd64 (CLANG): Assertion failed: (mblength != (size_t)-1 && mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 12:45:27 -0000 Hi! There is an open pr on this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dgnu/93629 2011/10/11 Dimitry Andric : > On 2011-10-11 11:44, O. Hartmann wrote: >> >> On my lab's server, a FreeBSD 9 box (9.0-BETA3 FreeBSD 9.0-BETA3 #40 >> r226245: Tue Oct 11 10:01:29 CEST 2011), I receive for some ports while >> compiling this error: >> >> Abort trap (core dumped) >> Assertion failed: (mblength !=3D (size_t)-1&& =A0mblength !=3D (size_t)-= 2), >> function inittables_mb, file >> /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706= . >> >> This just happened after the last update and reboot (did make world). Is >> this a bug? If yes, should I do a PR or is it already known? If not a >> bug, what is it? > > Looks like a problem in GNU sort, caused by something unknown. =A0Can you > figure out what input it asserts on? =A0Which specific ports cause it? > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 16:55:22 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C023E1065673 for ; Tue, 11 Oct 2011 16:55:22 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82C3D8FC15 for ; Tue, 11 Oct 2011 16:55:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:CC:To:Date:From:Subject:Content-Type:MIME-Version:In-Reply-To:References; bh=glbrGoNZIZ1J60jd+U4tVkHFOk9dbEkMnI+VSS3lDyk=; b=L5mJcGaoKIuijc0s7uNEV+LAQoigCXj3gTh0Kg9H+D7GQQtSk8Z4a/OgTQm/lRwZtxP38WdkvOugQRTcjJv9YSCg18oaGxEsFnliUGjtRVCMZLRr5K42lPsVLFCLAULS2dHkAcleuyOGBDRHjQGg4ZoFzoD4ZoNFaOHXKx5AHtc=; Received: from [32.97.110.64] (port=46122 helo=Android-A100001B9859B8.austin.ibm.com) by thebighonker.lerctr.org with esmtpa (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDfbs-000Go6-Ih; Tue, 11 Oct 2011 11:55:21 -0500 References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> User-Agent: K-9 Mail for Android In-Reply-To: <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> MIME-Version: 1.0 From: Larry Rosenman Date: Tue, 11 Oct 2011 11:55:22 -0500 To: Chuck Swiger Message-ID: <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:55:22 -0000 I didn't say bug for bug, just not generate stupid errors like the ffs one.= -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. C= huck Swiger wrote: On Oct 11, 2011, at 6:59 AM, Larry Ro= senman wrote: > We will NOT support clang as the compiler for lsof unless t= he system headers work the same way as gcc's do. That apparently means you= won't support clang then, because it's not intended to be (or ever going t= o be) fully bug-for-bug "compatible" with GCC. In this case, at least, clan= g is reporting legitimate issues which should be fixed, even if folks conti= nue to build lsof with GCC from now until the end of days. To echo a word = someone else just used, I'm baffled as to why you would hold such a positio= n. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:46:11 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7928A106564A for ; Tue, 11 Oct 2011 17:46:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 1452F8FC0A for ; Tue, 11 Oct 2011 17:46:11 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 403922A28CCA; Tue, 11 Oct 2011 19:46:10 +0200 (CEST) Date: Tue, 11 Oct 2011 19:46:10 +0200 From: Ed Schouten To: poyopoyo@puripuri.plala.or.jp Message-ID: <20111011174610.GV91943@hoeg.nl> References: <86sjmzra73.wl%poyopoyo@puripuri.plala.or.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6tnUusbJa3r4kWvc" Content-Disposition: inline In-Reply-To: <86sjmzra73.wl%poyopoyo@puripuri.plala.or.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org Subject: Re: MPSAFE tty and lastcomm output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:46:11 -0000 --6tnUusbJa3r4kWvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi , * poyopoyo@puripuri.plala.or.jp , 20111011 1= 4:20: > It looks stored accounting information is correct, but lastcomm failed > to represent device name gently after it has been destroyed. Yes, exactly. Our struct acct uses a dev_t to store the controlling TTY. This is obviously completely broken on 8+, because we garbage collect pseudo-terminals. Still, one could argue it has always been broken, because even before the new TTY layer it would break when unplugging USB-to-serial converters or performing a reboot. I think the only way to fix this, is by updating the acct structure to write a string representation of the device name. Best regards, --=20 Ed Schouten WWW: http://80386.nl/ --6tnUusbJa3r4kWvc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOlIDiAAoJEG5e2P40kaK7Jb4P/R5FdFlNJIcC0RkzDF9/IVpf 8SLNVOdpHpySP0OyhChcuaKnTfTwDUMJ4G6yUZlu0FvZIx8NrkZgKZqjvioTgxVD 48lmk3TqdATU9r/MmWRpxsLYf6w+PesOAYPn494g4urmBhukiwDPNOOGtlzA4SWH cZUfCqXGXUD98CrADPY1B5hpQGaY2oLhUxy5hZPc98k1opmgq9sw+AyUyggJvOao B4xN8Lg16K6HOGndrhnXBbQu9tTPo8YTy0meGJh/NtkzDomVeVyks7i3xIHgn4xW p1dpZzRQCePKZPkMzIZebwfoU8kQ/qCCJXBdVrR7/FgjFjLOdSNfg/p0J7+c5LsU oa0C6xE489q1j5aypZb6oC41/WzPJD2dGIBfFsKKt1kWhPuoTZTXsxcWhNlo2mL1 qIg8DBKhTtStMN+aMvfhCZSZTXBpPnel/DgOgyuPM/NojCygPVZzd7ZLLmuNdlOz GrzHxFctcjW9DSAHcKP5oVx8Pke3wBV/CQC8q9dvtNMmuW/qQuadIp5Esm3UDSNx dWCgUzvKBpe701WWTWIqFEC1yfzLaRyLN+yG/69Fastx5nC+foz/9g/sHMbM5F1l pNywWWcD+xWwhgK5stHgyYV+QVz4LxwGR0MzP/hy+7Z77eLv9JTPILnoKB4RdAAi kofxGZlCcHMt2BWnwzct =LlSU -----END PGP SIGNATURE----- --6tnUusbJa3r4kWvc-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:46:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87343106566B for ; Tue, 11 Oct 2011 17:46:45 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 167848FC0C for ; Tue, 11 Oct 2011 17:46:44 +0000 (UTC) Received: by wyj26 with SMTP id 26so11444490wyj.13 for ; Tue, 11 Oct 2011 10:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ecp5jTGQ/mwyg+sP1/LkXtmsGV+i+BKNJdAeLr1Zbdk=; b=QHYob4rCUFzoYxuoWX/9uvJ8PBWnzngc1z3P4NMJLM7yYrpyZwfYCwsmb8XhQbTwP+ Np5mdjWPnu7V7xQB6KPbKYZP2QnpbHdGfJE4q4E75HQrswxwhXBanbae6CykO+BAeBg/ +N42D132Ic2AlEhmuY8K27TbUl4R4vRBRUg+A= MIME-Version: 1.0 Received: by 10.216.163.194 with SMTP id a44mr7973071wel.1.1318355203940; Tue, 11 Oct 2011 10:46:43 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Tue, 11 Oct 2011 10:46:43 -0700 (PDT) Received: by 10.216.36.18 with HTTP; Tue, 11 Oct 2011 10:46:43 -0700 (PDT) In-Reply-To: <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> Date: Wed, 12 Oct 2011 04:16:43 +1030 Message-ID: From: Matt Thyer To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:46:45 -0000 On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: > > I didn't say bug for bug, just not generate stupid errors like the ffs one. > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Chuck Swiger wrote: > > On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: > > We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. > > That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:51:13 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83661065672 for ; Tue, 11 Oct 2011 17:51:13 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD7A88FC13 for ; Tue, 11 Oct 2011 17:51:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp023.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LSW0063JUSHOW20@asmtp023.mac.com> for freebsd-current@FreeBSD.ORG; Tue, 11 Oct 2011 09:50:41 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-11_05:2011-10-11, 2011-10-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110110177 From: Chuck Swiger In-reply-to: <4E944BA5.4080506@lerctr.org> Date: Tue, 11 Oct 2011 09:50:40 -0700 Message-id: <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> To: Larry Rosenman X-Mailer: Apple Mail (2.1084) Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:51:14 -0000 On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: > We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. To echo a word someone else just used, I'm baffled as to why you would hold such a position. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:55:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968D91065670 for ; Tue, 11 Oct 2011 17:55:30 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 580C28FC15 for ; Tue, 11 Oct 2011 17:55:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=W1YVIiYAU/OxvKpkQFVGJWYuV+oUkRJVOUwuJ7IPTjo=; b=ZDADC0Sbh/rUNYc7OiP5R9xrCE8ixNvnoR96wAj4+V+QQBZMXYxKm7XaMxtheKOwptAPAmpJwwmD/AtS+ZBLrPM7WyAhJAhpZ/F7ejSyTSxEvk6CslfBkmjf0i5k+VZgAW/qzqvFWAvdrr2BvIzG0Nt1Zzvo90dY3K7ok9L9uC0=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:30900 helo=[192.168.200.4]) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDgY3-000HRy-SE; Tue, 11 Oct 2011 12:55:29 -0500 Date: Tue, 11 Oct 2011 12:55:25 -0500 (CDT) From: Larry Rosenman Sender: ler@lrosenman.dyndns.org To: Matt Thyer In-Reply-To: Message-ID: References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:55:30 -0000 On Wed, 12 Oct 2011, Matt Thyer wrote: > On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: >> >> I didn't say bug for bug, just not generate stupid errors like the ffs > one. >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> Chuck Swiger wrote: >> >> On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: >>> We will NOT support clang as the compiler for lsof unless the system > headers work the same way as gcc's do. >> >> That apparently means you won't support clang then, because it's not > intended to be (or ever going to be) fully bug-for-bug "compatible" with > GCC. In this case, at least, clang is reporting legitimate issues which > should be fixed, even if folks continue to build lsof with GCC from now > until the end of days. > > The elegant solution would be to avoid this problem altogether by > re-implementation of lsof using interfaces into the kernel that provide the > required information. > > bsdof anyone? > lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:36:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D06B4106564A; Tue, 11 Oct 2011 18:36:13 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 18B898FC21; Tue, 11 Oct 2011 18:36:12 +0000 (UTC) Received: by wyj26 with SMTP id 26so11524812wyj.13 for ; Tue, 11 Oct 2011 11:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nzrHoG6ZkZ9XI9msdX23xcHKas4kYBx/An5YS8tSqYo=; b=TxDOtxfWle2fvsyWiLJDo6D9VeihaMnRCLKh6/T6gN3T6c8JTkEhB6j8k2nQpriOIF dZ1ZfIF0NZvMKHuLapreRktoHKtZsJDk/nPq0L7DqH3V3aDH3r5Fyj9XVzD7ZifdYQvw c9ln1sw1AsQ89C0ta0WJOVYDTRXVt/RQuiYIw= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr6298350wbc.49.1318358171904; Tue, 11 Oct 2011 11:36:11 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 11:36:11 -0700 (PDT) In-Reply-To: <4E942FF1.9000805@FreeBSD.org> References: <4E942FF1.9000805@FreeBSD.org> Date: Tue, 11 Oct 2011 14:36:11 -0400 Message-ID: From: Arnaud Lacombe To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:36:13 -0000 Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: > On 2011-10-09 19:32, Larry Rosenman wrote: >> >> I had gotten a PR about sysutils/lsof not compiling with clang. =A0I had >> Vic Abell check it out, and the problem is NOT with lsof per se, but >> with the system headers. >> >> Is there a project afoot to update the system headers to make them clang >> compilable? > > The problem isn't that clang can't compile the system headers, but > normally these don't get included from userspace. =A0And they certainly > won't work as expected when you define _KERNEL in userspace, as the lsof > port foolishly does. =A0It probably can't be avoided in such a tool, thou= gh. > #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:38:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CED11065676; Tue, 11 Oct 2011 18:38:33 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id AB5D48FC17; Tue, 11 Oct 2011 18:38:32 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:b9fd:2f11:cd06:1a6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 7ACAD4AC1C; Tue, 11 Oct 2011 22:38:30 +0400 (MSD) Date: Tue, 11 Oct 2011 22:38:27 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1564162658.20111011223827@serebryakov.spb.ru> To: Christer Solskogen In-Reply-To: References: <4E8D8451.6060103@freebsd.org> <07E6E2C5-D471-40AC-87E2-EF77B3CFB0F8@gmail.com> <7710238591.20111006223449@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , lev@freebsd.org, Andre Oppermann , "freebsd-current@freebsd.org" Subject: Re: subversion-freebsd dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:38:33 -0000 Hello, Christer. You wrote 11 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 11:52:00: > I'm not sure how Subversion 1.6.x is about this, but in 1.7 you can > just drop sqlite.c from sqlite-source over to Subversion's > sqlite-amalgamation/ directory. > http://svn.apache.org/repos/asf/subversion/trunk/INSTALL I don't want to use this way, as it will create hidden dependency. What if vulnerability is found tomorrow for sqlite? It is not a solution to have some sqlite.c taken from arbitrary source. It is better to fix sqlite3 port. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:39:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A35C4106564A; Tue, 11 Oct 2011 18:39:45 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 677998FC13; Tue, 11 Oct 2011 18:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hnluxXeIGIBBpgx2tySrTIqvUXPCOV3SzCR17OzsQCo=; b=U1faXiL0smTH7U/NIrrt8X42+8xxZl46VIL6RgjYWeBxIKIzwE5ydLjNFKLNkAHdNj8c3rtZtvszYJXCMAMyiLmWo1/DkpYN5JUwSKHXVXdFyXv+8XY6NScrIdmQzFvRA/TVpgI1a/lek7+pk3wXV0jdee9zBC7c9RLyoR3TVYk=; Received: from [32.97.110.60] (port=19403 helo=[9.41.58.142]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDhEt-000HxB-Gw; Tue, 11 Oct 2011 13:39:44 -0500 Message-ID: <4E948D59.5020006@lerctr.org> Date: Tue, 11 Oct 2011 13:39:21 -0500 From: Larry Rosenman Organization: LERCTR Consulting User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E942FF1.9000805@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:39:45 -0000 On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >> On 2011-10-09 19:32, Larry Rosenman wrote: >>> I had gotten a PR about sysutils/lsof not compiling with clang. I had >>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>> with the system headers. >>> >>> Is there a project afoot to update the system headers to make them clang >>> compilable? >> The problem isn't that clang can't compile the system headers, but >> normally these don't get included from userspace. And they certainly >> won't work as expected when you define _KERNEL in userspace, as the lsof >> port foolishly does. It probably can't be avoided in such a tool, though. >> > #ifdef _KERNEL/#endif protected part of system headers shall NEVER be > accessed by userland. It is a fault to have them present in > /usr/include. Linux got it right there, all those part are removed > upon headers' installation. > > - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. And it **NEEDS** to know what the structures are. That is unless someone(tm) writes the Kernel interfaces to get the info. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:40:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F38D1065673; Tue, 11 Oct 2011 18:40:49 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A204D8FC19; Tue, 11 Oct 2011 18:40:48 +0000 (UTC) Received: by wyj26 with SMTP id 26so11532277wyj.13 for ; Tue, 11 Oct 2011 11:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1/SLqGFAWCWQbIBFC3KYivEPOWBUpYsTlsImfhv8Qrw=; b=I89J5U1eytmd2CaBKF48aBaaj6CGn1iMePH8BQM/feQ90HU2jk+TXtZu0gA1xYIZc4 /6VXmXwUPvQmj0qlx0LXUYURSdLRnOrPdBzrFBk05paDf3eseer/o/WqV424GBlH1yON +/5dizwe1Sy7Ikgsqp/TKw0HEhQq0rAWFEdkw= MIME-Version: 1.0 Received: by 10.227.134.18 with SMTP id h18mr8135576wbt.49.1318358447430; Tue, 11 Oct 2011 11:40:47 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 11:40:47 -0700 (PDT) In-Reply-To: <4E9449F2.2000801@FreeBSD.org> References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> Date: Tue, 11 Oct 2011 14:40:47 -0400 Message-ID: From: Arnaud Lacombe To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:40:49 -0000 Hi, On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric wrote: > On 2011-10-11 15:31, Larry Rosenman wrote: >> >> On Tue, 11 Oct 2011, Dimitry Andric wrote: > > ... >>> >>> I've attached a fix for the lsof port, which also makes it build on >>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >>> hand-rolled configuration script). =A0Let me know if it works for you. >>> >> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support i= t. >> >> We need to get clang/system headers to allow warning free compilation >> just like GCC does. > > The system headers compile without warning, if you use them as intended > (e.g. from the kernel), which lsof obviously doesn't do. =A0There is no > easy workaround here, except by modifying lsof. > > For example, the warning about KASSERT is because lsof's headers don't > include the required headers for this macro. =A0And gcc is apparently not > smart enough to generate warnings for this. :) > KASSERT() (from `sys/systm.h') is kernel only, any userland code seeing it is not using the header properly. I'd be a strong proponent of: #ifdef _KERNEL #error "You are NOT meant to define _KERNEL in userland application" #endif So this has nothing to do about smartness, but correctness. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 18:52:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6543C1065670; Tue, 11 Oct 2011 18:52:27 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A48838FC30; Tue, 11 Oct 2011 18:52:26 +0000 (UTC) Received: by wwe3 with SMTP id 3so10563197wwe.31 for ; Tue, 11 Oct 2011 11:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oi/a2JQ6HcdPGcrAlpnLYfx/+CO++5kMRemY8UoWKJ4=; b=x9IPmHGJbbunOeFMKPZX3+qOdUzbueQFDDRvoa9s5SXndEDJKLm6LSsaOExK+PwPxL 39ZjDwwKVxkxoGBMZsvZlOiqmfNQtwWpKPOcgN7n4/Mu2s36yoMHxCiILN3ex3E7IC+F jFByKIQ4kXDdauXF30cnDO6HHRP9T3jqVR8rU= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr6318541wbc.49.1318359145572; Tue, 11 Oct 2011 11:52:25 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 11:52:17 -0700 (PDT) In-Reply-To: <4E948D59.5020006@lerctr.org> References: <4E942FF1.9000805@FreeBSD.org> <4E948D59.5020006@lerctr.org> Date: Tue, 11 Oct 2011 14:52:17 -0400 Message-ID: From: Arnaud Lacombe To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:52:27 -0000 Hi, On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman wrote: > On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric =A0wrot= e: >>> >>> On 2011-10-09 19:32, Larry Rosenman wrote: >>>> >>>> I had gotten a PR about sysutils/lsof not compiling with clang. =A0I h= ad >>>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>>> with the system headers. >>>> >>>> Is there a project afoot to update the system headers to make them cla= ng >>>> compilable? >>> >>> The problem isn't that clang can't compile the system headers, but >>> normally these don't get included from userspace. =A0And they certainly >>> won't work as expected when you define _KERNEL in userspace, as the lso= f >>> port foolishly does. =A0It probably can't be avoided in such a tool, >>> though. >>> >> #ifdef _KERNEL/#endif protected part of system headers shall NEVER be >> accessed by userland. It is a fault to have them present in >> /usr/include. Linux got it right there, all those part are removed >> upon headers' installation. >> >> =A0- Arnaud > > Then lsof would NOT be compilable / usable at all, as it delves into > /dev/kmem to get information. > AFAIK, Linux is capable of supporting lsof in a backward compatible manner, without exposing its internal guts. FWIW, KVM is a bad kernel/userland interface, as it does not guarantee backward compatibility. > And it **NEEDS** to know what the structures are. > No, not kernel-only structure. Now, if these structure are not meant to be kernel only, move them out of _KERNEL area, but beware of backward compatibility issue in the future. > That is unless someone(tm) writes the Kernel interfaces to get the info. > Yes, this is the core of the problem and a classical chicken/eggs problem solves the very wrongest way. At some point, I thought to modify the build system to pass kernel's headers through unifdef(1), but I quickly forgot about that: % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l 27 - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:05:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3903D106566C; Tue, 11 Oct 2011 19:05:14 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id EF4BA8FC15; Tue, 11 Oct 2011 19:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=nHtMY8FmWij98zYjmdI1uE4x52lcmXFixQ7LF3VKl3o=; b=ZXY6y+iuE7V2amZ8pGDgnMLFIapPKeg9BZvJscRP+wDvoLELYnnT8yB0+67UIJmk3hy823ugiI9WRzwim0lRUcU5GPpgbD3MpH5nRujXSSy6DD9fL5G2xPIckaLl9IMHVfoEVfdA5V/glAYwd3Oy4oyBWPRhhjpSYEtTqPjWkP8=; Received: from [32.97.110.60] (port=9002 helo=[9.41.58.142]) by thebighonker.lerctr.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDhdX-000IHC-Iz; Tue, 11 Oct 2011 14:05:13 -0500 Message-ID: <4E949351.5040904@lerctr.org> Date: Tue, 11 Oct 2011 14:04:49 -0500 From: Larry Rosenman Organization: LERCTR Consulting User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E942FF1.9000805@FreeBSD.org> <4E948D59.5020006@lerctr.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-LERCTR-Spam-Score: -2.9 (--) X-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 X-LERCTR-Spam-Report: SpamScore (-2.9/5.0) ALL_TRUSTED=-1,BAYES_00=-1.9 Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:05:14 -0000 On 10/11/2011 1:52 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman wrote: >> On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >>>> On 2011-10-09 19:32, Larry Rosenman wrote: >>>>> I had gotten a PR about sysutils/lsof not compiling with clang. I had >>>>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>>>> with the system headers. >>>>> >>>>> Is there a project afoot to update the system headers to make them clang >>>>> compilable? >>>> The problem isn't that clang can't compile the system headers, but >>>> normally these don't get included from userspace. And they certainly >>>> won't work as expected when you define _KERNEL in userspace, as the lsof >>>> port foolishly does. It probably can't be avoided in such a tool, >>>> though. >>>> >>> #ifdef _KERNEL/#endif protected part of system headers shall NEVER be >>> accessed by userland. It is a fault to have them present in >>> /usr/include. Linux got it right there, all those part are removed >>> upon headers' installation. >>> >>> - Arnaud >> Then lsof would NOT be compilable / usable at all, as it delves into >> /dev/kmem to get information. >> > AFAIK, Linux is capable of supporting lsof in a backward compatible > manner, without exposing its internal guts. > > FWIW, KVM is a bad kernel/userland interface, as it does not guarantee > backward compatibility. > >> And it **NEEDS** to know what the structures are. >> > No, not kernel-only structure. Now, if these structure are not meant > to be kernel only, move them out of _KERNEL area, but beware of > backward compatibility issue in the future. Therein lies the rub. In order to do it's job, it DOES need to grovel around in kernel only structures. > >> That is unless someone(tm) writes the Kernel interfaces to get the info. >> > Yes, this is the core of the problem and a classical chicken/eggs > problem solves the very wrongest way. > > At some point, I thought to modify the build system to pass kernel's > headers through unifdef(1), but I quickly forgot about that: > > % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l > 27 > > - Arnaud This is not going to fix things until/unless someone(tm) takes the bull by the horns, and writes a userland<->kernel interface to get ALL the data that lsof currently gathers from groveling around in /dev/kmem. I don't have the skills nor time to do that. We can go around and around on this topic, but until/unless either the clang headers/built-ins are changed to match the system/kernel headers, or someone(tm) writes the interfaces, clang will NOT be supported to compile sysutils/lsof. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:18:23 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B373106566C for ; Tue, 11 Oct 2011 19:18:23 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id 053288FC16 for ; Tue, 11 Oct 2011 19:18:22 +0000 (UTC) Received: from [77.73.27.98] (port=46651 helo=lissyara-gp.grand-prix) by mx.lissyara.su with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDhZY-000LHX-78 for freebsd-current@FreeBSD.org; Tue, 11 Oct 2011 23:01:04 +0400 Message-ID: <4E94926D.1040002@lissyara.su> Date: Tue, 11 Oct 2011 23:01:01 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.23) Gecko/20091202 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su Cc: Subject: 9.0-BETA3 - network scripts problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:18:23 -0000 I install 9.0-BETA3 i386, set next rc.conf configurations: mail# grep -E "hostname|ifconfig" /etc/rc.conf ifconfig_em0="inet 91.227.17.15 netmask 255.255.255.0" hostname="mail.AeroStarContract.ru" mail# after reboot with plugged LAN cable, I have this strange network configuration: lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a4 inet 91.227.16.17 netmask 0xff000000 broadcast 91.227.16.17 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a5 inet 91.227.16.17 netmask 0xff000000 broadcast 91.227.16.17 media: Ethernet autoselect status: no carrier ipfw0: flags=8801 metric 0 mtu 65536 if I unplug network cable and reboot - network configurations is correct: em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a4 inet 91.227.17.15 netmask 0xffffff00 broadcast 91.227.17.255 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8802 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a5 media: Ethernet autoselect status: no carrier ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 91.227.16.17 - is IP for DNS A record for mail.AeroStarContract.ru if I run /etc/rc.d/netif start with plugged cable - network configurations reset to first listing. If cable unplugged - to second. if I change hostname to non-existent: mail# grep -E "hostname|ifconfig" /etc/rc.conf ifconfig_em0="inet 91.227.17.15 netmask 255.255.255.0" hostname="mail.AeroStarContract-bad.ru" mail# reboot with/without LAN cable get good network configurations. change A DNS record for "mail.AeroStarContract.ru" from 91.227.16.17 to 91.227.16.27 get this configurations, with plugged cable: lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a4 inet 91.227.16.27 netmask 0xff000000 broadcast 91.227.16.27 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a5 inet 91.227.16.27 netmask 0xff000000 broadcast 91.227.16.27 media: Ethernet autoselect status: no carrier ipfw0: flags=8801 metric 0 mtu 65536 with unplugged - all correct. setting A record to 91.227.17.15 (as in rc.conf) get this, with plugged cable: lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a4 inet 91.227.17.15 netmask 0xff000000 broadcast 91.227.17.15 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:71:11:a5 inet 91.227.17.15 netmask 0xff000000 broadcast 91.227.17.15 media: Ethernet autoselect status: no carrier ipfw0: flags=8801 metric 0 mtu 65536 with unplugged - all correct. ============= DNS zone AeroStarContract.ru use our DNS servers, used in resolv.conf: mail# more /etc/resolv.conf nameserver 91.227.16.10 nameserver 91.227.17.11 mail# I think, it try find hostname in DNS (DNS server in some network with server) and use finded IP to set all interfaces. It's serious mistake, because I find it when server first booting and set to interface IP used in another server =)) All names, IP addresses and another information - is real. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:19:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A94B106566B for ; Tue, 11 Oct 2011 19:19:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6C48FC1F for ; Tue, 11 Oct 2011 19:19:44 +0000 (UTC) Received: by qadz30 with SMTP id z30so6706024qad.13 for ; Tue, 11 Oct 2011 12:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sQZDjH6RX9ot9irSmGDpdoYKl+Qsb0Dxc0gF8NsJPtM=; b=l9d5LJzDytbWkDAZW6RTLyksxVBhwEyIQntt/XSMvNVvzblHdyDiOIqJRBde4sutNb UJqcO2JQyGnWWdGaLEUMdvx0SfHsRqR4rXM4VACFEi/a9dZxTHOq15FpkMbd2ibSPPrd xjO2zZmuWFMSNw3OYo2gAYpmn68hA5nIFcbhk= MIME-Version: 1.0 Received: by 10.224.176.143 with SMTP id be15mr7974395qab.33.1318360783345; Tue, 11 Oct 2011 12:19:43 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Tue, 11 Oct 2011 12:19:43 -0700 (PDT) In-Reply-To: References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> Date: Tue, 11 Oct 2011 12:19:43 -0700 Message-ID: From: Garrett Cooper To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Cc: Matt Thyer , FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:19:44 -0000 On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: > On Wed, 12 Oct 2011, Matt Thyer wrote: > >> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: >>> >>> I didn't say bug for bug, just not generate stupid errors like the ffs >> >> one. >>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> >>> Chuck Swiger wrote: >>> >>> On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: >>>> >>>> We will NOT support clang as the compiler for lsof unless the system >> >> headers work the same way as gcc's do. >>> >>> That apparently means you won't support clang then, because it's not >> >> intended to be (or ever going to be) fully bug-for-bug "compatible" with >> GCC. In this case, at least, clang is reporting legitimate issues which >> should be fixed, even if folks continue to build lsof with GCC from now >> until the end of days. >> >> The elegant solution would be to avoid this problem altogether by >> re-implementation of lsof using interfaces into the kernel that provide >> the >> required information. >> >> bsdof anyone? >> > lsof is PORTABLE and available on LOTS of platforms. > > We have fstat, but lsof can be used between differing OS's. > > We've also asked for Kernel interfaces before, but no one volunteered > to make the KPI for them. > > I'm sure if someone(tm) (not me, insufficient knowledge) was > to make interfaces for ALL that lsof needs, Vic would implement it > as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:21:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C84061065672 for ; Tue, 11 Oct 2011 19:21:49 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 58C8F8FC0A for ; Tue, 11 Oct 2011 19:21:48 +0000 (UTC) Received: by wwe3 with SMTP id 3so10607108wwe.31 for ; Tue, 11 Oct 2011 12:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gb7X2rXQwMu9e2oGwUqA228vboLLDpjZkC3b+aQfiSs=; b=j/4u0cpHjn47LfUwduoJjH3cI8fD81wnBPMU+wwJ46abWOBANfacgU00hD5YGqrkjq wkFn52/VuroXTcPJEUu5bMY4VOR2cu2UddehrQhXOevALC5zt5JIg6wQR5d+s3wk5Dbh L6EKe+zluDc0Ao6CksekgBdS6AxPEnq+7ycvg= MIME-Version: 1.0 Received: by 10.227.19.210 with SMTP id c18mr8326969wbb.65.1318360908208; Tue, 11 Oct 2011 12:21:48 -0700 (PDT) Sender: r.c.ladan@gmail.com Received: by 10.180.83.130 with HTTP; Tue, 11 Oct 2011 12:21:48 -0700 (PDT) In-Reply-To: References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> Date: Tue, 11 Oct 2011 21:21:48 +0200 X-Google-Sender-Auth: _eoIh9XuWLPMFaTZWZyC1gpRako Message-ID: From: =?ISO-8859-1?Q?Ren=E9_Ladan?= To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Matt Thyer , FreeBSD current , Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:21:50 -0000 2011/10/11 Garrett Cooper : > On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: >> On Wed, 12 Oct 2011, Matt Thyer wrote: >> >>> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: >>>> >>>> I didn't say bug for bug, just not generate stupid errors like the ffs >>> >>> one. >>>> >>>> -- >>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>>> >>>> Chuck Swiger wrote: >>>> >>>> On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: >>>>> >>>>> We will NOT support clang as the compiler for lsof unless the system >>> >>> headers work the same way as gcc's do. >>>> >>>> That apparently means you won't support clang then, because it's not >>> >>> intended to be (or ever going to be) fully bug-for-bug "compatible" wit= h >>> GCC. In this case, at least, clang is reporting legitimate issues which >>> should be fixed, even if folks continue to build lsof with GCC from now >>> until the end of days. >>> >>> The elegant solution would be to avoid this problem altogether by >>> re-implementation of lsof using interfaces into the kernel that provide >>> the >>> required information. >>> >>> bsdof anyone? >>> >> lsof is PORTABLE and available on LOTS of platforms. >> >> We have fstat, but lsof can be used between differing OS's. >> >> We've also asked for Kernel interfaces before, but no one volunteered >> to make the KPI for them. >> >> I'm sure if someone(tm) (not me, insufficient knowledge) was >> to make interfaces for ALL that lsof needs, Vic would implement it >> as it would make his life easier. > > It would be nice in general if there were sysctls for accessing this > data as even utilities in base have libkvm magic sprinkled around with > pointer magic by default instead of using the sysctl analogs (I'm > referring to ifconfig, netstat, etc), and as noted by some.. using > libkvm on live memory could be potentially; the only valid usage I can > really think of is when dealing with . > > What data does Vic need to grab from the kernel in order to get the > file descriptor data? > Just a quick note that FreeBSD 9 and later also have libprocstat which could be a nice interface. I haven't looked at the details yet though. Ren=E9 From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:22:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5841065679 for ; Tue, 11 Oct 2011 19:22:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF9168FC1A for ; Tue, 11 Oct 2011 19:22:04 +0000 (UTC) Received: by qadz30 with SMTP id z30so6708840qad.13 for ; Tue, 11 Oct 2011 12:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=povrRYJJE/XwU3BU9SUqHD8aDHNVw0deXtL1Y3X+Mt0=; b=Yfk4A1nkAGa7LWrCcV+J4pquLgaKBRMkXfK1zlkCgpvDuPgOl1Mo7r1mrGmQYt80oR 5iKCb/bJWCrxZgrTRlEEVRXrqQGeqCW2OvEcEEJ4BcJ4xm7Erk9LO/DC34ocM/iKfAsS GRVv7yWA4CZyjVhMYdWd1VPKFx8yWl6hejFmE= MIME-Version: 1.0 Received: by 10.224.189.198 with SMTP id df6mr16119832qab.46.1318360924334; Tue, 11 Oct 2011 12:22:04 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Tue, 11 Oct 2011 12:22:04 -0700 (PDT) In-Reply-To: References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> Date: Tue, 11 Oct 2011 12:22:04 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric , Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:22:05 -0000 On Tue, Oct 11, 2011 at 11:40 AM, Arnaud Lacombe wrote= : > Hi, > > On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric wrote: >> On 2011-10-11 15:31, Larry Rosenman wrote: >>> >>> On Tue, 11 Oct 2011, Dimitry Andric wrote: >> >> ... >>>> >>>> I've attached a fix for the lsof port, which also makes it build on >>>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >>>> hand-rolled configuration script). =A0Let me know if it works for you. >>>> >>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support = it. >>> >>> We need to get clang/system headers to allow warning free compilation >>> just like GCC does. >> >> The system headers compile without warning, if you use them as intended >> (e.g. from the kernel), which lsof obviously doesn't do. =A0There is no >> easy workaround here, except by modifying lsof. >> >> For example, the warning about KASSERT is because lsof's headers don't >> include the required headers for this macro. =A0And gcc is apparently no= t >> smart enough to generate warnings for this. :) >> > KASSERT() (from `sys/systm.h') is kernel only, any userland code > seeing it is not using the header properly. I'd be a strong proponent > of: > > #ifdef _KERNEL > #error "You are NOT meant to define _KERNEL in userland application" > #endif > > So this has nothing to do about smartness, but correctness. net-snmp suffers from this as well because it pokes around some kernel structures and data types to gather statistics related to IPv6, routing, etc in order to fulfill MIB-II compliance. Part of the bits are present, but not all of them, and I would really like for the need to muck around in _KERNEL to go away... Similarly, we have several utilities in base that muck around in _KERNEL that really shouldn't IMHO. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:24:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E229106568D for ; Tue, 11 Oct 2011 19:24:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C06DD8FC15 for ; Tue, 11 Oct 2011 19:24:27 +0000 (UTC) Received: by qadz30 with SMTP id z30so6711643qad.13 for ; Tue, 11 Oct 2011 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gl9sPTCW3aSeoKZUQWp8NxKHA/mnTLlW8YszXKRUjpE=; b=axKfD+0b72YleT8tPbOLXM0ExFK96wTCuVjy/XYDA8tDP5i99MP13acve3i8kvm5Tv /tsN1XYElNK5Pyksweh3SCZDSr2pUkhmTjp1iVcBkgeuUZA3E4S3V/TSX05mKocrJ4Ne jfYvOZlYd9prk1vth1Rg6IFRPq3plspXYjlHU= MIME-Version: 1.0 Received: by 10.224.173.69 with SMTP id o5mr15787455qaz.7.1318361067160; Tue, 11 Oct 2011 12:24:27 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Tue, 11 Oct 2011 12:24:27 -0700 (PDT) In-Reply-To: References: <4E942FF1.9000805@FreeBSD.org> Date: Tue, 11 Oct 2011 12:24:27 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric , Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:24:28 -0000 On Tue, Oct 11, 2011 at 11:36 AM, Arnaud Lacombe wrote= : > Hi, > > On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >> On 2011-10-09 19:32, Larry Rosenman wrote: >>> >>> I had gotten a PR about sysutils/lsof not compiling with clang. =A0I ha= d >>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>> with the system headers. >>> >>> Is there a project afoot to update the system headers to make them clan= g >>> compilable? >> >> The problem isn't that clang can't compile the system headers, but >> normally these don't get included from userspace. =A0And they certainly >> won't work as expected when you define _KERNEL in userspace, as the lsof >> port foolishly does. =A0It probably can't be avoided in such a tool, tho= ugh. >> > #ifdef _KERNEL/#endif protected part of system headers shall NEVER be > accessed by userland. It is a fault to have them present in > /usr/include. Linux got it right there, all those part are removed > upon headers' installation. Yes, but instead Linux encourages mucking around with /proc and /sys, which have varying levels of formatting and provided output. The data needs to be exported properly via sysctl. If it's not done that way to userland, then the API/KPI is flawed and needs to be revised. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:28:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB1FC106564A; Tue, 11 Oct 2011 19:28:08 +0000 (UTC) (envelope-from nalitoja@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82A018FC08; Tue, 11 Oct 2011 19:28:08 +0000 (UTC) Received: by gyf2 with SMTP id 2so8788791gyf.13 for ; Tue, 11 Oct 2011 12:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version:content-type; bh=TYGWb/GassZeVGGSHiyuulvaETgQTYYNez3WUte7lJs=; b=klJP9t+m8s7dmye4nogXUHFwapP/aJ4VZOXrrJ8cMobnDMt+/IrZj3wq6sAh2a8rgO zIIqOwaIw8Mc38u526kD3NQEmv21Ut7kMl2X6TKsaQUGLmh/4kH4oh79dulYXBs2OLK3 KMN0Ivm6H83ZsTHOLMPm5u/0v4gkXOMVlYGn4= Received: by 10.42.163.4 with SMTP id a4mr13940380icy.4.1318361287665; Tue, 11 Oct 2011 12:28:07 -0700 (PDT) Received: from nil (lumumba.torservers.net. [77.247.181.163]) by mx.google.com with ESMTPS id l28sm9132987ibc.3.2011.10.11.12.27.59 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 12:28:06 -0700 (PDT) From: Nali Toja To: Doug Barton In-Reply-To: <4E935C9C.2090502@FreeBSD.org> (Doug Barton's message of "Mon, 10 Oct 2011 13:59:08 -0700") Date: Tue, 11 Oct 2011 19:27:47 +0000 Message-ID: <86y5wrnxak.fsf@gmail.com> References: <4E935C9C.2090502@FreeBSD.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: FreeBSD Current , "freebsd-ports@FreeBSD.org" Subject: Re: Patch for ports on 10-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:28:09 -0000 Doug Barton writes: > http://dougbarton.us/bam.patch [...] > +.if ${OSVERSION} >= 1000000 && !defined(NO_AUTOTOOLS_FIX) Being not limited to GNU_CONFIGURE, is it a feature? Also, there are a few ports that either set WRKSRC instead of BUILD_WRKSRC or extract several distfiles. Why not use WRKDIR then? # lang/python27, it does not use devel/libffi (ports/146823) WRKSRC/../Modules/_ctypes/libffi/configure: freebsd1*) WRKSRC/../Modules/_ctypes/libffi/configure:freebsd1*) From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:36:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50D80106564A; Tue, 11 Oct 2011 19:36:22 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id ACB2B8FC12; Tue, 11 Oct 2011 19:36:21 +0000 (UTC) Received: by wwe3 with SMTP id 3so10628311wwe.31 for ; Tue, 11 Oct 2011 12:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UvmmsbLxMQMjhlFTa1FCeVr8y6spV5pUEG3rz+D7UkY=; b=Nxtj28FKlvLBGYFcHvkHzMWzbNg4mE9XpWC+PZAssZdJCYGuBy/BLdHtM1U+HKGVSz NRnPF/cUk0DElbbmmTGjO2bXcGgoed1olkzCwpJ+Cdq7xmH6bvNDG9YEjW92F3yCuZ1w rZgoq3VZhG3rN0ZWoacaSGGprLLNO5lKSHMQA= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr6371559wbc.49.1318361780609; Tue, 11 Oct 2011 12:36:20 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 12:36:20 -0700 (PDT) In-Reply-To: References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> Date: Tue, 11 Oct 2011 15:36:20 -0400 Message-ID: From: Arnaud Lacombe To: =?ISO-8859-1?Q?Ren=E9_Ladan?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , Larry Rosenman , Matt Thyer , FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:36:22 -0000 Hi, On Tue, Oct 11, 2011 at 3:21 PM, Ren=E9 Ladan wrote: > 2011/10/11 Garrett Cooper : >> On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: >>> On Wed, 12 Oct 2011, Matt Thyer wrote: >>> >>>> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: >>>>> >>>>> I didn't say bug for bug, just not generate stupid errors like the ff= s >>>> >>>> one. >>>>> >>>>> -- >>>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>>>> >>>>> Chuck Swiger wrote: >>>>> >>>>> On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: >>>>>> >>>>>> We will NOT support clang as the compiler for lsof unless the system >>>> >>>> headers work the same way as gcc's do. >>>>> >>>>> That apparently means you won't support clang then, because it's not >>>> >>>> intended to be (or ever going to be) fully bug-for-bug "compatible" wi= th >>>> GCC. In this case, at least, clang is reporting legitimate issues whic= h >>>> should be fixed, even if folks continue to build lsof with GCC from no= w >>>> until the end of days. >>>> >>>> The elegant solution would be to avoid this problem altogether by >>>> re-implementation of lsof using interfaces into the kernel that provid= e >>>> the >>>> required information. >>>> >>>> bsdof anyone? >>>> >>> lsof is PORTABLE and available on LOTS of platforms. >>> >>> We have fstat, but lsof can be used between differing OS's. >>> >>> We've also asked for Kernel interfaces before, but no one volunteered >>> to make the KPI for them. >>> >>> I'm sure if someone(tm) (not me, insufficient knowledge) was >>> to make interfaces for ALL that lsof needs, Vic would implement it >>> as it would make his life easier. >> >> It would be nice in general if there were sysctls for accessing this >> data as even utilities in base have libkvm magic sprinkled around with >> pointer magic by default instead of using the sysctl analogs (I'm >> referring to ifconfig, netstat, etc), and as noted by some.. using >> libkvm on live memory could be potentially; the only valid usage I can >> really think of is when dealing with . >> >> What data does Vic need to grab from the kernel in order to get the >> file descriptor data? >> > Just a quick note that FreeBSD 9 and later also have libprocstat which > could be a nice interface. =A0I haven't looked at the details yet though. > libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:37:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56180106564A; Tue, 11 Oct 2011 19:37:16 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 83EDE8FC19; Tue, 11 Oct 2011 19:37:15 +0000 (UTC) Received: by wyj26 with SMTP id 26so11620900wyj.13 for ; Tue, 11 Oct 2011 12:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=y2MFWDonDiyBm3/ThYDhfwjNhwVH0kiCzs49RjFYd30=; b=TDn6ccTpO8XeHKY4HvM7R6mq4ocCnvbi/oUW1wn35uG+mN7+ld0WuGOiWlSo/Ic6Qp OunP2cv7BL2UNyRZvxiUpxTD0cOCH8j9OD4uA1JaEDr/9baZ7UlRamUemW+dewJxbNTj EztwLtxdMn2M7ew1fLW9AC3rlugbyhksSNHZE= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr6372613wbc.49.1318361834530; Tue, 11 Oct 2011 12:37:14 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 12:37:14 -0700 (PDT) In-Reply-To: <4E949351.5040904@lerctr.org> References: <4E942FF1.9000805@FreeBSD.org> <4E948D59.5020006@lerctr.org> <4E949351.5040904@lerctr.org> Date: Tue, 11 Oct 2011 15:37:14 -0400 Message-ID: From: Arnaud Lacombe To: Larry Rosenman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:37:16 -0000 Hi, On Tue, Oct 11, 2011 at 3:04 PM, Larry Rosenman wrote: > On 10/11/2011 1:52 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman =A0wrote= : >>> >>> On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: >>>> >>>> Hi, >>>> >>>> On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric >>>> =A0wrote: >>>>> >>>>> On 2011-10-09 19:32, Larry Rosenman wrote: >>>>>> >>>>>> I had gotten a PR about sysutils/lsof not compiling with clang. =A0I= had >>>>>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>>>>> with the system headers. >>>>>> >>>>>> Is there a project afoot to update the system headers to make them >>>>>> clang >>>>>> compilable? >>>>> >>>>> The problem isn't that clang can't compile the system headers, but >>>>> normally these don't get included from userspace. =A0And they certain= ly >>>>> won't work as expected when you define _KERNEL in userspace, as the >>>>> lsof >>>>> port foolishly does. =A0It probably can't be avoided in such a tool, >>>>> though. >>>>> >>>> #ifdef _KERNEL/#endif protected part of system headers shall NEVER be >>>> accessed by userland. It is a fault to have them present in >>>> /usr/include. Linux got it right there, all those part are removed >>>> upon headers' installation. >>>> >>>> =A0- Arnaud >>> >>> Then lsof would NOT be compilable / usable at all, as it delves into >>> /dev/kmem to get information. >>> >> AFAIK, Linux is capable of supporting lsof in a backward compatible >> manner, without exposing its internal guts. >> >> FWIW, KVM is a bad kernel/userland interface, as it does not guarantee >> backward compatibility. >> >>> And it **NEEDS** to know what the structures are. >>> >> No, not kernel-only structure. Now, if these structure are not meant >> to be kernel only, move them out of _KERNEL area, but beware of >> backward compatibility issue in the future. > > Therein lies the rub. =A0In order to do it's job, it DOES need to grovel > around in kernel only structures. > > >> >>> That is unless someone(tm) writes the Kernel interfaces to get the info= . >>> >> Yes, this is the core of the problem and a classical chicken/eggs >> problem solves the very wrongest way. >> >> At some point, I thought to modify the build system to pass kernel's >> headers through unifdef(1), but I quickly forgot about that: >> >> % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l >> =A0 =A0 =A0 27 >> >> =A0- Arnaud > > This is not going to fix things until/unless someone(tm) takes the bull b= y > the horns, and writes > a userland<->kernel interface to get ALL the data that lsof currently > gathers from groveling around > in /dev/kmem. > > I don't have the skills nor time to do that. > What are those interfaces exactly ? How is it done in Linux ? Thanks, - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:42:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25A55106566B for ; Tue, 11 Oct 2011 19:42:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id EC8A78FC1D for ; Tue, 11 Oct 2011 19:42:34 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9BJgPLb017753 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 12:42:27 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E949C26.4070105@freebsd.org> Date: Tue, 11 Oct 2011 12:42:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Garrett Cooper , =?ISO-8859-1?Q?Ren=E9_Ladan?= , Matt Thyer , FreeBSD current , Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:42:39 -0000 On 10/11/11 12:36 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 3:21 PM, René Ladan wrote: >> 2011/10/11 Garrett Cooper: >>> On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: >>>> On Wed, 12 Oct 2011, Matt Thyer wrote: >>>> >>>>> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: >>>>>> I didn't say bug for bug, just not generate stupid errors like the ffs >>>>> one. >>>>>> -- >>>>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>>>>> >>>>>> Chuck Swiger wrote: >>>>>> >>>>>> On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: >>>>>>> We will NOT support clang as the compiler for lsof unless the system >>>>> headers work the same way as gcc's do. >>>>>> That apparently means you won't support clang then, because it's not >>>>> intended to be (or ever going to be) fully bug-for-bug "compatible" with >>>>> GCC. In this case, at least, clang is reporting legitimate issues which >>>>> should be fixed, even if folks continue to build lsof with GCC from now >>>>> until the end of days. >>>>> >>>>> The elegant solution would be to avoid this problem altogether by >>>>> re-implementation of lsof using interfaces into the kernel that provide >>>>> the >>>>> required information. >>>>> >>>>> bsdof anyone? >>>>> >>>> lsof is PORTABLE and available on LOTS of platforms. >>>> >>>> We have fstat, but lsof can be used between differing OS's. >>>> >>>> We've also asked for Kernel interfaces before, but no one volunteered >>>> to make the KPI for them. >>>> >>>> I'm sure if someone(tm) (not me, insufficient knowledge) was >>>> to make interfaces for ALL that lsof needs, Vic would implement it >>>> as it would make his life easier. >>> It would be nice in general if there were sysctls for accessing this >>> data as even utilities in base have libkvm magic sprinkled around with >>> pointer magic by default instead of using the sysctl analogs (I'm >>> referring to ifconfig, netstat, etc), and as noted by some.. using >>> libkvm on live memory could be potentially; the only valid usage I can >>> really think of is when dealing with . >>> >>> What data does Vic need to grab from the kernel in order to get the >>> file descriptor data? >>> >> Just a quick note that FreeBSD 9 and later also have libprocstat which >> could be a nice interface. I haven't looked at the details yet though. >> > libprocstat is _itself_ a problem: > > % git grep 'define _KERNEL' . > [...] > lib/libprocstat/cd9660.c:#define _KERNEL > lib/libprocstat/nwfs.c:#define _KERNEL > lib/libprocstat/smbfs.c:#define _KERNEL > lib/libprocstat/udf.c:#define _KERNEL > lib/libprocstat/zfs.c:#define _KERNEL > [...] > > ok, I admit this is all FS related stuff :) but at least it comes with the system so it matches. we've been looking for the 'right' way to do this since, hmmm, 1988 that I remember and I bet before that too. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 19:57:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123D010656D0; Tue, 11 Oct 2011 19:57:55 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8D58FC1A; Tue, 11 Oct 2011 19:57:54 +0000 (UTC) Received: by wwn22 with SMTP id 22so5707936wwn.1 for ; Tue, 11 Oct 2011 12:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cQJQlqu3TBmIX/dvGcOHSErGllv4cVfBtOFivShVock=; b=kKHsixgR7UVLJYPaMx1+Pc1zWafyRmlFQLL8+ijDjJfW976DxG/PnNv4bNPNTRjsX5 XGnWbHPMN3KRNSaZQpHpZTf/GJnSqItwkXQmFu59+A6ZOx3FX7hhDIC07de4UWrq3DIe jFsYbd6fDu0GHpnOseB/cufXFF5vt287aXCYM= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr6396692wbc.49.1318363073415; Tue, 11 Oct 2011 12:57:53 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 12:57:53 -0700 (PDT) In-Reply-To: <4E949C26.4070105@freebsd.org> References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> <4E949C26.4070105@freebsd.org> Date: Tue, 11 Oct 2011 15:57:53 -0400 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:57:55 -0000 Hi, On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer wrote: > On 10/11/11 12:36 PM, Arnaud Lacombe wrote: >>> [...] >> libprocstat is _itself_ a problem: >> >> % git grep 'define _KERNEL' . >> [...] >> lib/libprocstat/cd9660.c:#define _KERNEL >> lib/libprocstat/nwfs.c:#define _KERNEL >> lib/libprocstat/smbfs.c:#define _KERNEL >> lib/libprocstat/udf.c:#define _KERNEL >> lib/libprocstat/zfs.c:#define _KERNEL >> [...] >> >> ok, I admit this is all FS related stuff :) > > but at least it comes with the system so it matches. > no, you should be able to run a FreeBSD 1.0 userland and a 9-RELEASE kernel together and have all utilities working. If not, you cannot claim to support backward compatibility, even if you do on a subset of kernel/userland interface. That said, this is just my personal opinion. > we've been looking for the 'right' way to do this since, hmmm, 1988 that I > remember and I bet before that too. > then the job was done bad. I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 kernel on a 4 years old openwrt image and still had a functional system. Comparatively, I could not mix FreeBSD 7-STABLE userland and 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to make FreeBSD 7 unable to boot (even single user). Let me emphasize again that it is only my personal opinion :-) - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 20:09:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C92D106566B; Tue, 11 Oct 2011 20:09:32 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A017B8FC15; Tue, 11 Oct 2011 20:09:31 +0000 (UTC) Received: by wyj26 with SMTP id 26so11673272wyj.13 for ; Tue, 11 Oct 2011 13:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dT54qadGFFLWm52J0ny6hhNUUFr8LWv3pxNIbBfGtGo=; b=uiWT/cv66f2MCM5cQwJNyAIHAyiNMgf5sZE117eDIp59ZPe85sXFKjfn5QftwHiCHW VClrM0kHmMHbqUby5w6mvLxqLxe/2YqZQpNb/GySzTL08nUQW8WAkeH+r/jwqewQHjT8 AXtAVfMAS82czVFCCVoJWxyTTaJL8/u0xLEqU= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr6409728wbc.49.1318363770784; Tue, 11 Oct 2011 13:09:30 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 13:09:30 -0700 (PDT) In-Reply-To: References: <4E942FF1.9000805@FreeBSD.org> Date: Tue, 11 Oct 2011 16:09:30 -0400 Message-ID: From: Arnaud Lacombe To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-current@freebsd.org, Dimitry Andric , Larry Rosenman Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 20:09:32 -0000 Hi, On Tue, Oct 11, 2011 at 3:24 PM, Garrett Cooper wrote: > On Tue, Oct 11, 2011 at 11:36 AM, Arnaud Lacombe wro= te: >> Hi, >> >> On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >>> On 2011-10-09 19:32, Larry Rosenman wrote: >>>> >>>> I had gotten a PR about sysutils/lsof not compiling with clang. =A0I h= ad >>>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>>> with the system headers. >>>> >>>> Is there a project afoot to update the system headers to make them cla= ng >>>> compilable? >>> >>> The problem isn't that clang can't compile the system headers, but >>> normally these don't get included from userspace. =A0And they certainly >>> won't work as expected when you define _KERNEL in userspace, as the lso= f >>> port foolishly does. =A0It probably can't be avoided in such a tool, th= ough. >>> >> #ifdef _KERNEL/#endif protected part of system headers shall NEVER be >> accessed by userland. It is a fault to have them present in >> /usr/include. Linux got it right there, all those part are removed >> upon headers' installation. > > Yes, but instead Linux encourages mucking around with /proc and /sys, > which have varying levels of formatting and provided output. > At least, interfaces exist (/proc and /sys) and the data are formatted enough (ASCII text) to abstract the underlying binary format. > The data needs to be exported properly via sysctl. If it's not done > that way to userland, then the API/KPI is flawed and needs to be > revised. > just exporting raw data would not do the job; it can already be done with KVM. What is needed is a defined ABI (ie. interface, data and format) between the kernel and userland. I'm not even considering it being stable for now, this would be the subject of another thread. NetBSD has done the interesting move of using property list for kernel/userland structure encoding. I haven't looked for a while so I'm not sure how much interface are now using them. - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 20:14:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0939106564A for ; Tue, 11 Oct 2011 20:14:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9B188FC13 for ; Tue, 11 Oct 2011 20:14:21 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6790E46B17; Tue, 11 Oct 2011 16:14:21 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F33A68A02E; Tue, 11 Oct 2011 16:14:20 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 11 Oct 2011 16:09:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E9017E8.4070900@restart.be> In-Reply-To: <4E9017E8.4070900@restart.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110111609.44187.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 11 Oct 2011 16:14:21 -0400 (EDT) Cc: Henri Hennebert Subject: Re: 9.0-BETA3 (r225759) without ACPI raise a page fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 20:14:22 -0000 On Saturday, October 08, 2011 5:29:12 am Henri Hennebert wrote: > Hello, > > On my configuration, If I boot 9.0-BETA3 (r225759) without ACPI, the > kernel encounter a page fault before the end of the boot. > > A photo of the screen can be found at: > > http://verbier.restart.be/xfer/dsc00042.jpg This is likely an old bug (since 5.0) where the PnP BIOS of some machines does causes a GP# during boot. You will just have to use ACPI (it is more accurate for modern systems anyway). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 20:19:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47EE6106566B for ; Tue, 11 Oct 2011 20:19:43 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id AC0AB8FC13 for ; Tue, 11 Oct 2011 20:19:42 +0000 (UTC) Received: (qmail invoked by alias); 11 Oct 2011 19:53:00 -0000 Received: from f055002131.adsl.alicedsl.de (EHLO mandree.no-ip.org) [78.55.2.131] by mail.gmx.net (mp012) with SMTP; 11 Oct 2011 21:53:00 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1++yDNkK9y+zPhd2aiwKAre9YpG0cVU8xJAMCKeej 6uMLOTijaNBc+4 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 640AF23CE69 for ; Tue, 11 Oct 2011 21:52:59 +0200 (CEST) Message-ID: <4E949E9B.2030407@gmx.de> Date: Tue, 11 Oct 2011 21:52:59 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Mnenhy/0.8.3 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E942FF1.9000805@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 20:19:43 -0000 Am 11.10.2011 15:31, schrieb Larry Rosenman: > On Tue, 11 Oct 2011, Dimitry Andric wrote: > >> On 2011-10-09 19:32, Larry Rosenman wrote: >>> I had gotten a PR about sysutils/lsof not compiling with clang. I had >>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>> with the system headers. >>> >>> Is there a project afoot to update the system headers to make them clang >>> compilable? >> >> The problem isn't that clang can't compile the system headers, but >> normally these don't get included from userspace. And they certainly >> won't work as expected when you define _KERNEL in userspace, as the lsof >> port foolishly does. It probably can't be avoided in such a tool, >> though. Point #1: some of the headers have special requirements, like inclusion order, or thereabouts. Since these are kernel headers, you need to abide by their rules. Violated here: >> >> >> ... >>> In file included from ckkv.c:43: >>> In file included from ./../lsof.h:195: >>> In file included from ./../dlsof.h:190: >>> In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36: >>> /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of >>> function 'KASSERT' is invalid in C99 >>> [-Wimplicit-function-declaration] >>> KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", >>> bp)); >>> ^ I *suppose* KASSERT is meant as a macro, but even if it's not, ... >>> /usr/src/sys/sys/buf.h:388:33: warning: expression result unused >>> [-Wunused-value] >>> KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", >>> bp)); >>> ^~~~~~~~~~~~~~~~~~~~~~~~~ >> >> These are more or less harmless warnings, as long as nobody calls a >> function that uses KASSERT. They occur because lsof's headers don't >> include and before . ...I'd say that's an lsof, rather than kernel or clang, bug. >> >> ... >>> In file included from ckkv.c:43: >>> In file included from ./../lsof.h:195: >>> In file included from ./../dlsof.h:432: >>> In file included from /usr/include/string.h:45: >>> /usr/include/strings.h:47:6: error: conflicting types for >>> '__builtin_ffs' >>> int ffs(int) __pure2; >>> ^ >>> /usr/include/machine/cpufunc.h:140:24: note: expanded from: >>> #define ffs(x) __builtin_ffs(x) >>> ^ >>> /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with >>> type 'int (unsigned int)' >> >> This is because the amd64 system headers redefine ffs to __builtin_ffs, >> after which it conflicts with the declaration in /usr/include/strings.h. >> On i386, ffs is not redefined, but I have no idea why. Arguably __builtin_ffs() is inconsistently defined if it expects an unsigned int argument. POSIX demands int for ffs()'s argument. The builtin should match that. I can't currently point fingers at the culprit for lack of research/information. Chances are -fno-builtin helps. > We need to get clang/system headers to allow warning free compilation > just like GCC does. Then make sure that your code is correct. NOTE: GCC defaults to C89 with GNU extensions, clang defaults to C99. To know how GCC treats your code in C99 mode, try gcc -pedantic-error -std=c99 (or possibly -pedantic without -error suffix if there are bogus warnings) and see if it's really clang -- or rather the code... You can override options for either in the port, see http://wiki.freebsd.org/PortsAndClang#Problems_with_fixes and look for USE_CSTD. It won't make your (Vic's) code future proof, but may help for the nonce - or not. Of course Vic is free in writing arbitrarily nonportable code, but before he or you go(es) pointing fingers, check if you're using kernel headers properly and requesting compilation in the right language, and if the code is actually conformant. From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 21:00:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFEA71065675 for ; Tue, 11 Oct 2011 21:00:45 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from mx.lissyara.su (mx.lissyara.su [91.227.18.11]) by mx1.freebsd.org (Postfix) with ESMTP id C80DE8FC19 for ; Tue, 11 Oct 2011 21:00:44 +0000 (UTC) Received: from [79.164.50.20] (port=57443 helo=dc7700p.lissyara.su) by mx.lissyara.su with esmtpa (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDjRJ-000EcK-Vx for freebsd-current@FreeBSD.org; Wed, 12 Oct 2011 01:00:42 +0400 Message-ID: <4E94AE78.9020708@lissyara.su> Date: Wed, 12 Oct 2011 01:00:40 +0400 From: Alex Keda User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <4E94926D.1040002@lissyara.su> In-Reply-To: <4E94926D.1040002@lissyara.su> Content-Type: multipart/mixed; boundary="------------060305070409010703070200" X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: mx.lissyara.su Cc: Subject: Re: 9.0-BETA3 - network scripts problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 21:00:46 -0000 This is a multi-part message in MIME format. --------------060305070409010703070200 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit 11.10.2011 23:01, Alex Keda ïèøåò: > I install 9.0-BETA3 i386, set next rc.conf configurations: > mail# grep -E "hostname|ifconfig" /etc/rc.conf > ifconfig_em0="inet 91.227.17.15 netmask 255.255.255.0" > hostname="mail.AeroStarContract.ru" > mail# I have run tcpdump, when I run /etc/rc.d/netif start with plugged cable (IP configurations is good, because I boot with unplugged cable) some questions to DNS server is strange > ifdisabled.AeroStarContract.ru: type A, class IN after answer to this questions (answer return: 91.227.16.17), interface have address 91.227.16.17 (bad address, used on another server). before - address from rc.conf - 91.227.17.15 tctpdump in attached file --------------060305070409010703070200 Content-Type: application/octet-stream; name="dump.tcp2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dump.tcp2" 1MOyoQIABAAAAAAAAAAAABAnAAABAAAATXmMTshMAwA+AAAAPgAAAAAwSHERpAALRRz0GggA RQAAMHo7QAB3Bh9evKNBl1vjEBHoEgBQb6pGTQAAAABwAiAAWvoAAAIEBVABAQQCTXmMTiNS AwA8AAAAPAAAAAAwSHERpAALRRz0GggARQAAKFHuQAB5Boc9LkiOaFvjEBHMjwBQN+sCSzfr AktQBAAARfAAAAAAAAAAAE15jE4kZgMAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADAuFkAA eQY2QlZq2xFb4xARBvQAULtTbO0AAAAAcAL//7YqAAACBAW0AQEEAk15jE79DQQASgAAAEoA AAAAMEhxEaQAC0Uc9BoIAEUAADy0mkAAOQbdWVDv8uRb4xARgx0AUEnbsjkAAAAAoAIW0JZk AAACBAW0BAIIClwWD2sAAAAAAQMDB015jE5dOwQAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADDDoEAAfAb+UFvadQhb4xAR4PkAUDH1SlQAAAAAcAL//+i1AAACBAW0AQEEAk15jE5sYQQA SgAAAEoAAAAAMEhxEaQAC0Uc9BoIAEUAADxK+0AANQYfptA1nvFb4xARgs8AUJbM71wAAAAA oAIW0J/wAAACBAW0BAIICgc0pacAAAAAAQMDB015jE4VbwQAPAAAADwAAAAAMEhxEaQAC0Uc 9BoIAEUAACjmQ0AAdwYoL1+HKeJb4xAREJ8AUFiyho6EUc8RUBD9LXm2AAAAAAAAAABNeYxO lZcEAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwCtNAAHUGxplfOmktW+MQEcSIABl8tLXY AAAAAHACIAA3qQAAAgQFoAEBBAJNeYxOfRQFAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAw Ia9AAHQGBWNZ3xnjW+MQEd5eEVxNHAGCAAAAAHAC//9lEAAAAgQFtAEBBAJNeYxO8xUFAMMA AADDAAAAADBIcRGkADBIgvksCABFAAC1HjcAAEARhCBb4xAKW+MQEQA1UHkAoa1taTuFgAAB AAIAAgACC2Jlc3QtY2hhbmdlAnJ1CWhvc3QtZm9vZAJydQAAAQABwAwABQABAAAOEAAKB3Rl c3QtaGbAJcA5AAEAAQAADhAABFvjEAvAOQACAAEAAA4QAAcEZG5zMMAbwDkAAgABAAAOEAAH BGRuczHAG8BfAAEAAQAADhAABFvjEArAcgABAAEAAA4QAARb4xELTXmMTskwBQCuAAAArgAA AAAwSHERpAAwSIL5LAgARQAAoB45AABAEYQzW+MQClvjEBEANXykAIws9OkkhYAAAQABAAIA Ag9tb25pdG9yaW5nLWNzMTYCcnUAAAEAAcAMAAEAAQAADhAABFvjEBHADAACAAEAAA4QABEE ZG5zMQlob3N0LWZvb2TAHMAMAAIAAQAADhAABwRkbnMwwEXAXQABAAEAAA4QAARb4xAKwEAA AQABAAAOEAAEW+MRC015jE4DUAUAhwAAAIcAAAAAMEhxEaQAMEiC+SwIAEUAAHkeOgAAQBGE WVvjEApb4xARADVScABlwBPF0IWAAAEAAAABAAALYmVzdC1jaGFuZ2UCcnUAABwAAcAMAAYA AQAADhAAMQRkbnMwCWhvc3QtZm9vZMAYBHJvb3QEc3J2N8Axd93q7wAAKjAAAA4QAAk6gAAB UYBNeYxO234FAMsAAADLAAAAADBIcRGkADBIgvlsCABFAAC90J0AAEAR0LBb4xELW+MQEQA1 w+kAqQULaiCFgAABAAIAAgACA3d3dwVzcGVjMwlpbnRlcnN0b2wCcnUJaG9zdC1mb29kAnJ1 AAABAAHADAAFAAEAAA4QAAoHdGVzdC1oZsAtwEEAAQABAAAOEAAEW+MQC8BBAAIAAQAADhAA BwRkbnMwwCPAQQACAAEAAA4QAAcEZG5zMcAjwGcAAQABAAAOEAAEW+MQCsB6AAEAAQAADhAA BFvjEQtNeYxO734FAEYAAABGAAAAADBIgvlsADBIcRGkCABFAAA4TxkAAEABUspb4xARW+MR CwMDMyoAAAAARQAAvdCdAABAEdCwW+MRC1vjEBEANcPpAKkFC015jE6+qwUAQgAAAEIAAAAA MEhxEaQAC0Uc9BoIAEUAADScxEAAegaBRlvLGvpb4xARDRYAUEnp/5wAAAAAgAL//zVyAAAC BAW0AQMDAQEBBAJNeYxOPuoFAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwxx1AAHkGU71f 3RscW+MQERKEAFDle1PuAAAAAHAC//9QCAAAAgQFoAEBBAJNeYxOpAAGAKwAAACsAAAAADBI cRGkADBIgvksCABFAACeHkUAAEARhClb4xAKW+MQEQA1xfYAiie7GgSFgAABAAEAAgACDXJl bGF4LW1vbml0b3ICcnUAAAEAAcAMAAEAAQAADhAABFvjEBHADAACAAEAAA4QABEEZG5zMQlo b3N0LWZvb2TAGsAMAAIAAQAADhAABwRkbnMwwEPAWwABAAEAAA4QAARb4xAKwD4AAQABAAAO EAAEW+MRC015jE4XKwYArQAAAK0AAAAAMEhxEaQAMEiC+SwIAEUAAJ8eSgAAQBGEI1vjEApb 4xARADWVOQCLo6vmVoWAAAEAAQACAAIOYnJpdHZhLXByb2plY3QCcnUAAAEAAcAMAAEAAQAA DhAABFvjEBHADAACAAEAAA4QABEEZG5zMAlob3N0LWZvb2TAG8AMAAIAAQAADhAABwRkbnMx wETAPwABAAEAAA4QAARb4xAKwFwAAQABAAAOEAAEW+MRC015jE6gjgYAPgAAAD4AAAAAMEhx EaQAC0Uc9BoIAEUAADA1HEAAeAY0aNl2U9lb4xARNUQAUJ39H/8AAAAAcAIgANaGAAACBAV4 AQEEAk15jE4WkAYAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADB9qUAAewa/6G1W6Otb4xAR 9v0AUMgoMcIAAAAAcAIgAK+wAAACBAW0AQEEAk15jE6NkQYAPAAAADwAAAD///////8AC0Uc 9BoIBgABCAAGBAABAAtFHPQaW+MRAQAAAAAAAFvjEY4AAAAAAAAAAAAAAAAAAAAAAABNeYxO SZwGAIYAAACGAAAAADBIcRGkADBIgvksCABFAAB4HlAAAEARhERb4xAKW+MQEQA1Xr0AZG+p cgGFgAABAAAAAQAAA3d3dwZtc2ttb24CcnUAABwAAcAQAAYAAQAADhAAMQRkbnMwCWhvc3Qt Zm9vZMAXBHJvb3QEc3J2N8Awd96AJwAAKjAAAA4QAAk6gAABUYBNeYxOza8GAEoAAABKAAAA ADBIcRGkAAtFHPQaCABFAAA8OZ1AADEG7XxDw3LrW+MQEbFdAFB3kQLPAAAAAKACFtD3sgAA AgQFtAQCCAqMTV5+AAAAAAEDAwhNeYxO1jsHAEIAAABCAAAAADBIcRGkADBIgvlsCABFAAA0 0KtAAEAGkjZb4xALW+MQEQBQx/e9+WHj+w0FoIAS//+vUQAAAgQFtAEDAwMEAgAATXmMTr0/ BwA8AAAAPAAAAAAwSHERpAALRRz0GggARQAAKP7rAADrBgFWOrso31vjEBF0IQAZRFaPCAAA AABQBP//mLkAAAAAAAAAAE15jE7wsAcAVQAAAFUAAAAAMEhxEaQAMEiC+WwIAEUAAEfQsAAA QBHRE1vjEQtb4xARzRMANQAzSuyHfAAAAAEAAAAAAAELcmVwZXRpdG9yNzMCcnUAAAYAAQAA KQgAAAAAAAAATXmMTgaxBwBGAAAARgAAAAAwSIL5bAAwSHERpAgARQAAOE8jAABAAVLAW+MQ EVvjEQsDA+SUAAAAAEUAAEfQsAAAQBHRE1vjEQtb4xARzRMANQAzSuxNeYxO1rQHAGIAAABi AAAAADBIcRGkAAtFHPQaCABFAABUTI4AADcBFcDDXfELW+MRDwgAWVeYuXcDTox5ZgAI2+0I CQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1NjdNeYxOFokI AJoAAACaAAAAADBIcRGkADBIgvksCABFAACMHmoAAEARhBZb4xAKW+MQEQA145EAeCeXnEiB gAABAAIAAgAAA3d3dwRzcGVjCWludGVyc3RvbAJydQAAAQABwAwABQABAAOOhgACwBDAEAAB AAEAA46GAARZvGVlwBUAAgABAAOOhgANA25zMQZtci13ZWLAH8AVAAIAAQADjoYABgNuczLA VU15jE6bsAgAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBDKUAAdgbEUc8uwipb4xARNnQA UDdHLYEAAAAAcAIgAMpFAAACBAW0AQEEAk15jE7r4QgASgAAAEoAAAAAMEhxEaQAC0Uc9BoI AEUAADypN0AAMQaA9kPDb9db4xAR24sAUJS2j44AAAAAoAIW0G0fAAACBAW0BAIIClp6SeYA AAAAAQMDCE15jE7S5QgASgAAAEoAAAAAMEhxEaQAC0Uc9BoIAEUAADwt1UAAMQb8WEPDb9db 4xAR24oAUJReC2wAAAAAoAIW0PGbAAACBAW0BAIIClp6SeUAAAAAAQMDCE15jE4yJgkAPgAA AD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBS6AAAegY0GtVPeIJb4xARifoAUJ0zLcoAAAAAcAJA ADQRAAACBAW0AQEEAk15jE70qAkAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADASXkAAdAYU t1nfGeBb4xARCf4RXGjD7PMAAAAAcAL//zJbAAACBAW0AQEEAk15jE5YrQkASgAAAEoAAAAA MEhxEaQAC0Uc9BoIAEUAADwTrUAAOQb0rU4vfz5b4xARlHsAUG89oWkAAAAAoAIW0IoCAAAC BAW0BAIIChRps/EAAAAAAQMDBk15jE5b1QkAkQAAAJEAAAAAMEhxEaQAC0Uc9BoIAEUAAIMY UAAAeRFah9RMjlJb4xARgj2yPgBv0OX/////STBwdWJsaWMuY3MtdG1uLnJ1IFtTVEVBTV0A ZGVfZHVzdDJfMngyAGNzdHJpa2UAQ291bnRlci1TdHJpa2UACgAQFQBkdwABMS4xLjIuNgCR PYIAdMuFugpAAQoAAAAAAAAATXmMTmlMCgBCAAAAQgAAAAAwSHERpAAwSIL5bAgARQAANNDE QABABpIdW+MQC1vjEBEAUMf3vflh4/sNBaCAEv//r1EAAAIEBbQBAwMDBAIAAE15jE5miQoA SgAAAEoAAAAAMEhxEaQAC0Uc9BoIAEUQADyeIUAAOgZ1w8HI/wpb4xARAFDCntfNauanaiNZ oBIgAO6BAAACBAW0AQMDAwQCCAqMExKrGg+Ddk15jE63kAoAEQEAABEBAAAAMEhxEaQAC0Uc 9BoIAEUAAQPEPAAAdhH8VLyGWt5b4xARaYicRQDv7lL/////UkwgMTAvMDUvMjAxMSAtIDE5 OjM2OjA0OiAiS2FkZGFmaSBpcyBKZXN1czwyMTY+PFNURUFNXzA6MDo2OTgyNDc5NTg+PFRF UlJPUklTVD4iIGF0dGFja2VkICJ6b21iaWXihKI8MjM4PjxTVEVBTV8wOjA6MTIwMzA0NzUz NT48Q1Q+IiB3aXRoICJtNGExIiAoZGFtYWdlICIyMiIpIChkYW1hZ2VfYXJtb3IgIjQiKSAo aGVhbHRoICI5OTAiKSAoYXJtb3IgIjk1IikgKGhpdGdyb3VwICJjaGVzdCIpCgBNeYxO67AK AEYAAABGAAAAADBIcRGkAAtFHPQaCABFAAA497pAAD0GenDZRYZbW+MQEdnuAFC3FvVEAAAA AJACFtCSNgAAAgQFtAQCCAo6tCYkAAAAAE15jE51wwoAQgAAAEIAAAAAMEhxEaQAC0Uc9BoI AEUAADRLZUAAdwYT8bJfhhpb4xAR6VMAUHCq6gkAAAAAgAIgAGZkAAACBAWgAQMDAgEBBAJN eYxOpnELAEIAAABCAAAAADBIcRGkADBIgvlsCABFAAA00MtAAEAGkhZb4xALW+MQEQBQQeLk 1NxvwHPi8YAS///xRwAAAgQFtAEDAwMEAgAATXmMTu2iCwA+AAAAPgAAAAAwSHERpAALRRz0 GggARQIAMGBBQAB4BiK92ZY6PVvjEBEGMQBQHu/spQAAAABwAkAAseEAAAIEBRQBAQQCTXmM TiauCwARAQAAEQEAAAAwSHERpAALRRz0GggARQABA8SEAAB2EfwMvIZa3lvjEBFpiJxFAO/m Wv////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDQ6ICJLYWRkYWZpIGlzIEplc3VzPDIxNj48 U1RFQU1fMDowOjY5ODI0Nzk1OD48VEVSUk9SSVNUPiIgYXR0YWNrZWQgInpvbWJpZeKEojwy Mzg+PFNURUFNXzA6MDoxMjAzMDQ3NTM1PjxDVD4iIHdpdGggIm00YTEiIChkYW1hZ2UgIjIy IikgKGRhbWFnZV9hcm1vciAiNCIpIChoZWFsdGggIjk2OCIpIChhcm1vciAiOTAiKSAoaGl0 Z3JvdXAgImNoZXN0IikKAE15jE5azgsAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUCADBgSUAA eAYitdmWOj1b4xARBjQAUPbbuR8AAAAAcAJAAA14AAACBAUUAQEEAk15jE5lzgsAPgAAAD4A AAAAMEhxEaQAC0Uc9BoIAEUCADBgSkAAeAYitNmWOj1b4xARBjUAUNtKXK0AAAAAcAJAAIV6 AAACBAUUAQEEAk15jE7K0AsAPAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUAACio00AAPAbu0VBM 6upb4xARltAAUGg3iPIAAAAAUAQAAIBrAAAAAAAAAABNeYxOSUoMAD4AAAA+AAAAADBIcRGk AAtFHPQaCABFAAAwVzhAAHgGO9xZvaoCW+MQEdwiAFBWADEEAAAAAHACIACP9AAAAgQFtAEB BAJNeYxOusUMAEYAAABGAAAAADBIcRGkAAtFHPQaCABFAAA45GpAAD0GjcDZRYZbW+MQEd1u AFC3n8LGAAAAAJACFtDAIwAAAgQFtAQCCAo6tCasAAAAAE15jE4VNw4AQgAAAEIAAAAAMEhx EaQAC0Uc9BoIAEUAADQ69EAAcAangClOkw1b4xARQvEAUNrf/oQAAAAAgAIgAAo3AAACBAWY AQMDCAEBBAJNeYxOgnYOABABAAAQAQAAADBIcRGkAAtFHPQaCABFAAECxScAAHYR+2q8hlre W+MQEWmInEUA7jNE/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNDogIkthZGRhZmkgaXMg SmVzdXM8MjE2PjxTVEVBTV8wOjA6Njk4MjQ3OTU4PjxURVJST1JJU1Q+IiBhdHRhY2tlZCAi em9tYmll4oSiPDIzOD48U1RFQU1fMDowOjEyMDMwNDc1MzU+PENUPiIgd2l0aCAibTRhMSIg KGRhbWFnZSAiMjIiKSAoZGFtYWdlX2FybW9yICI0IikgKGhlYWx0aCAiNzgiKSAoYXJtb3Ig Ijg1IikgKGhpdGdyb3VwICJjaGVzdCIpCgBNeYxOS5MOAD4AAAA+AAAAADBIcRGkAAtFHPQa CABFCAAwW5BAAHkGFiRSkNGHW+MQEfuNAFAvTj7mAAAAAHACIABpAQAAAgQFtAEBBAJOeYxO 5KEAAK8AAACvAAAAADBIcRGkAAtFHPQaCABFAAChxYEAAHYR+3G8hlreW+MQEWmInEUAjbSl /////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNDogV29ybGQgdHJpZ2dlcmVkICJraWxsbG9j YXRpb24iIChhdHRhY2tlcl9wb3NpdGlvbiAiLTYwOCAxOTA3IC0xMjEiKSAodmljdGltX3Bv c2l0aW9uICItMTY2IDIxMzcgLTYwIikKAE55jE4iogAAlgAAAJYAAAAAMEhxEaQAC0Uc9BoI AEUAAIjFggAAdhH7ibyGWt5b4xARaYicRQB0/g3/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2 OjA0OiAiS2FkZGFmaSBpcyBKZXN1czwyMTY+PFNURUFNXzA6MDo2OTgyNDc5NTg+PFRFUlJP UklTVD4iIHRyaWdnZXJlZCAiaGVhZHNob3QiCgBOeYxOQKMAAMoAAADKAAAAADBIcRGkAAtF HPQaCABFAAC8xYMAAHYR+1S8hlreW+MQEWmInEUAqB0B/////1JMIDEwLzA1LzIwMTEgLSAx OTozNjowNDogIkthZGRhZmkgaXMgSmVzdXM8MjE2PjxTVEVBTV8wOjA6Njk4MjQ3OTU4PjxU RVJST1JJU1Q+IiBraWxsZWQgInpvbWJpZeKEojwyMzg+PFNURUFNXzA6MDoxMjAzMDQ3NTM1 PjxDVD4iIHdpdGggIm00YTEiIChoZWFkc2hvdCkKAE55jE4nDAEAPgAAAD4AAAAAMEhxEaQA C0Uc9BoIAEUAADA6Y0AAewYB/09iCBBb4xARyKMAUG0+fBQAAAAAcAIgAO1yAAACBAW0AQEE Ak55jE4mIgEAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADQd00AAbgYpY9VXhEJb4xARqwAA UHb9/0sAAAAAgAL//4iPAAACBAUUAQMDAQEBBAJOeYxOGDgBAEIAAABCAAAAADBIcRGkADBI gvlsCABFAAA00OBAAEAGkgFb4xALW+MQEQBQr8xFGGtpgkh344AS//89WgAAAgQFtAEDAwME AgAATnmMTq5JAQA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMHkZAAA7BjQI0VWVXVvjEBEA ULlD+3ZZ4cSmpjBwEhZYIGsAAAIEBZYBAQQCTnmMTodNAQBCAAAAQgAAAAAwSHERpAALRRz0 GggARQAANGnOQABzBiUSslhal1vjEBHtHwBQOr6CdAAAAACAAiAAK5gAAAIEBawBAwMCAQEE Ak55jE5aaQEARgAAAEYAAAAAMEhxEaQAC0Uc9BoIAEUAADgAAAAA9gHHyE1KQ75b4xARCwCb 6AAAAABFAAAoowtAAAEG2Zhb4xARTUpD7gBQcckN5tkXTnmMToTIAQA8AAAAPAAAAAAwSHER pAALRRz0GggARQAAKA3UAAB5BvB/1b8ByVvjEBETeQBQ8RsA5/EbAOdQBAAAdJUAAAAAAAAA AE55jE5A+wEABgEAAAYBAAAAMEhxEaQAC0Uc9BoIAEUAAPjF0AAAdhH6y7yGWt5b4xARaYic RQDkCxL/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA0OiAiQ29uc3RyYXk8MjUwPjxTVEVB TV8wOjA6MTk4NDgwMTUxMj48Q1Q+IiBhdHRhY2tlZCAiQm9uZDwyMzU+PFNURUFNXzA6MDox MTMwMjk4OTMyPjxURVJST1JJU1Q+IiB3aXRoICJtNGExIiAoZGFtYWdlICIyNyIpIChkYW1h Z2VfYXJtb3IgIjUiKSAoaGVhbHRoICIxNyIpIChhcm1vciAiODMiKSAoaGl0Z3JvdXAgInN0 b21hY2giKQoATnmMTg0rAgBJAAAASQAAAAAwSHERpAAwSIL5bAgARQAAO9DkAABAEdDrW+MR C1vjEBHNEwA1ACf8qWXdAAAAAQAAAAAAAAlsZXhtYS11c2EDY29tAAAGAAFOeYxOXisCAEYA AABGAAAAADBIgvlsADBIcRGkCABFAAA4T0UAAEABUp5b4xARW+MRCwMDMuMAAAAARQAAO9Dk AABAEdDrW+MRC1vjEBHNEwA1ACf8qU55jE6wTgIAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUA ADTXT0AAdgb48VvMbMJb4xAR93wAUIRI6+cAAAAAgAL//9KXAAACBAW0AQMDAQEBBAJOeYxO PYkCAEIAAABCAAAAADBIcRGkAAtFHPQaCABFAAA0wsVAAHQG/N68hh6lW+MQEQTXAFDOHemp AAAAAIAC//9rCAAAAgQFtAEDAwIBAQQCTnmMTpH0AgA+AAAAPgAAAAAwSHERpAALRRz0GggA RQgAMFuWQAB5BhYeUpDRh1vjEBH5JQBQIUfujAAAAABwAiAAyckAAAIEBbQBAQQCTnmMTptC AwBGAAAARgAAAAAwSHERpAALRRz0GggARQAAOAGVQAA9BnCW2UWGW1vjEBG9wgBQt5Yd+QAA AACQAhbQgy0AAAIEBbQEAggKOrQoJQAAAABOeYxO9loDAAYBAAAGAQAAADBIcRGkAAtFHPQa CABFAAD4xicAAHYR+nS8hlreW+MQEWmInEUA5Dv//////1JMIDEwLzA1LzIwMTEgLSAxOToz NjowNDogIkNvbnN0cmF5PDI1MD48U1RFQU1fMDowOjE5ODQ4MDE1MTI+PENUPiIgYXR0YWNr ZWQgIkJvbmQ8MjM1PjxTVEVBTV8wOjA6MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIgd2l0aCAi bTRhMSIgKGRhbWFnZSAiMjIiKSAoZGFtYWdlX2FybW9yICI0IikgKGhlYWx0aCAiMCIpIChh cm1vciAiNzgiKSAoaGl0Z3JvdXAgImxlZnQgYXJtIikKAE55jE5WXwMAsAAAALAAAAAAMEhx EaQAC0Uc9BoIAEUAAKLGLAAAdhH6xbyGWt5b4xARaYicRQCOo3L/////UkwgMTAvMDUvMjAx MSAtIDE5OjM2OjA0OiBXb3JsZCB0cmlnZ2VyZWQgImtpbGxsb2NhdGlvbiIgKGF0dGFja2Vy X3Bvc2l0aW9uICItMTg0MyAtNTk2IDEyNCIpICh2aWN0aW1fcG9zaXRpb24gIi0xNDE0IC02 NzUgMTk0IikKAE55jE7TXwMAswAAALMAAAAAMEhxEaQAC0Uc9BoIAEUAAKXGLQAAdhH6wbyG Wt5b4xARaYicRQCRNET/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA0OiAiQ29uc3RyYXk8 MjUwPjxTVEVBTV8wOjA6MTk4NDgwMTUxMj48Q1Q+IiBraWxsZWQgIkJvbmQ8MjM1PjxTVEVB TV8wOjA6MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIgd2l0aCAibTRhMSIKAE55jE46ZAMA9wAA APcAAAAAMEhxEaQAC0Uc9BoIAEUAAOnGLgAAdhH6fLyGWt5b4xARaYicRQDVyDf/////Ukwg MTAvMDUvMjAxMSAtIDE5OjM2OjA0OiAiQm9uZDwyMzU+PFNURUFNXzA6MDoxMTMwMjk4OTMy PjxURVJST1JJU1Q+IiB0cmlnZ2VyZWQgIndlYXBvbnN0YXRzIiAod2VhcG9uICJtMjQ5Iikg KHNob3RzICI0IikgKGhpdHMgIjEiKSAoa2lsbHMgIjEiKSAoaGVhZHNob3RzICIxIikgKHRr cyAiMCIpIChkYW1hZ2UgIjEwNiIpIChkZWF0aHMgIjAiKQoATnmMTjRlAwD+AAAA/gAAAAAw SHERpAALRRz0GggARQAA8MYvAAB2Efp0vIZa3lvjEBFpiJxFANwW7v////9STCAxMC8wNS8y MDExIC0gMTk6MzY6MDQ6ICJCb25kPDIzNT48U1RFQU1fMDowOjExMzAyOTg5MzI+PFRFUlJP UklTVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMyIiAod2VhcG9uICJtMjQ5IikgKGhlYWQg IjEiKSAoY2hlc3QgIjAiKSAoc3RvbWFjaCAiMCIpIChsZWZ0YXJtICIwIikgKHJpZ2h0YXJt ICIwIikgKGxlZnRsZWcgIjAiKSAocmlnaHRsZWcgIjAiKQoATnmMThvOAwA+AAAAPgAAAAAw SHERpAALRRz0GggARQAAMETxQABoBoSXtPsoUFvjEBE6eAAZEF6hGgAAAABwAiAALhIAAAIE BXgBAQQCTnmMTvzSAwBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANPYPQAB5BpklW8uqz1vj EBEFEABQcptkBAAAAACAAv//IJ0AAAIEBaABAwMBAQEEAk55jE7uEQQAPgAAAD4AAAAAMEhx EaQAC0Uc9BoIAEUAADCNtwAAewaLRtWw5SVb4xARCroAbgb4yeIAAAAAcAL//4BSAAACBAW0 AQEEAk55jE73TAQAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADAj0EAAdAYXNV4hAa5b4xAR 0oYAGV0emr4AAAAAcAJAAK0HAAACBAWMAQEEAk55jE4ubAQAPAAAADwAAAAAMEhxEaQAC0Uc 9BoIAEUAACgvrAAAdgbvj1xxXS9b4xARDl0AUHW34JJ1t+CSUAQAAM8KAAAAAAAAAABOeYxO WnkEAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwToJAAHgGjpO9W/xiW+MQERNJABk/9pv/ AAAAAHAC//9uHQAAAgQFrAEBBAJOeYxO/psEAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAw PRZAAGkGXOE7XtB+W+MQEeBQABnsQExWAAAAAHACIADSVQAAAgQFrAEBBAJOeYxOtjQFAK4A AACuAAAAADBIcRGkADBIgvksCABFAACgHwcAAEARg2Vb4xAKW+MQEQA163UAjL4i6SSFgAAB AAEAAgACD21vbml0b3JpbmctY3MxNgJydQAAAQABwAwAAQABAAAOEAAEW+MQEcAMAAIAAQAA DhAAEQRkbnMxCWhvc3QtZm9vZMAcwAwAAgABAAAOEAAHBGRuczDARcBdAAEAAQAADhAABFvj EArAQAABAAEAAA4QAARb4xELTnmMTvBTBQCHAAAAhwAAAAAwSHERpAAwSIL5LAgARQAAeR8I AABAEYOLW+MQClvjEBEANUTBAGXNwsXQhYAAAQAAAAEAAAtiZXN0LWNoYW5nZQJydQAAHAAB wAwABgABAAAOEAAxBGRuczAJaG9zdC1mb29kwBgEcm9vdARzcnY3wDF33ervAAAqMAAADhAA CTqAAAFRgE55jE68mAUAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADTDv0AAdAb75LyGHqVb 4xARBNgAUM9YYNMAAAAAgAL///KiAAACBAW0AQMDAgEBBAJOeYxOIQQGAKwAAACsAAAAADBI cRGkADBIgvksCABFAACeHycAAEARg0db4xAKW+MQEQA1tAAAijmxGgSFgAABAAEAAgACDXJl bGF4LW1vbml0b3ICcnUAAAEAAcAMAAEAAQAADhAABFvjEBHADAACAAEAAA4QABEEZG5zMQlo b3N0LWZvb2TAGsAMAAIAAQAADhAABwRkbnMwwEPAWwABAAEAAA4QAARb4xAKwD4AAQABAAAO EAAEW+MRC055jE6GGgYAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADB5GgAAOwY0B9FVlV1b 4xARAFC5Q/t2WeHEpqYwcBIWWCBrAAACBAWWAQEEAk55jE6NLgYArQAAAK0AAAAAMEhxEaQA MEiC+SwIAEUAAJ8fKQAAQBGDRFvjEApb4xARADWu1ACLiw/mVoWAAAEAAQACAAIOYnJpdHZh LXByb2plY3QCcnUAAAEAAcAMAAEAAQAADhAABFvjEBHADAACAAEAAA4QABEEZG5zMQlob3N0 LWZvb2TAG8AMAAIAAQAADhAABwRkbnMwwETAXAABAAEAAA4QAARb4xAKwD8AAQABAAAOEAAE W+MRC055jE4AWAYAPAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUAAChUokAAega6iE5VN1xb4xAR DzAAUJRwVJiet/ZHUBD5RDdiAAAAAAAAAABOeYxOR7gHAGIAAABiAAAAADBIcRGkAAtFHPQa CABFAABUTJ8AADcBFa/DXfELW+MRDwgAVWWYuXcKTox5ZwAI39cICQoLDA0ODxAREhMUFRYX GBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1NjdOeYxOVbgHAEYAAABGAAAAADBIcRGk ADBIgvlsCABFAAA40P8AAEAR0NNb4xELW+MQEc0TADUAJIVHVW8AAAABAAAAAAAAB2lncmE3 NzcCcnUAAAYAAU55jE5puAcARgAAAEYAAAAAMEiC+WwAMEhxEaQIAEUAADhPXQAAQAFShlvj EBFb4xELAwOqSAAAAABFAAA40P8AAEAR0NNb4xELW+MQEc0TADUAJIVHTnmMTmLwBwAQAQAA EAEAAAAwSHERpAALRRz0GggARQABAgAAQAA8ER192cfaslvjEBFpipxFAO6vAP////9STCAx MC8wNS8yMDExIC0gMTk6MzY6MDc6ICJQ0ZJlW13OrjHRhV5eI19fX19fW3hEXTwxMj48U1RF QU1fMDoxOjQ0MTg5MjgxPjxDVD4iIGF0dGFja2VkICJUZU1rT15ePDQ+PFNURUFNXzA6MDoz NTMyODkwNT48VEVSUk9SSVNUPiIgd2l0aCAia25pZmUiIChkYW1hZ2UgIjY1IikgKGRhbWFn ZV9hcm1vciAiMCIpIChoZWFsdGggIjAiKSAoYXJtb3IgIjAiKSAoaGl0Z3JvdXAgImdlbmVy aWMiKQoATnmMTkr0BwCtAAAArQAAAAAwSHERpAALRRz0GggARQAAnwAAQAA8ER3g2cfaslvj EBFpipxFAIszzP////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDc6IFdvcmxkIHRyaWdnZXJl ZCAia2lsbGxvY2F0aW9uIiAoYXR0YWNrZXJfcG9zaXRpb24gIi03MTUgMTc2MCAtMzIiKSAo dmljdGltX3Bvc2l0aW9uICItNjcyIDE3OTIgMzIiKQoATnmMTsb0BwC/AAAAvwAAAAAwSHER pAALRRz0GggARQAAsQAAQAA8ER3O2cfaslvjEBFpipxFAJ1vD/////9STCAxMC8wNS8yMDEx IC0gMTk6MzY6MDc6ICJQ0ZJlW13OrjHRhV5eI19fX19fW3hEXTwxMj48U1RFQU1fMDoxOjQ0 MTg5MjgxPjxDVD4iIGtpbGxlZCAiVGVNa09eXjw0PjxTVEVBTV8wOjA6MzUzMjg5MDU+PFRF UlJPUklTVD4iIHdpdGggImtuaWZlIgoATnmMTiYOCABQAAAAUAAAAAAwSHERpAAwSIL5LAgA RQAAQh9KAABAEYOAW+MQClvjEBHwJAA1AC4Ot1r5AAAAAQAAAAAAAQZnby1yb2QCcnUAAAYA AQAAKQgAAAAAAAAATnmMTgONCACaAAAAmgAAAAAwSHERpAAwSIL5LAgARQAAjB92AABAEYMK W+MQClvjEBEANUctAHjG/JxIgYAAAQACAAIAAAN3d3cEc3BlYwlpbnRlcnN0b2wCcnUAAAEA AcAMAAUAAQADjoUAAsAQwBAAAQABAAOOhQAEWbxlZcAVAAIAAQADjoUADQNuczEGbXItd2Vi wB/AFQACAAEAA46FAAYDbnMywFVOeYxOw+cIAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAw T6dAAHkGVL9blZXYW+MQERB9AFAJ4ZqZAAAAAHACQAAw2gAAAgQFUAEBBAJOeYxOefMIAD4A AAA+AAAAADBIcRGkAAtFHPQaCABFAAAwEmNAADQGa6HZl4M4W+MQETLVAFCQww7mAAAAAHAC ///ojQAAAgQFtAQCAABOeYxOWDUJAEYAAABGAAAAADBIcRGkAAtFHPQaCABFAAA4AAAAAPYB x8hNSkO+W+MQEQsA4f0AAAAARQAAKKNYQAABBtlSW+MQEU1KQ+cAUBbuYB2bpk55jE7jWwkA PAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUAAChjs0AAfQY4lV+alflb4xARz2QAULRHE3a0RxN2 UAQAAO8oAAAAAAAAAABOeYxOnKMJAAgBAAAIAQAAADBIcRGkAAtFHPQaCABFAAD6x5gAAHYR +QG8hlreW+MQEWmJnEUA5vfk/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNTogIl8rX2Nl a2lzdF8rXzwzMTc+PFNURUFNXzA6MDo2NzQyMzkzOTc+PFRFUlJPUklTVD4iIGF0dGFja2Vk ICJhZTwyODk+PFNURUFNXzA6MDo0MTk2MzA1OTc+PENUPiIgd2l0aCAibTRhMSIgKGRhbWFn ZSAiMjQiKSAoZGFtYWdlX2FybW9yICIwIikgKGhlYWx0aCAiNzYiKSAoYXJtb3IgIjEwMCIp IChoaXRncm91cCAibGVmdCBsZWciKQoATnmMTparCgBCAAAAQgAAAAAwSHERpAALRRz0GggA RQAANPkLQAB2BtGeXDZx71vjEBEHGABQ0C5w3AAAAACAAvt88Q4AAAIEBbQBAwMAAQEEAk55 jE4w0woAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADATdkAAeAaVVV8cjuxb4xARz0wAUATd nO0AAAAAcAIgAJgfAAACBAVQAQEEAk55jE4edAsAPAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUA AChUqUAAega6gU5VN1xb4xARDyYAUCxI70xxOBwRUBD5gAxaAAAAAAAAAABOeYxOYs4LAD4A AAA+AAAAADBIcRGkAAtFHPQaCABFAAAwXTZAAHcG9pdSDPH5W+MQEYgBABlPQ37XAAAAAHAC //988AAAAgQFtAEBBAJOeYxOvXUMAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwUfBAAHkG hzMuSI5oW+MQEc2IAFD5PFpsAAAAAHACIAAY+QAAAgQFtAEBBAJOeYxOdoAMAD4AAAA+AAAA ADBIcRGkAAtFHPQaCABFAAAwUfFAAHkGhzIuSI5oW+MQEc2JAFCZZbI4AAAAAHACIAAhAwAA AgQFtAEBBAJOeYxOpKEMAEIAAABCAAAAADBIcRGkAAtFHPQaCABFAAA0AuZAAHUGaYbDFmpN W+MQEcA+AFB32gIKAAAAAIACIAB7rwAAAgQFUAEDAwIBAQQCTnmMTtmfDQA+AAAAPgAAAAAw SHERpAALRRz0GggARQAAMDOUQAB7BgiPspelGVvjEBEHBABQhhjWMwAAAABwAv//W9oAAAIE BbQBAQQCTnmMTq0LDgA8AAAAPAAAAAAwSHERpAALRRz0GggARWAAKDx9AAB8Bvk6vHrgSVvj EBELUwBQVwPMbVcDzG1QBAAAVKMAAAAAAAAAAE55jE5ARQ4APgAAAD4AAAAAMEhxEaQAC0Uc 9BoIAEUAADBFWEAAeAZyRV17gbtb4xAR2skAUJfnLGgAAAAAcAIgAHiLAAACBAW0AQEEAk55 jE4uXA4ADQEAAA0BAAAAMEhxEaQAC0Uc9BoIAEUAAP8AAEAAPBEdgNnH2rJb4xARaYqcRQDr Ao7/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiW1RMVCBUb3Bvcl0gR2hvc3Q8NT48 U1RFQU1fMDowOjM1NTc0NzM2PjxDVD4iIGF0dGFja2VkICLQsCA5SSBUeVQ8MTA+PFNURUFN XzA6MDo0MDc0NDI0OD48VEVSUk9SSVNUPiIgd2l0aCAia25pZmUiIChkYW1hZ2UgIjU1Iikg KGRhbWFnZV9hcm1vciAiNCIpIChoZWFsdGggIjUiKSAoYXJtb3IgIjE1IikgKGhpdGdyb3Vw ICJnZW5lcmljIikKAE55jE7IlA4AEwEAABMBAAAAMEhxEaQAC0Uc9BoIAEUAAQUAAEAAPBEd etnH2rJb4xARaYqcRQDxn3r/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiW1RMVCBU b3Bvcl0gR2hvc3Q8NT48U1RFQU1fMDowOjM1NTc0NzM2PjxDVD4iIGF0dGFja2VkICLQsCA5 SSBUeVQ8MTA+PFNURUFNXzA6MDo0MDc0NDI0OD48VEVSUk9SSVNUPiIgd2l0aCAicG9pbnRf aHVydCIgKGRhbWFnZSAiMTY1IikgKGRhbWFnZV9hcm1vciAiMCIpIChoZWFsdGggIjAiKSAo YXJtb3IgIjE1IikgKGhpdGdyb3VwICJnZW5lcmljIikKAE55jE66lg4ArQAAAK0AAAAAMEhx EaQAC0Uc9BoIAEUAAJ8AAEAAPBEd4NnH2rJb4xARaYqcRQCLNb//////UkwgMTAvMDUvMjAx MSAtIDE5OjM2OjA3OiBXb3JsZCB0cmlnZ2VyZWQgImtpbGxsb2NhdGlvbiIgKGF0dGFja2Vy X3Bvc2l0aW9uICItODA5IDE4MzcgLTMyIikgKHZpY3RpbV9wb3NpdGlvbiAiLTg3NSAxODA3 IDMyIikKAE55jE61lw4AwAAAAMAAAAAAMEhxEaQAC0Uc9BoIAEUAALIAAEAAPBEdzdnH2rJb 4xARaYqcRQCeD0X/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiW1RMVCBUb3Bvcl0g R2hvc3Q8NT48U1RFQU1fMDowOjM1NTc0NzM2PjxDVD4iIGtpbGxlZCAi0LAgOUkgVHlUPDEw PjxTVEVBTV8wOjA6NDA3NDQyNDg+PFRFUlJPUklTVD4iIHdpdGggInBvaW50X2h1cnQiCgBO eYxOqJkOAHoAAAB6AAAAADBIcRGkAAtFHPQaCABFAABsAABAADwRHhPZx9qyW+MQEWmKnEUA WN8A/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNzogVGVhbSAiQ1QiIHRyaWdnZXJlZCAi Q1RzX1dpbiIgKENUICI0NiIpIChUICIyNyIpCgBOeYxOJJoOAHAAAABwAAAAADBIcRGkAAtF HPQaCABFAABiAABAADwRHh3Zx9qyW+MQEWmKnEUATn+z/////1JMIDEwLzA1LzIwMTEgLSAx OTozNjowNzogVGVhbSAiQ1QiIHNjb3JlZCAiNDYiIHdpdGggIjQiIHBsYXllcnMKAE55jE6h mg4AdwAAAHcAAAAAMEhxEaQAC0Uc9BoIAEUAAGkAAEAAPBEeFtnH2rJb4xARaYqcRQBVPq// ////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiBUZWFtICJURVJST1JJU1QiIHNjb3JlZCAi MjciIHdpdGggIjMiIHBsYXllcnMKAE55jE4emw4AZQAAAGUAAAAAMEhxEaQAC0Uc9BoIAEUA AFcAAEAAPBEeKNnH2rJb4xARaYqcRQBDAwX/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3 OiBXb3JsZCB0cmlnZ2VyZWQgIlJvdW5kX0VuZCIKAE55jE4XnA4AAAEAAAABAAAAMEhxEaQA C0Uc9BoIAEUAAPIAAEAAPBEdjdnH2rJb4xARaYqcRQDe5cj/////UkwgMTAvMDUvMjAxMSAt IDE5OjM2OjA3OiAiUNGSZVtdzq4x0YVeXiNfX19fX1t4RF08MTI+PFNURUFNXzA6MTo0NDE4 OTI4MT48Q1Q+IiB0cmlnZ2VyZWQgIndlYXBvbnN0YXRzIiAod2VhcG9uICJrbmlmZSIpIChz aG90cyAiMSIpIChoaXRzICIxIikgKGtpbGxzICIxIikgKGhlYWRzaG90cyAiMCIpICh0a3Mg IjAiKSAoZGFtYWdlICI2NSIpIChkZWF0aHMgIjAiKQoATnmMThKdDgAIAQAACAEAAAAwSHER pAALRRz0GggARQAA+gAAQAA8ER2F2cfaslvjEBFpipxFAOa+w/////9STCAxMC8wNS8yMDEx IC0gMTk6MzY6MDc6ICJQ0ZJlW13OrjHRhV5eI19fX19fW3hEXTwxMj48U1RFQU1fMDoxOjQ0 MTg5MjgxPjxDVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMyIiAod2VhcG9uICJrbmlmZSIp IChoZWFkICIwIikgKGNoZXN0ICIwIikgKHN0b21hY2ggIjAiKSAobGVmdGFybSAiMCIpIChy aWdodGFybSAiMCIpIChsZWZ0bGVnICIwIikgKHJpZ2h0bGVnICIwIikKAE55jE6OnQ4A+gAA APoAAAAAMEhxEaQAC0Uc9BoIAEUAAOwAAEAAPBEdk9nH2rJb4xARaYqcRQDYe0L/////Ukwg MTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiW1RMVCBUb3Bvcl0gR2hvc3Q8NT48U1RFQU1fMDow OjM1NTc0NzM2PjxDVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMiICh3ZWFwb24gImtuaWZl IikgKHNob3RzICIxIikgKGhpdHMgIjIiKSAoa2lsbHMgIjEiKSAoaGVhZHNob3RzICIwIikg KHRrcyAiMCIpIChkYW1hZ2UgIjEyMCIpIChkZWF0aHMgIjAiKQoATnmMToieDgABAQAAAQEA AAAwSHERpAALRRz0GggARQAA8wAAQAA8ER2M2cfaslvjEBFpipxFAN+0CP////9STCAxMC8w NS8yMDExIC0gMTk6MzY6MDc6ICJbVExUIFRvcG9yXSBHaG9zdDw1PjxTVEVBTV8wOjA6MzU1 NzQ3MzY+PENUPiIgdHJpZ2dlcmVkICJ3ZWFwb25zdGF0czIiICh3ZWFwb24gImtuaWZlIikg KGhlYWQgIjAiKSAoY2hlc3QgIjAiKSAoc3RvbWFjaCAiMCIpIChsZWZ0YXJtICIwIikgKHJp Z2h0YXJtICIwIikgKGxlZnRsZWcgIjAiKSAocmlnaHRsZWcgIjAiKQoATnmMToKfDgAAAQAA AAEAAAAwSHERpAALRRz0GggARQAA8gAAQAA8ER2N2cfaslvjEBFpipxFAN5OA/////9STCAx MC8wNS8yMDExIC0gMTk6MzY6MDc6ICJbVExUIFRvcG9yXSBDcHQgTWFjVGF2aXNoPDY+PFNU RUFNXzA6MTozNzcyOTU1Mj48Q1Q+IiB0cmlnZ2VyZWQgIndlYXBvbnN0YXRzIiAod2VhcG9u ICJrbmlmZSIpIChzaG90cyAiMSIpIChoaXRzICIwIikgKGtpbGxzICIwIikgKGhlYWRzaG90 cyAiMCIpICh0a3MgIjAiKSAoZGFtYWdlICIwIikgKGRlYXRocyAiMCIpCgBOeYxOfKAOAAkB AAAJAQAAADBIcRGkAAtFHPQaCABFAAD7AABAADwRHYTZx9qyW+MQEWmKnEUA51WQ/////1JM IDEwLzA1LzIwMTEgLSAxOTozNjowNzogIltUTFQgVG9wb3JdIENwdCBNYWNUYXZpc2g8Nj48 U1RFQU1fMDoxOjM3NzI5NTUyPjxDVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMyIiAod2Vh cG9uICJrbmlmZSIpIChoZWFkICIwIikgKGNoZXN0ICIwIikgKHN0b21hY2ggIjAiKSAobGVm dGFybSAiMCIpIChyaWdodGFybSAiMCIpIChsZWZ0bGVnICIwIikgKHJpZ2h0bGVnICIwIikK AE55jE51oQ4A+AAAAPgAAAAAMEhxEaQAC0Uc9BoIAEUAAOoAAEAAPBEdldnH2rJb4xARaYqc RQDWvLH/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAi0LAgOUkgVHlUPDEwPjxTVEVB TV8wOjA6NDA3NDQyNDg+PFRFUlJPUklTVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMiICh3 ZWFwb24gImtuaWZlIikgKHNob3RzICIxIikgKGhpdHMgIjAiKSAoa2lsbHMgIjAiKSAoaGVh ZHNob3RzICIwIikgKHRrcyAiMCIpIChkYW1hZ2UgIjAiKSAoZGVhdGhzICIwIikKAE55jE7y oQ4AAQEAAAEBAAAAMEhxEaQAC0Uc9BoIAEUAAPMAAEAAPBEdjNnH2rJb4xARaYqcRQDfxD7/ ////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAi0LAgOUkgVHlUPDEwPjxTVEVBTV8wOjA6 NDA3NDQyNDg+PFRFUlJPUklTVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMyIiAod2VhcG9u ICJrbmlmZSIpIChoZWFkICIwIikgKGNoZXN0ICIwIikgKHN0b21hY2ggIjAiKSAobGVmdGFy bSAiMCIpIChyaWdodGFybSAiMCIpIChsZWZ0bGVnICIwIikgKHJpZ2h0bGVnICIwIikKAE55 jE5wog4AjgAAAI4AAAAAMEhxEaQAC0Uc9BoIAEUAAIAAAEAAPBEd/9nH2rJb4xARaYqcRQBs 1Kn/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiW1RMVCBUb3Bvcl0gR2hvc3Q8NT48 U1RFQU1fMDowOjM1NTc0NzM2PjxDVD4iIHRyaWdnZXJlZCAicm91bmRfbXZwIgoATnmMTu2i DgBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANPkbQAB2BtGOXDZx71vjEBEHGQBQAWyQhgAA AACAAvt8oCYAAAIEBbQBAwMAAQEEAk55jE5nzA4APgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADATd0AAeAaVVF8cjuxb4xARz00AUIHYA0IAAAAAcAIgALTOAAACBAVQAQEEAk55jE528g4A CgIAAAoCAAAAMEhxEaQAC0Uc9BoIAEUAAfxzGwAA8BEijF1kafFb4xAR37sTxAHoYdpSRUdJ U1RFUiBzaXA6cGJ4LnNpYWx0ZWxlLmNvbSBTSVAvMi4wDQpWaWE6IFNJUC8yLjAvVURQIDE5 Mi4xNjguMC4xNzY6NTA2MTticmFuY2g9ejloRzRiSy02NjMzNGFlOA0KRnJvbTogPHNpcDp0 cmlzLTYwMEBwYnguc2lhbHRlbGUuY29tPjt0YWc9M2Y3NDI0MTMzYjg3YjJjbzENClRvOiA8 c2lwOnRyaXMtNjAwQHBieC5zaWFsdGVsZS5jb20+DQpDYWxsLUlEOiBlMjNmYWMxMC04MzIy ZjY2ZkAxOTIuMTY4LjAuMTc2DQpDU2VxOiA0MzE5MyBSRUdJU1RFUg0KTWF4LUZvcndhcmRz OiA3MA0KQ29udGFjdDogPHNpcDp0cmlzLTYwMEAxOTIuMTY4LjAuMTc2OjUwNjE+O2V4cGly ZXM9MzYwMA0KVXNlci1BZ2VudDogTGlua3N5cy9QQVAyVC0zLjEuMTUoTFMpDQpDb250ZW50 LUxlbmd0aDogMA0KQWxsb3c6IEFDSywgQllFLCBDQU5DRUwsIElORk8sIElOVklURSwgTk9U SUZZLCBPUFRJT05TLCBSRUZFUg0KU3VwcG9ydGVkOiB4LXNpcHVyYQ0KDQpOeYxOgEEPAD4A AAA+AAAAADBIcRGkAAtFHPQaCABFAAAweRsAADsGNAbRVZVdW+MQEQBQuUP7dlnhxKamMHAS FlggawAAAgQFlgEBBAJPeYxO20sAADwAAAA8AAAAADBIcRGkAAtFHPQaCABFAAAo5+dAAHcG JotfhyniW+MQERCTAFCRP/cq+oWGr1AR+xak3AAAAAAAAAAAT3mMTvOsAAAXAQAAFwEAAAAw SHERpAALRRz0GggARQABCckDAAB2EfeHvIZa3lvjEBFpiJxFAPUIF/////9STCAxMC8wNS8y MDExIC0gMTk6MzY6MDU6ICJjc3Muc2V0dGkuaW5mbzwyNDU+PFNURUFNXzA6MDoxODAxNTcw OTg0PjxURVJST1JJU1Q+IiBhdHRhY2tlZCAiem9tYmll4oSiPDIzOD48U1RFQU1fMDowOjEy MDMwNDc1MzU+PENUPiIgd2l0aCAiaGVncmVuYWRlIiAoZGFtYWdlICIzNiIpIChkYW1hZ2Vf YXJtb3IgIjYiKSAoaGVhbHRoICI5NzYiKSAoYXJtb3IgIjkzIikgKGhpdGdyb3VwICJnZW5l cmljIikKAE95jE5h7AAAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADAN3EAAeQawb9W/Aclb 4xARBPwAUPHZ3qsAAAAAcAJAACo1AAACBAVQAQEEAk95jE76dQEAQgAAAEIAAAAAMEhxEaQA C0Uc9BoIAEUAADRiU0AAegZLpQJd5Hpb4xARz5EAUIWumr8AAAAAgAIgAAxfAAACBAVQAQMD AgEBBAJPeYxOX2wCADwAAAA8AAAAADBIcRGkAAtFHPQaCABFAAAo1ecAAHsGETxb4ZDXW+MQ EQ2uAFDD0ootw9KKLVAEAACtNQAAAAAAAAAAT3mMTvGRAgA+AAAAPgAAAAAwSHERpAALRRz0 GggARQAAMDgXQAB4BsXDXVQ7pVvjEBEO+gBQzvcWBAAAAABwAv//igAAAAIEBaABAQQCT3mM TuLQAgA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMDROQAB0Bj9yXbHJYlvjEBHIyABQpujA VwAAAABwAiAAn74AAAIEBbQBAQQCT3mMTsroAgA+AAAAPgAAAAAwSHERpAALRRz0GggARQAA MACDQAB5Bl562XZdYFvjEBFNFABQ1myX8AAAAABwAv//JM8AAAIEBXgBAQQCT3mMTk78AgBK AAAASgAAAAAwSHERpAALRRz0GggARQAAPDD7QAA8BvzWvI/oZlvjEBGePgBQvDzTeAAAAACg AhbQ1vsAAAIEBbQEAggKLrvsSwAAAAABAwMGT3mMTgpZAwBgAAAAYAAAAAAwSHERpAALRRz0 GggARQAAUtaGAAA6AXT8U951VlvjEBEDAcuVAAAAAEUAADajVwAAPREL/VvjEBHUTI4iOZJu 1AAiyhn/////VFNvdXJjZSBFbmdpbmUgUXVlcnkADU95jE7BiwMAQgAAAEIAAAAAMEhxEaQA C0Uc9BoIAEUAADQWSkAAdQbrE7JM5iVb4xAR85YAUGMZLVYAAAAAgAIgAMZVAAACBAW4AQMD AgEBBAJPeYxOGlwEAEIAAABCAAAAADBIcRGkAAtFHPQaCABFAAA0G/dAAHgG/NRb2yIpW+MQ Ed3RAFBRj8qnAAAAAIACIABqxQAAAgQFtAEDAwIBAQQCT3mMTndhBABKAAAASgAAAAAwSHER pAALRRz0GggARQAAPAG4AAA1Bv/LXxy5KFvjEBGHagBQckZVuwAAAACgAhbQcNQAAAIEBYwE AggKAMLrzAAAAAABAwMHT3mMTuUFBQBIAAAASAAAAAAwSHERpAAwSIL5bAgARQAAOtExAABA EdCfW+MRC1vjEBHNEwA1ACZB3+MxAAAAAQAAAAAAAAlrZXRzLWZvdG8CcnUAAAYAAU95jE7+ BQUARgAAAEYAAAAAMEiC+WwAMEhxEaQIAEUAADhPjwAAQAFSVFvjEBFb4xELAwPtrgAAAABF AAA60TEAAEAR0J9b4xELW+MQEc0TADUAJkHfT3mMTjbDBQBCAAAAQgAAAAAwSHERpAALRRz0 GggARQAANETPQABtBscbDmCHhVvjEBEHvAAZHZAlfgAAAACAAv//IlsAAAIEBbQBAwMBAQEE Ak95jE7+CgYAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBlnkAAbgYu+U3vvk1b4xARCN0A UNgEEv8AAAAAcAL//xbGAAACBAWsAQEEAk95jE7uXAYAPgAAAD4AAAAAMEhxEaQAC0Uc9BoI AEUAADBM30AAdwZOing8hC5b4xARLK0AGS6jk1UAAAAAcAIgAAwUAAACBAWiAQEEAk95jE5s mAYAmwAAAJsAAAAAMEhxEaQAMEiC+WwIAEUAAI3RPAAAQBHQQVvjEQtb4xARADVN+AB5y03l SYGAAAEAAgACAAADd3d3BXNwZWMzCWludGVyc3RvbAJydQAAAQABwAwABQABAAKWhAACwBDA EAABAAEAApaEAATZQQMVwBYAAgABAAKWeAANA25zMgZtci13ZWLAIMAWAAIAAQAClngABgNu czHAVk95jE6EmAYARgAAAEYAAAAAMEiC+WwAMEhxEaQIAEUAADhPkwAAQAFSUFvjEBFb4xEL AwPjCAAAAABFAACN0TwAAEAR0EFb4xELW+MQEQA1TfgAectNT3mMTja1BgA+AAAAPgAAAAAw SHERpAALRRz0GggARQAAMCArQAB6Bt3dw9jS8lvjEBHCKgBQpM067gAAAABwAiAAvj0AAAIE BaABAQQCT3mMTmnBBgBKAAAASgAAAAAwSHERpAALRRz0GggARQAAPJVFQAAxBpHMQ8Ny81vj EBGKAgBQh8Q9gAAAAACgAhbQm5QAAAIEBbQEAggKepOoxQAAAAABAwMIT3mMTq/eBgDEAAAA xAAAAAAwSHERpAAwSIL5bAgARQAAttE9AABAEdAXW+MRC1vjEBEANcj2AKJ5H0ymhYAAAQAC AAIAAgJjcwlsaXZlLXN1cmYCcnUJaG9zdC1mb29kAnJ1AAABAAHADAAFAAEAAA4QAAoHdGVz dC1oZsAmwDoAAQABAAAOEAAEW+MQC8A6AAIAAQAADhAABwRkbnMxwBzAOgACAAEAAA4QAAcE ZG5zMMAcwHMAAQABAAAOEAAEW+MQCsBgAAEAAQAADhAABFvjEQtPeYxOvN4GAEYAAABGAAAA ADBIgvlsADBIcRGkCABFAAA4T5YAAEABUk1b4xARW+MRCwMDug8AAAAARQAAttE9AABAEdAX W+MRC1vjEBEANcj2AKJ5H095jE4Z4gYAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBUmgAA egYyaNVPeIJb4xARtyEAUGrVTJAAAAAAcAJAABqCAAACBAW0AQEEAk95jE4OSQcACgIAAAoC AAAAMEhxEaQAC0Uc9BoIAEUAAfxzHAAA8BEii11kafFb4xAR37sTxAHoYdpSRUdJU1RFUiBz aXA6cGJ4LnNpYWx0ZWxlLmNvbSBTSVAvMi4wDQpWaWE6IFNJUC8yLjAvVURQIDE5Mi4xNjgu MC4xNzY6NTA2MTticmFuY2g9ejloRzRiSy02NjMzNGFlOA0KRnJvbTogPHNpcDp0cmlzLTYw MEBwYnguc2lhbHRlbGUuY29tPjt0YWc9M2Y3NDI0MTMzYjg3YjJjbzENClRvOiA8c2lwOnRy aXMtNjAwQHBieC5zaWFsdGVsZS5jb20+DQpDYWxsLUlEOiBlMjNmYWMxMC04MzIyZjY2ZkAx OTIuMTY4LjAuMTc2DQpDU2VxOiA0MzE5MyBSRUdJU1RFUg0KTWF4LUZvcndhcmRzOiA3MA0K Q29udGFjdDogPHNpcDp0cmlzLTYwMEAxOTIuMTY4LjAuMTc2OjUwNjE+O2V4cGlyZXM9MzYw MA0KVXNlci1BZ2VudDogTGlua3N5cy9QQVAyVC0zLjEuMTUoTFMpDQpDb250ZW50LUxlbmd0 aDogMA0KQWxsb3c6IEFDSywgQllFLCBDQU5DRUwsIElORk8sIElOVklURSwgTk9USUZZLCBP UFRJT05TLCBSRUZFUg0KU3VwcG9ydGVkOiB4LXNpcHVyYQ0KDQpPeYxOEpkHADwAAAA8AAAA ADBIcRGkAAtFHPQaCABFAAAoUfJAAHkGhzkuSI5oW+MQEcyKAFCyyXJ6sslyelAEAABv2QAA AAAAAAAAT3mMTkW5BwA8AAAAPAAAAAAwSHERpAALRRz0GggARQAAKAAAQAA+BgX6stkYCVvj EBHsfQBQ37vtoAAAAABQBAAAvt8AAAAAAAAAAE95jE45uwcAYgAAAGIAAAAAMEhxEaQAC0Uc 9BoIAEUAAFRMoQAANwEVrcNd8Qtb4xEPCABRaZi5dxtOjHloAAjjwQgJCgsMDQ4PEBESExQV FhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2N095jE4mIwgACgEAAAoBAAAAMEhx EaQAC0Uc9BoIAEUAAPzKvgAAdhH12byGWt5b4xARaYmcRQDoskD/////UkwgMTAvMDUvMjAx MSAtIDE5OjM2OjA2OiAiS2lyaWxsNDBydXM8MzE2PjxTVEVBTV8wOjA6NzkyNDQzNjg3PjxU RVJST1JJU1Q+IiBhdHRhY2tlZCAiYWU8Mjg5PjxTVEVBTV8wOjA6NDE5NjMwNTk3PjxDVD4i IHdpdGggImhlZ3JlbmFkZSIgKGRhbWFnZSAiMyIpIChkYW1hZ2VfYXJtb3IgIjAiKSAoaGVh bHRoICI3MyIpIChhcm1vciAiMTAwIikgKGhpdGdyb3VwICJnZW5lcmljIikKAE95jE5zPwgA RgAAAEYAAAAAMEhxEaQAC0Uc9BoIAEUAADhhFkAAPQYRFdlFhltb4xARgdwAULf2azgAAAAA kAIW0GxFAAACBAW0BAIICjq0LVQAAAAAT3mMTmZBCAA+AAAAPgAAAAAwSHERpAALRRz0GggA RQAAMMtnQABuBicLsoj72FvjEBEH7gBQxrnJ7QAAAABwAv//z+wAAAIEBawBAQQCT3mMTnRT CABKAAAASgAAAAAwSHERpAALRRz0GggARQAAPCseAAA3Bufq1JUwKlvjEBHHMQBQbZVcOAAA AACgAv//WHcAAAIEBbQBAwMABAIICqGXS/UAAAAAT3mMTrpwCABKAAAASgAAAAAwSHERpAAL RRz0GggARQAAPABPQAA5Bg70skcUPlvjEBETFAa7MSKU9wAAAACgAhbQfdwAAAIEBawEAggK BBGc7wAAAAABAwMAT3mMTuRwCQA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMA/VQAB2Bhr1 Us8bO1vjEBHbogBQXxKaSQAAAABwAiAAs+YAAAIEBaABAQQCT3mMTi55CQBGAAAARgAAAAAw SHERpAALRRz0GggARQAAOFW9QAA9Bhxu2UWGW1vjEBGJqwBQuCB4GAAAAACQAhbQVxsAAAIE BbQEAggKOrQtpQAAAABPeYxOC6cJAEoAAABKAAAAADBIcRGkAAtFHPQaCABFAAA8EEFAADwG HZG8j+hmW+MQEcBHAFDDJfmKAAAAAKACFtCHigAAAgQFtAQCCAouu+y4AAAAAAEDAwZPeYxO +r0JAJYAAACWAAAAADBIcRGkAAtFHPQaCABFAACIAABAADkR0VhN3LY8W+MQEWmHpQQAdESM /////20xMjcuMC4wLjE6MjcwMTUALT3QnNC+0YHQutCy0LBbR3JlZW5DaXR5XT0tAGRlX2Ns YW4yX2ZpcmUAY3N0cmlrZQBDb3VudGVyLVN0cmlrZQAgIC9kbAABAAAAAQAAAAAAAAABAAEA T3mMTmrACQD8AgAA/AIAAAAwSHERpAALRRz0GggARQAC7gAAQAA5Ec7yTdy2PFvjEBFph6UE AtraNP////9EHwBrb2xsZWdhKHZvbC8wKQACAAAAEjwcRAAtLT1EYS5SdD0tIGhpaG8gdSBN YUpJYklMTGxLYQACAAAAtKwbRABQZXJvIHYgYm9rXltHYXpHb2xkZXJdXgACAAAAzhgcRABE QVMgSVNUIEZBTlRBU1RJU0NIIDoqAAMAAACYQplDAGZMeS4ABgAAADDJG0QAOlByaW50AAUA AADaqQ1EAGNyb3NzAAIAAADUEYFDAEx1Y2lmZXIAAgAAABIcHEQAX1NWRC9EYUh1Sklde0Ff AAYAAABOQxxEAFBhMzRleEpJdVRlSkliXgAFAAAA/OwTRABwcm9zdG9ueWIAAgAAAKY8HEQA ZEVGRU5ERVIABwAAAArCG0QAUzRhc3RMMXY0aUsAAAAAAGYfHEQAd3d3LmlncmFlbS1jcy5S dQAAAAAAIB7qRABEdWJTdGVwKnRlYW1bXVJlYm9ybgAAAAAAwI6KQgBLYXlhYmEABgAAAKIH HEQAckpJQTNBIEhBSkl1VGJJIEtQT0JiSS0wAA0AAACKuBZEAERvWmVSW0tlTmlHc0JlUmdd AAUAAAAiXxBEAEFIYTZvL2x1SwAAAAAACLobRAB0aW1vbl9TcEJfWzggY3Jld10ABQAAAHAm HEQAbHVxAAYAAABot35DAFRlYW1eQF4vQWlNZ09PKlJQTy1BV1AAAwAAAI5iDUQAQ2hhdml6 AAQAAADSzRlEAFRJSElKLTc3AAUAAADCxRNEAC83cGFreXBvcAABAAAAuO8bRABwby4AAgAA AAjpokMAYmFycmFjdWRhIT5UZWFtUFJPAAAAAACgdr9CAHBpcmFuKnlhAAIAAAB4gxJEAE5p bWV0NExlc2hhNyAtLi0AAwAAAL7NAUQAYSB0YjEga2FrIGR5bWFsPwAFAAAAcHbLQwAtPTE2 MSBSdXM9LSBBbnRvbmlvAAQAAAAwobJDT3mMTnfACQCLAAAAiwAAAAAwSHERpAALRRz0GggA RQAAfQAAQAA5EdFjTdy2PFvjEBFph6UEAGkM7P////9JMC090JzQvtGB0LrQstCwW0dyZWVu Q2l0eV09LQBkZV9jbGFuMl9maXJlAGNzdHJpa2UAQ291bnRlci1TdHJpa2UACgAgIABkbAAB MS4xLjIuNi9TdGRpbwCAh2lPeYxOTu0JAFQAAABUAAAAADBIcRGkADBIgvlsCABFAABG0UgA AEAR0Hxb4xELW+MQEc0TADUAMv+6H38AAAABAAAAAAABCXNvemRhdGVsaQNiaXoAAAYAAQAA KQgAAAAAAAAAT3mMTlztCQBGAAAARgAAAAAwSIL5bAAwSHERpAgARQAAOE+lAABAAVI+W+MQ EVvjEQsDAy/HAAAAAEUAAEbRSAAAQBHQfFvjEQtb4xARzRMANQAy/7pPeYxOXRMKAEIAAABC AAAAADBIcRGkAAtFHPQaCABFAAA0W+VAAHkGfd9NKG7jW+MQEQ/NAFCKEyx5AAAAAIAC//+A dgAAAgQFrAEDAwEBAQQCT3mMTsAXCgBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANFvmQAB5 Bn3eTShu41vjEBEPzgBQKEZ9wQAAAACAAv//kPoAAAIEBawBAwMBAQEEAk95jE6cHQoAQgAA AEIAAAAAMEhxEaQAC0Uc9BoIAEUAADRb50AAeQZ93U0obuNb4xARD88AUDbvWVEAAAAAgAL/ /6bAAAACBAWsAQMDAQEBBAJPeYxOfSIKAEIAAABCAAAAADBIcRGkAAtFHPQaCABFAAA0W+hA AHkGfdxNKG7jW+MQEQ/QAFDBRajMAAAAAIAC///M7QAAAgQFrAEDAwEBAQQCT3mMTl4nCgBC AAAAQgAAAAAwSHERpAALRRz0GggARQAANFvpQAB5Bn3bTShu41vjEBEP0QBQhTwV0gAAAACA Av//m/AAAAIEBawBAwMBAQEEAk95jE62LQoAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADRb 6kAAeQZ92k0obuNb4xARD9IAUGaNzqIAAAAAgAL//wHOAAACBAWsAQMDAQEBBAJPeYxOKVgK AEIAAABCAAAAADBIcRGkAAtFHPQaCABFAAA0QaVAADYGsSxesodMW+MQETTpAFCtlgxLAAAA AIAC//8uEwAAAgQFrAEDAwABAQQCT3mMTld5CgBGAAAARgAAAAAwSHERpAALRRz0GggARQAA OLG+QAA9BsBs2UWGW1vjEBGD7wBQt0i7AgAAAACQAhbQGoQAAAIEBbQEAggKOrQt5gAAAABP eYxOJIEKAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwJmtAAHsGZ8XV1i/NW+MQEcr2AFCT kmnoAAAAAHACIAAoxgAAAgQFtAEBBAJPeYxOHL8KAD4AAAA+AAAAADBIcRGkAAtFHPQaCABF AAAw/rsAADIG6BnH/W4BW+MQETbPAFC5BoxoAAAAAHAC//9lswAAAgQFoAQCAABPeYxOI9IK AKMAAACjAAAAADBIcRGkADBIgvlsCABFAACV0U4AAEAR0Cdb4xELW+MQEQA186oAgYNYMjCF gAABAAEAAgACBHNydjcJaG9zdC1mb29kAnJ1AAABAAHADAABAAEAAA4QAARb4xARwBEAAgAB AAAOEAAHBGRuczHAEcARAAIAAQAADhAABwRkbnMwwBHAUgABAAEAAA4QAARb4xAKwD8AAQAB AAAOEAAEW+MRC095jE4y0goARgAAAEYAAAAAMEiC+WwAMEhxEaQIAEUAADhPsAAAQAFSM1vj EBFb4xELAwOFQwAAAABFAACV0U4AAEAR0Cdb4xELW+MQEQA186oAgYNYT3mMTifYCwBIAAAA SAAAAAAwSHERpAALRRz0GggARQAAOl5DAAB6ESouX9fsdlvjEBEkv8MCACbKekECeiaqMvpf AAAAAAA4AAA1KAAAAAgAAAAAAAAAAE95jE6SuQwAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADB9iEAAewYIrl4ar4Nb4xARBHMRXJaVdUUAAAAAcAL//+fjAAACBAW0AQEEAk95jE6HzwwA QgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADSOyEAAeQZ7TV+YLCJb4xARyAkAUPwh9uUAAAAA gAL//7xzAAACBAVIAQMDAQEBBAJPeYxOwhYNAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAw KSZAAHUGttRz8UXoW+MQERL4ABkMNNpeAAAAAHACIABDrgAAAgQFtAEBBAJPeYxOrtMNADwA AAA8AAAA////////AAtFHPQaCAYAAQgABgQAAQALRRz0GlvjEwEAAAAAAABb4xNUAAAAAAAA AAAAAAAAAAAAAAAAT3mMTtnxDQBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANABWQAB9BvoG 2U6+JFvjEBHU+rkIdMR3WwAAAACAAiAA0ekAAAIEBVABAwMIAQEEAk95jE6lDQ4ASAAAAEgA AAAAMEhxEaQAC0Uc9BoIAEUAADoAWAAAfRE59NlOviRb4xARd6a5CAAmMbhBAr4BTA+G7wAA AAAAOAAAx5AAAAAIAAAAAAAAAABPeYxOV0IOAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAw JnNAAHsGZ73V1i/NW+MQEcr3AFALLMRhAAAAAHACIABWsgAAAgQFtAEBBAJPeYxOJ14OAEIA AABCAAAAADBIcRGkAAtFHPQaCABFAAA0jslAAHkGe0xfmCwiW+MQEcgKAFABaE0wAAAAAIAC //9g4gAAAgQFSAEDAwEBAQQCT3mMTv6MDgA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMKk8 QAB4Bm1NVa4qnFvjEBEIPwBQ1TkWDQAAAABwAmBsQwMAAAIEBVABAQQCT3mMTiCwDgA+AAAA PgAAAAAwSHERpAALRRz0GggARQAAMKk7QAB4Bm1OVa4qnFvjEBEIPQBQ4lCiMgAAAABwAmBs qcgAAAIEBVABAQQCT3mMTuD2DgBJAAAASQAAAAAwSHERpAAwSIL5LAgARQAAOyK/AABAEYAS W+MQClvjEBHwJAA1ACf8/OPQAAAAAQAAAAAAAApvb28tbGVuZGVsAnJ1AAAGAAFQeYxOWRAA AEoAAABKAAAAADBIcRGkAAtFHPQaCABFAAA8FGpAAD0G6ZbDvRAKW+MQEdZdABlV8ejhAAAA AKACFtCQWAAAAgQFtAQCCArkBWfMAAAAAAEDAwdQeYxO9XAAAFIAAABSAAAAADBIcRGkADBI gvksCABFAABEIuYAAEARf+Jb4xAKW+MQEfAkADUAMM76fTIAAAABAAAAAAABCHdjMy1kb3Rh AnJ1AAAGAAEAACkIAAAAAAAAAFB5jE5K3QAASgAAAEoAAAAAMEhxEaQAC0Uc9BoIAEUAADwS ZkAANAZrktmXgzhb4xARMtoAUIELKLYAAAAAoAL//4dFAAACBAW0AQMDAwQCCAoG3BQzAAAA AFB5jE6AdwEATgAAAE4AAAAAMEhxEaQAC0Uc9BoIAEUAAECp3EAAdwZTKU5sTFJb4xARNbYA UJBuBlgAAAAAsAL//2J/AAACBAW0AQMDAwEBCAoAAAAAAAAAAAEBBAJQeYxOMCQCADwAAAA8 AAAAADBIcRGkAAtFHPQaCABFAAAoVMRAAHoGumZOVTdcW+MQEQ8oAFDUqkQBlClVyFAR9ZO2 hAAAAAAAAAAAUHmMTqY5AgAJAQAACQEAAAAwSHERpAALRRz0GggARQAA+8z5AAB2EfOfvIZa 3lvjEBFpiZxFAOc1Ov////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDY6ICJfK19jZWtpc3Rf K188MzE3PjxTVEVBTV8wOjA6Njc0MjM5Mzk3PjxURVJST1JJU1Q+IiBhdHRhY2tlZCAiYWU8 Mjg5PjxTVEVBTV8wOjA6NDE5NjMwNTk3PjxDVD4iIHdpdGggIm00YTEiIChkYW1hZ2UgIjIz IikgKGRhbWFnZV9hcm1vciAiMCIpIChoZWFsdGggIjUwIikgKGFybW9yICIxMDAiKSAoaGl0 Z3JvdXAgInJpZ2h0IGxlZyIpCgBQeYxOqLICAEIAAABCAAAAADBIcRGkAAtFHPQaCABFAAA0 y+pAAHQG87m8hh6lW+MQEQTZDOpioQvbAAAAAIAC//+ntwAAAgQFtAEDAwIBAQQCUHmMTny5 AgA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMDFzQAB6BrCP1QXdy1vjEBHBMgBQXfSffAAA AABwAiAAhcoAAAIEBVABAQQCUHmMTvi5AgA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMDFy QAB6BrCQ1QXdy1vjEBHBMQBQmsVZXQAAAABwAiAAjxkAAAIEBVABAQQCUHmMTgS6AgA+AAAA PgAAAAAwSHERpAALRRz0GggARQAAMDF0QAB6BrCO1QXdy1vjEBHBMwBQH6tkxwAAAABwAiAA /scAAAIEBVABAQQCUHmMTvELAwA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMHkcAAA7BjQF 0VWVXVvjEBEAULlD+3ZZ4cSmpjBwEhZYIGsAAAIEBZYBAQQCUHmMTo4bAwA8AAAAPAAAAAAw SHERpAALRRz0GggARQAAKFHzQAB5Boc4LkiOaFvjEBHMiQBQQnnnkkJ555JQBAAAZkoAAAAA AAAAAFB5jE5kNgMAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADAdo0AAdwZ79ryjQZdb4xAR 6BIAUG+qRk0AAAAAcAIgAFr6AAACBAVQAQEEAlB5jE6bRQMAiQAAAIkAAAAAMEhxEaQAMEiC +WwIAEUAAHvRhQAAQBHQClvjEQtb4xARADXszwBnWnpMq4GAAAEAAQACAAADd3d3B2Nhc2hp bmcCc3UAAAEAAcAMAAEAAQAAC44ABLwojO/AEAACAAEABP0uABAEZG5zMQZ5YW5kZXgCcnUA wBAAAgABAAT9LgAHBGRuczLAQVB5jE7aRQMARgAAAEYAAAAAMEiC+WwAMEhxEaQIAEUAADhP yAAAQAFSG1vjEBFb4xELAwO1FgAAAABFAAB70YUAAEAR0Apb4xELW+MQEQA17M8AZ1p6UHmM TuOrAwAqAAAAKgAAAP///////wAwSHERpAgGAAEIAAYEAAEAMEhxEaRb4xEPAAAAAAAAW+MR D1B5jE4L1AMAKgAAACoAAAD///////8AMEhxEaQIBgABCAAGBAABADBIcRGkW+MRDwAAAAAA AFvjEQtQeYxOeNUDADwAAAA8AAAAADBIcRGkADBIgvlsCAYAAQgABgQAAgAwSIL5bFvjEQsA MEhxEaRb4xEPAAAAAAAAAAAAAAAAAAAAAAAAUHmMTonVAwBVAAAAVQAAAAAwSIL5bAAwSHER pAgARQAAR0/JAABAEVD9W+MRD1vjEQuJ9AA1ADPaJKGHAQAAAQAAAAAAAAVpbmV0NhBBZXJv U3RhckNvbnRyYWN0AnJ1AAABAAFQeYxOW9kDAMcAAADHAAAAADBIcRGkAAtFHPQaCABFAAC5 0YkAAD8Rz8pb4xELW+MRDwA1ifQApewtoYeFgAABAAIAAgACBWluZXQ2EEFlcm9TdGFyQ29u dHJhY3QCcnUAAAEAAcAMAAUAAQAADhAABgN3d3fAEsA3AAEAAQAADhAABFvjEBHAEgACAAEA AA4QABEEZG5zMQlob3N0LWZvb2TAI8ASAAIAAQAADhAABwRkbnMwwF7AdgABAAEAAA4QAARb 4xAKwFkAAQABAAAOEAAEW+MRC1B5jE7K2wMAWgAAAFoAAAAAMEiC+WwAMEhxEaQIAEUAAExP ygAAQBFQ91vjEQ9b4xELb3UANQA42imhiAEAAAEAAAAAAAAKaWZkaXNhYmxlZBBBZXJvU3Rh ckNvbnRyYWN0AnJ1AAABAAFQeYxONt8DAMwAAADMAAAAADBIcRGkAAtFHPQaCABFAAC+0YoA AD8Rz8Rb4xELW+MRDwA1b3UAqiA4oYiFgAABAAIAAgACCmlmZGlzYWJsZWQQQWVyb1N0YXJD b250cmFjdAJydQAAAQABwAwABQABAAAOEAAGA3d3d8AXwDwAAQABAAAOEAAEW+MQEcAXAAIA AQAADhAAEQRkbnMwCWhvc3QtZm9vZMAowBcAAgABAAAOEAAHBGRuczHAY8BeAAEAAQAADhAA BFvjEArAewABAAEAAA4QAARb4xELUHmMTnfgAwAqAAAAKgAAAP///////wAwSHERpAgGAAEI AAYEAAEAMEhxEaRb4xARAAAAAAAAW+MQEVB5jE6p4QMAPAAAADwAAAAAMEhxEaQ8SpL3H1II BgABCAAGBAACPEqS9x9SW+MQEQAwSHERpFvjEBEAAAAAAAAAAAAAAAAAAAAAAABQeYxOulwE AEoAAABKAAAAADBIcRGkAAtFHPQaCABFAAA8SvxAADkGG6XQNZ7xW+MQEYLPAFCWzO9cAAAA AKACFtCUOAAAAgQFtAQCCAoHNLFfAAAAAAEDAwdQeYxOiYsEAEIAAABCAAAAADBIcRGkAAtF HPQaCABFAAA0fSpAAHcGkHBOJTwQW+MQEQtQAFAWh9GcAAAAAIAC//+FMAAAAgQFrAEDAwMB AQQCUHmMTrGYBAAIAQAACAEAAAAwSHERpAALRRz0GggARQAA+s2IAAB2EfMRvIZa3lvjEBFp iJxFAOYg9P////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDY6ICJCZXJrYW42ODwyNDA+PFNU RUFNXzA6MDoxMzcxODgwMjA4PjxDVD4iIGF0dGFja2VkICJCb25kPDIzNT48U1RFQU1fMDow OjExMzAyOTg5MzI+PFRFUlJPUklTVD4iIHdpdGggInVzcCIgKGRhbWFnZSAiMTIiKSAoZGFt YWdlX2FybW9yICI2IikgKGhlYWx0aCAiMTAwMCIpIChhcm1vciAiOTMiKSAoaGl0Z3JvdXAg ImxlZnQgYXJtIikKAFB5jE4ABwUAjAAAAIwAAAAAMEhxEaQAC0Uc9BoIAEUQAH4AAEAAPBGZ gD6M+l5b4xARaa6cRgBq5Y7/////UkwgMTAvMDUvMjAxMSAtIDE5OjQwOjU3OiBUZWFtICJU RVJST1JJU1QiIHRyaWdnZXJlZCAiSG9zdGFnZXNfTm90X1Jlc2N1ZWQiIChDVCAiMSIpIChU ICIwIikKAFB5jE4gBwUAbwAAAG8AAAAAMEhxEaQAC0Uc9BoIAEUQAGEAAEAAPBGZnT6M+l5b 4xARaa6cRgBNA1D/////UkwgMTAvMDUvMjAxMSAtIDE5OjQwOjU3OiBUZWFtICJDVCIgc2Nv cmVkICIxIiB3aXRoICI1IiBwbGF5ZXJzCgBQeYxO6QcFAHYAAAB2AAAAADBIcRGkAAtFHPQa CABFEABoAABAADwRmZY+jPpeW+MQEWmunEYAVO4f/////1JMIDEwLzA1LzIwMTEgLSAxOTo0 MDo1NzogVGVhbSAiVEVSUk9SSVNUIiBzY29yZWQgIjAiIHdpdGggIjQiIHBsYXllcnMKAFB5 jE4ECAUAZQAAAGUAAAAAMEhxEaQAC0Uc9BoIAEUQAFcAAEAAPBGZpz6M+l5b4xARaa6cRgBD f27/////UkwgMTAvMDUvMjAxMSAtIDE5OjQwOjU3OiBXb3JsZCB0cmlnZ2VyZWQgIlJvdW5k X0VuZCIKAFB5jE7cCQUA+AAAAPgAAAAAMEhxEaQAC0Uc9BoIAEUQAOoAAEAAPBGZFD6M+l5b 4xARaa6cRgDWlTj/////UkwgMTAvMDUvMjAxMSAtIDE5OjQwOjU3OiAia2FyYXB1dXo8NjQ+ PFNURUFNXzA6MDozODIxOTE5ND48VEVSUk9SSVNUPiIgdHJpZ2dlcmVkICJ3ZWFwb25zdGF0 cyIgKHdlYXBvbiAibTI0OSIpIChzaG90cyAiNiIpIChoaXRzICIxIikgKGtpbGxzICIxIikg KGhlYWRzaG90cyAiMSIpICh0a3MgIjAiKSAoZGFtYWdlICIxMTEiKSAoZGVhdGhzICIwIikK AFB5jE7UCgUA/wAAAP8AAAAAMEhxEaQAC0Uc9BoIAEUQAPEAAEAAPBGZDT6M+l5b4xARaa6c RgDdVnr/////UkwgMTAvMDUvMjAxMSAtIDE5OjQwOjU3OiAia2FyYXB1dXo8NjQ+PFNURUFN XzA6MDozODIxOTE5ND48VEVSUk9SSVNUPiIgdHJpZ2dlcmVkICJ3ZWFwb25zdGF0czIiICh3 ZWFwb24gIm0yNDkiKSAoaGVhZCAiMSIpIChjaGVzdCAiMCIpIChzdG9tYWNoICIwIikgKGxl ZnRhcm0gIjAiKSAocmlnaHRhcm0gIjAiKSAobGVmdGxlZyAiMCIpIChyaWdodGxlZyAiMCIp CgBQeYxOygsFAPgAAAD4AAAAADBIcRGkAAtFHPQaCABFEADqAABAADwRmRQ+jPpeW+MQEWmu nEYA1vXT/////1JMIDEwLzA1LzIwMTEgLSAxOTo0MDo1NzogIkFMVUNLQVJUPDYxPjxTVEVB TV8wOjE6NDQ4NTM5MTU+PFRFUlJPUklTVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMiICh3 ZWFwb24gIm00YTEiKSAoc2hvdHMgIjEwIikgKGhpdHMgIjEiKSAoa2lsbHMgIjAiKSAoaGVh ZHNob3RzICIwIikgKHRrcyAiMCIpIChkYW1hZ2UgIjIyIikgKGRlYXRocyAiMCIpCgBQeYxO wgwFAP8AAAD/AAAAADBIcRGkAAtFHPQaCABFEADxAABAADwRmQ0+jPpeW+MQEWmunEYA3b0J /////1JMIDEwLzA1LzIwMTEgLSAxOTo0MDo1NzogIkFMVUNLQVJUPDYxPjxTVEVBTV8wOjE6 NDQ4NTM5MTU+PFRFUlJPUklTVD4iIHRyaWdnZXJlZCAid2VhcG9uc3RhdHMyIiAod2VhcG9u ICJtNGExIikgKGhlYWQgIjAiKSAoY2hlc3QgIjAiKSAoc3RvbWFjaCAiMCIpIChsZWZ0YXJt ICIxIikgKHJpZ2h0YXJtICIwIikgKGxlZnRsZWcgIjAiKSAocmlnaHRsZWcgIjAiKQoAUHmM TnsaBQCgAAAAoAAAAAAwSHERpAAwSIL5LAgARQAAkiO5AABAEX7BW+MQClvjEBEANX91AH65 k2k8hYAAAQABAAEAAAtiZXN0LWNoYW5nZQJydQlob3N0LWZvb2QCcnUAABwAAcAMAAUAAQAA DhAACgd0ZXN0LWhmwCXAOQAGAAEAAA4QACcEZG5zMMAbBHJvb3QEc3J2McAbd95e8wAAKjAA AA4QAAk6gAABUYBQeYxOWIYFAEoAAABKAAAAADBIcRGkADBIgvlsCABFAAA80Z1AAEAGkTxb 4xALW+MQEQBQQ/WCiNLt9gBZwKAS///KHAAAAgQFtAEDAwMEAggKV1e9FRoPjfxQeYxOFlsG AD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwOf1AAHoGoRDDyPX9W+MQEfBtAFDtmgqgAAAA AHAC//90gAAAAgQFoAEBBAJQeYxObGAGABcBAAAXAQAAADBIcRGkAAtFHPQaCABFEAEJAABA ADwRmPU+jPpeW+MQEWm4nEYA9VVO/////1JMIDEwLzA1LzIwMTEgLSAxOTo0MDo1NzogIuC5 ltuj25xTMW4zcnx8fChaY0wpICLQu9C+0YXih5M8Njk+PFNURUFNXzA6MTozOTc4NDYyMz48 Q1Q+IiBhdHRhY2tlZCAiQk95a088NzI+PFNURUFNXzA6MDozODk3NzU2OD48VEVSUk9SSVNU PiIgd2l0aCAibTRhMSIgKGRhbWFnZSAiMzIiKSAoZGFtYWdlX2FybW9yICIwIikgKGhlYWx0 aCAiOTU4MCIpIChhcm1vciAiMCIpIChoaXRncm91cCAiY2hlc3QiKQoAUHmMThWcBgCbAAAA mwAAAAAwSHERpAAwSIL5LAgARQAAjSPvAABAEX6QW+MQClvjEBEANWDdAHnFYeVJgYAAAQAC AAIAAAN3d3cFc3BlYzMJaW50ZXJzdG9sAnJ1AAABAAHADAAFAAEAA46FAALAEMAQAAEAAQAD joUABNlBAxXAFgACAAEAA46DAA0DbnMyBm1yLXdlYsAgwBYAAgABAAOOgwAGA25zMcBWUHmM Tg7BBgBKAAAASgAAAAAwSHERpAALRRz0GggARQAAPGIvQAA3Bnu6XHCdblvjEBGJYgBQLRbT EQAAAACgAhawK08AAAIEBYQEAggKE0MDRQAAAAABAwMDUHmMTq/jBgDEAAAAxAAAAAAwSHER pAAwSIL5LAgARQAAtiP0AABAEX5iW+MQClvjEBEANSpCAKIY1UymhYAAAQACAAIAAgJjcwls aXZlLXN1cmYCcnUJaG9zdC1mb29kAnJ1AAABAAHADAAFAAEAAA4QAAoHdGVzdC1oZsAmwDoA AQABAAAOEAAEW+MQC8A6AAIAAQAADhAABwRkbnMxwBzAOgACAAEAAA4QAAcEZG5zMMAcwHMA AQABAAAOEAAEW+MQCsBgAAEAAQAADhAABFvjEQtQeYxOgwAHAD4AAAA+AAAAADBIcRGkAAtF HPQaCABFAAAwY4tAAHYGve0utUimW+MQEQkNAFCJStRjAAAAAHACIAAYxQAAAgQFtAEBBAJQ eYxOURoHAAcBAAAHAQAAADBIcRGkAAtFHPQaCABFAAD5zioAAHYR8nC8hlreW+MQEWmInEUA 5TRV/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNzogIkJvbmQ8MjM1PjxTVEVBTV8wOjA6 MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIgYXR0YWNrZWQgIkNvbnN0cmF5PDI1MD48U1RFQU1f MDowOjE5ODQ4MDE1MTI+PENUPiIgd2l0aCAiYXVnIiAoZGFtYWdlICIyMSIpIChkYW1hZ2Vf YXJtb3IgIjQiKSAoaGVhbHRoICIxNiIpIChhcm1vciAiODAiKSAoaGl0Z3JvdXAgInJpZ2h0 IGFybSIpCgBQeYxO1kIHAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwuGdAAGgG31Jv858m W+MQEb0HABlPj6PwAAAAAHAC//9XhQAAAgQFoAEBBAJQeYxO21EHAAoCAAAKAgAAADBIcRGk AAtFHPQaCABFAAH8cx0AAPARIopdZGnxW+MQEd+7E8QB6GHaUkVHSVNURVIgc2lwOnBieC5z aWFsdGVsZS5jb20gU0lQLzIuMA0KVmlhOiBTSVAvMi4wL1VEUCAxOTIuMTY4LjAuMTc2OjUw NjE7YnJhbmNoPXo5aEc0YkstNjYzMzRhZTgNCkZyb206IDxzaXA6dHJpcy02MDBAcGJ4LnNp YWx0ZWxlLmNvbT47dGFnPTNmNzQyNDEzM2I4N2IyY28xDQpUbzogPHNpcDp0cmlzLTYwMEBw Ynguc2lhbHRlbGUuY29tPg0KQ2FsbC1JRDogZTIzZmFjMTAtODMyMmY2NmZAMTkyLjE2OC4w LjE3Ng0KQ1NlcTogNDMxOTMgUkVHSVNURVINCk1heC1Gb3J3YXJkczogNzANCkNvbnRhY3Q6 IDxzaXA6dHJpcy02MDBAMTkyLjE2OC4wLjE3Njo1MDYxPjtleHBpcmVzPTM2MDANClVzZXIt QWdlbnQ6IExpbmtzeXMvUEFQMlQtMy4xLjE1KExTKQ0KQ29udGVudC1MZW5ndGg6IDANCkFs bG93OiBBQ0ssIEJZRSwgQ0FOQ0VMLCBJTkZPLCBJTlZJVEUsIE5PVElGWSwgT1BUSU9OUywg UkVGRVINClN1cHBvcnRlZDogeC1zaXB1cmENCg0KUHmMTmJpBwBKAAAASgAAAAAwSHERpAAw SIL5LAgARQAAPCQBQABABj7aW+MQClvjEBGIgwG7aYrr1gAAAACgAv//bIwAAAIEBbQBAwMD BAIIChYpDc4AAAAAUHmMTsGXBwAEAQAABAEAAAAwSHERpAALRRz0GggARQAA9s5HAAB2EfJW vIZa3lvjEBFpiJxFAOKGoP////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDc6ICJCZXJrYW42 ODwyNDA+PFNURUFNXzA6MDoxMzcxODgwMjA4PjxDVD4iIGF0dGFja2VkICJCb25kPDIzNT48 U1RFQU1fMDowOjExMzAyOTg5MzI+PFRFUlJPUklTVD4iIHdpdGggInVzcCIgKGRhbWFnZSAi MTIiKSAoZGFtYWdlX2FybW9yICI2IikgKGhlYWx0aCAiOTg4IikgKGFybW9yICI4NiIpICho aXRncm91cCAiY2hlc3QiKQoAUHmMToWcBwAEAQAABAEAAAAwSHERpAALRRz0GggARQAA9s5I AAB2EfJVvIZa3lvjEBFpiJxFAOKYpf////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDc6ICJD b25zdHJheTwyNTA+PFNURUFNXzA6MDoxOTg0ODAxNTEyPjxDVD4iIGF0dGFja2VkICJCb25k PDIzNT48U1RFQU1fMDowOjExMzAyOTg5MzI+PFRFUlJPUklTVD4iIHdpdGggIm00YTEiIChk YW1hZ2UgIjQyIikgKGRhbWFnZV9hcm1vciAiOSIpIChoZWFsdGggIjk0NiIpIChhcm1vciAi NzYiKSAoaGl0Z3JvdXAgImhlYWQiKQoAUHmMTke/BwBiAAAAYgAAAAAwSHERpAALRRz0GggA RQAAVEyxAAA3ARWdw13xC1vjEQ8IAE1umLl3LE6MeWkACOeqCAkKCwwNDg8QERITFBUWFxgZ GhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3UHmMTpLvBwA+AAAAPgAAAAAwSHERpAAL RRz0GggARQAAMDTOQAB3BmiZskFIK1vjEBEK6ABQSXIMhQAAAABwAv//u78AAAIEBYQBAQQC UHmMTiR4CAA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMKk9QAB4Bm1MVa4qnFvjEBEIOwBQ t16xXAAAAABwAmBsxZIAAAIEBVABAQQCUHmMTg95CAAGAQAABgEAAAAwSHERpAALRRz0GggA RQAA+M6FAAB2EfIWvIZa3lvjEBFpiJxFAOTS6/////9STCAxMC8wNS8yMDExIC0gMTk6MzY6 MDc6ICJCb25kPDIzNT48U1RFQU1fMDowOjExMzAyOTg5MzI+PFRFUlJPUklTVD4iIGF0dGFj a2VkICJDb25zdHJheTwyNTA+PFNURUFNXzA6MDoxOTg0ODAxNTEyPjxDVD4iIHdpdGggImF1 ZyIgKGRhbWFnZSAiMjEiKSAoZGFtYWdlX2FybW9yICI0IikgKGhlYWx0aCAiMCIpIChhcm1v ciAiNzUiKSAoaGl0Z3JvdXAgInJpZ2h0IGFybSIpCgBQeYxObH4IALAAAACwAAAAADBIcRGk AAtFHPQaCABFAACizoYAAHYR8mu8hlreW+MQEWmInEUAjqZt/////1JMIDEwLzA1LzIwMTEg LSAxOTozNjowNzogV29ybGQgdHJpZ2dlcmVkICJraWxsbG9jYXRpb24iIChhdHRhY2tlcl9w b3NpdGlvbiAiLTEwMjggLTc4MyAxMzEiKSAodmljdGltX3Bvc2l0aW9uICItMTcxOSAtNzQ2 IDE3NyIpCgBQeYxO6X4IALIAAACyAAAAADBIcRGkAAtFHPQaCABFAACkzocAAHYR8mi8hlre W+MQEWmInEUAkC8+/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNzogIkJvbmQ8MjM1PjxT VEVBTV8wOjA6MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIga2lsbGVkICJDb25zdHJheTwyNTA+ PFNURUFNXzA6MDoxOTg0ODAxNTEyPjxDVD4iIHdpdGggImF1ZyIKAFB5jE7ifwgA9AAAAPQA AAAAMEhxEaQAC0Uc9BoIAEUAAObOiAAAdhHyJbyGWt5b4xARaYicRQDSLBH/////UkwgMTAv MDUvMjAxMSAtIDE5OjM2OjA3OiAiQ29uc3RyYXk8MjUwPjxTVEVBTV8wOjA6MTk4NDgwMTUx Mj48Q1Q+IiB0cmlnZ2VyZWQgIndlYXBvbnN0YXRzIiAod2VhcG9uICJtNGExIikgKHNob3Rz ICIxNyIpIChoaXRzICIzIikgKGtpbGxzICIxIikgKGhlYWRzaG90cyAiMCIpICh0a3MgIjAi KSAoZGFtYWdlICI5MSIpIChkZWF0aHMgIjAiKQoAUHmMTtqACAD7AAAA+wAAAAAwSHERpAAL RRz0GggARQAA7c6JAAB2EfIdvIZa3lvjEBFpiJxFANnzVP////9STCAxMC8wNS8yMDExIC0g MTk6MzY6MDc6ICJDb25zdHJheTwyNTA+PFNURUFNXzA6MDoxOTg0ODAxNTEyPjxDVD4iIHRy aWdnZXJlZCAid2VhcG9uc3RhdHMyIiAod2VhcG9uICJtNGExIikgKGhlYWQgIjEiKSAoY2hl c3QgIjAiKSAoc3RvbWFjaCAiMSIpIChsZWZ0YXJtICIxIikgKHJpZ2h0YXJtICIwIikgKGxl ZnRsZWcgIjAiKSAocmlnaHRsZWcgIjAiKQoAUHmMTtKBCADxAAAA8QAAAAAwSHERpAALRRz0 GggARQAA486KAAB2EfImvIZa3lvjEBFpiJxFAM8bd/////9STCAxMC8wNS8yMDExIC0gMTk6 MzY6MDc6ICJDb25zdHJheTwyNTA+PFNURUFNXzA6MDoxOTg0ODAxNTEyPjxDVD4iIHRyaWdn ZXJlZCAid2VhcG9uc3RhdHMiICh3ZWFwb24gInVzcCIpIChzaG90cyAiMiIpIChoaXRzICIw IikgKGtpbGxzICIwIikgKGhlYWRzaG90cyAiMCIpICh0a3MgIjAiKSAoZGFtYWdlICIwIikg KGRlYXRocyAiMCIpCgBQeYxOzYIIAPoAAAD6AAAAADBIcRGkAAtFHPQaCABFAADszosAAHYR 8hy8hlreW+MQEWmInEUA2K16/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNzogIkNvbnN0 cmF5PDI1MD48U1RFQU1fMDowOjE5ODQ4MDE1MTI+PENUPiIgdHJpZ2dlcmVkICJ3ZWFwb25z dGF0czIiICh3ZWFwb24gInVzcCIpIChoZWFkICIwIikgKGNoZXN0ICIwIikgKHN0b21hY2gg IjAiKSAobGVmdGFybSAiMCIpIChyaWdodGFybSAiMCIpIChsZWZ0bGVnICIwIikgKHJpZ2h0 bGVnICIwIikKAFB5jE7XgggAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBU/QAAegYyBdVP eIJb4xARifoAUJ0zLcoAAAAAcAJAADQRAAACBAW0AQEEAlB5jE7HwAgAPgAAAD4AAAAAMEhx EaQAC0Uc9BoIAEUAADBtXkAAegZbVFw1b+xb4xAR6DERXAIZtGEAAAAAcAL//5sBAAACBAW0 AQEEAlB5jE461wgAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADB+x0AAdgah6k0zKu9b4xAR wN4AUAG8Q8oAAAAAcAIgAHhcAAACBAWsAQEEAlB5jE6K3ggASgAAAEoAAAAAMEhxEaQAC0Uc 9BoIAEUAADyoDkAANgZksFA2e9Nb4xARsrwAUI40/OQAAAAAoAIW0DElAAACBAW0BAIICjGC WGwAAAAAAQMDAFB5jE68FAkASgAAAEoAAAAAMEhxEaQAC0Uc9BoIAEUAADylIkAAOQbsWlDv 81tb4xARufIAUEqZdzcAAAAAoAIW0M3oAAACBAW0BAIIClwT2uEAAAAAAQMDB1B5jE6dQAkA SAAAAEgAAAAAMEhxEaQAMEiC+WwIAEUAADrRtAAAQBHQHFvjEQtb4xARzRMANQAmgZr6OQAA AAEAAAAAAAAFd21idXgDYnpzAnN1AAAGAAFQeYxO+6oJAAcBAAAHAQAAADBIcRGkAAtFHPQa CABFAAD5ztAAAHYR8cq8hlreW+MQEWmInEUA5cR2/////1JMIDEwLzA1LzIwMTEgLSAxOToz NjowNzogIkJlcmthbjY4PDI0MD48U1RFQU1fMDowOjEzNzE4ODAyMDg+PENUPiIgYXR0YWNr ZWQgIkJvbmQ8MjM1PjxTVEVBTV8wOjA6MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIgd2l0aCAi dXNwIiAoZGFtYWdlICIxOSIpIChkYW1hZ2VfYXJtb3IgIjAiKSAoaGVhbHRoICI5MjciKSAo YXJtb3IgIjc2IikgKGhpdGdyb3VwICJsZWZ0IGxlZyIpCgBQeYxOI0YKAEIAAABCAAAAADBI cRGkADBIgvlsCABFAAA00bdAAEAGkSpb4xALW+MQEQBQx/e9+WHj+w0FoIAS//+vUQAAAgQF tAEDAwMEAgAAUHmMTppvCgAJAQAACQEAAAAwSHERpAALRRz0GggARQAA+88HAAB2EfGRvIZa 3lvjEBFpiZxFAOc4Mv////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDc6ICJfK19jZWtpc3Rf K188MzE3PjxTVEVBTV8wOjA6Njc0MjM5Mzk3PjxURVJST1JJU1Q+IiBhdHRhY2tlZCAiYWU8 Mjg5PjxTVEVBTV8wOjA6NDE5NjMwNTk3PjxDVD4iIHdpdGggIm00YTEiIChkYW1hZ2UgIjIz IikgKGRhbWFnZV9hcm1vciAiMCIpIChoZWFsdGggIjI3IikgKGFybW9yICIxMDAiKSAoaGl0 Z3JvdXAgInJpZ2h0IGxlZyIpCgBQeYxOjoUKAEoAAABKAAAAADBIcRGkAAtFHPQaCABFEAA8 nxlAADoGdMvByP8KW+MQEQBQwp7XzWrmp2ojWaASIADiyQAAAgQFtAEDAwMEAggKjBMSqxoP jy5QeYxOb4oKADwAAAA8AAAAADBIcRGkAAtFHPQaCABFAAAoPDZAAPcGtQRFq+D1W+MQEYAj AFDKrspVAAAAAFAUAAAHxAAAAAAAAAAAUHmMTmKMCgA+AAAAPgAAAAAwSHERpAALRRz0GggA RQAAMGSUQAB2BrzkLrVIplvjEBEJDgBQ4Ti9ugAAAABwAiAA134AAAIEBbQBAQQCUHmMTjm7 CgBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANEtqQAB3BhPssl+GGlvjEBHpUwBQcKrqCQAA AACAAiAAZmQAAAIEBaABAwMCAQEEAlB5jE6GPAsAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADCrJEAAfAbSb14ttxJb4xAREMMAUCrfC8kAAAAAcAL//7qUAAACBAVQAQEEAlB5jE4XTgsA PgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADDTY0AAfAbBIR+D3stb4xARD+gAULzg6uwAAAAA cAL//2DrAAACBAWgAQEEAlB5jE6OYwsA/wAAAP8AAAAAMEhxEaQAC0Uc9BoIAEUAAPEAAEAA OBG8ei4y61tb4xARaYg+gwDdGgT/////RAsAcGxheWVyNjY2ICgxMDIpABAAAACYLMxDAGFr LTQ3AAEAAADsQgVEADJQYWMAFgAAAHS4G0QAWF9DcmF6WT5LYVN0UnVMeQAIAAAAQKTIQwBk b3MACQAAAOB9uUMAb0xvTG8gQmVaIEdtTwALAAAAOFmyQwBzAAUAAADgl4pDAExvdzJhcQAM AAAAeMTLQwBzbWlyAAAAAADwL81DAEJdb1tULnRlQW0uX19WaVRhTDR5a19fAAoAAACoyLxD AFBATG80a0EACwAAAEicyENQeYxOC2QLAMsAAADLAAAAADBIcRGkAAtFHPQaCABFAAC9AABA ADgRvK4uMutbW+MQEWmIPoMAqQbZ/////20xMjcuMC4wLjE6MjcwMTYAW0NTU0UtUlYuUlVd IFtDU0RNK9Cf0KPQqNCa0Jgr0JvQkNCX0JXQoNCrXSBb0KfQldCb0J7QktCV0Jog0J3QkCDQ n9CQ0KDQkNCo0K7QotCY0JrQlV3CqQBkZV9kdXN0AGNzdHJpa2UAW0NTc2UtcnYucnVdAAsg L2RsAAEAAAABAAAAAAAAAAEAAQBQeYxOiGQLAMAAAADAAAAAADBIcRGkAAtFHPQaCABFAACy AABAADgRvLkuMutbW+MQEWmIPoMAnuwb/////0kwW0NTU0UtUlYuUlVdIFtDU0RNK9Cf0KPQ qNCa0Jgr0JvQkNCX0JXQoNCrXSBb0KfQldCb0J7QktCV0Jog0J3QkCDQn9CQ0KDQkNCo0K7Q otCY0JrQlV3CqQBkZV9kdXN0AGNzdHJpa2UAW0NTc2UtcnYucnVdAAoACyAAZGwAATEuMS4y LjYvU3RkaW8AgIhpUHmMTtaUCwBKAAAASgAAAAAwSHERpAALRRz0GggARQAAPM1XQAA5BkhD 2dTmWFvjEBHetwBQR3femwAAAACgAhbQh0sAAAIEBbQEAggKXBAcmAAAAAABAwMHUHmMTg+g CwCAAAAAgAAAAAAwSHERpAAwSIL5LAgARQAAciRxAABAEX4pW+MQClvjEBEANUdYAF6+OmNZ hYAAAQAAAAEAAARzcnY3CWhvc3QtZm9vZAJydQAAHAABwBEABgABAAABLAAnBGRuczDAEQRy b290BHNydjHAEXfe1CEAAAEsAAAAlgAJOoAAAAEsUHmMTtesCwBKAAAASgAAAAAwSHERpAAL RRz0GggARQAAPAG5AAA1Bnz3XVA9yFvjEBG+6wBQh3aS1wAAAACgAhbQY6EAAAIEBYwEAggK AMLsXgAAAAABAwMHUHmMToC4CwBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANB3UQABuBili 1VeEQlvjEBGrAABQdv3/SwAAAACAAv//iI8AAAIEBRQBAwMBAQEEAlB5jE6q7QsABwEAAAcB AAAAMEhxEaQAC0Uc9BoIAEUAAPnPWgAAdhHxQLyGWt5b4xARaYicRQDlhYn/////UkwgMTAv MDUvMjAxMSAtIDE5OjM2OjA3OiAiQm9uZDwyMzU+PFNURUFNXzA6MDoxMTMwMjk4OTMyPjxU RVJST1JJU1Q+IiBhdHRhY2tlZCAiQmVya2FuNjg8MjQwPjxTVEVBTV8wOjA6MTM3MTg4MDIw OD48Q1Q+IiB3aXRoICJhdWciIChkYW1hZ2UgIjIxIikgKGRhbWFnZV9hcm1vciAiNCIpICho ZWFsdGggIjc5IikgKGFybW9yICI5NSIpIChoaXRncm91cCAicmlnaHQgYXJtIikKAFB5jE52 9QsAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUCADBiJ0AAeAYg19mWOj1b4xARBjEAUB7v7KUA AAAAcAJAALHhAAACBAUUAQEEAlB5jE7x9QsAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUCADBi KEAAeAYg1tmWOj1b4xARBjQAUPbbuR8AAAAAcAJAAA14AAACBAUUAQEEAlB5jE779QsAPgAA AD4AAAAAMEhxEaQAC0Uc9BoIAEUCADBiKUAAeAYg1dmWOj1b4xARBjUAUNtKXK0AAAAAcAJA AIV6AAACBAUUAQEEAlB5jE6tUQwABQEAAAUBAAAAMEhxEaQAC0Uc9BoIAEUAAPfPdAAAdhHx KLyGWt5b4xARaYmcRQDjl/X/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiS2lyaWxs NDBydXM8MzE2PjxTVEVBTV8wOjA6NzkyNDQzNjg3PjxURVJST1JJU1Q+IiBhdHRhY2tlZCAi YWU8Mjg5PjxTVEVBTV8wOjA6NDE5NjMwNTk3PjxDVD4iIHdpdGggInA5MCIgKGRhbWFnZSAi MTIiKSAoZGFtYWdlX2FybW9yICIyIikgKGhlYWx0aCAiMTUiKSAoYXJtb3IgIjk3IikgKGhp dGdyb3VwICJsZWZ0IGFybSIpCgBQeYxO38IMAEYAAABGAAAAADBIcRGkAAtFHPQaCABFAAA4 5GtAAD0Gjb/ZRYZbW+MQEd1uAFC3n8LGAAAAAJACFtC0awAAAgQFtAQCCAo6tDJkAAAAAFB5 jE4nWQ0AQgAAAEIAAAAAMEhxEaQAMEiC+WwIAEUAADTRxEAAQAaRHVvjEAtb4xARAFDH9735 YeP7DQWggBL//69RAAACBAW0AQMDAwQCAABQeYxOBOwNAEIAAABCAAAAADBIcRGkAAtFHPQa CABFAAA0Yo9AAHoGS2kCXeR6W+MQEc+lAFDVnyugAAAAAIACIAAreQAAAgQFUAEDAwIBAQQC UHmMTiwODgBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANDr+QABwBqd2KU6TDVvjEBFC8QBQ 2t/+hAAAAACAAiAACjcAAAIEBZgBAwMIAQEEAlB5jE7Jbw4APgAAAD4AAAAAMEhxEaQAC0Uc 9BoIAEUAADBR9EAAeQaHLy5Ijmhb4xARzYwAUHYjBIYAAAAAcAIgAPH0AAACBAW0AQEEAlB5 jE6Vdg4ABgEAAAYBAAAAMEhxEaQAC0Uc9BoIAEUAAPjP9wAAdhHwpLyGWt5b4xARaYicRQDk TRn/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiQmVya2FuNjg8MjQwPjxTVEVBTV8w OjA6MTM3MTg4MDIwOD48Q1Q+IiBhdHRhY2tlZCAiQm9uZDwyMzU+PFNURUFNXzA6MDoxMTMw Mjk4OTMyPjxURVJST1JJU1Q+IiB3aXRoICJ1c3AiIChkYW1hZ2UgIjEzIikgKGRhbWFnZV9h cm1vciAiNiIpIChoZWFsdGggIjg3IikgKGFybW9yICI2OSIpIChoaXRncm91cCAibGVmdCBh cm0iKQoAUHmMToN5DgA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMFH1QAB5BocuLkiOaFvj EBHNjQBQig/vAAAAAABwAiAA84wAAAIEBbQBAQQCUHmMTq08DwA+AAAAPgAAAAAwSHERpAAL RRz0GggARQAAMJ/yQAB7BuwRHxzos1vjEBEIyABQ4UnXaQAAAABwAkAADfQAAAIEBVABAQQC UXmMTvo0AAA8AAAAPAAAAAAwSHERpAALRRz0GggARQAAKAAAQAA6Brb3TlXPj1vjEBH76QBQ vxjioAAAAABQBAAAiBQAAAAAAAAAAFF5jE7oNwAAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADDRiEAAeQZBBW1vFddb4xARBDgAUNJmn2wAAAAAcAL//x2eAAACBAWgAQEEAlF5jE4UqgAA PgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADAGCUAAdwbfxbx79Ylb4xARmm0AUPyJQT0AAAAA cAJAAEyhAAACBAW0AQEEAlF5jE7KtQAABAEAAAQBAAAAMEhxEaQAC0Uc9BoIAEUAAPbQVAAA dhHwSbyGWt5b4xARaYmcRQDiL53/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiS2ly aWxsNDBydXM8MzE2PjxTVEVBTV8wOjA6NzkyNDQzNjg3PjxURVJST1JJU1Q+IiBhdHRhY2tl ZCAiYWU8Mjg5PjxTVEVBTV8wOjA6NDE5NjMwNTk3PjxDVD4iIHdpdGggInA5MCIgKGRhbWFn ZSAiMTIiKSAoZGFtYWdlX2FybW9yICIwIikgKGhlYWx0aCAiMyIpIChhcm1vciAiOTciKSAo aGl0Z3JvdXAgImxlZnQgbGVnIikKAFF5jE4luwAAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADAGCkAAdwbfxLx79Ylb4xARnhAAULNrMG0AAAAAcAJAAKLsAAACBAW0AQEEAlF5jE4evAAA PgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADB6jUAAdwaLrc8uwmpb4xAR8ZsAUKEWIjAAAAAA cAIgALBfAAACBAW0AQEEAlF5jE5/JgEABgEAAAYBAAAAMEhxEaQAC0Uc9BoIAEUAAPjQbwAA dhHwLLyGWt5b4xARaYmcRQDkSPX/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiXytf Y2VraXN0XytfPDMxNz48U1RFQU1fMDowOjY3NDIzOTM5Nz48VEVSUk9SSVNUPiIgYXR0YWNr ZWQgImFlPDI4OT48U1RFQU1fMDowOjQxOTYzMDU5Nz48Q1Q+IiB3aXRoICJtNGExIiAoZGFt YWdlICIyMyIpIChkYW1hZ2VfYXJtb3IgIjAiKSAoaGVhbHRoICIwIikgKGFybW9yICI5NyIp IChoaXRncm91cCAibGVmdCBsZWciKQoAUXmMThU5AQCuAAAArgAAAAAwSHERpAALRRz0GggA RQAAoNBwAAB2EfCDvIZa3lvjEBFpiZxFAIzUq/////9STCAxMC8wNS8yMDExIC0gMTk6MzY6 MDc6IFdvcmxkIHRyaWdnZXJlZCAia2lsbGxvY2F0aW9uIiAoYXR0YWNrZXJfcG9zaXRpb24g IjE2MDAgMjc2MCAxNDEiKSAodmljdGltX3Bvc2l0aW9uICIxNDQ5IDI0MjUgMTAzIikKAFF5 jE6GOQEAswAAALMAAAAAMEhxEaQAC0Uc9BoIAEUAAKXQcQAAdhHwfbyGWt5b4xARaYmcRQCR Nzr/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiXytfY2VraXN0XytfPDMxNz48U1RF QU1fMDowOjY3NDIzOTM5Nz48VEVSUk9SSVNUPiIga2lsbGVkICJhZTwyODk+PFNURUFNXzA6 MDo0MTk2MzA1OTc+PENUPiIgd2l0aCAibTRhMSIKAFF5jE6AOgEA7QAAAO0AAAAAMEhxEaQA C0Uc9BoIAEUAAN/QcgAAdhHwQryGWt5b4xARaYmcRQDLAjz/////UkwgMTAvMDUvMjAxMSAt IDE5OjM2OjA3OiAiYWU8Mjg5PjxTVEVBTV8wOjA6NDE5NjMwNTk3PjxDVD4iIHRyaWdnZXJl ZCAid2VhcG9uc3RhdHMiICh3ZWFwb24gImRlYWdsZSIpIChzaG90cyAiMSIpIChoaXRzICIw IikgKGtpbGxzICIwIikgKGhlYWRzaG90cyAiMCIpICh0a3MgIjAiKSAoZGFtYWdlICIwIikg KGRlYXRocyAiMCIpCgBReYxOeTsBAPYAAAD2AAAAADBIcRGkAAtFHPQaCABFAADo0HMAAHYR 8Di8hlreW+MQEWmJnEUA1Ofq/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowNzogImFlPDI4 OT48U1RFQU1fMDowOjQxOTYzMDU5Nz48Q1Q+IiB0cmlnZ2VyZWQgIndlYXBvbnN0YXRzMiIg KHdlYXBvbiAiZGVhZ2xlIikgKGhlYWQgIjAiKSAoY2hlc3QgIjAiKSAoc3RvbWFjaCAiMCIp IChsZWZ0YXJtICIwIikgKHJpZ2h0YXJtICIwIikgKGxlZnRsZWcgIjAiKSAocmlnaHRsZWcg IjAiKQoAUXmMToVNAQBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANGn+QABzBiTislhal1vj EBHtHwBQOr6CdAAAAACAAiAAK5gAAAIEBawBAwMCAQEEAlF5jE6/gAEAPgAAAD4AAAAAMEhx EaQAC0Uc9BoIAEUAADDRpUAAeQZA6G1vFddb4xARBDkAUDnBhswAAAAAcAL//87iAAACBAWg AQEEAlF5jE7KgAEAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADDRpkAAeQZA521vFddb4xAR BDoAUP0rs9wAAAAAcAL//95mAAACBAWgAQEEAlF5jE48gQEAPgAAAD4AAAAAMEhxEaQAC0Uc 9BoIAEUAADDRp0AAeQZA5m1vFddb4xARBDsAUIu+RRgAAAAAcAL//76XAAACBAWgAQEEAlF5 jE5GgQEAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADDRqEAAeQZA5W1vFddb4xARBDwAUDIu 9isAAAAAcAL//2cTAAACBAWgAQEEAlF5jE64gQEAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUA ADDRqUAAeQZA5G1vFddb4xARBD0AUIgBITYAAAAAcAL//+Y0AAACBAWgAQEEAlF5jE7PHwIA PgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADANz0AAdgba+LJ5/ZJb4xARYXUAUPlT4bMAAAAA cAIgAAqOAAACBAV4AQEEAlF5jE7wLgIABgEAAAYBAAAAMEhxEaQAC0Uc9BoIAEUAAPjQqwAA dhHv8LyGWt5b4xARaYicRQDkUCH/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA3OiAiQmVy a2FuNjg8MjQwPjxTVEVBTV8wOjA6MTM3MTg4MDIwOD48Q1Q+IiBhdHRhY2tlZCAiQm9uZDwy MzU+PFNURUFNXzA6MDoxMTMwMjk4OTMyPjxURVJST1JJU1Q+IiB3aXRoICJ1c3AiIChkYW1h Z2UgIjEzIikgKGRhbWFnZV9hcm1vciAiNiIpIChoZWFsdGggIjc0IikgKGFybW9yICI2MiIp IChoaXRncm91cCAibGVmdCBhcm0iKQoAUXmMTr9KAgBCAAAAQgAAAAAwSHERpAALRRz0GggA RQAANNdpQAB2BvjXW8xswlvjEBH3fABQhEjr5wAAAACAAv//0pcAAAIEBbQBAwMBAQEEAlF5 jE5slAIAPAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUAACyyVEAAdQbVHXkImV1b4xARwfsAGUjZ p1YAAAAAYAJAACeIAAACBAW0AABReYxOkgcDAA4BAAAOAQAAADBIcRGkAAtFHPQaCABFEAEA AABAADwRmP4+jPpeW+MQEWm4nEYA7ABE/////1JMIDEwLzA1LzIwMTEgLSAxOTo0MDo1ODog InszYURyT19vVGlLfS1TVFJFTE9LIDI1PDU3PjxTVEVBTV8wOjA6Mzk4NDYzMDA+PENUPiIg YXR0YWNrZWQgIkJPeWtPPDcyPjxTVEVBTV8wOjA6Mzg5Nzc1Njg+PFRFUlJPUklTVD4iIHdp dGggImFrNDciIChkYW1hZ2UgIjcwIikgKGRhbWFnZV9hcm1vciAiMCIpIChoZWFsdGggIjkx OTAiKSAoYXJtb3IgIjAiKSAoaGl0Z3JvdXAgImhlYWQiKQoAUXmMTvpHAwCJAAAAiQAAAAAw SHERpAAwSIL5LAgARQAAeyY5AABAEXxYW+MQClvjEBEANT8UAGcIHUyrgYAAAQABAAIAAAN3 d3cHY2FzaGluZwJzdQAAAQABwAwAAQABAABELAAEvCiM78AQAAIAAQAE4WwAEARkbnMyBnlh bmRleAJydQDAEAACAAEABOFsAAcEZG5zMcBBUXmMTl6eAwDLAAAAywAAAAAwSHERpAAwSIL5 bAgARQAAvdHYAABAEc91W+MRC1vjEBEANStKAKnH5IhQhYAAAQACAAIAAwducHBpcmlzAnJ1 AAAPAAHADAAPAAEAAA4QAAkACgRtYWlswAzADAAPAAEAAA4QAAQAFMAqwAwAAgABAAAOEAAR BGRuczAJaG9zdC1mb29kwBTADAACAAEAAA4QAAcEZG5zMcBSwCoAAQABAAAOEAAEW+MQEcBN AAEAAQAADhAABFvjEArAagABAAEAAA4QAARb4xELUXmMTq6kAwAXAQAAFwEAAAAwSHERpAAL RRz0GggARRABCQAAQAA8EZj1Poz6XlvjEBFpuJxGAPXAP/////9STCAxMC8wNS8yMDExIC0g MTk6NDA6NTg6ICLguZbbo9ucUzFuM3J8fHwoWmNMKSAi0LvQvtGF4oeTPDY5PjxTVEVBTV8w OjE6Mzk3ODQ2MjM+PENUPiIgYXR0YWNrZWQgIkJPeWtPPDcyPjxTVEVBTV8wOjA6Mzg5Nzc1 Njg+PFRFUlJPUklTVD4iIHdpdGggIm00YTEiIChkYW1hZ2UgIjEzMCIpIChkYW1hZ2VfYXJt b3IgIjAiKSAoaGVhbHRoICI5MDYwIikgKGFybW9yICIwIikgKGhpdGdyb3VwICJoZWFkIikK AFF5jE7nFAQAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADRpI0AAegYnvLKbUVVb4xAR138A UFvZPPkAAAAAgAIgAG6PAAACBAW0AQMDAgEBBAJReYxOnYUEAD4AAAA+AAAAADBIcRGkAAtF HPQaCABFAAAwNMlAAHwGvpouAHFwW+MQEQvVAFAmMfxxAAAAAHACIAApBwAAAgQFoAEBBAJR eYxOEocEAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwNMpAAHwGvpkuAHFwW+MQEQvWAFDX fJ9hAAAAAHACIADUygAAAgQFoAEBBAJReYxOvJQEAFIAAABSAAAAADBIcRGkADBIgvlsCABF AABE0eIAAEARz+Rb4xELW+MQEc0TADUAMLI6bNcAAAABAAAAAAABCGFydGVtaWtvAnJ1AAAG AAEAACkIAAAAAAAAAFF5jE6RmwQAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBg2EAAegb4 sF8l3CVb4xARDTwAUMui1P0AAAAAcAL//y3IAAACBAWgAQEEAlF5jE6KnAQADwEAAA8BAAAA MEhxEaQAC0Uc9BoIAEUQAQEAAEAAPBGY/T6M+l5b4xARabicRgDtkCn/////UkwgMTAvMDUv MjAxMSAtIDE5OjQwOjU4OiAiezNhRHJPX29UaUt9LVNUUkVMT0sgMjU8NTc+PFNURUFNXzA6 MDozOTg0NjMwMD48Q1Q+IiBhdHRhY2tlZCAiQk95a088NzI+PFNURUFNXzA6MDozODk3NzU2 OD48VEVSUk9SSVNUPiIgd2l0aCAiYWs0NyIgKGRhbWFnZSAiMTciKSAoZGFtYWdlX2FybW9y ICIwIikgKGhlYWx0aCAiNzc0MyIpIChhcm1vciAiMCIpIChoaXRncm91cCAiY2hlc3QiKQoA UXmMTuKiBAA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMD4dQABpBlvaO17QflvjEBHgUAAZ 7EBMVgAAAABwAiAA0lUAAAIEBawBAQQCUXmMTkCoBAAGAQAABgEAAAAwSHERpAALRRz0GggA RQAA+NEyAAB2Ee9pvIZa3lvjEBFpiJxFAORUH/////9STCAxMC8wNS8yMDExIC0gMTk6MzY6 MDc6ICJCZXJrYW42ODwyNDA+PFNURUFNXzA6MDoxMzcxODgwMjA4PjxDVD4iIGF0dGFja2Vk ICJCb25kPDIzNT48U1RFQU1fMDowOjExMzAyOTg5MzI+PFRFUlJPUklTVD4iIHdpdGggInVz cCIgKGRhbWFnZSAiMTQiKSAoZGFtYWdlX2FybW9yICI3IikgKGhlYWx0aCAiNjAiKSAoYXJt b3IgIjU0IikgKGhpdGdyb3VwICJsZWZ0IGFybSIpCgBReYxOBdoEAD4AAAA+AAAAADBIcRGk AAtFHPQaCABFAAAwJB1AAHQGFuheIQGuW+MQEdKGABldHpq+AAAAAHACQACtBwAAAgQFjAEB BAJReYxOVfYEAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwMkpAAHoGyQDVUMQ4W+MQEcQO AFBVDQnLAAAAAHACIAA6cwAAAgQFrAEBBAJReYxO/pAFAD4AAAA+AAAAADBIcRGkAAtFHPQa CABFAAAwMuBAAHUGG01Zv/HnW+MQEc04vGaJSmcwAAAAAHACIAAxfgAAAgQFoAEBBAJReYxO 66cFADwAAAA8AAAAADBIcRGkAAtFHPQaCABFAAAoYqpAAHcG5IFeM/J8W+MQEQ91AFCDDmPD d+4aSVAR//9qYQAAAAAAAAAAUXmMTlrnBQA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMEuw QAB3BlX9snxDqlvjEBE+NgBQk9Wt2AAAAABwAv//oQwAAAIEBXgBAQQCUXmMTppuBgAPAQAA DwEAAAAwSHERpAALRRz0GggARRABAQAAQAA8EZj9Poz6XlvjEBFpuJxGAO2SJv////9STCAx MC8wNS8yMDExIC0gMTk6NDA6NTg6ICJ7M2FEck9fb1RpS30tU1RSRUxPSyAyNTw1Nz48U1RF QU1fMDowOjM5ODQ2MzAwPjxDVD4iIGF0dGFja2VkICJCT3lrTzw3Mj48U1RFQU1fMDowOjM4 OTc3NTY4PjxURVJST1JJU1Q+IiB3aXRoICJhazQ3IiAoZGFtYWdlICIxNyIpIChkYW1hZ2Vf YXJtb3IgIjAiKSAoaGVhbHRoICI3NzI2IikgKGFybW9yICIwIikgKGhpdGdyb3VwICJjaGVz dCIpCgBReYxO9psGAGIAAABiAAAAADBIcRGkAAtFHPQaCABFYABUvtsAADsBssHVtMwDW+MQ EQAAysP2igAATox5agADi7QICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKiss LS4vMDEyMzQ1NjdReYxOuaMGADwAAAA8AAAAADBIcRGkAAtFHPQaCABFAAAsO4tAAD0GufbZ QQMVW+MQEQBQPtjAkLMQpWlEg2ASAACzFQAAAgQFtAAAUXmMThnmBgDEAAAAxAAAAAAwSHER pAAwSIL5LAgARQAAtiZVAABAEXwBW+MQClvjEBEANdbOAKJsSEymhYAAAQACAAIAAgJjcwls aXZlLXN1cmYCcnUJaG9zdC1mb29kAnJ1AAABAAHADAAFAAEAAA4QAAoHdGVzdC1oZsAmwDoA AQABAAAOEAAEW+MQC8A6AAIAAQAADhAABwRkbnMxwBzAOgACAAEAAA4QAAcEZG5zMMAcwHMA AQABAAAOEAAEW+MQCsBgAAEAAQAADhAABFvjEQtReYxOgDgHAAMBAAADAQAAADBIcRGkAAtF HPQaCABFAAD10cMAAHYR7tu8hlreW+MQEWmInEUA4Wsd/////1JMIDEwLzA1LzIwMTEgLSAx OTozNjowODogIkJvbmQ8MjM1PjxTVEVBTV8wOjA6MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIg YXR0YWNrZWQgIkJlcmthbjY4PDI0MD48U1RFQU1fMDowOjEzNzE4ODAyMDg+PENUPiIgd2l0 aCAiYXVnIiAoZGFtYWdlICIyMSIpIChkYW1hZ2VfYXJtb3IgIjQiKSAoaGVhbHRoICI4MyIp IChhcm1vciAiOTAiKSAoaGl0Z3JvdXAgImNoZXN0IikKAFF5jE6aSAcADwEAAA8BAAAAMEhx EaQAC0Uc9BoIAEUQAQEAAEAAPBGY/T6M+l5b4xARabicRgDtlCP/////UkwgMTAvMDUvMjAx MSAtIDE5OjQwOjU4OiAiezNhRHJPX29UaUt9LVNUUkVMT0sgMjU8NTc+PFNURUFNXzA6MDoz OTg0NjMwMD48Q1Q+IiBhdHRhY2tlZCAiQk95a088NzI+PFNURUFNXzA6MDozODk3NzU2OD48 VEVSUk9SSVNUPiIgd2l0aCAiYWs0NyIgKGRhbWFnZSAiMTciKSAoZGFtYWdlX2FybW9yICIw IikgKGhlYWx0aCAiNzcwOSIpIChhcm1vciAiMCIpIChoaXRncm91cCAiY2hlc3QiKQoAUXmM Tk+lBwA+AAAAPgAAAAAwSHERpAALRRz0GggARQAAMBcrQAB6Bp+0vCshyVvjEBHXlwBQsYrt IAAAAABwAiAAorcAAAIEBaABAQQCUXmMTjCqBwACAQAAAgEAAAAwSHERpAALRRz0GggARQAA 9NHcAAB2Ee7DvIZa3lvjEBFpiJxFAOD98f////9STCAxMC8wNS8yMDExIC0gMTk6MzY6MDg6 ICJCZXJrYW42ODwyNDA+PFNURUFNXzA6MDoxMzcxODgwMjA4PjxDVD4iIGF0dGFja2VkICJC b25kPDIzNT48U1RFQU1fMDowOjExMzAyOTg5MzI+PFRFUlJPUklTVD4iIHdpdGggInVzcCIg KGRhbWFnZSAiNTciKSAoZGFtYWdlX2FybW9yICIyOCIpIChoZWFsdGggIjMiKSAoYXJtb3Ig IjI1IikgKGhpdGdyb3VwICJoZWFkIikKAFF5jE6bwQcAYgAAAGIAAAAAMEhxEaQAC0Uc9BoI AEUAAFRMtAAANwEVmsNd8Qtb4xEPCABJf5i5dzZOjHlqAAjrjggJCgsMDQ4PEBESExQVFhcY GRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2N1F5jE4n6AcAPgAAAD4AAAAAMEhxEaQA C0Uc9BoIAEUAADBRJEAAeQZTQluVldhb4xAREH0AUAnhmpkAAAAAcAJAADDaAAACBAVQAQEE AlF5jE5mVwgAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADA02EAAfAa+iy4AcXBb4xARC9oA UHrJhiwAAAAAcAIgAEqvAAACBAWgAQEEAlF5jE5zaQgAPgAAAD4AAAAAMEhxEaQAC0Uc9BoI AEUAADDQzEAAegZWIFqXE1Bb4xARBTkAUEoK6AsAAAAAcALAALH0AAACBAVkAQEEAlF5jE4w iAgAjwAAAI8AAAAAMEhxEaQAC0Uc9BoIAEUAAIFVsUAAfhGFwdkc2+hb4xARaYmcRgBtz/X/ ////UkwgMTAvMDUvMjAxMSAtIDE5OjM0OjA0OiAiQXNzYS1KdW5pb3LihKI8Nzk+PFNURUFN XzA6MTozODc0OTI4OT48VW5hc3NpZ25lZD4iIGpvaW5lZCB0ZWFtICJDVCIKAFF5jE4mAwkA PAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUAACgQwkAAegazZ05qgkhb4xAR+IcAUEnSvk9J0r5P UAQAAGoeAAAAAAAAAABReYxO9AoJAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwT7VAAHcG mCNBNG7HW+MQEbIcAFBoX8TdAAAAAHACIABnhgAAAgQFtAEBBAJReYxOqRYJAEIAAABCAAAA ADBIcRGkAAtFHPQaCABFAAA0+R9AAHYG0YpcNnHvW+MQEQcYAFDQLnDcAAAAAIAC+3zxDgAA AgQFtAEDAwABAQQCUXmMTss7CQAOAQAADgEAAAAwSHERpAALRRz0GggARRABAAAAQAA8EZj+ Poz6XlvjEBFpuJxGAOwINv////9STCAxMC8wNS8yMDExIC0gMTk6NDA6NTg6ICJ7M2FEck9f b1RpS30tU1RSRUxPSyAyNTw1Nz48U1RFQU1fMDowOjM5ODQ2MzAwPjxDVD4iIGF0dGFja2Vk ICJCT3lrTzw3Mj48U1RFQU1fMDowOjM4OTc3NTY4PjxURVJST1JJU1Q+IiB3aXRoICJhazQ3 IiAoZGFtYWdlICI3MCIpIChkYW1hZ2VfYXJtb3IgIjAiKSAoaGVhbHRoICI3NjM5IikgKGFy bW9yICIwIikgKGhpdGdyb3VwICJoZWFkIikKAFF5jE4fugkAhgAAAIYAAAAAMEhxEaQAC0Uc 9BoIAEUAAHgAAEAAORHNfE3cuihb4xARgm31FgBko/X/////bTEyNy4wLjAuMTozMzM4OQBQ cm9eU3RlYW0gRkZBW0NTRE0gU0VSVkVSXQBkZV9kdXN0MgBjc3RyaWtlAENTRE0AEBQvZGwA AQAAAAEAAAAAAAAAAQABAFF5jE6TuwkAJAEAACQBAAAAMEhxEaQAC0Uc9BoIAEUAARYAAEAA ORHM3k3cuihb4xARgm31FgECCZL/////RA0AW3dhcjNmdC5ydV1WTllKSQB4AAAAQJCrRABl YmsubHVja3kAOwAAAAA/GEQAdzEAfgAAAHy+tUUASmFjayAhISEhAAQAAAAAPQpDAHRyZXdx ABwBAAAIqCpFAEdvbGRQQXRyb04tW1hEMjRocF1fdGVhbSkAAwAAAAAUR0IALT1Gcm9zdD0t AAAAAAAAzCVCAEFuZHJpawAAAAAAAPgCQgBadW0AGwAAAAA7m0MAU2tVbExMAO8AAADwsL5E AGZhbG9zIHZpY3RvcnkARAAAAEAmJ0QAQm9KSW9kOSoAJQAAAABGtUMATEs0AAYAAAAA1HJC UXmMThC8CQB7AAAAewAAAAAwSHERpAALRRz0GggARQAAbQAAQAA5Ec2HTdy6KFvjEBGCbfUW AFm9EP////9JMFByb15TdGVhbSBGRkFbQ1NETSBTRVJWRVJdAGRlX2R1c3QyAGNzdHJpa2UA Q1NETQAKABAUAGRsAAExLjEuMi42L1N0ZGlvAIBtglF5jE7j/wkASgAAAEoAAAAAMEhxEaQA C0Uc9BoIAEUAADwBugAAPAYyTF60gA5b4xARrX4AUHQWWY4AAAAAoAIW0H23AAACBAWMBAII CgDC7LQAAAAAAQMDB1F5jE4vMAoAAQEAAAEBAAAAMEhxEaQAC0Uc9BoIAEUAAPPSdwAAdhHu KbyGWt5b4xARaYicRQDfCCj/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA4OiAiQmVya2Fu Njg8MjQwPjxTVEVBTV8wOjA6MTM3MTg4MDIwOD48Q1Q+IiBhdHRhY2tlZCAiQm9uZDwyMzU+ PFNURUFNXzA6MDoxMTMwMjk4OTMyPjxURVJST1JJU1Q+IiB3aXRoICJ1c3AiIChkYW1hZ2Ug IjY1IikgKGRhbWFnZV9hcm1vciAiMjUiKSAoaGVhbHRoICIwIikgKGFybW9yICIwIikgKGhp dGdyb3VwICJoZWFkIikKAFF5jE4ENwoAsAAAALAAAAAAMEhxEaQAC0Uc9BoIAEUAAKLSfAAA dhHudbyGWt5b4xARaYicRQCOnW7/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA4OiBXb3Js ZCB0cmlnZ2VyZWQgImtpbGxsb2NhdGlvbiIgKGF0dGFja2VyX3Bvc2l0aW9uICItMTM4OCAt NzUyIDEyOSIpICh2aWN0aW1fcG9zaXRpb24gIi0xMDI4IC03ODMgMTc4IikKAFF5jE4NNwoA iAAAAIgAAAAAMEhxEaQAC0Uc9BoIAEUAAHrSfQAAdhHunLyGWt5b4xARaYicRQBmj8D///// UkwgMTAvMDUvMjAxMSAtIDE5OjM2OjA4OiAiQmVya2FuNjg8MjQwPjxTVEVBTV8wOjA6MTM3 MTg4MDIwOD48Q1Q+IiB0cmlnZ2VyZWQgImhlYWRzaG90IgoAUXmMTv03CgC9AAAAvQAAAAAw SHERpAALRRz0GggARQAAr9J+AAB2Ee5mvIZa3lvjEBFpiJxFAJuebP////9STCAxMC8wNS8y MDExIC0gMTk6MzY6MDg6ICJCZXJrYW42ODwyNDA+PFNURUFNXzA6MDoxMzcxODgwMjA4PjxD VD4iIGtpbGxlZCAiQm9uZDwyMzU+PFNURUFNXzA6MDoxMTMwMjk4OTMyPjxURVJST1JJU1Q+ IiB3aXRoICJ1c3AiIChoZWFkc2hvdCkKAFF5jE7xOQoA9gAAAPYAAAAAMEhxEaQAC0Uc9BoI AEUAAOjSfwAAdhHuLLyGWt5b4xARaYicRQDU0vT/////UkwgMTAvMDUvMjAxMSAtIDE5OjM2 OjA4OiAiQm9uZDwyMzU+PFNURUFNXzA6MDoxMTMwMjk4OTMyPjxURVJST1JJU1Q+IiB0cmln Z2VyZWQgIndlYXBvbnN0YXRzIiAod2VhcG9uICJhdWciKSAoc2hvdHMgIjExIikgKGhpdHMg IjQiKSAoa2lsbHMgIjEiKSAoaGVhZHNob3RzICIwIikgKHRrcyAiMCIpIChkYW1hZ2UgIjg0 IikgKGRlYXRocyAiMCIpCgBReYxO6zoKAP0AAAD9AAAAADBIcRGkAAtFHPQaCABFAADv0oAA AHYR7iS8hlreW+MQEWmInEUA2z2R/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowODogIkJv bmQ8MjM1PjxTVEVBTV8wOjA6MTEzMDI5ODkzMj48VEVSUk9SSVNUPiIgdHJpZ2dlcmVkICJ3 ZWFwb25zdGF0czIiICh3ZWFwb24gImF1ZyIpIChoZWFkICIwIikgKGNoZXN0ICIxIikgKHN0 b21hY2ggIjAiKSAobGVmdGFybSAiMCIpIChyaWdodGFybSAiMyIpIChsZWZ0bGVnICIwIikg KHJpZ2h0bGVnICIwIikKAFF5jE5RUwoAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADBDlkAA bwYOLlmw9F9b4xARk1kAGcgNJE0AAAAAcAL//0lOAAACBAW0AQEEAlF5jE5ioQoAPgAAAD4A AAAAMEhxEaQAC0Uc9BoIAEUAADBVV0AAdgaTgUE0bsdb4xARshgAUJ59/GYAAAAAcAIgAPni AAACBAW0AQEEAlF5jE5q9wsAUwAAAFMAAAAAMEhxEaQAMEiC+WwIAEUAAEXSEwAAQBHPslvj EQtb4xARzRMANQAx8Jo1KgAAAAEAAAAAAAEJYmFuYW5hd2ViAnJ1AAAGAAEAACkIAAAAAAAA AFF5jE4vKQwAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADT5IEAAdgbRiVw2ce9b4xARBxkA UAFskIYAAAAAgAL7fKAmAAACBAW0AQMDAAEBBAJReYxOxrIMAAUBAAAFAQAAADBIcRGkAAtF HPQaCABFAAD30w0AAHYR7Y+8hlreW+MQEWmInEUA4wjd/////1JMIDEwLzA1LzIwMTEgLSAx OTozNjowODogIkJpT1M8MjA0PjxTVEVBTV8wOjA6MTg1NjU3NDY0OT48VEVSUk9SSVNUPiIg YXR0YWNrZWQgIkNvbnN0cmF5PDI1MD48U1RFQU1fMDowOjE5ODQ4MDE1MTI+PENUPiIgd2l0 aCAibTRhMSIgKGRhbWFnZSAiMjIiKSAoZGFtYWdlX2FybW9yICI0IikgKGhlYWx0aCAiOTkw IikgKGFybW9yICI5NSIpIChoaXRncm91cCAiY2hlc3QiKQoAUXmMTqG4DABCAAAAQgAAAAAw SHERpAALRRz0GggARQAANALyQAB1Bml6wxZqTVvjEBHAPgBQd9oCCgAAAACAAiAAe68AAAIE BVABAwMCAQEEAlF5jE67yAwAPgAAAD4AAAAAMEhxEaQAC0Uc9BoIAEUAADAOwkAAdgayJCmI rmVb4xAR2qUAGURfGZUAAAAAcAIgAOaSAAACBAWsAQEEAlF5jE7Teg0APgAAAD4AAAAAMEhx EaQAC0Uc9BoIAEUAADBI/0AAfAYRW1vX3KJb4xARLwgAUCRSkKQAAAAAcAL///p2AAACBAWg AQEEAlF5jE5j8Q0AFwEAABcBAAAAMEhxEaQAC0Uc9BoIAEUQAQkAAEAAPBGY9T6M+l5b4xAR abicRgD1Okr/////UkwgMTAvMDUvMjAxMSAtIDE5OjQwOjU4OiAiezNhRHJPX29UaUt9LVNU UkVMT0sgMjU8NTc+PFNURUFNXzA6MDozOTg0NjMwMD48Q1Q+IiBhdHRhY2tlZCAiYWwudmV0 Y2tvdjw3OD48U1RFQU1fMDoxOjQwMzQ3Njc0PjxURVJST1JJU1Q+IiB3aXRoICJhazQ3IiAo ZGFtYWdlICIxMyIpIChkYW1hZ2VfYXJtb3IgIjAiKSAoaGVhbHRoICI5OTg3IikgKGFybW9y ICIwIikgKGhpdGdyb3VwICJsZWZ0IGxlZyIpCgBReYxONGAOAD4AAAA+AAAAADBIcRGkAAtF HPQaCABFAAAwg8ZAADoGUZhZb6YGW+MQEVXuADUhM0QvAAAAAHAC//9dMQAAAgQFtAQCAABR eYxOToIOAAUBAAAFAQAAADBIcRGkAAtFHPQaCABFAAD304EAAHYR7Ru8hlreW+MQEWmInEUA 4wDl/////1JMIDEwLzA1LzIwMTEgLSAxOTozNjowODogIkJpT1M8MjA0PjxTVEVBTV8wOjA6 MTg1NjU3NDY0OT48VEVSUk9SSVNUPiIgYXR0YWNrZWQgIkNvbnN0cmF5PDI1MD48U1RFQU1f MDowOjE5ODQ4MDE1MTI+PENUPiIgd2l0aCAibTRhMSIgKGRhbWFnZSAiMjIiKSAoZGFtYWdl X2FybW9yICI0IikgKGhlYWx0aCAiOTY4IikgKGFybW9yICI5MCIpIChoaXRncm91cCAiY2hl c3QiKQoAUXmMTlC+DgBCAAAAQgAAAAAwSHERpAALRRz0GggARQAANAKEQAB1BnYesktu4lvj EBHAJgBQ4hof8QAAAACAAiAA/6EAAAIEBYQBAwMCAQEEAlF5jE4z6w4APgAAAD4AAAAAMEhx EaQAC0Uc9BoIAEUAADAN30AAeQawbNW/Aclb4xARBPwAUPHZ3qsAAAAAcAJAACo1AAACBAVQ AQEEAlJ5jE5mnQAAPAAAADwAAAAAMEhxEaQAC0Uc9BoIAEUAACgAAEAAPgYF+rLZGAlb4xAR 7FwAUKKnpvMAAAAAUAQAAELCAAAAAAAAAABSeYxOx94AAAcBAAAHAQAAADBIcRGkAAtFHPQa CABFAAD50+IAAHYR7Li8hlreW+MQEWmInEUA5ZR0/////1JMIDEwLzA1LzIwMTEgLSAxOToz NjowODogIkJpT1M8MjA0PjxTVEVBTV8wOjA6MTg1NjU3NDY0OT48VEVSUk9SSVNUPiIgYXR0 YWNrZWQgIkNvbnN0cmF5PDI1MD48U1RFQU1fMDowOjE5ODQ4MDE1MTI+PENUPiIgd2l0aCAi bTRhMSIgKGRhbWFnZSAiMjgiKSAoZGFtYWdlX2FybW9yICI2IikgKGhlYWx0aCAiOTQwIikg KGFybW9yICI4MyIpIChoaXRncm91cCAic3RvbWFjaCIpCgBSeYxOUVYBAE4AAABOAAAAADBI cRGkAAtFHPQaCABFAABA+AZAAHkG7p5UJlr4W+MQEQsbABmP1o2RAAAAALAC///yTwAAAgQF tAEDAwMBAQgKAAAAAAAAAAABAQQCUnmMTqeZAQA+AAAAPgAAAAAwSHERpAALRRz0GggARQAA MCrZQAB7BtaQbV8lC1vjEBHF3ABQEACbtQAAAABwAiAA8uYAAAIEBawBAQQCUnmMTpfEAQAF AQAABQEAAAAwSHERpAALRRz0GggARQAA99QXAAB2EeyFvIZa3lvjEBFpiJxFAOMC4v////9S TCAxMC8wNS8yMDExIC0gMTk6MzY6MDg6ICJCaU9TPDIwND48U1RFQU1fMDowOjE4NTY1NzQ2 NDk+PFRFUlJPUklTVD4iIGF0dGFja2VkICJDb25zdHJheTwyNTA+PFNURUFNXzA6MDoxOTg0 ODAxNTEyPjxDVD4iIHdpdGggIm00YTEiIChkYW1hZ2UgIjIyIikgKGRhbWFnZV9hcm1vciAi NCIpIChoZWFsdGggIjkxOCIpIChhcm1vciAiNzgiKSAoaGl0Z3JvdXAgImNoZXN0IikKAFJ5 jE4HxwEAQgAAAEIAAAAAMEhxEaQAC0Uc9BoIAEUAADQCsEAAdQZ18rJLbuJb4xARwDkAUBFm DRIAAAAAgAIgAOMiAAACBAWEAQMDAgEBBAJSeYxO6UQCAEoAAABKAAAAADBIcRGkAAtFHPQa CABFAAA8J+pAADkGah9Q7/LPW+MQEZ3ZAFBCvMJ9AAAAAKACFtCTsAAAAgQFtAQCCApcCe5f AAAAAAEDAwdSeYxO+M8CAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwOQ9AAHgGxMtdVDul W+MQEQ76AFDO9xYEAAAAAHAC//+KAAAAAgQFoAEBBAJSeYxOONoCABMBAAATAQAAADBIcRGk AAtFHPQaCABFEAEFAABAADwRmPk+jPpeW+MQEWm4nEYA8Rfq/////1JMIDEwLzA1LzIwMTEg LSAxOTo0MDo1OTogInszYURyT19vVGlLfS1TVFJFTE9LIDI1PDU3PjxTVEVBTV8wOjA6Mzk4 NDYzMDA+PENUPiIgYXR0YWNrZWQgImFsLnZldGNrb3Y8Nzg+PFNURUFNXzA6MTo0MDM0NzY3 ND48VEVSUk9SSVNUPiIgd2l0aCAiYWs0NyIgKGRhbWFnZSAiNzAiKSAoZGFtYWdlX2FybW9y ICIwIikgKGhlYWx0aCAiOTkxNyIpIChhcm1vciAiMCIpIChoaXRncm91cCAiaGVhZCIpCgBS eYxO2DkDAD4AAAA+AAAAADBIcRGkAAtFHPQaCABFAAAwg1RAAG8G3CeyrY2qW+MQEVEFAFCZ NHqPAAAAAHAC//9xwgAAAgQFrAEBBAJSeYxOj0UDAD4AAAA+AAAAADBIcRGkAAtFHPQaCABF AAAwg1NAAG8G3CiyrY2qW+MQEVEEAFDxVmaEAAAAAHAC//8trAAAAgQFrAEBBAJSeYxO50sD AIkAAACJAAAAADBIcRGkADBIgvksCABFAAB7JvMAAEARe55b4xAKW+MQEQA1Xm8AZ+jETKuB gAABAAEAAgAAA3d3dwdjYXNoaW5nAnN1AAABAAHADAABAAEAAEQrAAS8KIzvwBAAAgABAATh awAQBGRuczIGeWFuZGV4AnJ1AMAQAAIAAQAE4WsABwRkbnMxwEE= --------------060305070409010703070200-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:34:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93135106566B for ; Tue, 11 Oct 2011 22:34:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C86D8FC17 for ; Tue, 11 Oct 2011 22:34:51 +0000 (UTC) Received: by wyj26 with SMTP id 26so135049wyj.13 for ; Tue, 11 Oct 2011 15:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=HgYeS09qR4t91TaYgRSlcsxuVdc02h/Zu7stYBlH6hM=; b=RqJ9/TScv944Mq51RbPXdthHnlUxhaFbEM1hjT6TnjYd2MvLjNwuueb0GncRws+8ZD dzdzG+245Es0nNPRp96dPpfEETnvzAWyAl6MdsfeQ7O0+6V2w/2e9zSkOZutYalmcm5n dBTxTtXo2s9VxndcsIi0b+YDWLr3nzhznhtak= MIME-Version: 1.0 Received: by 10.216.210.216 with SMTP id u66mr1477570weo.49.1318372491026; Tue, 11 Oct 2011 15:34:51 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 15:34:50 -0700 (PDT) Date: Tue, 11 Oct 2011 18:34:50 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1 Subject: ipmi(4)/isa woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 22:34:52 -0000 Hi folks, I've got a machine where ipmi(4) seem to be unable to fully attach. 10-current kernel complains the following way: ipmi0: at iomem 0-0x1 on isa0 ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa ipmi0: couldn't configure I/O resource device_attach: ipmi0 attach returned 6 Now, 6 is ENXIO, which match the following resource allocation failure: if (info.offset == 1) { sc->ipmi_io_rid = 0; sc->ipmi_io_res[0] = bus_alloc_resource(dev, type, &sc->ipmi_io_rid, info.address, info.address + count - 1, count, RF_ACTIVE); if (sc->ipmi_io_res[0] == NULL) { device_printf(dev, "couldn't configure I/O resource\n"); return (ENXIO); } } Has anyone encountered this issue ? Thanks, - Arnaud From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 22:53:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2008B106566B for ; Tue, 11 Oct 2011 22:53:13 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A9E418FC22 for ; Tue, 11 Oct 2011 22:53:12 +0000 (UTC) Received: by wwe3 with SMTP id 3so128543wwe.31 for ; Tue, 11 Oct 2011 15:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=dCEt5AG8GIhRe+5mZFaLi8FIWOPz9WHFlNufe8vq44k=; b=FlxPOTJ1oxivOqeM/NnmZugAkAZL/Sq1ZAd44/Os2Yqi9FzMQVKqyq2+KoAAGMtEJF S2crscOoga3M3ZASVg3nm40yDmfNdo1xJPNaS1HOHwVhcQmuWp0EGn3yjiQwyWVWhrnw eDoxdx+9/cdmgaH3DNMSBZlSVVbzafXsHkVPU= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr64101wbc.49.1318373591645; Tue, 11 Oct 2011 15:53:11 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 15:53:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Oct 2011 18:53:11 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD-Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: ipmi(4)/isa woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 22:53:13 -0000 Hi, On Tue, Oct 11, 2011 at 6:34 PM, Arnaud Lacombe wrote: > Hi folks, > > I've got a machine where ipmi(4) seem to be unable to fully attach. > 10-current kernel complains the following way: > > ipmi0: at iomem 0-0x1 on isa0 > ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa > ipmi0: couldn't configure I/O resource > device_attach: ipmi0 attach returned 6 > Actually, I can bypass this issue by enabling acpi(4): ipmi0: port 0xca2,0xca3 on acpi0 ipmi0: KCS mode found at io 0xca2 on acpi ipmi1: on isa0 device_attach: ipmi1 attach returned 16 pmtimer0 on isa0 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 However, the driver fails right after with: ipmi0: Timed out waiting for GET_DEVICE_ID and thus never complete its startup... :( - Arnaud > Now, 6 is ENXIO, which match the following resource allocation failure: > > =A0if (info.offset =3D=3D 1) { > =A0 =A0 =A0 =A0 =A0sc->ipmi_io_rid =3D 0; > =A0 =A0 =A0 =A0 =A0sc->ipmi_io_res[0] =3D bus_alloc_resource(dev, type, > =A0 =A0 =A0 =A0 =A0 =A0 =A0&sc->ipmi_io_rid, info.address, info.address += count - 1, > =A0 =A0 =A0 =A0 =A0 =A0 =A0count, RF_ACTIVE); > =A0 =A0 =A0 =A0 =A0if (sc->ipmi_io_res[0] =3D=3D NULL) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "couldn't configure= I/O resource\n"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENXIO); > =A0 =A0 =A0 =A0 =A0} > =A0} > > Has anyone encountered this issue ? > > Thanks, > =A0- Arnaud > From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 23:00:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F53106564A for ; Tue, 11 Oct 2011 23:00:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4929A8FC1A for ; Tue, 11 Oct 2011 23:00:56 +0000 (UTC) Received: by qadz30 with SMTP id z30so121276qad.13 for ; Tue, 11 Oct 2011 16:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FhArGtevypuB4RKhnHPmqvhernJXD388M4YdRMV3HjA=; b=sPXqYkVYo0+GjcIRUctqkMgU8lLEf7lysSQKyAgYcZ74BagjttD8l7rLqHdIXazeRV 9f47Jv15GbIcDdXQ4w13IvvRTxy9YSYMJpQiDhCJcHrL6cLXK8x9oD6VfK8hQ0J6/o9i DG2nWnv9/S6m0IZni752TLX8N2j+2kt3mY2OU= MIME-Version: 1.0 Received: by 10.224.213.2 with SMTP id gu2mr12333060qab.85.1318374055539; Tue, 11 Oct 2011 16:00:55 -0700 (PDT) Received: by 10.224.74.82 with HTTP; Tue, 11 Oct 2011 16:00:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Oct 2011 16:00:55 -0700 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-Current Subject: Re: ipmi(4)/isa woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Oct 2011 23:00:56 -0000 On Tue, Oct 11, 2011 at 3:53 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 6:34 PM, Arnaud Lacombe wrot= e: >> Hi folks, >> >> I've got a machine where ipmi(4) seem to be unable to fully attach. >> 10-current kernel complains the following way: >> >> ipmi0: at iomem 0-0x1 on isa0 >> ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa >> ipmi0: couldn't configure I/O resource >> device_attach: ipmi0 attach returned 6 >> > Actually, I can bypass this issue by enabling acpi(4): > > ipmi0: port 0xca2,0xca3 on acpi0 > ipmi0: KCS mode found at io 0xca2 on acpi > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > pmtimer0 on isa0 > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > > However, the driver fails right after with: > > ipmi0: Timed out waiting for GET_DEVICE_ID > > and thus never complete its startup... :( > > =A0- Arnaud > >> Now, 6 is ENXIO, which match the following resource allocation failure: >> >> =A0if (info.offset =3D=3D 1) { >> =A0 =A0 =A0 =A0 =A0sc->ipmi_io_rid =3D 0; >> =A0 =A0 =A0 =A0 =A0sc->ipmi_io_res[0] =3D bus_alloc_resource(dev, type, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0&sc->ipmi_io_rid, info.address, info.address = + count - 1, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0count, RF_ACTIVE); >> =A0 =A0 =A0 =A0 =A0if (sc->ipmi_io_res[0] =3D=3D NULL) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "couldn't configur= e I/O resource\n"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENXIO); >> =A0 =A0 =A0 =A0 =A0} >> =A0} >> >> Has anyone encountered this issue ? You might need to define a hint to use the KCS interface via device.hints. I don't remember the incantation exactly, but I think it was required for some Dells. ipmi(4) should have more info. Failing that, a BMC upgrade/downgrade might be required (some vendors don't test out BMC firmware upgrades really well, esp. in FreeBSD). HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 00:01:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABD61106564A for ; Wed, 12 Oct 2011 00:01:31 +0000 (UTC) (envelope-from nalitoja@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 781988FC13 for ; Wed, 12 Oct 2011 00:01:31 +0000 (UTC) Received: by iaky10 with SMTP id y10so144789iak.13 for ; Tue, 11 Oct 2011 17:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; bh=Px9gv5Yht08PcmaXTilliQE0Ldd321ucdOEiOD5DNJQ=; b=iokAXY+IonIsC5MatF8YJZE3cb3Nn/O86yX3fIybt6L4Ru5Eis9GPzC4lmcp9QSQ5Z O4IDZqf3f6DCY4fMdZwN5kokWPEJbuR0z8HmNK+NVgtCRHi3/xSC0i870fyY2WyBUbkk 36NI0nRV/VVCRGZPf25eY11+Ki2Oi49uAfxP8= Received: by 10.43.51.9 with SMTP id vg9mr30489996icb.32.1318377690684; Tue, 11 Oct 2011 17:01:30 -0700 (PDT) Received: from nil (router-sun-nat-i.pilsfree.net. [212.79.110.24]) by mx.google.com with ESMTPS id l28sm767247ibc.3.2011.10.11.17.01.24 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 17:01:29 -0700 (PDT) From: Nali Toja To: freebsd-current@freebsd.org Date: Wed, 12 Oct 2011 00:00:07 +0000 Message-ID: <86mxd7qdzk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 00:01:31 -0000 After r216641 sbcl built with sb-thread dies on mailbox tests. It also dies when I try to complete a symbol in slime. The workaround seems to be to revert libthr to r216640. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050 http://svn.freebsd.org/changeset/base/216641 http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52 Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ in case it's the latter one. $ cd lang/sbcl $ rm files/patch-disable-failing-tests $ make # it should fail $ cd $(make -V WRKSRC) $ SBCL_HOME=contrib/ ./src/runtime/sbcl \ --core output/sbcl.core --no-userinit --no-sysinit \ --eval "(require 'sb-concurrency)" \ --eval "(asdf:oos 'asdf:test-op :sb-concurrency-tests)" This is SBCL 1.0.52, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Doing 16 pending tests of 16 tests total. SB-CONCURRENCY-TEST::QUEUE.1 SB-CONCURRENCY-TEST::QUEUE.2 SB-CONCURRENCY-TEST::QUEUE.3 SB-CONCURRENCY-TEST::QUEUE.4 SB-CONCURRENCY-TEST::QUEUE.5 SB-CONCURRENCY-TEST::QUEUE.T.1 SB-CONCURRENCY-TEST::QUEUE.T.2 SB-CONCURRENCY-TEST::QUEUE.T.3 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.1 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.2 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.3 SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-SINGLE-CONSUMER SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-MULTIPLE-CONSUMERS FFatal error 'thread was already on queue.' at atal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) FaFtfatal error encounteredalal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in tal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (erf in SBCL pid 1993rfatal error encounteredFatal error 'thread was already on queue.' at line infatal error encountered222 in file /usr/src/lib/libthr/thread/thr_cond.c (errnole /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) o = 0) (tid 34384826368) in SBCL pid 1993= 0F)fatal error encounteredaFFataltfatal error encounteredatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) error 'thread was already on queue.' aa in SBCL pid 1993t lFataFl error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) l error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) : (tid 34384824320) in SBCL pid 1993fatal error encounteredfatal error encounteredfatal error encountered in SBCL pid 1993fatal error encounteredfatal error encountered in SBCL pid 1993(tid 34384815104): SIGABRT received. atal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered(tid 34384823296)SIGABRT received. : (tid 34384822272) in SBCL pid 1993 in SBCL pid 1993 in SBCL pid 1993(tid 34384828416) in SBCL pid 1993(tid 34384813056)FFaFatal error 'thread was already on queue.' t at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) al error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) aFatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 Fatal error 'thread was already on queue.' at lFine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (err in SBCL pid 1993: SIGABRT received. : (tid 34384816128)(tid 34384819200)(tid 34384817152): : fatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encounteredfatal error encountered in SBCL pid 1993(tid 34381009920): SIGABRT received. tal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34384812032): SIGABRT received. atal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34384803840): SIGABRT received. (tid 34384814080): SIGABRT received. SIGABRT received. SIGABRT received. : SIGABRT received. : SIGABRT received. : SIGABRT received. SIGABRT received. SIGABRT received. in SBCL pid 1993(tid 34384806912): SIGABRT received. in SBCL pid 1993(tid 34384808960): SIGABRT received. in SBCL pid 1993(tid 34381020160): SIGABRT received. in SBCL pid 1993(tid 34384804864): SIGABRT received. in SBCL pid 1993(tid 34381018112): SIGABRT received. in SBCL pid 1993(tid 34381016064): SIGABRT received. in SBCL pid 1993(tid 34381015040): SIGABRT received. in SBCL pid 1993(tid 34381014016): SIGABRT received. in SBCL pid 1993(tid 34381010944): SIGABRT received. in SBCL pid 1993(tid 34381011968): SIGABRT received. no = 0) fatal error encountered in SBCL pid 1993(tid 34381007872): SIGABRT received. Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34381003776): SIGABRT received. Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34381002752): SIGABRT received. Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34381001728): SIGABRT received. Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34380999680): SIGABRT received. Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34380792832): SIGABRT received. Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered in SBCL pid 1993(tid 34380749824): SIGABRT received. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> backtrace Backtrace: 0: Foreign function handle_trap, fp = 0x832e561b0, ra = 0x415040 1: Foreign function handle_trap, fp = 0x832e56310, ra = 0x4152f8 2: Foreign function ldb_monitor, fp = 0x832e56380, ra = 0x415344 3: Foreign function monitor_or_something, fp = 0x832e56390, ra = 0x41539e 4: Foreign function lose, fp = 0x832e563a0, ra = 0x41146d 5: Foreign function lose, fp = 0x832e56490, ra = 0x41145d 6: Foreign function sigabrt_handler, fp = 0x832e564c0, ra = 0x4144d2 7: Foreign function handle_guard_page_triggered, fp = 0x832e56500, ra = 0x41427d 8: Foreign fp = 0x832e56980, ra = 0x7ffffffff023 9: Foreign function abort, fp = 0x832e569b0, ra = 0x8009e6063 10: Foreign function _pthread_attr_getaffinity_np, fp = 0x832e569e0, ra = 0x800c61479 11: Foreign function pthread_cond_destroy, fp = 0x832e56a30, ra = 0x800c5f548 12: Foreign function pthread_cond_destroy, fp = 0x832e56a80, ra = 0x800c5f856 13: Foreign function pthread_cond_wait, fp = 0x832e56aa0, ra = 0x800c5f8b7 14: Foreign function pthread_cond_wait, fp = 0x832e56ad0, ra = 0x8009e9fa0 15: Foreign function sig_stop_for_gc_handler, fp = 0x832e56af0, ra = 0x413574 16: Foreign function sig_stop_for_gc_handler, fp = 0x832e56b30, ra = 0x4133a8 17: Foreign function handle_guard_page_triggered, fp = 0x832e56b70, ra = 0x41427d 18: Foreign fp = 0x832e57040, ra = 0x7ffffffff023 19: Foreign function _pthread_kill, fp = 0x832e57070, ra = 0x800c5c04b 20: Foreign function pthread_cond_destroy, fp = 0x832e570c0, ra = 0x800c5f5dd 21: Foreign function pthread_cond_destroy, fp = 0x832e57110, ra = 0x800c5f856 22: Foreign function pthread_cond_wait, fp = 0x832e57130, ra = 0x800c5f8b7 23: Foreign function pthread_cond_wait, fp = 0x832e57160, ra = 0x8009e9fa0 24: Foreign function lutex_wait, fp = 0x832e571a0, ra = 0x41804f 25: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CONDITION-WAIT]230) 26: (SB-C::TL-XEP SB-THREAD::CONDITION-WAIT) 27: (COMMON-LISP::FLET SB-THREAD::WITH-SYSTEM-MUTEX-THUNK) 28: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CALL-WITH-SYSTEM-MUTEX/ALLOW-WITH-INTERRUPTS]206) 29: SB-THREAD::WAIT-ON-SEMAPHORE 30: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[RECEIVE-MESSAGE]139) 31: (SB-C::VARARGS-ENTRY SB-CONCURRENCY::RECEIVE-MESSAGE) 32: (COMMON-LISP::LAMBDA ()) 33: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[BLOCK443]448) 34: (COMMON-LISP::FLET SB-THREAD::WITH-MUTEX-THUNK) 35: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]309) 36: SB-THREAD::CALL-WITH-MUTEX 37: SB-THREAD::INITIAL-THREAD-FUNCTION 38: Foreign function call_into_lisp, fp = 0x832e57f30, ra = 0x426920 39: Foreign function funcall0, fp = 0x832e57f60, ra = 0x40d61d 40: Foreign function funcall0, fp = 0x832e57f90, ra = 0x40d5e6 41: Foreign function new_thread_trampoline, fp = 0x832e57fc0, ra = 0x41ab26 42: Foreign function pthread_create, fp = 0x832e57ff0, ra = 0x800c523fe ldb> kill 11 Program received signal SIGSEGV, Segmentation fault. 0x0000000800c5c7ec in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) Current language: auto; currently asm (gdb) bt #0 0x0000000800c5c7ec in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x0000000800c5423e in _thr_umtx_timedwait_uint (mtx=0x8006d4ea8, id=0, clockid=0, abstime=0x0, shared=0) at /usr/src/lib/libthr/thread/thr_umtx.c:214 #2 0x0000000800c5c04b in _thr_sleep (curthread=0x828d5d400, clockid=0, abstime=0x0) at /usr/src/lib/libthr/thread/thr_kern.c:212 #3 0x0000000800c5f5dd in cond_wait_user (cvp=0x828fdf850, mp=0x828fe0970, abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:243 #4 0x0000000800c5f856 in cond_wait_common (cond=0x8480f0008, mutex=0x8480f0000, abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:299 #5 0x0000000800c5f8b7 in __pthread_cond_wait (cond=0x8480f0008, mutex=0x8480f0000) at /usr/src/lib/libthr/thread/thr_cond.c:313 #6 0x00000008009e9fa0 in pthread_cond_wait_exp (p0=0x8480f0008, p1=0x8480f0000) at /usr/src/lib/libc/gen/_pthread_stubs.c:217 #7 0x0000000000413574 in wait_for_thread_state_change (thread=0x8480f0010, state=16) at thread.h:53 #8 0x00000000004133a8 in sig_stop_for_gc_handler (signal=31, info=0x847eef630, context=0x847eef2c0) at interrupt.c:1265 #9 0x000000000041427d in low_level_handle_now_handler (signal=31, info=0x847eef630, void_context=0x847eef2c0) at interrupt.c:1729 #10 0x00007ffffffff023 in ?? () #11 0x0000000000414220 in low_level_unblock_me_trampoline () at interrupt.c:1723 #12 0x000000100154c990 in ?? () #13 0x000000000063eaa0 in interrupt_handlers () #14 0x0000000200411d4f in ?? () #15 0x0000001003375721 in ?? () #16 0x38b485040000001a in ?? () #17 0x00000000000a81f0 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000847eef840 in ?? () #20 0x0000001003af2a2f in ?? () #21 0x0000002004e9c3e1 in ?? () #22 0x0000000800c58570 in _sigprocmask (how=Could not find the frame base for "_sigprocmask". ) at /usr/src/lib/libthr/thread/thr_sig.c:584 Previous frame inner to this frame (corrupt stack?) (gdb) f 7 #7 0x0000000000413574 in wait_for_thread_state_change (thread=0x8480f0010, state=16) at thread.h:53 53 pthread_cond_wait(thread->state_cond, thread->state_lock); (gdb) l 48 static inline void 49 wait_for_thread_state_change(struct thread *thread, lispobj state) 50 { 51 pthread_mutex_lock(thread->state_lock); 52 while (thread->state == state) 53 pthread_cond_wait(thread->state_cond, thread->state_lock); 54 pthread_mutex_unlock(thread->state_lock); 55 } 56 57 extern pthread_key_t lisp_thread; From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 01:09:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B004B1065670 for ; Wed, 12 Oct 2011 01:09:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC928FC1A for ; Wed, 12 Oct 2011 01:09:35 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9C19WSF018751 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 18:09:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E94E8D2.8010502@freebsd.org> Date: Tue, 11 Oct 2011 18:09:38 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> <4E949C26.4070105@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 01:09:36 -0000 On 10/11/11 12:57 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer wrote: >> On 10/11/11 12:36 PM, Arnaud Lacombe wrote: >>>> [...] >>> libprocstat is _itself_ a problem: >>> >>> % git grep 'define _KERNEL' . >>> [...] >>> lib/libprocstat/cd9660.c:#define _KERNEL >>> lib/libprocstat/nwfs.c:#define _KERNEL >>> lib/libprocstat/smbfs.c:#define _KERNEL >>> lib/libprocstat/udf.c:#define _KERNEL >>> lib/libprocstat/zfs.c:#define _KERNEL >>> [...] >>> >>> ok, I admit this is all FS related stuff :) >> but at least it comes with the system so it matches. >> > no, you should be able to run a FreeBSD 1.0 userland and a 9-RELEASE > kernel together and have all utilities working. If not, you cannot > claim to support backward compatibility, even if you do on a subset of > kernel/userland interface. That said, this is just my personal > opinion. > >> we've been looking for the 'right' way to do this since, hmmm, 1988 that I >> remember and I bet before that too. >> > then the job was done bad. I didn't say we DID it I said we've been looking for the right answer. libkvm was a small step... you really don't want to know what was done before that. I've run FreeBSD 1.1 on a freeBSD 8 jail so I know what you mean, you have to put some things like 'ps' and ifconfig, and 'netstat' into it (statically compiled) or you can't get anywhere but even if there was a differnt interface, the likelyhood of it still being valid after 19 years pretty small. > I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 > kernel on a 4 years old openwrt image and still had a functional > system. Comparatively, I could not mix FreeBSD 7-STABLE userland and > 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to > make FreeBSD 7 unable to boot (even single user). actually due to libkvm there are actually a lot of programs that will work over the 7-8 boundary... a lot more than used to. between, say 2 and 3. > Let me emphasize again that it is only my personal opinion :-) Yep but its shared.. Unfortunately the problem is actually trickier than first appears. My own attempt at it can be seen with netgraph, where we instituted a text based config scheme, and in geom where PHK made an XML config scheme. > - Arnaud > From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 01:50:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023FF106566C; Wed, 12 Oct 2011 01:50:30 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB438FC08; Wed, 12 Oct 2011 01:50:28 +0000 (UTC) Received: by wwe3 with SMTP id 3so259327wwe.31 for ; Tue, 11 Oct 2011 18:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EGEBCrx76uhohqoFFGrJW52mbkzWoqtOKveCVZTlcWU=; b=o4irSW469TtDVT1nKvubyfXoh2DpMD3beVyroYMR7TwuudYwLHhqB8myjM653fG4iG lvqbGc1+7+tDqu2XcRxu7g1LlKDv6mWG7UvqeH9VwMFXsFY3+d2+e6VHU+tvFJzijYt4 wEIMtgAVQxC3EdM/QUnRzuSfZVq15FEPpTO6E= MIME-Version: 1.0 Received: by 10.227.29.161 with SMTP id q33mr218836wbc.49.1318384228217; Tue, 11 Oct 2011 18:50:28 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Tue, 11 Oct 2011 18:50:28 -0700 (PDT) In-Reply-To: <4E94E8D2.8010502@freebsd.org> References: <4E942FF1.9000805@FreeBSD.org> <4E9449F2.2000801@FreeBSD.org> <4E944BA5.4080506@lerctr.org> <83FC19FA-BD52-4383-9ABE-708161597B85@mac.com> <589d032a-7b71-4ff1-8adf-f5e49e87696c@email.android.com> <4E949C26.4070105@freebsd.org> <4E94E8D2.8010502@freebsd.org> Date: Tue, 11 Oct 2011 21:50:28 -0400 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current Subject: Re: System headers with clang? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 01:50:30 -0000 Hi, On Tue, Oct 11, 2011 at 9:09 PM, Julian Elischer wrote= : > On 10/11/11 12:57 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer >> =A0wrote: >>> >>> On 10/11/11 12:36 PM, Arnaud Lacombe wrote: >>>>> >>>>> [...] >> I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 >> kernel on a 4 years old openwrt image and still had a functional >> system. Comparatively, I could not mix FreeBSD 7-STABLE userland and >> 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to >> make FreeBSD 7 unable to boot (even single user). > > actually due to libkvm there are actually a lot of programs that will wor= k > over the > 7-8 boundary... =A0a lot more than used to. between, say 2 and 3. > >> Let me emphasize again that it is only my personal opinion :-) > > Yep but its shared.. Unfortunately the problem is actually trickier than > first appears. > My own attempt at it can be seen with netgraph, where we instituted a tex= t > based > config scheme, and in geom where PHK made an XML config scheme. > it would seem that any attempt to solves that problem somehow ends-up to hierarchically text-encode/decode the binary data, Linux /proc / /sys text file-based interface, the netgraph encoding (which I admit is really powerful once dominated), phk's XML config scheme, NetBSD & Apple property list :) - Arnaud From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 02:05:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E844106564A for ; Wed, 12 Oct 2011 02:05:40 +0000 (UTC) (envelope-from mashtizadeh@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id EED0B8FC08 for ; Wed, 12 Oct 2011 02:05:39 +0000 (UTC) Received: by qyk4 with SMTP id 4so268845qyk.13 for ; Tue, 11 Oct 2011 19:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HcM9ZekubhF/unYA8cIHGTsU5uf+BAByam46K+yqdq4=; b=IIM5Q1y+WY/HKoQt/Qd+YosdQA7aniVkUofD21kb+hP9FGcfndE4rvRPrPOP6B8X1S F4NAu/hsOGTPgbJMQOytdZ3d3YCEstQ4ZuzaIqd36rqFTpaSwtXv1xV3T/YkSQU0hp0e wqrxKJLXwUktgkvIIIHLbtNyray488sDkA9Ug= MIME-Version: 1.0 Received: by 10.229.87.137 with SMTP id w9mr5243595qcl.284.1318385138927; Tue, 11 Oct 2011 19:05:38 -0700 (PDT) Received: by 10.229.52.145 with HTTP; Tue, 11 Oct 2011 19:05:38 -0700 (PDT) In-Reply-To: <8e26f2944efcfe0a48a83d065e19eff5.squirrel@eternamente.info> References: <8e42ff5adc4823b6a46fb59704a2bca5.squirrel@eternamente.info> <4E90D6CC.1030500@FreeBSD.org> <0c062e2fefcf6a8bc2c436281780cec0.squirrel@eternamente.info> <4E9365C2.2020909@nixil.net> <8e26f2944efcfe0a48a83d065e19eff5.squirrel@eternamente.info> Date: Tue, 11 Oct 2011 19:05:38 -0700 Message-ID: From: Ali Mashtizadeh To: Nenhum_de_Nos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: flash for 9-beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 02:05:40 -0000 Hi Folks, Sorry if this is unrelated but in 9.0-BETA3 about:plugins in chromium and firefox both show both flash and acrobat plugins, but I see these NSPlugin Wrapper errors in the console when I start the browser from the command line. *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection After some google searching it seems it has to do with a compile/runtime time change in the linux syscall interface. I experimented with the changing the linux osrelease sysctl but it hasn't fixed the issue for me. ~ Ali On Mon, Oct 10, 2011 at 8:00 PM, Nenhum_de_Nos w= rote: > > On Mon, October 10, 2011 18:38, Phil Oleson wrote: >> On 10/10/11 15:30, Nenhum_de_Nos wrote: >>> >>> On Sun, October 9, 2011 13:39, Nenhum_de_Nos wrote: >>>> >>>> On Sat, October 8, 2011 20:03, Doug Barton wrote: >>>>> On 10/08/2011 14:53, Warren Block wrote: >>>>>> nspluginwrapper needs to be run as the end user. >>>>> >>>>> The pkg-message tells them to do that. >>>> >>>> ops, haven't seen it though. all the ports cleaned by the "clean" part >>>> of >>>> the command got on my way :( >>> >>> I did, no good though. >>> >>> FF still says no plugins. >>> >>> is it FF 7 compatible ? >>> >>> matheus >>> >> >> I ran into this recently. =C2=A0Though I have not figured out a more cor= rect >> fix.. add this to your .bashrc: >> >> export >> MOZ_PLUGIN_PATH=3D/usr/local/lib/browser_plugins/symlinks/gecko19:/usr/l= ocal/lib/npapi/symlinks/firefox >> >> or.. .cshrc >> >> setenv MOZ_PLUGIN_PATH >> /usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/sym= links/firefox >> >> and flash will work with the newer firefox. >> >> -Phil. > > thanks Phil, > > but no good to me :/ > > Both dirs don't exist, and I tried exporting to browser_plugins dir also = ... > > thanks, > > matheus > > > -- > We will call you cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style > _______________________________________________ > 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 12 02:20:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 0DB961065678; Wed, 12 Oct 2011 02:20:07 +0000 (UTC) Date: Wed, 12 Oct 2011 02:20:07 +0000 From: Alexey Dokuchaev To: Nali Toja Message-ID: <20111012022007.GA49833@FreeBSD.org> References: <4e4ab684.0c4c970a.68e8.6846SMTPIN_ADDED@mx.google.com> <9A6F7C9D-32D8-4387-BB03-B11CB0A91BFA@gmail.com> <20110829.214640.1568838937885804931.ken@tydfam.jp> <20110831124126.GB82908@FreeBSD.org> <86vcs2q4vh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <86vcs2q4vh.fsf@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: fidaj@ukr.net, gobledb@gmail.com, yanegomi@gmail.com, Ali Mashtizadeh , Olivier Smedts , freebsd-current@freebsd.org Subject: Re: x11/nvidia-driver / Compilation has failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 02:20:08 -0000 On Thu, Oct 06, 2011 at 01:35:14AM +0000, Nali Toja wrote: > Ali Mashtizadeh writes: > > 2011/8/31 Alexey Dokuchaev : > >> On Mon, Aug 29, 2011 at 02:59:48PM +0200, Olivier Smedts wrote: > >>> 2011/8/29 ken : > >>> > Could I test your patch for nvidia-driver, too? > >>> > I cannot find your patch in this mail. > >>> > >>> I took the patch in : > >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html > >>> > >>> And it worked for me. > >> > >> Should be fixed in the port itself now (also updated to 280.13). > > > > Is there any reason I should still be hitting this bug when building > > on 9-STABLE? With Linux compatibility disabled I can build the driver, > > but the kernel refuses to load it saying it's incompatible with my > > kernel version. > > Only if you're using 285.05.09 with the port. And it'd affect both > /stable/9 and /head users. > > // from src/nv-freebsd.h: > #if __FreeBSD_version >= 900041 > #include > #else > #define fget(td, fd, cap, fp) fget(td, fd, fp) > #endif > > Can you commit below tiny change? It should make testing the new version a > bit easier for people who are impatient to wait for the next port update. > > That version also includes tunable support similar to ports/156386. Port was updated to serve the most recent release from NVidia, 285.05.09. Please test and report of any issues. Thanks, ./danfe From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:39:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9691065672; Wed, 12 Oct 2011 13:39:16 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 93CFC8FC0A; Wed, 12 Oct 2011 13:39:15 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 4403BE65C3; Wed, 12 Oct 2011 14:39:14 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=7/yq9hQxZxZP z5S073pAc0UR3Os=; b=g+xCUgvpnRGVnvLNmm4HJx8ItKTz+KMDRMx0uxrh5LcX 0CBUHU/0oaSr7D5pslFE3MTNoIaT6U4mNuSGZBSrx39cOIJPlGLzdUt7ZYQkuMZL jB4edgkhoIdxBdIc80foyaTYL5PVGpckOxJgDV/hsgSTVUf/jjsVL2McbapmI7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=SsZPvy HoY5WcKhj5dnPrt0vRNW8YV/P1us4ZZCXTC5C34AlPBYcE9kr5H0Z66pNkPH3Q6M 4uQby/DRu0KbXnFbOUgLf9H5mSfQnhBMlCLaGHOtG20IH5iX546Q710z1N50o9Nw phCcMZuIHpjiJKa48XTrSN2UVexMu4qCl51Jo= Received: from [192.168.1.170] (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 143ECE6476; Wed, 12 Oct 2011 14:39:14 +0100 (BST) Message-ID: <4E95987D.5090907@cran.org.uk> Date: Wed, 12 Oct 2011 14:39:09 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ken Smith References: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> In-Reply-To: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 9.0-BETA3 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:39:16 -0000 On 29/09/2011 02:42, Ken Smith wrote: > MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc > MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 > MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c The -dvd1.iso files seem to be less than a CD, at 610MB. Are they expected to contain more data over time, or could 'dvd' be removed? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:39:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E87E1065676; Wed, 12 Oct 2011 13:39:57 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from core.impulsive.hu (core.impulsive.hu [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id 970728FC18; Wed, 12 Oct 2011 13:39:56 +0000 (UTC) Received: by core.impulsive.hu (Postfix, from userid 143) id A8B63DC0EF; Wed, 12 Oct 2011 13:40:39 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by core.impulsive.hu (Postfix) with ESMTP id 6B4BDDC0C0 for ; Wed, 12 Oct 2011 13:40:36 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B85A5162B98; Wed, 12 Oct 2011 13:39:23 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2E49810656B4; Wed, 12 Oct 2011 13:39:23 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9691065672; Wed, 12 Oct 2011 13:39:16 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 93CFC8FC0A; Wed, 12 Oct 2011 13:39:15 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 4403BE65C3; Wed, 12 Oct 2011 14:39:14 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=7/yq9hQxZxZP z5S073pAc0UR3Os=; b=g+xCUgvpnRGVnvLNmm4HJx8ItKTz+KMDRMx0uxrh5LcX 0CBUHU/0oaSr7D5pslFE3MTNoIaT6U4mNuSGZBSrx39cOIJPlGLzdUt7ZYQkuMZL jB4edgkhoIdxBdIc80foyaTYL5PVGpckOxJgDV/hsgSTVUf/jjsVL2McbapmI7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=SsZPvy HoY5WcKhj5dnPrt0vRNW8YV/P1us4ZZCXTC5C34AlPBYcE9kr5H0Z66pNkPH3Q6M 4uQby/DRu0KbXnFbOUgLf9H5mSfQnhBMlCLaGHOtG20IH5iX546Q710z1N50o9Nw phCcMZuIHpjiJKa48XTrSN2UVexMu4qCl51Jo= Received: from [192.168.1.170] (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 143ECE6476; Wed, 12 Oct 2011 14:39:14 +0100 (BST) Message-ID: <4E95987D.5090907@cran.org.uk> Date: Wed, 12 Oct 2011 14:39:09 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ken Smith References: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> In-Reply-To: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 9.0-BETA3 Available... X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:39:57 -0000 On 29/09/2011 02:42, Ken Smith wrote: > MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc > MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 > MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c The -dvd1.iso files seem to be less than a CD, at 610MB. Are they expected to contain more data over time, or could 'dvd' be removed? -- Bruce Cran _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:53:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9457106564A; Wed, 12 Oct 2011 13:53:08 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id B88E88FC14; Wed, 12 Oct 2011 13:53:08 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 31289FA31; Wed, 12 Oct 2011 09:47:42 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 9E4A0FA34; Wed, 12 Oct 2011 09:47:41 -0400 (EDT) Received: from smtp4.acsu.buffalo.edu (smtp4.acsu.buffalo.edu [128.205.5.229]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 96EDFFA31; Wed, 12 Oct 2011 09:47:41 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp4.acsu.buffalo.edu (Postfix) with ESMTPSA id 6F212453B9; Wed, 12 Oct 2011 09:47:41 -0400 (EDT) From: Ken Smith To: Bruce Cran In-Reply-To: <4E95987D.5090907@cran.org.uk> References: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> <4E95987D.5090907@cran.org.uk> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GwY86b+SpelHEkqhA+qv" Date: Wed, 12 Oct 2011 09:47:40 -0400 Message-ID: <1318427260.35743.7.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 9.0-BETA3 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:53:09 -0000 --=-GwY86b+SpelHEkqhA+qv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: > On 29/09/2011 02:42, Ken Smith wrote: > > MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) =3D 2ce7b93d28fd7ff37965893f= 1af3f7fc > > MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) =3D 4affc701f2052edc548274f090e4= 9235 > > MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) =3D e260f2f2122326cb9a93ac83= eb006c1c >=20 > The -dvd1.iso files seem to be less than a CD, at 610MB. Are they=20 > expected to contain more data over time, or could 'dvd' be removed? >=20 I was planning on them having package sets. The new installer doesn't support installing packages like sysinstall had but if I provide Gnome, KDE, and perhaps a small set of other stuff it would be useful to people with crummy network connectivity. They could install the packages from the DVD instead of needing to have everything downloaded. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-GwY86b+SpelHEkqhA+qv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6VmnAACgkQ/G14VSmup/Zw7ACeNGptTqV7rPLehiVR974AFHem ai8An1svcQTE6eR4N2EZ/QHF39GIfIVr =C9g/ -----END PGP SIGNATURE----- --=-GwY86b+SpelHEkqhA+qv-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 13:53:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE691065688; Wed, 12 Oct 2011 13:53:50 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from core.impulsive.hu (core.impulsive.hu [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id 40CD38FC17; Wed, 12 Oct 2011 13:53:50 +0000 (UTC) Received: by core.impulsive.hu (Postfix, from userid 143) id 8FC5CDC0EF; Wed, 12 Oct 2011 13:54:33 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by core.impulsive.hu (Postfix) with ESMTP id 284F8DC0C0 for ; Wed, 12 Oct 2011 13:54:29 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8767017A9C0; Wed, 12 Oct 2011 13:53:17 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4A9D610656B6; Wed, 12 Oct 2011 13:53:16 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9457106564A; Wed, 12 Oct 2011 13:53:08 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id B88E88FC14; Wed, 12 Oct 2011 13:53:08 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 31289FA31; Wed, 12 Oct 2011 09:47:42 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 9E4A0FA34; Wed, 12 Oct 2011 09:47:41 -0400 (EDT) Received: from smtp4.acsu.buffalo.edu (smtp4.acsu.buffalo.edu [128.205.5.229]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 96EDFFA31; Wed, 12 Oct 2011 09:47:41 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp4.acsu.buffalo.edu (Postfix) with ESMTPSA id 6F212453B9; Wed, 12 Oct 2011 09:47:41 -0400 (EDT) From: Ken Smith To: Bruce Cran In-Reply-To: <4E95987D.5090907@cran.org.uk> References: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> <4E95987D.5090907@cran.org.uk> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GwY86b+SpelHEkqhA+qv" Date: Wed, 12 Oct 2011 09:47:40 -0400 Message-ID: <1318427260.35743.7.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 9.0-BETA3 Available... X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 13:53:50 -0000 --=-GwY86b+SpelHEkqhA+qv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: > On 29/09/2011 02:42, Ken Smith wrote: > > MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) =3D 2ce7b93d28fd7ff37965893f= 1af3f7fc > > MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) =3D 4affc701f2052edc548274f090e4= 9235 > > MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) =3D e260f2f2122326cb9a93ac83= eb006c1c >=20 > The -dvd1.iso files seem to be less than a CD, at 610MB. Are they=20 > expected to contain more data over time, or could 'dvd' be removed? >=20 I was planning on them having package sets. The new installer doesn't support installing packages like sysinstall had but if I provide Gnome, KDE, and perhaps a small set of other stuff it would be useful to people with crummy network connectivity. They could install the packages from the DVD instead of needing to have everything downloaded. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-GwY86b+SpelHEkqhA+qv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6VmnAACgkQ/G14VSmup/Zw7ACeNGptTqV7rPLehiVR974AFHem ai8An1svcQTE6eR4N2EZ/QHF39GIfIVr =C9g/ -----END PGP SIGNATURE----- --=-GwY86b+SpelHEkqhA+qv-- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 14:59:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A57E1065676 for ; Wed, 12 Oct 2011 14:59:24 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id AC8CF8FC08 for ; Wed, 12 Oct 2011 14:59:23 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RE0HB-0008gH-ST for freebsd-current@freebsd.org; Wed, 12 Oct 2011 16:59:22 +0200 Message-ID: <4E95AB49.30908@dumbbell.fr> Date: Wed, 12 Oct 2011 16:59:21 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: "BTX halted" when booting 9.0-BETA3 (Root On ZFS) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 14:59:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, For a couple of days now, I can't boot FreeBSD 9-BETA3 on my laptop. It stops at this stage (copied by hand from a screenshot): FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (root@farrell.cse.buffalo.edu, Sat Sep 24 20:25:50 UTC 2011) - int=00000000 err=00000000 efl=00010246 eip=0002f4ab eax=00000001 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 ebp=00094880 esp=00094808 cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 cs:eip=f7 f1 85 db 89 c1 89 45-94 74 08 8b 55 18 89 32 89 7a 04 89 4d 98 8b 45-94 8b 55 98 83 c4 6c 5b ss:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted It was installed using the RootOnZFS guide almost two years ago (MBR, multiboot with Windows 7 and Ubuntu, ZFS in a single slice[1]). I'm usually tracking CURRENT up until the ports breakage with 10-CURRENT. Now I'm tracking 9.0. I built world from SVN revision 226141. But now, kernel, zfsboot and zfsloader are those from 9.0-BETA3's DVD1. The zpool is version 28 and the zfs filesystems are version 5. It all started when I copied a directory containing around 3.5GB of JPEG images, while building world (I can't remember if the build was finished, maybe it was waiting for install). This was quite slow (but I can't give you numbers). When I then ran make installkernel, I found it to be really slow two (maybe 1-2 seconds per module). I continued with installworld in single user, then rebooted. I can't remember if the problems appeared right away but the first one was an "ZFS: invalid zap_type=134218628" at boot, exactly as described on freebsd-fs@ [2]. At this point, I used VirtualBox (on Windows) to boot from 9.0-BETA3's DVD1 and restored kernel.old (I think). Now I have this "BTX halted" exception. What I tried so far: o reinstall zfsboot from 9.0-BETA3 o restore zfsloader.old o reinstall zfsloader from 9.0-BETA3 o zfs scrub (no error) o regen zpool.cache o SMART Extended Text (no error) o memtest (no error) o zdb -cv but it's unable to complete, not enough memory The only sign of hardware failure is "Reallocated Sector Count: 98" from smartctl. But for now, I can't be sure the HDD is the root of the problems. Does someone have any suggestions about this sofware and/or hardware issue? I'm running out of ideas on how to isolate it. [1] http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition [2] http://lists.freebsd.org/pipermail/freebsd-fs/2011-August/012248.html - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Vq0kACgkQa+xGJsFYOlOCewCfQT4jQVOVH5dDezNiSInFJS0N IBIAoNHU67v9O2BctFG3kT84gmXumBV6 =/H4A -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 15:20:11 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7801065670; Wed, 12 Oct 2011 15:20:11 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE518FC14; Wed, 12 Oct 2011 15:20:11 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 0810B60E5; Wed, 12 Oct 2011 11:20:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1318432810; bh=sRc8VNAzlIqMzJfT0r0+FXk0jgUG6J6l1En1JQNHZZg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=Muno8K5J8ejYeRuBYFYlsW8goy2eslenev1/rDqQEtwHrK1Nm2sQiDlfyATSTQFtg yhwCF4uVTH/g9fpKgLg159kTA2IjKhTZNF4mksaf3fdXLBxeX4w/3Q9yeO9MC9c DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: content-type:content-transfer-encoding; b=Us6PQ+FnYnl+UXZ+8L5KAECoBtUsxHy/DyWSXqSAG+h40k3LS7CDrNLQowfRwf9QX Nu4k2GU6eVu4k/J0OJ7B0fsA+qu5tCF4r+9Ca3Qf8qURqY45ZWmhy0vADMb8JFx Message-ID: <4E95B028.6090307@protected-networks.net> Date: Wed, 12 Oct 2011 11:20:08 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 15:20:11 -0000 SVN r226302 solves the ichwd failure to attach issue .. instead of .. isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 .. I now get .. isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH7 or equivalent chipset: Intel ICH7M watchdog timer pcib0: allocated type 4 (0x1030-0x1037) for rid 0 of ichwd0 pcib0: allocated type 4 (0x1060-0x107f) for rid 1 of ichwd0 ichwd0: Intel ICH7M watchdog timer (ICH7 or equivalent) ichwd0: timer disabled .. thanks! Michael From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 17:24:12 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 032071065675; Wed, 12 Oct 2011 17:24:12 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BA9558FC0A; Wed, 12 Oct 2011 17:24:11 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C3B9B1FFC33; Wed, 12 Oct 2011 17:24:10 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B64E0B95F; Wed, 12 Oct 2011 19:24:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Motin References: <86bou59gpf.fsf@ds4.des.no> <4E83186C.4080707@FreeBSD.org> Date: Wed, 12 Oct 2011 19:24:10 +0200 In-Reply-To: <4E83186C.4080707@FreeBSD.org> (Alexander Motin's message of "Wed, 28 Sep 2011 15:51:56 +0300") Message-ID: <86botmjf7p.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:24:12 -0000 Alexander Motin writes: > If short freezes you've descrived happens often enough, you may try to > log them down with enabling KTR_SPARE2 ktr event type and disabling > logging within few seconds after such freeze happened. I've been working with adri to try to isolate it. We've eliminated nfs and zfs as possible sources. I definitely think it's network-related, because I can trigger it by downloading a large file to /dev/null. Interestingly, it looks like serial console activity wakes it up - not immediately, but when I hooked up the console, it woke up within seconds after being frozen for almost ten minutes. I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR and KTR_SCHED enabled by default. I'll see what turns up. I'm also going to try machdep.idle=3Dhlt with kern.eventtimer.idletick=3D0, and using a PCI re(4) instead of the on-board msk(4) while running with default settings. BTW, can I suggest appropriating one of KTR_SPARE[234] and renaming it to KTR_CLOCK? I don't see why cxgb should use them, let alone all three; it should use KTR_DEV or KTR_NET instead. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 18:13:45 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C83FC106566B for ; Wed, 12 Oct 2011 18:13:45 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 59B778FC1A for ; Wed, 12 Oct 2011 18:13:45 +0000 (UTC) Received: by wyj26 with SMTP id 26so1485835wyj.13 for ; Wed, 12 Oct 2011 11:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b/vVS4xc4p5egsYNLgsYPEy+i0YsRjnDt6rkdrQglPQ=; b=Ld+MJk62dYoA9YTFJAHBjQrXbE/zPeowKCTTSyxx3RCQfMoljXwyEnE4xaT+o9MROo 6k5rfd5jOfRZ58v3x1CNdrs9M7NeuJqTvPSZ3ZdPDQD3YuXkNEi4D/xnNIxmxQVDUQxj V695eXVXljt6By3fGB4oXcRA3CqbzPPMj894Q= MIME-Version: 1.0 Received: by 10.227.155.84 with SMTP id r20mr4508360wbw.107.1318441605909; Wed, 12 Oct 2011 10:46:45 -0700 (PDT) Received: by 10.180.96.104 with HTTP; Wed, 12 Oct 2011 10:46:45 -0700 (PDT) In-Reply-To: <86botmjf7p.fsf@ds4.des.no> References: <86bou59gpf.fsf@ds4.des.no> <4E83186C.4080707@FreeBSD.org> <86botmjf7p.fsf@ds4.des.no> Date: Wed, 12 Oct 2011 13:46:45 -0400 Message-ID: From: Ryan Stone To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , current@freebsd.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:13:45 -0000 2011/10/12 Dag-Erling Sm=F8rgrav : > BTW, can I suggest appropriating one of KTR_SPARE[234] and renaming it > to KTR_CLOCK? =A0I don't see why cxgb should use them, let alone all > three; it should use KTR_DEV or KTR_NET instead. KTR_MALLOC has been completely unused in the tree since at least FreeBSD 6(presumably since uma went in), so that would be a better candidate to be appropriated. (Independent of that, though, I do agree that nothing in src/ should use KTR_SPAREX. Kinda defeats the purpose of SPAREX). From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 19:28:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7B31106566C for ; Wed, 12 Oct 2011 19:28:51 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 93C318FC0A for ; Wed, 12 Oct 2011 19:28:51 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9CJIUYA058174; Wed, 12 Oct 2011 12:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318447110; bh=pqVzn0Mt2Nw2tHw19z9lRZXtC9t6NCg6+i7ungdrEIk=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=MNRepIQ7lCNGJNiUG8/OyH9WzGm9JpUSjQGtYj1HAuvPd1PKwe7pwreaTpxR/drwS I2pIVXXr6hY1a6UBerrJ/czMlcACeshoijcUBAmA5K08nN/CYgY3iba73YM29CbM/2 HDroIIwS7fbb/viio2JctPGlveINcoGlW0KUDCOw= From: Sean Bruno To: Arnaud Lacombe In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 12 Oct 2011 12:18:29 -0700 Message-ID: <1318447109.2658.2.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: ipmi(4)/isa woes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 19:28:51 -0000 On Tue, 2011-10-11 at 15:34 -0700, Arnaud Lacombe wrote: > Hi folks, > > I've got a machine where ipmi(4) seem to be unable to fully attach. > 10-current kernel complains the following way: > > ipmi0: at iomem 0-0x1 on isa0 > ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa > ipmi0: couldn't configure I/O resource > device_attach: ipmi0 attach returned 6 Been running a lot of ipmi stuff over here at big purple lately. Haven't seen this. Which h/w model/vendor gear is this? Sean From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 19:40:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 158301065679; Wed, 12 Oct 2011 19:40:17 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B54FD8FC1C; Wed, 12 Oct 2011 19:40:16 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC430DB.dip.t-dialin.net [79.196.48.219]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 8FBF184401A; Wed, 12 Oct 2011 21:40:03 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id CA3EC1F03; Wed, 12 Oct 2011 21:40:00 +0200 (CEST) Date: Wed, 12 Oct 2011 21:39:54 +0200 From: Alexander Leidinger To: Adrian Chadd Message-ID: <20111012213954.00007d8a@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10cvs7 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 8FBF184401A.A0FFD X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1319053204.10999@cuLvY3dGJi2oBL37ckcNsg X-EBL-Spam-Status: No Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Is there a step by step howto for dtrace on 9.0 ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:40:17 -0000 On Sun, 9 Oct 2011 20:05:21 +0800 Adrian Chadd wrote: > Hi, > > the subject says it all - does anyone have a step by step howto for > doing userland and kernel dtrace on 9.0? Are you talking about the setup of dtrace? -> Wiki Are you talking about how to trace something? -> Solaris Dynamic Tracing Guide (for the basics) Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Oct 12 22:33:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B48C5106566C for ; Wed, 12 Oct 2011 22:33:35 +0000 (UTC) (envelope-from christoph_hoffmann@me.com) Received: from asmtpout209.mac.com (asmtpout209.mac.com [17.172.48.72]) by mx1.freebsd.org (Postfix) with ESMTP id 866A58FC0A for ; Wed, 12 Oct 2011 22:33:35 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from tunnel0.sec101.ch ([62.2.44.112]) by st11b01mm-asmtp209.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LSZ00DX12J8EO20@st11b01mm-asmtp209.mac.com> for freebsd-current@freebsd.org; Wed, 12 Oct 2011 14:33:35 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-10-12_07:2011-10-12, 2011-10-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110120259 From: Christoph Hoffmann In-reply-to: <4E944197.7050803@digsys.bg> Date: Wed, 12 Oct 2011 23:33:07 +0200 Message-id: References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> To: Daniel Kalchev X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-current@freebsd.org Subject: Re: gptzfsboot error using HP Smart Array P410i Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Oct 2011 22:33:35 -0000 Hello Daniel, Last time I checked up on the issue was on the 23rd of September, it was not fixed then. I was able to to boot from drive 0x80 after adding: *** zfsboot.c.orig Fri Sep 23 18:03:26 2011 --- zfsboot.c Fri Sep 23 18:47:44 2011 *************** *** 459,464 **** --- 459,465 ---- heap_end = (char *) PTOV(bios_basemem); } + printf("Hello! I am a hack.\n"); dsk = malloc(sizeof(struct dsk)); dsk->drive = *(uint8_t *)PTOV(ARGS); dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD; I am inclined to think that this is related to the way how we compile this code, especially when run on the following particular processor: 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz QPI Speed: 5.8 GT/s. Regards, Christoph On Oct 11, 2011, at 3:16 PM, Daniel Kalchev wrote: > Has this issue been resolved somehow? Sane method to build gptzfsboot that will run on HP's P410i? > > 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" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 06:41:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C38106567F for ; Thu, 13 Oct 2011 06:41:45 +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 D79A58FC0A for ; Thu, 13 Oct 2011 06:41:44 +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 JAA28156; Thu, 13 Oct 2011 09:41:36 +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 1REEz1-000MQA-VE; Thu, 13 Oct 2011 09:41:36 +0300 Message-ID: <4E96881E.5020505@FreeBSD.org> Date: Thu, 13 Oct 2011 09:41:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christoph Hoffmann References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Daniel Kalchev Subject: Re: gptzfsboot error using HP Smart Array P410i Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 06:41:45 -0000 on 13/10/2011 00:33 Christoph Hoffmann said the following: > Hello Daniel, > > Last time I checked up on the issue was on the 23rd of September, > it was not fixed then. > I was able to to boot from drive 0x80 after adding: > > *** zfsboot.c.orig Fri Sep 23 18:03:26 2011 > --- zfsboot.c Fri Sep 23 18:47:44 2011 > *************** > *** 459,464 **** > --- 459,465 ---- > heap_end = (char *) PTOV(bios_basemem); > } > > + printf("Hello! I am a hack.\n"); > dsk = malloc(sizeof(struct dsk)); > dsk->drive = *(uint8_t *)PTOV(ARGS); > dsk->type = dsk->drive & DRV_HARD ? TYPE_AD : TYPE_FD; > > I am inclined to think that this is related to the way how we compile this code, > especially when run on the following particular processor: > > 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled > Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz > QPI Speed: 5.8 GT/s. Can you try the latest code in head? I've removed all the optimization/pessimization compiler flags for gpt/zfs boot blocks that at times seemed to do more harm than good. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 08:15:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE41D10656AD for ; Thu, 13 Oct 2011 08:15:23 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 32DCF8FC13 for ; Thu, 13 Oct 2011 08:15:22 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1365956bkb.13 for ; Thu, 13 Oct 2011 01:15:22 -0700 (PDT) Received: by 10.204.15.194 with SMTP id l2mr1748252bka.83.1318493721766; Thu, 13 Oct 2011 01:15:21 -0700 (PDT) Received: from amy.lab.techwires.net (p54B4B204.dip.t-dialin.net. [84.180.178.4]) by mx.google.com with ESMTPS id d17sm2588243bkq.11.2011.10.13.01.15.19 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 01:15:19 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-current@freebsd.org Date: Thu, 13 Oct 2011 10:17:07 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-BETA3; KDE/4.6.5; amd64; ; ) References: <4E8ED3C8.1020108@freebsd.org> <4E8F0A47.1010408@gmail.com> In-Reply-To: <4E8F0A47.1010408@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201110131017.07154.bschmidt@freebsd.org> Cc: Rene Ladan , Niclas Zeising Subject: Re: iwn panic with 9.0-BETA3-amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 08:15:23 -0000 On Friday 07 October 2011 16:18:47 Niclas Zeising wrote: > This might or might not be related, but, I'm having trouble with the iwn > firmware crashing. I also have a clang built kernel (and userland) > buildwith CPUTYPE=core2. My iwn device is > iwn0: mem 0xe4000000-0xe4001fff irq > 17 at device 0.0 on pci16 > and the firmware gives the following output when it dies. > iwn0: iwn_intr: fatal firmware error > firmware error log: > error type = "NMI_INTERRUPT_WDG" (0x00000004) > program counter = 0x0000046C > source line = 0x000000D0 This is a known issue with the 4965's firmware. I have yet to find a reliable solution for that.. As a workaround you can disable background scan with ifconfig wlan0 -bgscan > The only way to restore the firmware is to reboot the computer. No need to reboot, killing the VAP and recreating it should get you going again. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 08:50:22 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6390110656A8 for ; Thu, 13 Oct 2011 08:50:22 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id E0EE68FC14 for ; Thu, 13 Oct 2011 08:50:21 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p9D8oCa8009064 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 13 Oct 2011 11:50:18 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E96A643.7010702@digsys.bg> Date: Thu, 13 Oct 2011 11:50:11 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christoph Hoffmann References: <9B96176A-7550-4B60-8F4D-0B667EEF7A15@me.com> <201108161515.50127.jhb@freebsd.org> <23B6937F-F261-4DC4-9168-96720251C98D@me.com> <4E502F2F.50209@FreeBSD.org> <9FAB808F-E5D4-4B93-9D5F-BAE025930273@me.com> <4E944197.7050803@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: gptzfsboot error using HP Smart Array P410i Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 08:50:22 -0000 On 13.10.11 00:33, Christoph Hoffmann wrote: > I am inclined to think that this is related to the way how we compile this code, > especially when run on the following particular processor: > > 1 Processor(s) detected, 4 total cores enabled, Hyperthreading is enabled > Proc 1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz > QPI Speed: 5.8 GT/s. For me, this happens on CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.10-MHz K8-class CPU) On HP DL360 G7 I try to boot -stable. Daniel From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 09:03:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DB811065672 for ; Thu, 13 Oct 2011 09:03:50 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 130188FC08 for ; Thu, 13 Oct 2011 09:03:49 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9D93deK031980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2011 20:03:41 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9D93dHv055315; Thu, 13 Oct 2011 20:03:39 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9D93dWh055314; Thu, 13 Oct 2011 20:03:39 +1100 (EST) (envelope-from peter) Date: Thu, 13 Oct 2011 20:03:39 +1100 From: Peter Jeremy To: =?iso-8859-1?Q?Jean-S=E9bastien_P=E9dron?= Message-ID: <20111013090339.GB54924@server.vk2pj.dyndns.org> References: <4E95AB49.30908@dumbbell.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <4E95AB49.30908@dumbbell.fr> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: "BTX halted" when booting 9.0-BETA3 (Root On ZFS) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 09:03:50 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Oct-12 16:59:21 +0200, Jean-S=E9bastien P=E9dron wrote: >For a couple of days now, I can't boot FreeBSD 9-BETA3 on my laptop. =2E.. >I built world from SVN revision 226141. But now, kernel, zfsboot and >zfsloader are those from 9.0-BETA3's DVD1. The zpool is version 28 and >the zfs filesystems are version 5. r226141 is head. Did you build a 10-current or RELENG_9 world? >It all started when I copied a directory containing around 3.5GB of >JPEG images, while building world (I can't remember if the build was >finished, maybe it was waiting for install). This was quite slow (but >I can't give you numbers). When I then ran make installkernel, I found >it to be really slow two (maybe 1-2 seconds per module). I continued >with installworld in single user, then rebooted. How full is your zpool? Has it ever been quite full (>~90%)? >What I tried so far: > o reinstall zfsboot from 9.0-BETA3 I presume you mean dd'ing it into the front of boot slice. > o restore zfsloader.old What is "zfsloader.old" at this point? The one from r226141? > o zfs scrub (no error) This means your pool is OK and you've run afoul of limitations in zfsboot. I suspect you have two options: 1) Do a send|recv to rebuild your root pool. 2) Build (and install) a new zfsboot with the patches mentioned in http://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012448.html I thought those patches had been committed but it seems they haven't bee= n. --=20 Peter Jeremy --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6WqWsACgkQ/opHv/APuIfVnQCgmeTRL3Z9QlN0zaet9S/RTIbu eNkAnRstFuLKXBFjqASksnt0C7wxsdY0 =mvyu -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 09:07:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF9310656E0 for ; Thu, 13 Oct 2011 09:07:46 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 076248FC12 for ; Thu, 13 Oct 2011 09:07:45 +0000 (UTC) Received: by eyd10 with SMTP id 10so2091875eyd.13 for ; Thu, 13 Oct 2011 02:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=QW3FXaAp6lFWREzoHERuMHE8BdQCWpt9Q/DXArDUWoQ=; b=gH4Iba838sRSssaiLT3SV+JDFQje1nyuNP9/+wNftxrKIICAUqRnCOmImJt6AO3Pp2 00DHl9fYhMRf43WUp9M2Kz4VZOXWVGNi52ReyfNBTGa/YtF/Fnt1KMBOSPziTUXhRBtW VDbhC6+/b47aWvvjbdmQxhFqD8Mn4sjMg+2mY= Received: by 10.213.112.200 with SMTP id x8mr492584ebp.12.1318495167804; Thu, 13 Oct 2011 01:39:27 -0700 (PDT) Received: from [192.168.1.129] (schavemaker.nl. [213.84.84.186]) by mx.google.com with ESMTPS id w58sm12315013eeb.4.2011.10.13.01.39.26 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 01:39:26 -0700 (PDT) Message-ID: <4E96A3BD.3080002@gmail.com> Date: Thu, 13 Oct 2011 10:39:25 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 9.x installer and GPT vs geom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 09:07:46 -0000 Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 09:25:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 982EC106568B for ; Thu, 13 Oct 2011 09:25:04 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4858FC14 for ; Thu, 13 Oct 2011 09:25:04 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1REHXD-0001lT-0w>; Thu, 13 Oct 2011 11:25:03 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1REHXC-0002Bd-Pt>; Thu, 13 Oct 2011 11:25:02 +0200 Message-ID: <4E96AE6E.8070609@zedat.fu-berlin.de> Date: Thu, 13 Oct 2011 11:25:02 +0200 From: "O. Hartmann" Organization: Freie =?ISO-8859-1?Q?Universit=E4t_Berlin?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Johan Hendriks References: <4E96A3BD.3080002@gmail.com> In-Reply-To: <4E96A3BD.3080002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@freebsd.org Subject: Re: 9.x installer and GPT vs geom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 09:25:04 -0000 On 10/13/11 10:39, Johan Hendriks wrote: > Hello all. > > I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. > However, and there has been some discussions about it, it would be nice > if the installer warns me that i could get in trouble if i want to use > gmirror and the like. > > Also i find it a little strange that the default mode, GPT in this case > is in some sort not compatible with the other default geom structure. > For a newcomer or for people who use gmirror and glabel on a regular > basis because there somewhat default, it could strike them if they start > using the default GPT. > > It is not logical. > Two default ways to do things that are in a way not compatible. > > So a warning at the installer level could make a lot of users aware of > this, and they can decide what to do, use GPT or go back to the old MBR. > They can start looking at the mailling list and so on to make the right > decision is GPT acceptable for me or not. > And not install FreeBSD and find out later that you could not use your > old gmirror and glabel tactics without corrupting the GPT structure. > > Just my thoughts about this. > > regards, > Johan Hendriks > Shouldn't be there also a warning that GPT can not be used with the FreeBSD native bootselector? I had trouble installing FreeBSD 9.0-CURRENT a while ago with default being GPT on my notebook and also wanting a Windows 7/x64 for presentations, selectable via the FreeBSD bootselector. This was possible with MBR, but it seems gone with GPT. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 10:54:40 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B61DE1065692; Thu, 13 Oct 2011 10:54:40 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA078FC0A; Thu, 13 Oct 2011 10:54:40 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D0BC51FFC33; Thu, 13 Oct 2011 10:54:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id B873DB93C; Thu, 13 Oct 2011 12:54:38 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org Date: Thu, 13 Oct 2011 12:54:38 +0200 Message-ID: <86pqi1b1qp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: pjd@freebsd.org Subject: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 10:54:40 -0000 I looked at some of the programs that use pidfile(3) in base, and they pretty much all get it wrong. Consider these two scenarios: 1) common case process A process B main() pidfile_open() -> success perform_initialization() daemon() pidfile_write() -> success perform_work() main() pidfile_open() -> EEXIST exit() 2) very unlikely but still possible case process A process B main() pidfile_open() -> success main() perform_initialization() pidfile_open() -> EAGAIN daemon() perform_initialization() pidfile_write() -> success daemon() perform_work() perform_work() The problem is that most of them (at least the ones I checked) ignore a pidfile_open() failure unless errno =3D=3D EEXIST. How do we fix this? My suggestion is to loop until pidfile_open() succeeds or errno !=3D EAGAIN. Does anyone have any objections to that approach? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 11:36:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA5DF10656AA; Thu, 13 Oct 2011 11:36:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6738FC16; Thu, 13 Oct 2011 11:36:06 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 9E7111FFC33; Thu, 13 Oct 2011 11:36:05 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8178BB93C; Thu, 13 Oct 2011 13:36:05 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Motin References: <86bou59gpf.fsf@ds4.des.no> <4E83186C.4080707@FreeBSD.org> <86botmjf7p.fsf@ds4.des.no> Date: Thu, 13 Oct 2011 13:36:05 +0200 In-Reply-To: <86botmjf7p.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Wed, 12 Oct 2011 19:24:10 +0200") Message-ID: <86lispaztm.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:36:06 -0000 Dag-Erling Sm=C3=B8rgrav writes: > I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR > and KTR_SCHED enabled by default. I'll see what turns up. I'm also > going to try machdep.idle=3Dhlt with kern.eventtimer.idletick=3D0, and us= ing > a PCI re(4) instead of the on-board msk(4) while running with default > settings. Great, the bug does not occur when KTR is enabled. The machine has been up for 14+ hours without crashing, despite plenty of network activity, which usually triggers a freeze within minutes. It looks like there may still be short freezes (a few seconds at a time). I'm thinking of instrumenting fetch(1) to record any instances of fread() taking more than, say, half a second. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 11:47:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E0B810656FA for ; Thu, 13 Oct 2011 11:47:08 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 639C28FC13 for ; Thu, 13 Oct 2011 11:47:07 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id B174BCE7; Thu, 13 Oct 2011 13:31:08 +0200 (CEST) Date: Thu, 13 Oct 2011 13:30:26 +0200 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20111013113024.GE1667@garage.freebsd.pl> References: <86pqi1b1qp.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m1UC1K4AOz1Ywdkx" Content-Disposition: inline In-Reply-To: <86pqi1b1qp.fsf@ds4.des.no> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:47:08 -0000 --m1UC1K4AOz1Ywdkx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2011 at 12:54:38PM +0200, Dag-Erling Sm=F8rgrav wrote: > I looked at some of the programs that use pidfile(3) in base, and they > pretty much all get it wrong. Consider these two scenarios: >=20 > 1) common case >=20 > process A process B >=20 > main() > pidfile_open() -> success > perform_initialization() > daemon() > pidfile_write() -> success > perform_work() main() > pidfile_open() -> EEXIST > exit() >=20 > 2) very unlikely but still possible case >=20 > process A process B >=20 > main() > pidfile_open() -> success main() > perform_initialization() pidfile_open() -> EAGAIN > daemon() perform_initialization() > pidfile_write() -> success daemon() > perform_work() perform_work() >=20 > The problem is that most of them (at least the ones I checked) ignore a > pidfile_open() failure unless errno =3D=3D EEXIST. >=20 > How do we fix this? My suggestion is to loop until pidfile_open() > succeeds or errno !=3D EAGAIN. Does anyone have any objections to that > approach? I think we already do that internally in pidfile_open(). Can you take a loo= k at the source and confirm that this is what you mean? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --m1UC1K4AOz1Ywdkx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6Wy88ACgkQForvXbEpPzTV6QCcDsNDZ/F72yizM78kgw6bMZhe FZwAoO8jFCQRyzPTFOsviAf9ofh4bHkj =dbic -----END PGP SIGNATURE----- --m1UC1K4AOz1Ywdkx-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 11:51:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FCC110656B4; Thu, 13 Oct 2011 11:51:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D38828FC08; Thu, 13 Oct 2011 11:51:27 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DC7291FFC33; Thu, 13 Oct 2011 11:51:26 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C0195B93C; Thu, 13 Oct 2011 13:51:26 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek References: <86pqi1b1qp.fsf@ds4.des.no> <20111013113024.GE1667@garage.freebsd.pl> Date: Thu, 13 Oct 2011 13:51:26 +0200 In-Reply-To: <20111013113024.GE1667@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu, 13 Oct 2011 13:30:26 +0200") Message-ID: <86botlaz41.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:51:28 -0000 Pawel Jakub Dawidek writes: > Dag-Erling Sm=C3=B8rgrav writes: > > How do we fix this? My suggestion is to loop until pidfile_open() > > succeeds or errno !=3D EAGAIN. Does anyone have any objections to that > > approach? > I think we already do that internally in pidfile_open(). Can you take a l= ook at > the source and confirm that this is what you mean? No, it doesn't; pidfile_open(3) returns NULL with errno =3D=3D EAGAIN if the pidfile is locked but empty, as is the case in the window between a successful pidfile_open(3) and the first pidfile_write(3). This is documented in the man page: [EAGAIN] Some process already holds the lock on the given pi= d=E2=80=90 file, but the file is truncated. Most likely, the existing daemon is writing new PID into the file. I have a patch that adds a pidfile to dhclient(8), where I do this: for (;;) { pidfile =3D pidfile_open(path_dhclient_pidfile, 0600, &othe= rpid); if (pidfile !=3D NULL || errno !=3D EAGAIN) break; sleep(1); } if (pidfile =3D=3D NULL) { if (errno =3D=3D EEXIST) error("dhclient already running, pid: %d.", otherpi= d); warning("Cannot open or create pidfile: %m"); } I'm not sure I agree with the common idiom (which I copied here) of ignoring all other errors than EEXIST, but that's a different story. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:10:08 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A6110656EB; Thu, 13 Oct 2011 12:10:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0E98FC15; Thu, 13 Oct 2011 12:10:08 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C4CEE5DCB; Thu, 13 Oct 2011 12:10:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p9DCA40J002570; Thu, 13 Oct 2011 12:10:05 GMT (envelope-from phk@phk.freebsd.dk) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 13 Oct 2011 13:36:05 +0200." <86lispaztm.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 13 Oct 2011 12:10:04 +0000 Message-ID: <2569.1318507804@critter.freebsd.dk> Cc: Alexander Motin , current@FreeBSD.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 12:10:08 -0000 In message <86lispaztm.fsf@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >Dag-Erling Sm=C3=B8rgrav writes: >> I've just built a kernel with KTR support, and with KTR_SPARE2, KTR_INTR >> and KTR_SCHED enabled by default. I'll see what turns up. I'm also >> going to try machdep.idle=3Dhlt with kern.eventtimer.idletick=3D0, and us= >ing >> a PCI re(4) instead of the on-board msk(4) while running with default >> settings. > >Great, the bug does not occur when KTR is enabled. The machine has been >up for 14+ hours without crashing, despite plenty of network activity, >which usually triggers a freeze within minutes. For what it's worth, I regularly (=every 10-12 days or so) see all timer activity in the system die and have to use the 4-sec power-switch to get the system down. This is on: FreeBSD critter.freebsd.dk 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r224239M: Fri Aug 19 14:35:16 UTC 2011 phk@critter.freebsd.dk:/sys/amd64/compile/CRITTER amd64 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:51:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA67F10656D3 for ; Thu, 13 Oct 2011 12:51:30 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id A7DAB8FC0A for ; Thu, 13 Oct 2011 12:51:30 +0000 (UTC) Received: by iaky10 with SMTP id y10so1654029iak.13 for ; Thu, 13 Oct 2011 05:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bvBBsPWfXhCibUXrVMWg3wHmVqCJBSZGH7YeU+5GJ1U=; b=uljopDg+MrlKXI5abJ/a8GJR1fkodM98TO+67thSNGDnWjhdjCovx0otArMy5DT/83 JY+ydvGvRKW1Mmbb+FlN7yd5v+JqBBfQMl0GT+N9HtCXNMUUWVOQgMmkCo5tm7IZs+9m OMfLsHdacLDLeYf7ryd8iPPwkz3mrthn0NK+4= MIME-Version: 1.0 Received: by 10.231.83.19 with SMTP id d19mr1645438ibl.7.1318508471553; Thu, 13 Oct 2011 05:21:11 -0700 (PDT) Received: by 10.231.23.66 with HTTP; Thu, 13 Oct 2011 05:21:11 -0700 (PDT) In-Reply-To: <86botlaz41.fsf@ds4.des.no> References: <86pqi1b1qp.fsf@ds4.des.no> <20111013113024.GE1667@garage.freebsd.pl> <86botlaz41.fsf@ds4.des.no> Date: Thu, 13 Oct 2011 09:21:11 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pawel Jakub Dawidek , current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 12:51:31 -0000 2011/10/13 Dag-Erling Sm=C3=B8rgrav : > Pawel Jakub Dawidek writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > How do we fix this? =C2=A0My suggestion is to loop until pidfile_open(= ) >> > succeeds or errno !=3D EAGAIN. =C2=A0Does anyone have any objections t= o that >> > approach? >> I think we already do that internally in pidfile_open(). Can you take a = look at >> the source and confirm that this is what you mean? > > No, it doesn't; pidfile_open(3) returns NULL with errno =3D=3D EAGAIN if = the > pidfile is locked but empty, as is the case in the window between a > successful pidfile_open(3) and the first pidfile_write(3). =C2=A0This is > documented in the man page: > > =C2=A0 =C2=A0 [EAGAIN] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Some process al= ready holds the lock on the given pid=E2=80=90 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0file, but the file is truncated. =C2=A0Most likely, the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0existing daemon is writing new PID into the file. > > I have a patch that adds a pidfile to dhclient(8), where I do this: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0for (;;) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pidfile =3D pidfil= e_open(path_dhclient_pidfile, 0600, &otherpid); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (pidfile !=3D N= ULL || errno !=3D EAGAIN) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0break; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sleep(1); > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (pidfile =3D=3D NULL) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (errno =3D=3D E= EXIST) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0error("dhclient already running, pid: %d.", otherpid); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0warning("Cannot op= en or create pidfile: %m"); > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > > I'm not sure I agree with the common idiom (which I copied here) of > ignoring all other errors than EEXIST, but that's a different story. You are also ignoring the return value of sleep(1), which would tell you if the call was interrupted by a signal handler. This can be fine for dhclient(8) but other utilities might require some guards against such interruptions. --=20 "The flames are all long gone, but the=EF=BB=BF pain lingers on" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 12:54:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D26210656A6; Thu, 13 Oct 2011 12:54:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF268FC17; Thu, 13 Oct 2011 12:54:17 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D6DEA1FFC33; Thu, 13 Oct 2011 12:54:16 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id BAF90B93C; Thu, 13 Oct 2011 14:54:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org References: <86pqi1b1qp.fsf@ds4.des.no> Date: Thu, 13 Oct 2011 14:54:16 +0200 In-Reply-To: <86pqi1b1qp.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Thu, 13 Oct 2011 12:54:38 +0200") Message-ID: <864nzdaw7b.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: pjd@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 12:54:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable After discussing this with pjd@ on IRC, I arrived at the attached patch, which increases the length of time pidfile_open() itself waits (I hadn't noticed that it already looped) and sets *pidptr to -1 if it fails to read a pid. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=pidfile_open-loop.diff Index: lib/libutil/pidfile.c =================================================================== --- lib/libutil/pidfile.c (revision 226271) +++ lib/libutil/pidfile.c (working copy) @@ -118,22 +118,19 @@ */ fd = flopen(pfh->pf_path, O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode); - if (fd == -1) { - count = 0; + if (fd == -1 && errno == EWOULDBLOCK && pidptr != NULL) { + *pidptr = -1; + count = 20; rqtp.tv_sec = 0; rqtp.tv_nsec = 5000000; - if (errno == EWOULDBLOCK && pidptr != NULL) { - again: + for (;;) { errno = pidfile_read(pfh->pf_path, pidptr); - if (errno == 0) - errno = EEXIST; - else if (errno == EAGAIN) { - if (++count <= 3) { - nanosleep(&rqtp, 0); - goto again; - } - } + if (errno != EAGAIN || --count == 0) + break; + nanosleep(&rqtp, 0); } + if (errno == 0) + errno = EEXIST; free(pfh); return (NULL); } --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:13:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E580106566C for ; Thu, 13 Oct 2011 13:13:53 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 0316B8FC15 for ; Thu, 13 Oct 2011 13:13:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LT000A04A34JM00@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Thu, 13 Oct 2011 08:13:52 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.68.83]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LT000A21A33G100@smtpauth3.wiscmail.wisc.edu> for freebsd-current@freebsd.org; Thu, 13 Oct 2011 08:13:51 -0500 (CDT) Date: Thu, 13 Oct 2011 08:13:49 -0500 From: Nathan Whitehorn In-reply-to: <4E96AE6E.8070609@zedat.fu-berlin.de> To: freebsd-current@freebsd.org Message-id: <4E96E40D.80706@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.68.83 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.13.130314, SenderIP=76.210.68.83 References: <4E96A3BD.3080002@gmail.com> <4E96AE6E.8070609@zedat.fu-berlin.de> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 Subject: Re: 9.x installer and GPT vs geom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 13:13:53 -0000 On 10/13/11 04:25, O. Hartmann wrote: > On 10/13/11 10:39, Johan Hendriks wrote: >> Hello all. >> >> I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. >> However, and there has been some discussions about it, it would be nice >> if the installer warns me that i could get in trouble if i want to use >> gmirror and the like. >> >> Also i find it a little strange that the default mode, GPT in this case >> is in some sort not compatible with the other default geom structure. >> For a newcomer or for people who use gmirror and glabel on a regular >> basis because there somewhat default, it could strike them if they start >> using the default GPT. >> >> It is not logical. >> Two default ways to do things that are in a way not compatible. >> >> So a warning at the installer level could make a lot of users aware of >> this, and they can decide what to do, use GPT or go back to the old MBR. >> They can start looking at the mailling list and so on to make the right >> decision is GPT acceptable for me or not. >> And not install FreeBSD and find out later that you could not use your >> old gmirror and glabel tactics without corrupting the GPT structure. >> >> Just my thoughts about this. >> >> regards, >> Johan Hendriks >> > Shouldn't be there also a warning that GPT can not be used with the > FreeBSD native bootselector? I had trouble installing FreeBSD > 9.0-CURRENT a while ago with default being GPT on my notebook and also > wanting a Windows 7/x64 for presentations, selectable via the FreeBSD > bootselector. This was possible with MBR, but it seems gone with GPT. If you install onto an already MBR-formatted disk (say, you're dual-booting), it will use MBR as the default, not GPT. It only uses GPT as the default if you (a) put in a totally blank disk or (b) say you want to dedicate the disk entirely to FreeBSD. -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:38:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42049106572C for ; Thu, 13 Oct 2011 13:38:24 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id C18DC8FC21 for ; Thu, 13 Oct 2011 13:38:23 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RELUL-0008a6-WC for freebsd-current@freebsd.org; Thu, 13 Oct 2011 15:38:22 +0200 Message-ID: <4E96E9CD.3080708@dumbbell.fr> Date: Thu, 13 Oct 2011 15:38:21 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E95AB49.30908@dumbbell.fr> <20111013090339.GB54924@server.vk2pj.dyndns.org> In-Reply-To: <20111013090339.GB54924@server.vk2pj.dyndns.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: "BTX halted" when booting 9.0-BETA3 (Root On ZFS) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 13:38:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13.10.2011 11:03, Peter Jeremy wrote: >> I built world from SVN revision 226141. (...) > > r226141 is head. Did you build a 10-current or RELENG_9 world? I built stable/9. Sorry, the revision I mention is wrong because I have one checkout of /base/ (with head/ and stable/9 inside). I always run svn update from this directory, so when I do "svn info" in stable/9, it indicates the last revision for the entire checkout, which as in head as you pointed out. I checked with "svn log" and the last revision is 226115. Sorry for the mistake. > How full is your zpool? Has it ever been quite full (>~90%)? Yes, it's pretty full right now (> 95%). >> What I tried so far: o reinstall zfsboot from 9.0-BETA3 > > I presume you mean dd'ing it into the front of boot slice. Yes, as described in the RootOnZFS guide. > What is "zfsloader.old" at this point? The one from r226141? Now, I have zfsboot and zfsloader from 9.0-BETA3's DVD1. The problem is the same with the one from r226115. > I suspect you have two options: 1) Do a send|recv to rebuild your > root pool. 2) Build (and install) a new zfsboot with the patches > mentioned in > http://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012448.html > > > I thought those patches had been committed but it seems they haven't been. I tried this patch but it doesn't fix the problem. Andriy suggested me to try tools/tools/zfsboottest and this tool reads the files properly. Peter, I'll try to send/recv as soon as I have access to a storage with enough space. Thank you for your help! - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6W6c0ACgkQa+xGJsFYOlMLOACguADWl0oTovV2S8Io5evSQ0EX JNoAoMyoWtmHpEiLcTAQUkxWGZy/KQhb =3BKE -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 13:49:30 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A481065695 for ; Thu, 13 Oct 2011 13:49:30 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 583258FC08 for ; Thu, 13 Oct 2011 13:49:29 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id CED2FD99; Thu, 13 Oct 2011 15:49:24 +0200 (CEST) Date: Thu, 13 Oct 2011 15:48:42 +0200 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20111013134841.GF1667@garage.freebsd.pl> References: <86pqi1b1qp.fsf@ds4.des.no> <864nzdaw7b.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GdbWtwDHkcXqP16f" Content-Disposition: inline In-Reply-To: <864nzdaw7b.fsf@ds4.des.no> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 13:49:30 -0000 --GdbWtwDHkcXqP16f Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2011 at 02:54:16PM +0200, Dag-Erling Sm=F8rgrav wrote: > After discussing this with pjd@ on IRC, I arrived at the attached patch, > which increases the length of time pidfile_open() itself waits (I hadn't > noticed that it already looped) and sets *pidptr to -1 if it fails to read > a pid. I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same value on FreeBSD) should be converted to EEXIST on pidfile_open() return. Also if we now have for loop, why not to put count in there? I'm not very happy about touching pidptr in case of error other than EEXIST. This is not documented, but a bit unexpected anyway. I'm happy with increasing the timeout. > Index: lib/libutil/pidfile.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/libutil/pidfile.c (revision 226271) > +++ lib/libutil/pidfile.c (working copy) > @@ -118,22 +118,19 @@ > */ > fd =3D flopen(pfh->pf_path, > O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode); > - if (fd =3D=3D -1) { > - count =3D 0; > + if (fd =3D=3D -1 && errno =3D=3D EWOULDBLOCK && pidptr !=3D NULL) { > + *pidptr =3D -1; > + count =3D 20; > rqtp.tv_sec =3D 0; > rqtp.tv_nsec =3D 5000000; > - if (errno =3D=3D EWOULDBLOCK && pidptr !=3D NULL) { > - again: > + for (;;) { > errno =3D pidfile_read(pfh->pf_path, pidptr); > - if (errno =3D=3D 0) > - errno =3D EEXIST; > - else if (errno =3D=3D EAGAIN) { > - if (++count <=3D 3) { > - nanosleep(&rqtp, 0); > - goto again; > - } > - } > + if (errno !=3D EAGAIN || --count =3D=3D 0) > + break; > + nanosleep(&rqtp, 0); > } > + if (errno =3D=3D 0) > + errno =3D EEXIST; > free(pfh); > return (NULL); > } --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --GdbWtwDHkcXqP16f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6W7DkACgkQForvXbEpPzRUbQCeJlsMsNYJvPMRKe4Ht9c82fZx vLkAoMzzW86nyjmzY7QLmwzMxHOFf7lQ =ngQc -----END PGP SIGNATURE----- --GdbWtwDHkcXqP16f-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:11:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 333F1106564A; Thu, 13 Oct 2011 14:11:42 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EAFA38FC08; Thu, 13 Oct 2011 14:11:41 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0B60F1FFC34; Thu, 13 Oct 2011 14:11:41 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E584CB93C; Thu, 13 Oct 2011 16:11:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek References: <86pqi1b1qp.fsf@ds4.des.no> <864nzdaw7b.fsf@ds4.des.no> <20111013134841.GF1667@garage.freebsd.pl> Date: Thu, 13 Oct 2011 16:11:40 +0200 In-Reply-To: <20111013134841.GF1667@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Thu, 13 Oct 2011 15:48:42 +0200") Message-ID: <86mxd59e1v.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 14:11:42 -0000 Pawel Jakub Dawidek writes: > I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same > value on FreeBSD) should be converted to EEXIST on pidfile_open() > return. The historical (and documented) behavior is to return EAGAIN. > Also if we now have for loop, why not to put count in there? Because if we do, there will be a nanosleep after the last pidfile_read() attempt. We need to break the loop after pidfile_read() failed but before nanosleep(). > I'm not very happy about touching pidptr in case of error other than > EEXIST. This is not documented, but a bit unexpected anyway. Well, it was your idea, I just moved it to before the loop :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:13:01 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D9DB106566B; Thu, 13 Oct 2011 14:13:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 013348FC0A; Thu, 13 Oct 2011 14:13:00 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3F5751FFC33; Thu, 13 Oct 2011 14:13:00 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 31B3BB93C; Thu, 13 Oct 2011 16:13:00 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Poul-Henning Kamp" References: <2569.1318507804@critter.freebsd.dk> Date: Thu, 13 Oct 2011 16:13:00 +0200 In-Reply-To: <2569.1318507804@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 13 Oct 2011 12:10:04 +0000") Message-ID: <86lisp9dzn.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , current@FreeBSD.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 14:13:01 -0000 "Poul-Henning Kamp" writes: > For what it's worth, I regularly (=3Devery 10-12 days or so) see all > timer activity in the system die and have to use the 4-sec > power-switch to get the system down. Could you check if network activity (e.g. downloading an ISO) triggers it, and if so, if it goes away when you set the kern.eventtimer.idletick sysctl to 0? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:15:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA25F106564A; Thu, 13 Oct 2011 14:15:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54BB08FC14; Thu, 13 Oct 2011 14:15:55 +0000 (UTC) Received: by ggeq3 with SMTP id q3so66576gge.13 for ; Thu, 13 Oct 2011 07:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hjUTuL+t1kBLwsNgUDzvLADtHWKyIgwv0+jQgzzYedU=; b=kuXz97kFfJMqz+3HvawK2rpde3/yV4xs5ZAJa5qGLh1SBt2cdam2SSbPv0fmqqIufu OCbYau6xFUyZW/1NpZpvE4E8MEuIOOjQ6ZIELNkczKSPjbsJEHG4FkZIJvFZYCI78g0E qSzXNvpP5ES93MeAqSOhemGSQsLK56RS+msRk= MIME-Version: 1.0 Received: by 10.236.187.70 with SMTP id x46mr5082505yhm.71.1318515354792; Thu, 13 Oct 2011 07:15:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.109.167 with HTTP; Thu, 13 Oct 2011 07:15:54 -0700 (PDT) In-Reply-To: <86lisp9dzn.fsf@ds4.des.no> References: <2569.1318507804@critter.freebsd.dk> <86lisp9dzn.fsf@ds4.des.no> Date: Thu, 13 Oct 2011 22:15:54 +0800 X-Google-Sender-Auth: nfffbHmrF2ivtLpHtCK4RQO1CBE Message-ID: From: Adrian Chadd To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , Alexander Motin , current@freebsd.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 14:15:55 -0000 2011/10/13 Dag-Erling Sm=F8rgrav : > "Poul-Henning Kamp" writes: >> For what it's worth, I regularly (=3Devery 10-12 days or so) see all >> timer activity in the system die and have to use the 4-sec >> power-switch to get the system down. > > Could you check if network activity (e.g. downloading an ISO) triggers > it, and if so, if it goes away when you set the kern.eventtimer.idletick > sysctl to 0? Don't you mean 'set it to 1' ? adrian From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:39:46 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC83E1065678; Thu, 13 Oct 2011 14:39:46 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4478FC19; Thu, 13 Oct 2011 14:39:46 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E4B745DC4; Thu, 13 Oct 2011 14:39:44 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p9DEdiqV002803; Thu, 13 Oct 2011 14:39:44 GMT (envelope-from phk@phk.freebsd.dk) To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 13 Oct 2011 16:13:00 +0200." <86lisp9dzn.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1 Date: Thu, 13 Oct 2011 14:39:44 +0000 Message-ID: <2802.1318516784@critter.freebsd.dk> Cc: Alexander Motin , current@FreeBSD.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 14:39:46 -0000 In message <86lisp9dzn.fsf@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >"Poul-Henning Kamp" writes: >> For what it's worth, I regularly (=3Devery 10-12 days or so) see all >> timer activity in the system die and have to use the 4-sec >> power-switch to get the system down. > >Could you check if network activity (e.g. downloading an ISO) triggers >it, and if so, if it goes away when you set the kern.eventtimer.idletick >sysctl to 0? I have never seen any correlation, mostly because I usually don't notice it right away, but only when something like top(1) doesn't update and similar. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 14:56:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C4631065670; Thu, 13 Oct 2011 14:56:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6518FC0A; Thu, 13 Oct 2011 14:56:43 +0000 (UTC) Received: by ywp17 with SMTP id 17so1626911ywp.13 for ; Thu, 13 Oct 2011 07:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=mZuyhcBjSqxyHfPrG0nxL80WlTTBAbUsP61s8+GKmwc=; b=JqtQlBE6miANUVLEu4+sm3jKGrnahaDg9Sxpz+Shg+J9NR2xduYviqtyVqZIKhIRHo p5eYx9/c1H3WFeenq0bFhzngLrB0tOVrHui2IZnzG3665pldYEmlK/3D6YO1KGJ/Ei8B twhmfa32PTqoDnvyke7Gcbtujrtf+l5pJTVsQ= MIME-Version: 1.0 Received: by 10.236.181.196 with SMTP id l44mr5419593yhm.37.1318517803387; Thu, 13 Oct 2011 07:56:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.109.167 with HTTP; Thu, 13 Oct 2011 07:56:43 -0700 (PDT) Date: Thu, 13 Oct 2011 22:56:43 +0800 X-Google-Sender-Auth: U5IcGkuI8TGNePTHHxh4D0dWuF4 Message-ID: From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: usb related wtf-ness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 14:56:44 -0000 Here's something from a recentish -head. This is the same behaviour as my beta2/beta3 boxes. This time, however, it's on a MIPS board. It's quite possible this _isn't_ a USB problem but is a scsi or cam layer problem. The root is on /dev/da0, a USB device. usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered ugen0.2: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:0:0:-1: Attached to scbus0 Trying to mount root from ufs:da0s1a []... mountroot: waiting for device da0s1a ... da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3902MB (7991296 512 byte sectors: 255H 63S/T 497C) Then, I plug in a second USB storage device: ugen0.3: at usbus0 umass1: on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x0000 umass1:1:1:-1: Attached to scbus1 da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) Then: adrian-home-mips# fdisk load: 0.00 cmd: tcsh 1544 [vnread] 3.47r 0.00u 0.00s 0% 3472k (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 6d 69 d0 0 0 40 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: HARDWARE FAILURE asc:4b,0 (Data phase error) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 6d 69 d0 0 0 40 0 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (da0:umass-sim0:0:0:0): Invalidating pack (da0:umass-sim0:0:0:0): oustanding 0 load: 0.00 cmd: tg_vfs_done():da0s1a[READ(offset=3667099648, length=32768)]error = 6 csh 1544 [vnreadvnode_pager_getpages: I/O read error ] 4.37r 0.00u 0.00s 0% 3472k /sbin/fdisk: Input/output error. adrian-home-mips# bsdlabel g_vfs_done():da0s1a[READ(offset=3666673664, length=32768)]error = 6 vnode_pager_getpages: I/O read error /sbin/bsdlabel: Input/output error. adrian-home-mips# usbdevs usbdevs: Command not found. adrian-home-mips# usbconfig -l g_vfs_done():da0s1a[READ(offset=1594703872, length=16384)]error = 6 vnode_pager_getpages: I/O read error /usr/sbin/usbconfig: Input/output error. .. what the? :) adrian From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 15:34:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D0D106564A for ; Thu, 13 Oct 2011 15:34:57 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 91F7D8FC16 for ; Thu, 13 Oct 2011 15:34:55 +0000 (UTC) Received: by wwe3 with SMTP id 3so1866492wwe.31 for ; Thu, 13 Oct 2011 08:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=dILNHbpnRI/mAxn/I2WQ5dXW7S++n9LORfzrLaoNjIw=; b=HFcp/8vDnZR7/UjaYWcEBsWRhb+GUJpcSIFObPz364eHqWoUocKyx6LGsHWUtHw4AZ C6p6JphbhxQr1ASpqjGS/FFNVEoMR9KDl0f63LpWJCCNbq2DWxEcd1/A3q4MWyz4r7i4 LmVY8YcqB/KuQQgWWcmKIJl8WbGKqPzEroAno= Received: by 10.216.14.83 with SMTP id c61mr107549wec.4.1318520094257; Thu, 13 Oct 2011 08:34:54 -0700 (PDT) Received: from [192.168.1.129] (schavemaker.nl. [213.84.84.186]) by mx.google.com with ESMTPS id l9sm6602206wba.5.2011.10.13.08.34.52 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 08:34:53 -0700 (PDT) Message-ID: <4E97051A.3010602@gmail.com> Date: Thu, 13 Oct 2011 17:34:50 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nathan Whitehorn , freebsd-current@freebsd.org References: <4E96A3BD.3080002@gmail.com> <4E96AE6E.8070609@zedat.fu-berlin.de> <4E96E40D.80706@freebsd.org> In-Reply-To: <4E96E40D.80706@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 9.x installer and GPT vs geom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 15:34:57 -0000 Nathan Whitehorn schreef: > On 10/13/11 04:25, O. Hartmann wrote: >> On 10/13/11 10:39, Johan Hendriks wrote: >>> Hello all. >>> >>> I just used the 9.0 B3 installer, and it defaults to GPT, which is >>> nice. >>> However, and there has been some discussions about it, it would be nice >>> if the installer warns me that i could get in trouble if i want to use >>> gmirror and the like. >>> >>> Also i find it a little strange that the default mode, GPT in this case >>> is in some sort not compatible with the other default geom structure. >>> For a newcomer or for people who use gmirror and glabel on a regular >>> basis because there somewhat default, it could strike them if they >>> start >>> using the default GPT. >>> >>> It is not logical. >>> Two default ways to do things that are in a way not compatible. >>> >>> So a warning at the installer level could make a lot of users aware of >>> this, and they can decide what to do, use GPT or go back to the old >>> MBR. >>> They can start looking at the mailling list and so on to make the right >>> decision is GPT acceptable for me or not. >>> And not install FreeBSD and find out later that you could not use your >>> old gmirror and glabel tactics without corrupting the GPT structure. >>> >>> Just my thoughts about this. >>> >>> regards, >>> Johan Hendriks >>> >> Shouldn't be there also a warning that GPT can not be used with the >> FreeBSD native bootselector? I had trouble installing FreeBSD >> 9.0-CURRENT a while ago with default being GPT on my notebook and >> also wanting a Windows 7/x64 for presentations, selectable via the >> FreeBSD bootselector. This was possible with MBR, but it seems gone >> with GPT. > > If you install onto an already MBR-formatted disk (say, you're > dual-booting), it will use MBR as the default, not GPT. It only uses > GPT as the default if you (a) put in a totally blank disk or (b) say > you want to dedicate the disk entirely to FreeBSD. > -Nathan And that is what most people do, use an entire new disk, and use that whole disk for FreeBSD. Me included, if i install a new server that is the way i do it. I think most people do it that way. If they must install a new server i think the most users will use the defaults the installer gives them. And because there are a lot of people who use gmirror to mirror the whole disk, they get bitten by the GPT vs geom metadata issue. If however the installer warns people, they know things have changed, so they can investigate, and then they will hopefully find the threads regarding GPT, gmirror and glabel, and the problems that could arise. There is a lot on the internet about it already. Forums.freebsd.org included. So a warning (or pointer) is at place as far as i am concerned. regards Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:27:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057481065675; Thu, 13 Oct 2011 16:27:10 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B71E88FC1F; Thu, 13 Oct 2011 16:27:09 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 035F61FFC37; Thu, 13 Oct 2011 16:27:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id EB24FB93E; Thu, 13 Oct 2011 18:27:08 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Adrian Chadd References: <2569.1318507804@critter.freebsd.dk> <86lisp9dzn.fsf@ds4.des.no> Date: Thu, 13 Oct 2011 18:27:08 +0200 In-Reply-To: (Adrian Chadd's message of "Thu, 13 Oct 2011 22:15:54 +0800") Message-ID: <86d3e0amcj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , Alexander Motin , current@freebsd.org Subject: Re: 9 hangs with idletick = 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 16:27:10 -0000 Adrian Chadd writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Could you check if network activity (e.g. downloading an ISO) triggers > > it, and if so, if it goes away when you set the kern.eventtimer.idletick > > sysctl to 0? > Don't you mean 'set it to 1' ? Uh, yes :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 18:00:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35AA8106564A for ; Thu, 13 Oct 2011 18:00:25 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED7448FC19 for ; Thu, 13 Oct 2011 18:00:24 +0000 (UTC) Received: by qadz30 with SMTP id z30so364090qad.13 for ; Thu, 13 Oct 2011 11:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer; bh=t+ErHWB7XGNLMf0W9Ut4QjAGqbZ2CkWV55YlthfZQpc=; b=Ao1EadPV19X0TDBguEcJc4T1dZ3UoNfsKAxHVz++9JQZMqUWBpEcnkdYq6f4cvRVtW 1MzI+X7R8/3VxYAiq8d9hOt4WdYjR10gI+qr8mfeRoDAvIpWQtSvxbLe46Uf3e5bmrWO jbxVXs3MO3pOhRczGstTYE9SjdVJ7XdRN1iKs= Received: by 10.224.196.201 with SMTP id eh9mr4184679qab.39.1318528821698; Thu, 13 Oct 2011 11:00:21 -0700 (PDT) Received: from localhost.localdomain ([184.175.13.173]) by mx.google.com with ESMTPS id bh18sm8359757qab.8.2011.10.13.11.00.20 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 11:00:20 -0700 (PDT) From: lacombar@gmail.com To: FreeBSD Current Date: Thu, 13 Oct 2011 14:00:05 -0400 Message-Id: <4e972734.52b1e00a.15ed.ffffd873@mx.google.com> X-Mailer: git-send-email 1.7.6.153.g78432 Cc: Arnaud Lacombe Subject: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 18:00:25 -0000 From: Arnaud Lacombe Hi folks, There is many case recently when I really wished timestamp were present in the post-mortem msgbuf. Such situation could be when userland application segfault potentially triggering a panic/crash, or have information about the time-wise location of a given message (kernel or userland). Attached patch is available in the git repository at: git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp Arnaud Lacombe (3): msgbuf(4): convert `msg_needsnl' to a bit flag msgbuf(4): add logic to prepend timestamp on new line msgbuf(4): add a sysctl to toggle timestamp prepend sys/kern/subr_msgbuf.c | 53 ++++++++++++++++++++++++++++++++++++++++------- sys/sys/msgbuf.h | 4 ++- 2 files changed, 48 insertions(+), 9 deletions(-) diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c index cd9c551..b2f0e1a 100644 --- a/sys/kern/subr_msgbuf.c +++ b/sys/kern/subr_msgbuf.c @@ -34,6 +34,7 @@ #include #include #include +#include /* * Maximum number conversion buffer length: uintmax_t in base 2, plus <> @@ -47,6 +48,13 @@ static u_int msgbuf_cksum(struct msgbuf *mbp); /* + * + */ +static int msgbuf_show_timestamp = 1; +SYSCTL_INT(_kern, OID_AUTO, msgbuf_show_timestamp, CTLFLAG_RW, + &msgbuf_show_timestamp, 0, "Show timestamp in msgbuf"); + +/* * Initialize a message buffer of the specified size at the specified * location. This also zeros the buffer area. */ @@ -60,7 +68,7 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) msgbuf_clear(mbp); mbp->msg_magic = MSG_MAGIC; mbp->msg_lastpri = -1; - mbp->msg_needsnl = 0; + mbp->msg_flags = 0; bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); } @@ -95,7 +103,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) mbp->msg_lastpri = -1; /* Assume that the old message buffer didn't end in a newline. */ - mbp->msg_needsnl = 1; + mbp->msg_flags |= MSGBUF_NEEDNL; bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); } @@ -134,7 +142,7 @@ msgbuf_getcount(struct msgbuf *mbp) * The caller should hold the message buffer spinlock. */ static inline void -msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) +__msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) { u_int pos; @@ -149,6 +157,34 @@ msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) *seq = MSGBUF_SEQNORM(mbp, *seq + 1); } +static inline void +msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) +{ + + if (msgbuf_show_timestamp && mbp->msg_flags & MSGBUF_NEXT_NEW_LINE) { + char buf[32], *bufp; + struct timespec ts; + int err; + + buf[0] = '\0'; + getnanouptime(&ts); + err = snprintf(buf, sizeof buf, "[%d.%ld] ", ts.tv_sec, ts.tv_nsec / 1000); + + bufp = buf; + while (*bufp != '\0') { + __msgbuf_do_addchar(mbp, seq, *bufp); + bufp++; + } + + mbp->msg_flags &= ~MSGBUF_NEXT_NEW_LINE; + } + + __msgbuf_do_addchar(mbp, seq, c); + + if (c == '\n') + mbp->msg_flags |= MSGBUF_NEXT_NEW_LINE; +} + /* * Append a character to a message buffer. */ @@ -207,10 +243,10 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int filter_cr) * did not end with a newline. If that is the case, we need to * insert a newline before this string. */ - if (mbp->msg_lastpri != pri && mbp->msg_needsnl != 0) { + if (mbp->msg_lastpri != pri && (mbp->msg_flags & MSGBUF_NEEDNL) != 0) { msgbuf_do_addchar(mbp, &seq, '\n'); - mbp->msg_needsnl = 0; + mbp->msg_flags &= ~MSGBUF_NEEDNL; } for (i = 0; i < len; i++) { @@ -219,7 +255,7 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int filter_cr) * (and therefore prefix_len != 0), then we need a priority * prefix for this line. */ - if (mbp->msg_needsnl == 0 && prefix_len != 0) { + if ((mbp->msg_flags & MSGBUF_NEEDNL) == 0 && prefix_len != 0) { int j; for (j = 0; j < prefix_len; j++) @@ -242,9 +278,9 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str, int filter_cr) * we need to insert a new prefix or insert a newline later. */ if (str[i] == '\n') - mbp->msg_needsnl = 0; + mbp->msg_flags &= ~MSGBUF_NEEDNL; else - mbp->msg_needsnl = 1; + mbp->msg_flags |= MSGBUF_NEEDNL; msgbuf_do_addchar(mbp, &seq, str[i]); } @@ -395,3 +431,4 @@ msgbuf_copy(struct msgbuf *src, struct msgbuf *dst) while ((c = msgbuf_getchar(src)) >= 0) msgbuf_addchar(dst, c); } + diff --git a/sys/sys/msgbuf.h b/sys/sys/msgbuf.h index 67f80a5..639ed72 100644 --- a/sys/sys/msgbuf.h +++ b/sys/sys/msgbuf.h @@ -46,7 +46,9 @@ struct msgbuf { u_int msg_cksum; /* checksum of contents */ u_int msg_seqmod; /* range for sequence numbers */ int msg_lastpri; /* saved priority value */ - int msg_needsnl; /* set when newline needed */ + uint32_t msg_flags; +#define MSGBUF_NEEDNL 0x01 /* set when newline needed */ +#define MSGBUF_NEXT_NEW_LINE 0x02 struct mtx msg_lock; /* mutex to protect the buffer */ }; From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 18:40:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFA88106567C for ; Thu, 13 Oct 2011 18:40:54 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 495AD8FC13 for ; Thu, 13 Oct 2011 18:40:53 +0000 (UTC) Received: by wwe3 with SMTP id 3so2157288wwe.31 for ; Thu, 13 Oct 2011 11:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KAtCp5u4ekM7xc/cbECeS2qkhbNFthv74BRXyz5T7PM=; b=TXyMUVC997K777oKuX5Df6E8Y4YhNWhFT06ALreyixzF5GVZP0dKEsXBzp/v6qSe// ZlOBAtRiAhnsZBBM32bAnxKq5Rv0dat6M9Ufh5jGtRya+lkXOaMFa7XlRu1zn/1S34z9 ohAKr1uTyW34VKr5ThJcFYb14mIylwAJg4DMs= MIME-Version: 1.0 Received: by 10.216.210.216 with SMTP id u66mr313322weo.49.1318531253062; Thu, 13 Oct 2011 11:40:53 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Thu, 13 Oct 2011 11:40:53 -0700 (PDT) In-Reply-To: <4e972734.52b1e00a.15ed.ffffd873@mx.google.com> References: <4e972734.52b1e00a.15ed.ffffd873@mx.google.com> Date: Thu, 13 Oct 2011 14:40:53 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 18:40:54 -0000 Hi, On Thu, Oct 13, 2011 at 2:00 PM, wrote: > From: Arnaud Lacombe > > Hi folks, > > There is many case recently when I really wished timestamp were present i= n the > post-mortem msgbuf. Such situation could be when userland application seg= fault > potentially triggering a panic/crash, or have information about the time-= wise > location of a given message (kernel or userland). > > Attached patch is available in the git repository at: > =A0git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp > > Arnaud Lacombe (3): > =A0 =A0 =A0msgbuf(4): convert `msg_needsnl' to a bit flag > =A0 =A0 =A0msgbuf(4): add logic to prepend timestamp on new line > =A0 =A0 =A0msgbuf(4): add a sysctl to toggle timestamp prepend > > =A0sys/kern/subr_msgbuf.c | =A0 53 ++++++++++++++++++++++++++++++++++++++= ++------- > =A0sys/sys/msgbuf.h =A0 =A0 =A0 | =A0 =A04 ++- > =A02 files changed, 48 insertions(+), 9 deletions(-) > also tracked as: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161553 - Arnaud > diff --git a/sys/kern/subr_msgbuf.c b/sys/kern/subr_msgbuf.c > index cd9c551..b2f0e1a 100644 > --- a/sys/kern/subr_msgbuf.c > +++ b/sys/kern/subr_msgbuf.c > @@ -34,6 +34,7 @@ > =A0#include > =A0#include > =A0#include > +#include > > =A0/* > =A0* Maximum number conversion buffer length: uintmax_t in base 2, plus <= > > @@ -47,6 +48,13 @@ > =A0static u_int msgbuf_cksum(struct msgbuf *mbp); > > =A0/* > + * > + */ > +static int msgbuf_show_timestamp =3D 1; > +SYSCTL_INT(_kern, OID_AUTO, msgbuf_show_timestamp, CTLFLAG_RW, > + =A0 =A0&msgbuf_show_timestamp, 0, "Show timestamp in msgbuf"); > + > +/* > =A0* Initialize a message buffer of the specified size at the specified > =A0* location. This also zeros the buffer area. > =A0*/ > @@ -60,7 +68,7 @@ msgbuf_init(struct msgbuf *mbp, void *ptr, int size) > =A0 =A0 =A0 =A0msgbuf_clear(mbp); > =A0 =A0 =A0 =A0mbp->msg_magic =3D MSG_MAGIC; > =A0 =A0 =A0 =A0mbp->msg_lastpri =3D -1; > - =A0 =A0 =A0 mbp->msg_needsnl =3D 0; > + =A0 =A0 =A0 mbp->msg_flags =3D 0; > =A0 =A0 =A0 =A0bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); > =A0 =A0 =A0 =A0mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); > =A0} > @@ -95,7 +103,7 @@ msgbuf_reinit(struct msgbuf *mbp, void *ptr, int size) > > =A0 =A0 =A0 =A0mbp->msg_lastpri =3D -1; > =A0 =A0 =A0 =A0/* Assume that the old message buffer didn't end in a newl= ine. */ > - =A0 =A0 =A0 mbp->msg_needsnl =3D 1; > + =A0 =A0 =A0 mbp->msg_flags |=3D MSGBUF_NEEDNL; > =A0 =A0 =A0 =A0bzero(&mbp->msg_lock, sizeof(mbp->msg_lock)); > =A0 =A0 =A0 =A0mtx_init(&mbp->msg_lock, "msgbuf", NULL, MTX_SPIN); > =A0} > @@ -134,7 +142,7 @@ msgbuf_getcount(struct msgbuf *mbp) > =A0* The caller should hold the message buffer spinlock. > =A0*/ > =A0static inline void > -msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) > +__msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) > =A0{ > =A0 =A0 =A0 =A0u_int pos; > > @@ -149,6 +157,34 @@ msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, in= t c) > =A0 =A0 =A0 =A0*seq =3D MSGBUF_SEQNORM(mbp, *seq + 1); > =A0} > > +static inline void > +msgbuf_do_addchar(struct msgbuf *mbp, u_int *seq, int c) > +{ > + > + =A0 =A0 =A0 if (msgbuf_show_timestamp && mbp->msg_flags & MSGBUF_NEXT_N= EW_LINE) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 char buf[32], *bufp; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct timespec ts; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 int err; > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 buf[0] =3D '\0'; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 getnanouptime(&ts); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D snprintf(buf, sizeof buf, "[%d.%ld]= ", ts.tv_sec, ts.tv_nsec / 1000); > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufp =3D buf; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 while (*bufp !=3D '\0') { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __msgbuf_do_addchar(mbp, se= q, *bufp); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bufp++; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_flags &=3D ~MSGBUF_NEXT_NEW_LINE; > + =A0 =A0 =A0 } > + > + =A0 =A0 =A0 __msgbuf_do_addchar(mbp, seq, c); > + > + =A0 =A0 =A0 if (c =3D=3D '\n') > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_flags |=3D MSGBUF_NEXT_NEW_LINE; > +} > + > =A0/* > =A0* Append a character to a message buffer. > =A0*/ > @@ -207,10 +243,10 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *st= r, int filter_cr) > =A0 =A0 =A0 =A0 * did not end with a newline. =A0If that is the case, we = need to > =A0 =A0 =A0 =A0 * insert a newline before this string. > =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 if (mbp->msg_lastpri !=3D pri && mbp->msg_needsnl !=3D 0) { > + =A0 =A0 =A0 if (mbp->msg_lastpri !=3D pri && (mbp->msg_flags & MSGBUF_N= EEDNL) !=3D 0) { > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msgbuf_do_addchar(mbp, &seq, '\n'); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_needsnl =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_flags &=3D ~MSGBUF_NEEDNL; > =A0 =A0 =A0 =A0} > > =A0 =A0 =A0 =A0for (i =3D 0; i < len; i++) { > @@ -219,7 +255,7 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str,= int filter_cr) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * (and therefore prefix_len !=3D 0), then= we need a priority > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * prefix for this line. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (mbp->msg_needsnl =3D=3D 0 && prefix_len= !=3D 0) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((mbp->msg_flags & MSGBUF_NEEDNL) =3D=3D= 0 && prefix_len !=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int j; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (j =3D 0; j < prefix_l= en; j++) > @@ -242,9 +278,9 @@ msgbuf_addstr(struct msgbuf *mbp, int pri, char *str,= int filter_cr) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * we need to insert a new prefix or inser= t a newline later. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (str[i] =3D=3D '\n') > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_needsnl =3D 0; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_flags &=3D ~MSGBUF= _NEEDNL; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_needsnl =3D 1; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mbp->msg_flags |=3D MSGBUF_= NEEDNL; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msgbuf_do_addchar(mbp, &seq, str[i]); > =A0 =A0 =A0 =A0} > @@ -395,3 +431,4 @@ msgbuf_copy(struct msgbuf *src, struct msgbuf *dst) > =A0 =A0 =A0 =A0while ((c =3D msgbuf_getchar(src)) >=3D 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0msgbuf_addchar(dst, c); > =A0} > + > diff --git a/sys/sys/msgbuf.h b/sys/sys/msgbuf.h > index 67f80a5..639ed72 100644 > --- a/sys/sys/msgbuf.h > +++ b/sys/sys/msgbuf.h > @@ -46,7 +46,9 @@ struct msgbuf { > =A0 =A0 =A0 =A0u_int =A0 =A0 =A0msg_cksum; =A0 =A0 =A0 =A0 =A0 /* checksu= m of contents */ > =A0 =A0 =A0 =A0u_int =A0 =A0 =A0msg_seqmod; =A0 =A0 =A0 =A0 =A0/* range f= or sequence numbers */ > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0msg_lastpri; =A0 =A0 =A0 =A0 /* saved p= riority value */ > - =A0 =A0 =A0 int =A0 =A0 =A0 =A0msg_needsnl; =A0 =A0 =A0 =A0 /* set when= newline needed */ > + =A0 =A0 =A0 uint32_t =A0 msg_flags; > +#define MSGBUF_NEEDNL =A0 =A0 =A0 =A0 =A00x01 =A0 =A0/* set when newline= needed */ > +#define MSGBUF_NEXT_NEW_LINE =A0 0x02 > =A0 =A0 =A0 =A0struct mtx msg_lock; =A0 =A0 =A0 =A0 =A0 =A0/* mutex to pr= otect the buffer */ > =A0}; > > From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:12:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168461065676 for ; Thu, 13 Oct 2011 21:12:37 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (unknown [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBF5A8FC16 for ; Thu, 13 Oct 2011 21:12:36 +0000 (UTC) Received: from PortaPegIII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.5/8.14.3) with ESMTP id p9DLCV5a026145 for ; Thu, 13 Oct 2011 21:12:33 GMT (envelope-from ken@mthelicon.com) From: "Pegasus Mc Cleaft" To: Date: Thu, 13 Oct 2011 22:12:31 +0100 Message-ID: <001f01cc89ec$d44a5470$7cdefd50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyJ7NIRS8cX7WGZRiiutjvar5M/cA== Content-Language: en-gb X-Spam-Status: No, score=2.8 required=15.0 tests=BAYES_20,DOS_OUTLOOK_TO_MX, FSL_HELO_NON_FQDN_1 autolearn=no version=3.3.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hercules.mthelicon.com Subject: Compatibility with 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:12:37 -0000 Hi Current, Should the new Beta 3 have "options COMPAT_FREEBSD8" in the GENERIC kernel config file? Or, does this happen when it goes RC? Ta Peg From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 21:28:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC174106566C for ; Thu, 13 Oct 2011 21:28:56 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 76A288FC1C for ; Thu, 13 Oct 2011 21:28:56 +0000 (UTC) Received: by wwe3 with SMTP id 3so2380994wwe.31 for ; Thu, 13 Oct 2011 14:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IPkt6mbq7bBUGunTL9m7WHisv25emD5DI52o0Fx1NT8=; b=GuXxWDOIZhdyBzN8T8fu8OxJB6zq3sxPMDCkCMdGIT7ywFyUTgwBJ2YCegq7LlBPZY y1ZaPOvxHZvY2Rv5nk5W0S3DPDdM7IYgy/EZjyPjTmpALOUjM3glZHOHtFZ4DNbuwtQT evUL6iJ1PLhDucWo3pbWAppgjRvSV3c2nOwpw= MIME-Version: 1.0 Received: by 10.227.32.73 with SMTP id b9mr748018wbd.49.1318541335254; Thu, 13 Oct 2011 14:28:55 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Thu, 13 Oct 2011 14:28:55 -0700 (PDT) In-Reply-To: <001f01cc89ec$d44a5470$7cdefd50$@com> References: <001f01cc89ec$d44a5470$7cdefd50$@com> Date: Thu, 13 Oct 2011 17:28:55 -0400 Message-ID: From: Arnaud Lacombe To: Pegasus Mc Cleaft Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Compatibility with 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:28:56 -0000 Hi, On Thu, Oct 13, 2011 at 5:12 PM, Pegasus Mc Cleaft wrot= e: > Hi Current, > > =A0 =A0 =A0 =A0Should the new Beta 3 have "options COMPAT_FREEBSD8" in th= e GENERIC > kernel config file? Or, does this happen when it goes RC? > What would you expect this option to cover ? I'd assume that no ABI[0] have been broken between FreeBSD 8 and FreeBSD 9. If ABI had been broken, the developer should have been responsible enough to create the proper compatibility shim and would already have introduced COMPAT_FREEBSD9. Of course, this leaves options for ABI being broken, compatibility shim introduced, but COMPAT_FREEBSD9 not introduced :) - Arnaud [0]: all the mentions of "ABI" exclude KVM. > Ta > Peg > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:23:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 25013106564A; Thu, 13 Oct 2011 22:23:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B5C31152568; Thu, 13 Oct 2011 22:23:46 +0000 (UTC) Message-ID: <4E9764F2.3010802@FreeBSD.org> Date: Thu, 13 Oct 2011 15:23:46 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ken Smith References: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> <4E95987D.5090907@cran.org.uk> <1318427260.35743.7.camel@bauer.cse.buffalo.edu> In-Reply-To: <1318427260.35743.7.camel@bauer.cse.buffalo.edu> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bruce Cran , freebsd-current , freebsd-stable Subject: Re: FreeBSD 9.0-BETA3 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 22:23:47 -0000 On 10/12/2011 06:47, Ken Smith wrote: > On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: >> On 29/09/2011 02:42, Ken Smith wrote: >>> MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc >>> MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 >>> MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c >> >> The -dvd1.iso files seem to be less than a CD, at 610MB. Are they >> expected to contain more data over time, or could 'dvd' be removed? >> > > I was planning on them having package sets. The new installer doesn't > support installing packages like sysinstall had but if I provide Gnome, > KDE, and perhaps a small set of other stuff it would be useful to people > with crummy network connectivity. They could install the packages from > the DVD instead of needing to have everything downloaded. Is there still going to be a CD-sized installer? I find this really useful both at home, and also for virtualized installs. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:25:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1A7A1065670; Thu, 13 Oct 2011 22:25:57 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from core.impulsive.hu (core.impulsive.hu [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id 653E18FC1D; Thu, 13 Oct 2011 22:25:57 +0000 (UTC) Received: by core.impulsive.hu (Postfix, from userid 143) id 158F0DC0E6; Thu, 13 Oct 2011 22:26:44 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by core.impulsive.hu (Postfix) with ESMTP id CC55CDC0B4 for ; Thu, 13 Oct 2011 22:26:42 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3B176157182; Thu, 13 Oct 2011 22:23:56 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3B14B10656B6; Thu, 13 Oct 2011 22:23:55 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 25013106564A; Thu, 13 Oct 2011 22:23:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B5C31152568; Thu, 13 Oct 2011 22:23:46 +0000 (UTC) Message-ID: <4E9764F2.3010802@FreeBSD.org> Date: Thu, 13 Oct 2011 15:23:46 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ken Smith References: <1317260554.93406.33.camel@bauer.cse.buffalo.edu> <4E95987D.5090907@cran.org.uk> <1318427260.35743.7.camel@bauer.cse.buffalo.edu> In-Reply-To: <1318427260.35743.7.camel@bauer.cse.buffalo.edu> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Bruce Cran , freebsd-current , freebsd-stable Subject: Re: FreeBSD 9.0-BETA3 Available... X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 22:25:57 -0000 On 10/12/2011 06:47, Ken Smith wrote: > On Wed, 2011-10-12 at 14:39 +0100, Bruce Cran wrote: >> On 29/09/2011 02:42, Ken Smith wrote: >>> MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc >>> MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 >>> MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c >> >> The -dvd1.iso files seem to be less than a CD, at 610MB. Are they >> expected to contain more data over time, or could 'dvd' be removed? >> > > I was planning on them having package sets. The new installer doesn't > support installing packages like sysinstall had but if I provide Gnome, > KDE, and perhaps a small set of other stuff it would be useful to people > with crummy network connectivity. They could install the packages from > the DVD instead of needing to have everything downloaded. Is there still going to be a CD-sized installer? I find this really useful both at home, and also for virtualized installs. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:27:29 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 683F21065678; Thu, 13 Oct 2011 22:27:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 952A6160444; Thu, 13 Oct 2011 22:26:26 +0000 (UTC) Message-ID: <4E976592.2060804@FreeBSD.org> Date: Thu, 13 Oct 2011 15:26:26 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Michael Butler References: <4E95B028.6090307@protected-networks.net> In-Reply-To: <4E95B028.6090307@protected-networks.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 22:27:29 -0000 On 10/12/2011 08:20, Michael Butler wrote: > SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 r226340, smp, amd64 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 22:31:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C01E106566B for ; Thu, 13 Oct 2011 22:31:30 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 323508FC17 for ; Thu, 13 Oct 2011 22:31:30 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [IPv6:2002:d947:452:1:224:8cff:fe02:de01]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 264382BE2A for ; Fri, 14 Oct 2011 00:31:28 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.4.1 mail.tyknet.dk 264382BE2A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1318545089; bh=0uSLQSoZgsSUmCrcOpEt8H2KRKe2YEDngMUok/qTpKw=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=nA1av2Ce1KxMJLTht24BD/2rjAbqfL4uM4d3qQkOq4YJAhXjxQi1ZsHz6L7DX4CN2 dwKRsqj0Ho7WyfS4yE0CctlPgq9EteHjtUyqRyZjhopgNnJhM5SW+qBupVNLFFqQOG B2xdl8lPoSdcBKRDi9lO5pFGU3cFvOZ+QFRQBbVQ= Message-ID: <4E9766C0.1020409@gibfest.dk> Date: Fri, 14 Oct 2011 00:31:28 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 22:31:30 -0000 Hello list, I just upgraded my home workstation to 9.0-beta3 amd64. It seems like my web browsers are preferring ipv4 over ipv6 after the upgrade, I tested Firefox and Opera. After digging into rc.conf(5) I found this bit: If ``AUTO'' is specified, it attempts to read a file /etc/ip6addrctl.conf first. If this file is found, ip6addrctl(8) reads and installs it. If not found, a policy is automatically set according to ipv6_activate_all_interfaces variable; if the variable is set to ``YES'' the IPv6-preferred one is used. Otherwise IPv4-preferred. The default value of ip6addrctl_enable and ip6addrctl_policy are ``YES'' and ``AUTO'', respectively. I already have ipv6_activate_all_interfaces="YES" in /etc/rc.conf so ip6addrctl_policy _should_ be "ip6addrctl_policy" if I am reading this correctly. But my browsers still prefer ipv4. Is this a bug, or do the manpage need updating ? Before the upgrade to 9 I was running 8-stable which preferred ipv6 like I would expect. Thank you in advance, Thomas Steen Rasmussen From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 23:04:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E91106566C; Thu, 13 Oct 2011 23:04:17 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id B82EA8FC08; Thu, 13 Oct 2011 23:04:16 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [IPv6:2002:d947:452:1:224:8cff:fe02:de01]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id E88322BE5B; Fri, 14 Oct 2011 01:04:15 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.4.1 mail.tyknet.dk E88322BE5B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1318547056; bh=D7nPn0SY1D9wd04kXq7nb5MOHPlhoJbhPp92v/M43L8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ePB2+8vGlTmbf/nnHtsdUKPi1q4f3w77MILCodhHeU8dc+mj/MFjkbJgD+SoDthIM rLEJ/UFZGEyFJWsKcXNeyCjy399gdmg9xG9/UWrssPvRxNmCf3m42V9gG2ejK+Nr5z quXVURCEaosoISFHRdifJPQ8SYdWYQV6tytUGrkI= Message-ID: <4E976E6F.9060709@gibfest.dk> Date: Fri, 14 Oct 2011 01:04:15 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4E9766C0.1020409@gibfest.dk> In-Reply-To: <4E9766C0.1020409@gibfest.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Oct 2011 23:04:17 -0000 On 14.10.2011 00:31, Thomas Steen Rasmussen wrote: > Hello list, > > I just upgraded my home workstation to 9.0-beta3 amd64. It seems > like my web browsers are preferring ipv4 over ipv6 after the upgrade, My laptop is also running 9.0-beta3 amd64 and I observe the same behaviour there, so this doesn't seem like an issue with a specific machine. On IRC I was advised to include hrs@freebsd.org as cc in this thread. Best regards Thomas Steen Rasmussen From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 00:53:08 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 717B9106564A for ; Fri, 14 Oct 2011 00:53:08 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id C84A68FC16 for ; Fri, 14 Oct 2011 00:53:07 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p9E0qsB7011540; Fri, 14 Oct 2011 09:53:05 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p9E0qrWh018382; Fri, 14 Oct 2011 09:52:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 14 Oct 2011 09:52:18 +0900 (JST) Message-Id: <20111014.095218.1603335403119728346.hrs@allbsd.org> To: thomas@gibfest.dk From: Hiroki Sato In-Reply-To: <4E9766C0.1020409@gibfest.dk> References: <4E9766C0.1020409@gibfest.dk> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct_14_09_52_18_2011_331)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 14 Oct 2011 09:53:05 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 00:53:08 -0000 ----Security_Multipart(Fri_Oct_14_09_52_18_2011_331)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Steen Rasmussen wrote in <4E9766C0.1020409@gibfest.dk>: th> Hello list, th> th> I just upgraded my home workstation to 9.0-beta3 amd64. It seems th> like my web browsers are preferring ipv4 over ipv6 after the upgrade, th> I tested Firefox and Opera. After digging into rc.conf(5) I found this bit: th> th> If ``AUTO'' is specified, it attempts to read a file th> /etc/ip6addrctl.conf first. If this file is found, th> ip6addrctl(8) reads and installs it. If not found, a policy th> is automatically set according to th> ipv6_activate_all_interfaces variable; if the variable is set th> to ``YES'' the IPv6-preferred one is used. Otherwise th> IPv4-preferred. th> th> The default value of ip6addrctl_enable and ip6addrctl_policy th> are ``YES'' and ``AUTO'', respectively. th> th> I already have ipv6_activate_all_interfaces="YES" in /etc/rc.conf th> so ip6addrctl_policy _should_ be "ip6addrctl_policy" if I am reading th> this correctly. But my browsers still prefer ipv4. Is this a bug, or th> do the manpage need updating ? Can you please send me the results of the following commands: % ifconfig % grep ^ipv6 /etc/rc.conf % grep ipv6= /etc/rc.conf % ip6addrctl show # /bin/sh -x /etc/rc.d/ip6addrctl start -- Hiroki ----Security_Multipart(Fri_Oct_14_09_52_18_2011_331)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6Xh8IACgkQTyzT2CeTzy3aBwCgh164LhJSaqPhNt82JIieqxnB ikwAnjAwGE/ge554O4hM1sNZGcv0F4Tk =OVI2 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct_14_09_52_18_2011_331)---- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 01:30:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98D051065676 for ; Fri, 14 Oct 2011 01:30:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 57AF78FC12 for ; Fri, 14 Oct 2011 01:30:24 +0000 (UTC) Received: by gyd8 with SMTP id 8so811697gyd.13 for ; Thu, 13 Oct 2011 18:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PpUfS9Wx1iSaMYmsSiFizS9BJouBah3d2WVEO35fHiI=; b=Xpgg+UgO7M1SRPzoaiwDrEp8JOPKIr0VAcqPLr95OW/9SzytHFsT+Sza+UR2IIvMQm OSyB9Xc0p3e1cS9eJ7Ad/xFkpOgIOeqW0jA1QO674OiMa4lkFLZ7pcY5ziYYePYDsReS uuzjn1T3lY1SQY4RIv/PysNHtmmhO5Dblyrsw= MIME-Version: 1.0 Received: by 10.236.187.70 with SMTP id x46mr8609694yhm.71.1318555823560; Thu, 13 Oct 2011 18:30:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.109.167 with HTTP; Thu, 13 Oct 2011 18:30:23 -0700 (PDT) In-Reply-To: References: <4e972734.52b1e00a.15ed.ffffd873@mx.google.com> Date: Fri, 14 Oct 2011 09:30:23 +0800 X-Google-Sender-Auth: JXMoJZ939npJOE5S1A0AikxhSvQ Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 01:30:24 -0000 On 14 October 2011 02:40, Arnaud Lacombe wrote: > Hi, > > On Thu, Oct 13, 2011 at 2:00 PM, =A0 wrote: >> From: Arnaud Lacombe >> >> Hi folks, >> >> There is many case recently when I really wished timestamp were present = in the >> post-mortem msgbuf. Such situation could be when userland application se= gfault >> potentially triggering a panic/crash, or have information about the time= -wise >> location of a given message (kernel or userland). >> Nice! Once the -head dust settles and 9.0-rel makes it out the door, I'd like to see this make an appearance. Adrian From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 02:43:22 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57670106566B for ; Fri, 14 Oct 2011 02:43:22 +0000 (UTC) (envelope-from jos@catnook.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F8118FC0A for ; Fri, 14 Oct 2011 02:43:21 +0000 (UTC) Received: by vws11 with SMTP id 11so735310vws.13 for ; Thu, 13 Oct 2011 19:43:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.113.67 with SMTP id iw3mr6411206vdb.121.1318558561473; Thu, 13 Oct 2011 19:16:01 -0700 (PDT) Received: by 10.52.188.35 with HTTP; Thu, 13 Oct 2011 19:16:01 -0700 (PDT) Received: by 10.52.188.35 with HTTP; Thu, 13 Oct 2011 19:16:01 -0700 (PDT) In-Reply-To: <86mxd59e1v.fsf@ds4.des.no> References: <86pqi1b1qp.fsf@ds4.des.no> <864nzdaw7b.fsf@ds4.des.no> <20111013134841.GF1667@garage.freebsd.pl> <86mxd59e1v.fsf@ds4.des.no> Date: Thu, 13 Oct 2011 19:16:01 -0700 Message-ID: From: Jos Backus To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 02:43:22 -0000 Why not import daemontools? It's public domain these days. Pidfiles are a hacky mess. UNIX already has a way to track processes which avoids all these issues, with very little overhead. Jos From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 06:00:31 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2B11065672; Fri, 14 Oct 2011 06:00:31 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id A89068FC17; Fri, 14 Oct 2011 06:00:30 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [IPv6:2002:d947:452:1:224:8cff:fe02:de01]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 36EE665006; Fri, 14 Oct 2011 08:00:28 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.4.1 mail.tyknet.dk 36EE665006 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1318572029; bh=AdvhCHiyHjVIEuAKsTazbywtuFcAbXHLtrmkqSj8ibQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=uecy4yBMawMLIzyGIiltY9Wh1BWZT0A1UbY0yyxlLw4Aj+mFIHahgUorCQe/CEClT cmB96MsygaaWMCXslapFo0Fls4yHmW1GdmRw1GLBKjUzedxp/GjMh6fxcRQKLwZyS9 s3pawLdsMo5LJxqSG9u5SgV9RFvjsZhXAFZfscg0= Message-ID: <4E97CFFC.5020900@gibfest.dk> Date: Fri, 14 Oct 2011 08:00:28 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hiroki Sato References: <4E9766C0.1020409@gibfest.dk> <20111014.095218.1603335403119728346.hrs@allbsd.org> In-Reply-To: <20111014.095218.1603335403119728346.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 06:00:31 -0000 On 14.10.2011 02:52, Hiroki Sato wrote: > Can you please send me the results of the following commands: Please see the output below each command. I forgot to mention that the ipv6 uplink is a 6to4 tunnel, as you can see below from the 2002: prefix. > > % ifconfig [tykling@tykburk ~]$ ifconfig re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:24:8c:02:de:01 inet6 fe80::224:8cff:fe02:de01%re0 prefixlen 64 scopeid 0x5 inet6 2002:d947:452:1:224:8cff:fe02:de01 prefixlen 64 autoconf inet 10.10.1.115 netmask 0xffffff00 broadcast 10.10.1.255 nd6 options=23 media: Ethernet autoselect (100baseTX ) status: active fwe0: flags=8943 metric 0 mtu 1500 options=8 ether 02:1e:8c:b6:37:7b inet6 fe80::1e:8cff:feb6:377b%fwe0 prefixlen 64 scopeid 0x6 nd6 options=21 ch 1 dma 0 fwip0: flags=8843 metric 0 mtu 1500 lladdr 0.1e.8c.0.1.b6.37.7b.a.2.ff.fe.0.0.0.0 inet6 fe80::21e:8c00:1b6:377b%fwip0 prefixlen 64 scopeid 0x7 nd6 options=21 em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:1b:21:32:fe:80 inet6 fe80::21b:21ff:fe32:fe80%em0 prefixlen 64 scopeid 0xc nd6 options=21 media: Ethernet autoselect status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd inet 127.0.0.1 netmask 0xff000000 nd6 options=21 > % grep ^ipv6 /etc/rc.conf [tykling@tykburk ~]$ grep ^ipv6 /etc/rc.conf ipv6_activate_all_interfaces="YES" > % grep ipv6= /etc/rc.conf [tykling@tykburk ~]$ grep ipv6= /etc/rc.conf ifconfig_re0_ipv6="accept_rtadv" > % ip6addrctl show [tykling@tykburk ~]$ ip6addrctl show Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 2266 2002::/16 30 2 1164 ::/96 20 3 0 ::ffff:0.0.0.0/96 10 4 0 > # /bin/sh -x /etc/rc.d/ip6addrctl start [tykling@tykburk ~]$ sudo /bin/sh -x /etc/rc.d/ip6addrctl start + . /etc/rc.subr + : 'rc.conf(5)' + : 47981 + export RC_PID + [ -z '' ] + _rc_subr_loaded=YES + SYSCTL=/sbin/sysctl + SYSCTL_N='/sbin/sysctl -n' + SYSCTL_W=/sbin/sysctl + ID=/usr/bin/id + IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi' + PS='/bin/ps -ww' + /bin/ps -ww -p 47981 -o jid= + JID=' 0' + _rc_subr_loaded=: + . /etc/network.subr + name=ip6addrctl + set_rcvar + echo ip6addrctl_enable + rcvar=ip6addrctl_enable + start_cmd=ip6addrctl_start + stop_cmd=ip6addrctl_stop + extra_commands='status prefer_ipv6 prefer_ipv4' + status_cmd=ip6addrctl + prefer_ipv6_cmd=ip6addrctl_prefer_ipv6 + prefer_ipv4_cmd=ip6addrctl_prefer_ipv4 + config_file=/etc/ip6addrctl.conf + set_rcvar_obsolete ipv6_enable ipv6_activate_all_interfaces + local _var + _var=ipv6_enable + debug 'rcvar_obsolete: $ipv6_enable(old) -> $ipv6_activate_all_interfaces(new) is defined' + rcvars_obsolete=' ipv6_enable' + eval 'ipv6_enable_newvar="ipv6_activate_all_interfaces"' + ipv6_enable_newvar=ipv6_activate_all_interfaces + shift 2 + eval 'ipv6_enable_obsolete_msg=""' + ipv6_enable_obsolete_msg='' + set_rcvar_obsolete ipv6_prefer ip6addrctl_policy + local _var + _var=ipv6_prefer + debug 'rcvar_obsolete: $ipv6_prefer(old) -> $ip6addrctl_policy(new) is defined' + rcvars_obsolete='ipv6_enable ipv6_prefer' + eval 'ipv6_prefer_newvar="ip6addrctl_policy"' + ipv6_prefer_newvar=ip6addrctl_policy + shift 2 + eval 'ipv6_prefer_obsolete_msg=""' + ipv6_prefer_obsolete_msg='' + load_rc_config ip6addrctl + local _name _var _defval _v _msg _new + _name=ip6addrctl + [ -z ip6addrctl ] + false + [ -r /etc/defaults/rc.conf ] + debug 'Sourcing /etc/defaults/rc.conf' + . /etc/defaults/rc.conf + rc_debug=NO + rc_info=NO + rc_startmsgs=YES + rcshutdown_timeout=30 + early_late_divider=FILESYSTEMS + swapfile=NO + apm_enable=NO + apmd_enable=NO + apmd_flags='' + ddb_enable=NO + ddb_config=/etc/ddb.conf + devd_enable=YES + devd_flags='' + kldxref_enable=NO + kldxref_clobber=NO + kldxref_module_path='' + powerd_enable=NO + powerd_flags='' + tmpmfs=AUTO + tmpsize=20m + tmpmfs_flags=-S + varmfs=AUTO + varsize=32m + varmfs_flags=-S + populate_var=AUTO + cleanvar_enable=YES + local_startup=/usr/local/etc/rc.d + script_name_sep=' ' + rc_conf_files='/etc/rc.conf /etc/rc.conf.local' + zfs_enable=NO + gptboot_enable=YES + gbde_autoattach_all=NO + gbde_devices=NO + gbde_attach_attempts=3 + gbde_lockdir=/etc + geli_devices='' + geli_tries='' + geli_default_flags='' + geli_autodetach=YES + geli_swap_flags='-e aes -l 256 -s 4096 -d' + root_rw_mount=YES + fsck_y_enable=NO + fsck_y_flags='' + background_fsck=YES + background_fsck_delay=60 + netfs_types='nfs:NFS oldnfs:OLDNFS smbfs:SMB portalfs:PORTAL nwfs:NWFS' + extra_netfs_types=NO + hostname='' + hostid_enable=YES + hostid_file=/etc/hostid + nisdomainname=NO + dhclient_program=/sbin/dhclient + dhclient_flags='' + background_dhclient=NO + synchronous_dhclient=NO + defaultroute_delay=30 + defaultroute_carrier_delay=5 + wpa_supplicant_program=/usr/sbin/wpa_supplicant + wpa_supplicant_flags=-s + wpa_supplicant_conf_file=/etc/wpa_supplicant.conf + firewall_enable=NO + firewall_script=/etc/rc.firewall + firewall_type=UNKNOWN + firewall_quiet=NO + firewall_logging=NO + firewall_flags='' + firewall_coscripts='' + firewall_client_net=192.0.2.0/24 + firewall_simple_iif=ed1 + firewall_simple_inet=192.0.2.16/28 + firewall_simple_oif=ed0 + firewall_simple_onet=192.0.2.0/28 + firewall_myservices='' + firewall_allowservices='' + firewall_trusted='' + firewall_logdeny=NO + firewall_nologports='135-139,445 1026,1027 1433,1434' + firewall_nat_enable=NO + firewall_nat_interface='' + firewall_nat_flags='' + dummynet_enable=NO + ip_portrange_first=NO + ip_portrange_last=NO + ike_enable=NO + ike_program=/usr/local/sbin/isakmpd + ike_flags='' + ipsec_enable=NO + ipsec_file=/etc/ipsec.conf + natd_program=/sbin/natd + natd_enable=NO + natd_interface='' + natd_flags='' + ipfilter_enable=NO + ipfilter_program=/sbin/ipf + ipfilter_rules=/etc/ipf.rules + ipfilter_flags='' + ipnat_enable=NO + ipnat_program=/sbin/ipnat + ipnat_rules=/etc/ipnat.rules + ipnat_flags='' + ipmon_enable=NO + ipmon_program=/sbin/ipmon + ipmon_flags=-Ds + ipfs_enable=NO + ipfs_program=/sbin/ipfs + ipfs_flags='' + pf_enable=NO + pf_rules=/etc/pf.conf + pf_program=/sbin/pfctl + pf_flags='' + pflog_enable=NO + pflog_logfile=/var/log/pflog + pflog_program=/sbin/pflogd + pflog_flags='' + ftpproxy_enable=NO + ftpproxy_flags='' + pfsync_enable=NO + pfsync_syncdev='' + pfsync_syncpeer='' + pfsync_ifconfig='' + tcp_extensions=YES + log_in_vain=0 + tcp_keepalive=YES + tcp_drop_synfin=NO + icmp_drop_redirect=NO + icmp_log_redirect=NO + network_interfaces=auto + cloned_interfaces='' + sppp_interfaces='' + gif_interfaces='' + fec_interfaces='' + ppp_enable=NO + ppp_program=/usr/sbin/ppp + ppp_mode=auto + ppp_nat=YES + ppp_profile=papchap + ppp_user=root + hostapd_enable=NO + syslogd_enable=YES + syslogd_program=/usr/sbin/syslogd + syslogd_flags=-s + inetd_enable=NO + inetd_program=/usr/sbin/inetd + inetd_flags='-wW -C 60' + hastd_enable=NO + hastd_program=/sbin/hastd + hastd_flags='' + named_enable=NO + named_program=/usr/sbin/named + named_conf=/etc/namedb/named.conf + named_uid=bind + named_chrootdir=/var/named + named_chroot_autoupdate=YES + named_symlink_enable=YES + named_wait=NO + named_wait_host=localhost + named_auto_forward=NO + named_auto_forward_only=NO + kerberos5_server_enable=NO + kerberos5_server=/usr/libexec/kdc + kerberos5_server_flags=--detach + kadmind5_server_enable=NO + kadmind5_server=/usr/libexec/kadmind + kpasswdd_server_enable=NO + kpasswdd_server=/usr/libexec/kpasswdd + gssd_enable=NO + gssd_flags='' + rwhod_enable=NO + rwhod_flags='' + rarpd_enable=NO + rarpd_flags=-a + bootparamd_enable=NO + bootparamd_flags='' + pppoed_enable=NO + pppoed_provider='*' + pppoed_flags='-P /var/run/pppoed.pid' + pppoed_interface=fxp0 + sshd_enable=NO + sshd_program=/usr/sbin/sshd + sshd_flags='' + ftpd_enable=NO + ftpd_program=/usr/libexec/ftpd + ftpd_flags='' + amd_enable=NO + amd_program=/usr/sbin/amd + amd_flags='-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map' + amd_map_program=NO + nfs_client_enable=NO + nfs_access_cache=60 + nfs_server_enable=NO + oldnfs_server_enable=NO + nfs_server_flags='-u -t -n 4' + mountd_enable=NO + mountd_flags=-r + weak_mountd_authentication=NO + nfs_reserved_port_only=NO + nfs_bufpackets='' + rpc_lockd_enable=NO + rpc_lockd_flags='' + rpc_statd_enable=NO + rpc_statd_flags='' + rpcbind_enable=NO + rpcbind_program=/usr/sbin/rpcbind + rpcbind_flags='' + rpc_ypupdated_enable=NO + keyserv_enable=NO + keyserv_flags='' + nfsv4_server_enable=NO + nfscbd_enable=NO + nfscbd_flags='' + nfsuserd_enable=NO + nfsuserd_flags='' + timed_enable=NO + timed_flags='' + ntpdate_enable=NO + ntpdate_program=/usr/sbin/ntpdate + ntpdate_flags=-b + ntpdate_config=/etc/ntp.conf + ntpdate_hosts='' + ntpd_enable=NO + ntpd_program=/usr/sbin/ntpd + ntpd_config=/etc/ntp.conf + ntpd_sync_on_start=NO + ntpd_flags='-p /var/run/ntpd.pid -f /var/db/ntpd.drift' + nis_client_enable=NO + nis_client_flags='' + nis_ypset_enable=NO + nis_ypset_flags='' + nis_server_enable=NO + nis_server_flags='' + nis_ypxfrd_enable=NO + nis_ypxfrd_flags='' + nis_yppasswdd_enable=NO + nis_yppasswdd_flags='' + bsnmpd_enable=NO + bsnmpd_flags='' + defaultrouter=NO + static_arp_pairs='' + static_routes='' + natm_static_routes='' + gateway_enable=NO + routed_enable=NO + routed_program=/sbin/routed + routed_flags=-q + mrouted_enable=NO + mrouted_program=/usr/local/sbin/mrouted + mrouted_flags='' + ipxgateway_enable=NO + ipxrouted_enable=NO + ipxrouted_flags='' + arpproxy_all=NO + forward_sourceroute=NO + accept_sourceroute=NO + atm_enable=NO + atm_pvcs='' + atm_arps='' + hcsecd_enable=NO + hcsecd_config=/etc/bluetooth/hcsecd.conf + sdpd_enable=NO + sdpd_control=/var/run/sdp + sdpd_groupname=nobody + sdpd_username=nobody + bthidd_enable=NO + bthidd_config=/etc/bluetooth/bthidd.conf + bthidd_hids=/var/db/bthidd.hids + rfcomm_pppd_server_enable=NO + rfcomm_pppd_server_profile='one two' + rfcomm_pppd_server_one_channel=1 + rfcomm_pppd_server_two_channel=3 + ubthidhci_enable=NO + netwait_enable=NO + netwait_timeout=60 + netwait_if_timeout=30 + icmp_bmcastecho=NO + ipv6_network_interfaces=auto + ipv6_activate_all_interfaces=NO + ipv6_defaultrouter=NO + ipv6_static_routes='' + ipv6_gateway_enable=NO + ipv6_cpe_wanif=NO + ipv6_privacy=NO + route6d_enable=NO + route6d_program=/usr/sbin/route6d + route6d_flags='' + ipv6_default_interface=NO + rtsol_flags='' + rtsold_enable=NO + rtsold_flags=-a + rtadvd_enable=NO + rtadvd_interfaces='' + mroute6d_enable=NO + mroute6d_program=/usr/local/sbin/pim6dd + mroute6d_flags='' + stf_interface_ipv4addr='' + stf_interface_ipv4plen=0 + stf_interface_ipv6_ifid=0:0:0:1 + stf_interface_ipv6_slaid=0000 + ipv6_faith_prefix=NO + ipv6_ipv4mapping=NO + ipv6_ipfilter_rules=/etc/ipf6.rules + ip6addrctl_enable=YES + ip6addrctl_verbose=NO + ip6addrctl_policy=AUTO + keyboard='' + keymap=NO + keyrate=NO + keybell=NO + keychange=NO + cursor=NO + scrnmap=NO + font8x16=NO + font8x14=NO + font8x8=NO + blanktime=300 + saver=NO + moused_nondefault_enable=YES + moused_enable=NO + moused_type=auto + moused_port=/dev/psm0 + moused_flags='' + mousechar_start=NO + allscreens_flags='' + allscreens_kbdflags='' + mta_start_script=/etc/rc.sendmail + sendmail_enable=NO + sendmail_pidfile=/var/run/sendmail.pid + sendmail_procname=/usr/sbin/sendmail + sendmail_flags='-L sm-mta -bd -q30m' + sendmail_submit_enable=YES + sendmail_submit_flags='-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost' + sendmail_outbound_enable=YES + sendmail_outbound_flags='-L sm-queue -q30m' + sendmail_msp_queue_enable=YES + sendmail_msp_queue_flags='-L sm-msp-queue -Ac -q30m' + sendmail_rebuild_aliases=NO + auditd_enable=NO + auditd_program=/usr/sbin/auditd + auditd_flags='' + cron_enable=YES + cron_program=/usr/sbin/cron + cron_dst=YES + cron_flags='' + lpd_enable=NO + lpd_program=/usr/sbin/lpd + lpd_flags='' + nscd_enable=NO + chkprintcap_enable=NO + chkprintcap_flags=-d + dumpdev=AUTO + dumpdir=/var/crash + savecore_flags='' + crashinfo_enable=YES + crashinfo_program=/usr/sbin/crashinfo + quota_enable=NO + check_quotas=YES + quotaon_flags=-a + quotaoff_flags=-a + quotacheck_flags=-a + accounting_enable=NO + ibcs2_enable=NO + ibcs2_loaders=coff + sysvipc_enable=NO + linux_enable=NO + svr4_enable=NO + clear_tmp_enable=NO + clear_tmp_X=YES + ldconfig_insecure=NO + ldconfig_paths='/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg' + ldconfig32_paths=/usr/lib32 + ldconfig_paths_aout='/usr/lib/compat/aout /usr/local/lib/aout' + ldconfig_local_dirs=/usr/local/libdata/ldconfig + ldconfig_local32_dirs=/usr/local/libdata/ldconfig32 + kern_securelevel_enable=NO + kern_securelevel=-1 + update_motd=YES + entropy_file=/entropy + entropy_dir=/var/db/entropy + entropy_save_sz=2048 + entropy_save_num=8 + harvest_interrupt=YES + harvest_ethernet=YES + harvest_p_to_p=YES + dmesg_enable=YES + watchdogd_enable=NO + watchdogd_flags='' + devfs_rulesets='/etc/defaults/devfs.rules /etc/devfs.rules' + devfs_system_ruleset='' + devfs_set_rulesets='' + performance_cx_lowest=HIGH + performance_cpu_freq=NONE + economy_cx_lowest=HIGH + economy_cpu_freq=NONE + virecover_enable=YES + ugidfw_enable=NO + bsdextended_script=/etc/rc.bsdextended + newsyslog_enable=YES + newsyslog_flags=-CN + mixer_enable=YES + opensm_enable=NO + jail_enable=NO + jail_parallel_start=NO + jail_list='' + jail_set_hostname_allow=YES + jail_socket_unixiproute_only=YES + jail_sysvipc_allow=NO + [ -z '' ] + source_rc_confs_defined=yes + source_rc_confs + local i sourced_files + sourced_files=:/etc/rc.conf: + [ -r /etc/rc.conf ] + . /etc/rc.conf + ifconfig_re0=DHCP + ifconfig_re0_ipv6=accept_rtadv + hostname=tykburk.tyknet.cn.dom + ipv6_activate_all_interfaces=YES + zfs_enable=YES + fusefs_enable=YES + keymap=danish.iso + hald_enable=YES + dbus_enable=YES + smbd_enable=YES + openntpd_enable=YES + sshd_enable=YES + vboxnet_enable=YES + smbd_enable=YES + sourced_files=:/etc/rc.conf::/etc/rc.conf.local: + [ -r /etc/rc.conf.local ] + _rc_conf_loaded=true + [ -f /etc/rc.conf.d/ip6addrctl ] + eval '_defval=$ip6addrctl_enable_defval' + _defval='' + [ -n '' ] + eval '_v=$ipv6_enable' + _v='' + eval '_msg=$ipv6_enable_obsolete_msg' + _msg='' + eval '_new=$ipv6_enable_newvar' + _new=ipv6_activate_all_interfaces + eval '_v=$ipv6_prefer' + _v='' + eval '_msg=$ipv6_prefer_obsolete_msg' + _msg='' + eval '_new=$ipv6_prefer_newvar' + _new=ip6addrctl_policy + run_rc_command start + _return=0 + rc_arg=start + [ -z ip6addrctl ] + shift 1 + rc_extra_args='' + _rc_prefix='' + eval '_override_command=$ip6addrctl_program' + _override_command='' + command='' + _keywords='start stop restart rcvar status prefer_ipv6 prefer_ipv4' + rc_pid='' + _pidcmd='' + _procname='' + [ -n '' ] + [ -z start ] + [ -n '' ] + eval 'rc_flags=$ip6addrctl_flags' + rc_flags='' + eval '_chdir=$ip6addrctl_chdir' '_chroot=$ip6addrctl_chroot' '_nice=$ip6addrctl_nice' '_user=$ip6addrctl_user' '_group=$ip6addrctl_group' '_groups=$ip6addrctl_groups' + _chdir='' _chroot='' _nice='' _user='' _group='' _groups='' + [ -n '' ] + eval + [ start != start ] + [ -n ip6addrctl_enable -a start != rcvar -a start != stop ] + checkyesno ip6addrctl_enable + eval '_value=$ip6addrctl_enable' + _value=YES + debug 'checkyesno: ip6addrctl_enable is set to YES.' + return 0 + eval '_cmd=$start_cmd' '_precmd=$start_precmd' '_postcmd=$start_postcmd' + _cmd=ip6addrctl_start _precmd='' _postcmd='' + [ -n ip6addrctl_start ] + _run_rc_precmd + check_required_before start + local _f + return 0 + [ -n '' ] + check_required_after start + local _f _args + return 0 + return 0 + _run_rc_doit 'ip6addrctl_start ' + debug 'run_rc_command: doit: ip6addrctl_start ' + eval 'ip6addrctl_start ' + ip6addrctl_start + afexists inet6 + local _af + _af=inet6 + check_kern_features inet6 + local _v + [ -n inet6 ] + eval '_v=$_rc_cache_kern_features_inet6' + _v='' + [ -n '' ] + /sbin/sysctl -n kern.features.inet6 + eval _rc_cache_kern_features_inet6=0 + _rc_cache_kern_features_inet6=0 + return 0 + [ -r /etc/ip6addrctl.conf -a -s /etc/ip6addrctl.conf ] + checkyesno ipv6_activate_all_interfaces + eval '_value=$ipv6_activate_all_interfaces' + _value=YES + debug 'checkyesno: ipv6_activate_all_interfaces is set to YES.' + return 0 + ip6addrctl_prefer_ipv6 + afexists inet6 + local _af + _af=inet6 + check_kern_features inet6 + local _v + [ -n inet6 ] + eval '_v=$_rc_cache_kern_features_inet6' + _v=0 + [ -n 0 ] + return 0 + ip6addrctl flush + ip6addrctl add ::1/128 50 0 + ip6addrctl add ::/0 40 1 + ip6addrctl add 2002::/16 30 2 + ip6addrctl add ::/96 20 3 + ip6addrctl add ::ffff:0:0/96 10 4 + checkyesno ip6addrctl_verbose + eval '_value=$ip6addrctl_verbose' + _value=NO + debug 'checkyesno: ip6addrctl_verbose is set to NO.' + return 1 + _return=1 + [ 1 -ne 0 ] + [ -z '' ] + return 1 + return 1 Best regards Thomas Steen Rasmussen From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 06:15:34 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E497E1065677 for ; Fri, 14 Oct 2011 06:15:34 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 47CF48FC18 for ; Fri, 14 Oct 2011 06:15:33 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p9E6FKJw089523; Fri, 14 Oct 2011 15:15:30 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p9E6FIA1021319; Fri, 14 Oct 2011 15:15:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 14 Oct 2011 15:14:02 +0900 (JST) Message-Id: <20111014.151402.1498559224124829567.hrs@allbsd.org> To: thomas@gibfest.dk From: Hiroki Sato In-Reply-To: <4E97CFFC.5020900@gibfest.dk> References: <4E9766C0.1020409@gibfest.dk> <20111014.095218.1603335403119728346.hrs@allbsd.org> <4E97CFFC.5020900@gibfest.dk> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct_14_15_14_02_2011_155)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 14 Oct 2011 15:15:31 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 06:15:35 -0000 ----Security_Multipart(Fri_Oct_14_15_14_02_2011_155)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Steen Rasmussen wrote in <4E97CFFC.5020900@gibfest.dk>: th> On 14.10.2011 02:52, Hiroki Sato wrote: th> > Can you please send me the results of the following commands: th> th> Please see the output below each command. I forgot to th> mention that the ipv6 uplink is a 6to4 tunnel, as you can th> see below from the 2002: prefix. Okay, what is the result of the following? % telnet www.freebsd.org 80 < /dev/null -- Hiroki ----Security_Multipart(Fri_Oct_14_15_14_02_2011_155)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6X0yoACgkQTyzT2CeTzy1lvgCcCVSVqe0FrCGhDk15DUj3Wzad FAYAn0bC/b0rvkrqU0nsNZauKbsgABfn =xa9G -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct_14_15_14_02_2011_155)---- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 06:43:01 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0FEC1065670; Fri, 14 Oct 2011 06:43:01 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2F38FC1C; Fri, 14 Oct 2011 06:43:01 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [IPv6:2002:d947:452:1:224:8cff:fe02:de01]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 8FAB265067; Fri, 14 Oct 2011 08:43:00 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.4.1 mail.tyknet.dk 8FAB265067 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1318574580; bh=H+eaa+iAxcCkRM0aYYUJvFsVpqYte9PejYoUMYZowr0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CIN0NtK5Cr+FMtpMWjNf9OmqI/HckdEGoEmxXGNCCxFZZbpWdSepZwItbwOvfUiqJ lceVeQLKy3C+Hbvw/hZyHV5cdZ4WC58GPz9VD9p4n8xp59i/eAN4YVz3YHatdiLFgI sF0HdloYferTGy/XvL/+JHfMNGhQIsv+zKwVuVtI= Message-ID: <4E97D9F3.4020308@gibfest.dk> Date: Fri, 14 Oct 2011 08:42:59 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hiroki Sato References: <4E9766C0.1020409@gibfest.dk> <20111014.095218.1603335403119728346.hrs@allbsd.org> <4E97CFFC.5020900@gibfest.dk> <20111014.151402.1498559224124829567.hrs@allbsd.org> In-Reply-To: <20111014.151402.1498559224124829567.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 06:43:02 -0000 On 14.10.2011 08:14, Hiroki Sato wrote: > telnet www.freebsd.org 80 < /dev/null [tykling@tykburk ~]$ telnet www.freebsd.org 80 < /dev/null Trying 69.147.83.34... Connected to red.freebsd.org. Escape character is '^]'. Connection closed by foreign host. /Thomas From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 07:24:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17B5F1065674 for ; Fri, 14 Oct 2011 07:24:18 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8EE8FC1A for ; Fri, 14 Oct 2011 07:24:17 +0000 (UTC) Received: by eyd10 with SMTP id 10so1051921eyd.13 for ; Fri, 14 Oct 2011 00:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Up0yA1vkXqugtS4olpgyb52PKkr1Wk26PHNjHD/URGs=; b=YYPwT9Up+EZmEpJgjfCAPTA8aED+dRFTld36auOPuanOso6Uahi2mjV7YMl7BWgoYb QNrvXhXejwjmKgZZh9oUdQ2c4qItRBp16WUOPJhrTxhwwuxSaLpaWcgbQEAT76Kt9pU9 RNw/sfulSMBvULFskPiVz0dVAbBpe5IedPkKg= Received: by 10.223.85.134 with SMTP id o6mr2059861fal.8.1318575480449; Thu, 13 Oct 2011 23:58:00 -0700 (PDT) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id a1sm1992392fab.4.2011.10.13.23.57.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 23:57:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: Date: Fri, 14 Oct 2011 09:57:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <45812C38-5FD2-43C4-825E-94B0E03A7AA6@gmail.com> References: <4e972734.52b1e00a.15ed.ffffd873@mx.google.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1251.1) Cc: FreeBSD Current Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 07:24:18 -0000 On Oct 13, 2011, at 9:40 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Thu, Oct 13, 2011 at 2:00 PM, wrote: >> From: Arnaud Lacombe >>=20 >> Hi folks, >>=20 >> There is many case recently when I really wished timestamp were = present in the >> post-mortem msgbuf. Such situation could be when userland application = segfault >> potentially triggering a panic/crash, or have information about the = time-wise >> location of a given message (kernel or userland). >>=20 >> Attached patch is available in the git repository at: >> git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp >>=20 >> Arnaud Lacombe (3): >> msgbuf(4): convert `msg_needsnl' to a bit flag >> msgbuf(4): add logic to prepend timestamp on new line >> msgbuf(4): add a sysctl to toggle timestamp prepend >>=20 >> sys/kern/subr_msgbuf.c | 53 = ++++++++++++++++++++++++++++++++++++++++------- >> sys/sys/msgbuf.h | 4 ++- >> 2 files changed, 48 insertions(+), 9 deletions(-) >>=20 Cool! I've dreamt for something like this for a long time, it can be very = useful. Regards, Nikolay From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 07:51:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1770106564A for ; Fri, 14 Oct 2011 07:51:15 +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 195E78FC17 for ; Fri, 14 Oct 2011 07:51:14 +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 KAA17602; Fri, 14 Oct 2011 10:51:04 +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 1REcXo-000PaR-Bn; Fri, 14 Oct 2011 10:51:04 +0300 Message-ID: <4E97E9E5.2020908@FreeBSD.org> Date: Fri, 14 Oct 2011 10:51:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4E580B14.7090208@FreeBSD.org> <1A828073-1D5F-4850-9379-4AB62CF3DAE3@xcllnt.net> <4E5B4BFB.9040907@FreeBSD.org> <4E5BF43A.5050306@FreeBSD.org> <4E5CB502.5020508@FreeBSD.org> In-Reply-To: <4E5CB502.5020508@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , FreeBSD-Current Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 07:51:16 -0000 on 30/08/2011 13:01 Andriy Gapon said the following: > > So, just to re-iterate, I think that this is indeed a regression and the one > that could be particularly unhelpful for a new release - the time when people > are much more likely to end up at the mountroot prompt during an installation of > a new system or an upgrade. Marcel, is there any chance that this regression can be fixed before the release? If not, then maybe it would be proper to pull the change that introduced it out of the release branch (r214006) ? > on 29/08/2011 23:19 Andriy Gapon said the following: >> on 29/08/2011 19:45 Marcel Moolenaar said the following: >>> >>> On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote: >>> >>>> on 27/08/2011 18:16 Marcel Moolenaar said the following: >>>>> >>>>> On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote: >>>>> >>>>>> >>>>>> It seems that after the introduction of the mountroot scripting language a user >>>>>> now has exactly one chance to try to specify a correct root device at the >>>>>> mountroot prompt. I am not sure that that is convenient/enough. >>>>> >>>>> This is no different from before. >>>> >>>> Are you sure? >>>> I remember trying multiple (incorrect) possibilities at the prompt and not >>>> getting the panic. But I know that sometimes I have cases of "false memories", >>>> so _I_ am not sure. >>> >>> I'm sure now that we're both not sure :-) >>> >>> It's possible the failure mode varied by how the root mount >>> failed... >> >> >> Judging from the code before r214006 it shouldn't have panic-ed upon such a failure: >> static int >> vfs_mountroot_ask(void) >> { >> char name[128]; >> char *mountfrom; >> char *options; >> >> for(;;) { >> ... >> gets(name, sizeof(name), 1); >> if (name[0] == '\0') >> return (1); >> if (name[0] == '?') { >> printf("\nList of GEOM managed disk devices:\n "); >> g_dev_print(); >> continue; >> } >> if (!vfs_mountroot_try(name, NULL)) >> return (0); >> } >> } >> >> >> So this "endless" loop was exited only if vfs_mountroot_try() returned success >> (error == 0) or if a user entered an empty string. >> > > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 08:09:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B7011065674 for ; Fri, 14 Oct 2011 08:09:38 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id A34118FC08 for ; Fri, 14 Oct 2011 08:09:36 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p9E89MkD016697; Fri, 14 Oct 2011 17:09:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p9E89KlS022593; Fri, 14 Oct 2011 17:09:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 14 Oct 2011 17:09:11 +0900 (JST) Message-Id: <20111014.170911.2032702506326503484.hrs@allbsd.org> To: thomas@gibfest.dk From: Hiroki Sato In-Reply-To: <4E97D9F3.4020308@gibfest.dk> References: <4E97CFFC.5020900@gibfest.dk> <20111014.151402.1498559224124829567.hrs@allbsd.org> <4E97D9F3.4020308@gibfest.dk> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Oct_14_17_09_11_2011_200)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 14 Oct 2011 17:09:33 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 08:09:38 -0000 ----Security_Multipart(Fri_Oct_14_17_09_11_2011_200)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Steen Rasmussen wrote in <4E97D9F3.4020308@gibfest.dk>: th> On 14.10.2011 08:14, Hiroki Sato wrote: th> > telnet www.freebsd.org 80 < /dev/null th> [tykling@tykburk ~]$ telnet www.freebsd.org 80 < /dev/null th> Trying 69.147.83.34... th> Connected to red.freebsd.org. th> Escape character is '^]'. th> Connection closed by foreign host. Thanks. There is no problem with the source address selection. The last questions are: % route get -inet www.freebsd.org % route get -inet6 www.freebsd.org % netstat -nrf inet6 % ndp -r I guess the second one returns "route: writing to routing socket: No such process" on your box. Is it correct? -- Hiroki ----Security_Multipart(Fri_Oct_14_17_09_11_2011_200)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6X7icACgkQTyzT2CeTzy2iJgCfUYZp49rW5HwUmH9cLMJaud1J nmkAnAhAlIIndZcSnooDBrvoZi4FvHya =3gYj -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Oct_14_17_09_11_2011_200)---- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 08:26:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0CD51065673; Fri, 14 Oct 2011 08:26:33 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:141:52a3:186::]) by mx1.freebsd.org (Postfix) with ESMTP id 315108FC1E; Fri, 14 Oct 2011 08:26:33 +0000 (UTC) Received: from [IPv6:2a01:3a0:a:90:346d:232:b90:fa86] (unknown [IPv6:2a01:3a0:a:90:346d:232:b90:fa86]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 1CD5C6516F; Fri, 14 Oct 2011 10:26:31 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.4.1 mail.tyknet.dk 1CD5C6516F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1318580792; bh=d/3YIysWY9G2SoRV0AR/SidUxY7VW71+VxabWFicO8E=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QJYjD4BYF+CF15fDsXASU2igP24hNaI496WV/fLbHpEfkkQE2tS7Z/CnDAjPFYdoy Wy4E/zi7npNQ1Ce0kevOqdjxSXroN7l6IrCa3iLBN5M/1l8zfTUXaPkCj7GZfA1szs BScLZ4COdJl5Ucwu5LHep5dQb1f82LKjADkt4DjI= Message-ID: <4E97F236.8040203@gibfest.dk> Date: Fri, 14 Oct 2011 10:26:30 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: hrs@FreeBSD.org References: <4E97CFFC.5020900@gibfest.dk> <20111014.151402.1498559224124829567.hrs@allbsd.org> <4E97D9F3.4020308@gibfest.dk> <20111014.170911.2032702506326503484.hrs@allbsd.org> In-Reply-To: <20111014.170911.2032702506326503484.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 08:26:33 -0000 On 14-10-2011 10:09, Hiroki Sato wrote: > Thanks. There is no problem with the source address selection. The > last questions are: > > % route get -inet www.freebsd.org [tykling@tykburk ~]$ route get -inet www.freebsd.org route to: red.freebsd.org destination: default mask: default gateway: fitfw interface: re0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 > % route get -inet6 www.freebsd.org [tykling@tykburk ~]$ route get -inet6 www.freebsd.org route to: red.freebsd.org destination: :: mask: default gateway: fe80::20d:f0ff:fe8d:4d23%re0 interface: re0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 > % netstat -nrf inet6 [tykling@tykburk ~]$ netstat -nrf inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fe80::20d:f0ff:fe8d:4d23%re0 UG re0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2002:d947:452:1::/64 link#5 U re0 2002:d947:452:1:224:8cff:fe02:de01 link#5 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%re0/64 link#5 U re0 fe80::224:8cff:fe02:de01%re0 link#5 UHS lo0 fe80::%fwe0/64 link#6 U fwe0 fe80::1e:8cff:feb6:377b%fwe0 link#6 UHS lo0 fe80::%fwip0/64 link#7 U fwip0 fe80::21e:8c00:1b6:377b%fwip0 link#7 UHS lo0 fe80::%em0/64 link#12 U em0 fe80::21b:21ff:fe32:fe80%em0 link#12 UHS lo0 fe80::%lo0/64 link#13 U lo0 ff01::%re0/32 fe80::224:8cff:fe02:de01%re0 U re0 ff01::%fwe0/32 fe80::1e:8cff:feb6:377b%fwe0 U fwe0 ff01::%fwip0/32 fe80::21e:8c00:1b6:377b%fwip0 U fwip0 ff01::%em0/32 fe80::21b:21ff:fe32:fe80%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%re0/32 fe80::224:8cff:fe02:de01%re0 U re0 ff02::%fwe0/32 fe80::1e:8cff:feb6:377b%fwe0 U fwe0 ff02::%fwip0/32 fe80::21e:8c00:1b6:377b%fwip0 U fwip0 ff02::%em0/32 fe80::21b:21ff:fe32:fe80%em0 U em0 ff02::%lo0/32 ::1 U lo0 > % ndp -r [tykling@tykburk ~]$ ndp -r fe80::20d:f0ff:fe8d:4d23%re0 if=re0, flags=, pref=medium, expire=28m15s > I guess the second one returns "route: writing to routing socket: No > such process" on your box. Is it correct? No, it returns the route to red.freebsd.org / 2001:4f8:fff6::22 (which is the default route of course). Extra info: [tykling@tykburk ~]$ telnet -6 www.freebsd.org 80 < /dev/null Trying 2001:4f8:fff6::22... Connected to red.freebsd.org. Escape character is '^]'. Connection closed by foreign host. Thanks, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 08:56:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id CEB071065675; Fri, 14 Oct 2011 08:56:09 +0000 (UTC) Date: Fri, 14 Oct 2011 08:56:09 +0000 From: Alexander Best To: Nikolay Denev Message-ID: <20111014085609.GA3799@freebsd.org> References: <4e972734.52b1e00a.15ed.ffffd873@mx.google.com> <45812C38-5FD2-43C4-825E-94B0E03A7AA6@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45812C38-5FD2-43C4-825E-94B0E03A7AA6@gmail.com> Cc: FreeBSD Current , Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 08:56:09 -0000 On Fri Oct 14 11, Nikolay Denev wrote: > > On Oct 13, 2011, at 9:40 PM, Arnaud Lacombe wrote: > > > Hi, > > > > On Thu, Oct 13, 2011 at 2:00 PM, wrote: > >> From: Arnaud Lacombe > >> > >> Hi folks, > >> > >> There is many case recently when I really wished timestamp were present in the > >> post-mortem msgbuf. Such situation could be when userland application segfault > >> potentially triggering a panic/crash, or have information about the time-wise > >> location of a given message (kernel or userland). > >> > >> Attached patch is available in the git repository at: > >> git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp > >> > >> Arnaud Lacombe (3): > >> msgbuf(4): convert `msg_needsnl' to a bit flag > >> msgbuf(4): add logic to prepend timestamp on new line > >> msgbuf(4): add a sysctl to toggle timestamp prepend > >> > >> sys/kern/subr_msgbuf.c | 53 ++++++++++++++++++++++++++++++++++++++++------- > >> sys/sys/msgbuf.h | 4 ++- > >> 2 files changed, 48 insertions(+), 9 deletions(-) > >> > > Cool! > > I've dreamt for something like this for a long time, it can be very useful. great work! a have a few comments however: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? 2) my dmesg output contains a lot of these entries: "<118>" 3) roughly the first 30 lines of my dmesg output have the timestamp "[1.0]". would it be possible to have more accuracy there? 4) maybe a new dmesg flag would be a good idea to suppress timestamps. cheers. alex > > Regards, > Nikolay > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:00:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 157EB1065686 for ; Fri, 14 Oct 2011 09:00:21 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C0E698FC19 for ; Fri, 14 Oct 2011 09:00:11 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 730365DCC; Fri, 14 Oct 2011 09:00:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id p9E909Rk040449; Fri, 14 Oct 2011 09:00:09 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Best From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Oct 2011 08:56:09 GMT." <20111014085609.GA3799@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 14 Oct 2011 09:00:09 +0000 Message-ID: <40448.1318582809@critter.freebsd.dk> Cc: Nikolay Denev , FreeBSD Current , Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 09:00:21 -0000 In message <20111014085609.GA3799@freebsd.org>, Alexander Best writes: >1) would it be possible to prepend those timestamps to the actual console >output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. >2) my dmesg output contains a lot of these entries: "<118>" These are magic markers for syslogd(8) specifying priority. >3) roughly the first 30 lines of my dmesg output have the timestamp "[1.0]". >would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:24:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id CB40A1065674; Fri, 14 Oct 2011 09:24:45 +0000 (UTC) Date: Fri, 14 Oct 2011 09:24:45 +0000 From: Alexander Best To: Poul-Henning Kamp Message-ID: <20111014092445.GA11785@freebsd.org> References: <20111014085609.GA3799@freebsd.org> <40448.1318582809@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40448.1318582809@critter.freebsd.dk> Cc: Nikolay Denev , FreeBSD Current , Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 09:24:45 -0000 On Fri Oct 14 11, Poul-Henning Kamp wrote: > In message <20111014085609.GA3799@freebsd.org>, Alexander Best writes: > > >1) would it be possible to prepend those timestamps to the actual console > >output and not only to the output of demsg? maybe via a sysctl toggle? > > The kernel does not know enough about timezones to emit anything > but UTC timestamps. hmm ok. > > >2) my dmesg output contains a lot of these entries: "<118>" > > These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. > > >3) roughly the first 30 lines of my dmesg output have the timestamp "[1.0]". > >would it be possible to have more accuracy there? > > No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. cheers. alex > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:34:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2F67E1065670; Fri, 14 Oct 2011 09:34:06 +0000 (UTC) Date: Fri, 14 Oct 2011 09:34:06 +0000 From: Alexander Best To: Poul-Henning Kamp Message-ID: <20111014093406.GA13981@freebsd.org> References: <20111014085609.GA3799@freebsd.org> <40448.1318582809@critter.freebsd.dk> <20111014092445.GA11785@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014092445.GA11785@freebsd.org> Cc: Nikolay Denev , FreeBSD Current , Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 09:34:06 -0000 On Fri Oct 14 11, Alexander Best wrote: > On Fri Oct 14 11, Poul-Henning Kamp wrote: > > In message <20111014085609.GA3799@freebsd.org>, Alexander Best writes: > > > > >1) would it be possible to prepend those timestamps to the actual console > > >output and not only to the output of demsg? maybe via a sysctl toggle? > > > > The kernel does not know enough about timezones to emit anything > > but UTC timestamps. > > hmm ok. > > > > > >2) my dmesg output contains a lot of these entries: "<118>" > > > > These are magic markers for syslogd(8) specifying priority. > > it would be nice, if their output could be turned off via a dmesg flag imo. > > > > > >3) roughly the first 30 lines of my dmesg output have the timestamp "[1.0]". > > >would it be possible to have more accuracy there? > > > > No, because we don't know the time until we've found the RTC chip. > > maybe prepending the output with [??] instead of [1.0] would make more sense, > so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] <118>/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] <118>Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] <118>Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] <118>Starting wpa_supplicant. [10.335514] <118>Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. cheers. alex > > cheers. > alex > > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 09:36:13 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E95CB106566C; Fri, 14 Oct 2011 09:36:13 +0000 (UTC) Date: Fri, 14 Oct 2011 09:36:13 +0000 From: Alexander Best To: Poul-Henning Kamp Message-ID: <20111014093613.GA15025@freebsd.org> References: <20111014085609.GA3799@freebsd.org> <40448.1318582809@critter.freebsd.dk> <20111014092445.GA11785@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014092445.GA11785@freebsd.org> Cc: Nikolay Denev , FreeBSD Current , Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 09:36:14 -0000 On Fri Oct 14 11, Alexander Best wrote: > On Fri Oct 14 11, Poul-Henning Kamp wrote: > > In message <20111014085609.GA3799@freebsd.org>, Alexander Best writes: > > > > >1) would it be possible to prepend those timestamps to the actual console > > >output and not only to the output of demsg? maybe via a sysctl toggle? > > > > The kernel does not know enough about timezones to emit anything > > but UTC timestamps. > > hmm ok. > > > > > >2) my dmesg output contains a lot of these entries: "<118>" > > > > These are magic markers for syslogd(8) specifying priority. > > it would be nice, if their output could be turned off via a dmesg flag imo. > > > > > >3) roughly the first 30 lines of my dmesg output have the timestamp "[1.0]". > > >would it be possible to have more accuracy there? > > > > No, because we don't know the time until we've found the RTC chip. > > maybe prepending the output with [??] instead of [1.0] would make more sense, > so users knows that those timestamps are bogus. or even better: if timestamp == 1.0 then simply don't ouput it at all. > > cheers. > alex > > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 10:06:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42ABB1065672 for ; Fri, 14 Oct 2011 10:06:03 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id EBC428FC24 for ; Fri, 14 Oct 2011 10:06:02 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 5E955144; Fri, 14 Oct 2011 12:06:01 +0200 (CEST) Date: Fri, 14 Oct 2011 12:05:22 +0200 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20111014100520.GA1635@garage.freebsd.pl> References: <86pqi1b1qp.fsf@ds4.des.no> <864nzdaw7b.fsf@ds4.des.no> <20111013134841.GF1667@garage.freebsd.pl> <86mxd59e1v.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <86mxd59e1v.fsf@ds4.des.no> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 10:06:03 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2011 at 04:11:40PM +0200, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek writes: > > I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same > > value on FreeBSD) should be converted to EEXIST on pidfile_open() > > return. >=20 > The historical (and documented) behavior is to return EAGAIN. We don't want to duplicate the code of handling EAGAIN into every single pidfile(3) consumer. This is why we hav pidfile(3) API in the first place - to make it easy for people to use. > > Also if we now have for loop, why not to put count in there? >=20 > Because if we do, there will be a nanosleep after the last > pidfile_read() attempt. We need to break the loop after pidfile_read() > failed but before nanosleep(). Right, ok. > > I'm not very happy about touching pidptr in case of error other than > > EEXIST. This is not documented, but a bit unexpected anyway. >=20 > Well, it was your idea, I just moved it to before the loop :) In my patch *pidptr was set to -1 only in the case of EAGAIN from pidfile_read(), not for every other error. BTW. With your patch we will continue even when flopen(3) failed for other reasons, instead of returning NULL. Checking for fd being -1 should not be done in the same statement with other checks. After proposed changes it would look like this, what do you think? http://people.freebsd.org/~pjd/patches/pidfile.3.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --KsGdsel6WgEHnImy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6YCWAACgkQForvXbEpPzT4GwCfeqfL6imNSNtIuYdQ/GZQg69v UYkAn2kFa2uQmESGl+BGjWuRjR//nXCp =HrI4 -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 10:32:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C94B1065675 for ; Fri, 14 Oct 2011 10:32:41 +0000 (UTC) (envelope-from jonathan.robert.anderson@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CAF718FC1C for ; Fri, 14 Oct 2011 10:32:40 +0000 (UTC) Received: by qadz30 with SMTP id z30so890457qad.13 for ; Fri, 14 Oct 2011 03:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=a/ZG0fNmQKDBeGmE59lCx1aGORICm4T5pAperidIDZc=; b=FIofAUptPQcD5sWOAvBw2O2sWupEwYKITDOjCk+2kANfl1iKqFwA63cUJrbZC50bgA KARconl+1A9rn7A8K9fM3/zHD3pVxEsBtq0GRePdwBjpStQqGkGrYDO+VWouOkZGUj7T 81Q29Le/mtCzkOj8k/xoabJYjAaCY4pP89NM4= MIME-Version: 1.0 Received: by 10.182.147.42 with SMTP id th10mr4799361obb.44.1318588359611; Fri, 14 Oct 2011 03:32:39 -0700 (PDT) Sender: jonathan.robert.anderson@gmail.com Received: by 10.182.188.71 with HTTP; Fri, 14 Oct 2011 03:32:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Oct 2011 11:32:39 +0100 X-Google-Sender-Auth: L6bD9ieU3Ggmf-XiYIeycn6xQeA Message-ID: From: Jonathan Anderson To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: PANIC: "ffs_valloc: dup alloc" on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 10:32:41 -0000 That's ok, a more aggressive fsck-from-a-rescue-disk strategy managed to clean things up. J Anderson On 6 October 2011 15:58, Benjamin Kaduk wrote: > On Thu, 6 Oct 2011, Jonathan Anderson wrote: > >> On 5 October 2011 23:50, Jonathan Anderson wrote: >>> >>> I was about to upgrade my build VM from BETA2 to BETA3, but I can't >>> seem to boot BETA2 any more: I get a "ffs_valloc: dup alloc" panic on >>> boot, every time. fsck runs and says, "ok, I've cleaned things up for >>> you", but then later on, when trying to update motd, FFS dies. >> >> Here are two screenshots: fsck succeeding and the relevant backtrace. > > Mailman seems to have stripped them. > > -Ben Kaduk > -- Jonathan Anderson jonathan@FreeBSD.org http://freebsd.org/~jonathan/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 11:39:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29315106567A; Fri, 14 Oct 2011 11:39:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 00AC38FC14; Fri, 14 Oct 2011 11:39:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AA60446B3C; Fri, 14 Oct 2011 07:39:09 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 49F498A02E; Fri, 14 Oct 2011 07:39:09 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Fri, 14 Oct 2011 07:35:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E95B028.6090307@protected-networks.net> <4E976592.2060804@FreeBSD.org> In-Reply-To: <4E976592.2060804@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110140735.52298.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 14 Oct 2011 07:39:09 -0400 (EDT) Cc: Michael Butler , FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 11:39:10 -0000 On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: > On 10/12/2011 08:20, Michael Butler wrote: > > SVN r226302 solves the ichwd failure to attach issue .. > > Still failing for me: > > ichwd0: on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 12:44:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0D6106566B; Fri, 14 Oct 2011 12:44:02 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF958FC0A; Fri, 14 Oct 2011 12:44:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A3CE91FFC33; Fri, 14 Oct 2011 12:44:01 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 88846B93C; Fri, 14 Oct 2011 14:44:01 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek References: <86pqi1b1qp.fsf@ds4.des.no> <864nzdaw7b.fsf@ds4.des.no> <20111013134841.GF1667@garage.freebsd.pl> <86mxd59e1v.fsf@ds4.des.no> <20111014100520.GA1635@garage.freebsd.pl> Date: Fri, 14 Oct 2011 14:44:01 +0200 In-Reply-To: <20111014100520.GA1635@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri, 14 Oct 2011 12:05:22 +0200") Message-ID: <86ty7b4ub2.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: incorrect use of pidfile(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 12:44:02 -0000 Pawel Jakub Dawidek writes: > After proposed changes it would look like this, what do you think? > > http://people.freebsd.org/~pjd/patches/pidfile.3.patch Looks OK to me, but you should also remove the paragraph about EAGAIN in the man page. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 12:53:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C39F91065677 for ; Fri, 14 Oct 2011 12:53:24 +0000 (UTC) (envelope-from nalitoja@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27CD28FC18 for ; Fri, 14 Oct 2011 12:53:23 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so1859027bkb.13 for ; Fri, 14 Oct 2011 05:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version:content-type; bh=UcHkY8j45OwV/8sQcAzGf62CbVerLf7dOCah6YRnBnE=; b=JrxQ/Nl24mW1GfVbTZ7VqNDaPx3kNXweNp7UPT+3QqHlupwv+MOY1OeAbKLorSs3gr bEXvS7JFNSRtt4nh77XR+iS1ynLryZ6q9sKFNLZfR7nXVwhkv4nCmNEaqqljX9LOnYOl 4nKCRxxMKYFAlPpN6Q8VceMrRkSJk2ID0eYwc= Received: by 10.204.152.201 with SMTP id h9mr6640779bkw.99.1318596803131; Fri, 14 Oct 2011 05:53:23 -0700 (PDT) Received: from nil (politkovskaja.torservers.net. [77.247.181.165]) by mx.google.com with ESMTPS id a27sm8352974bku.9.2011.10.14.05.52.46 (version=SSLv3 cipher=OTHER); Fri, 14 Oct 2011 05:53:22 -0700 (PDT) From: Nali Toja To: Alexander Best In-Reply-To: <20111014093406.GA13981@freebsd.org> (Alexander Best's message of "Fri, 14 Oct 2011 09:34:06 +0000") Date: Fri, 14 Oct 2011 12:52:03 +0000 Message-ID: <8662jrlor0.fsf@gmail.com> References: <20111014085609.GA3799@freebsd.org> <40448.1318582809@critter.freebsd.dk> <20111014092445.GA11785@freebsd.org> <20111014093406.GA13981@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Nikolay Denev , Poul-Henning Kamp , FreeBSD Current , Arnaud Lacombe Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 12:53:24 -0000 Alexander Best writes: >> On Fri Oct 14 11, Poul-Henning Kamp wrote: >> > In message <20111014085609.GA3799@freebsd.org>, Alexander Best writes: >> > >> > >1) would it be possible to prepend those timestamps to the actual console >> > >output and not only to the output of demsg? maybe via a sysctl toggle? >> > >> > The kernel does not know enough about timezones to emit anything >> > but UTC timestamps. >> >> hmm ok. >> >> > >> > >2) my dmesg output contains a lot of these entries: "<118>" >> > >> > These are magic markers for syslogd(8) specifying priority. >> >> it would be nice, if their output could be turned off via a dmesg flag imo. >> >> > >> > >3) roughly the first 30 lines of my dmesg output have the timestamp "[1.0]". >> > >would it be possible to have more accuracy there? >> > >> > No, because we don't know the time until we've found the RTC chip. >> >> maybe prepending the output with [??] instead of [1.0] would make more sense, >> so users knows that those timestamps are bogus. > > maybe the granularity of the timestamps could be limited to a static value? the > following output doesn't really look pretty: > > [7.729516] <118>/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) > [7.891512] <118>Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. > [8.33519] . > [9.440514] <118>Setting hostname: otaku. > [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 > [9.850516] <118>Starting wpa_supplicant. > [10.335514] <118>Starting Network: lo0 ath0. > > so it would be nice, if trailing zeros got printed out, too. Why not make formatting similar to linux/xorg logs, e.g. [ 31.897] (**) Option "XkbLayout" "us" [ 31.897] (II) XINPUT: Adding extended input device "" (type: KEYBOARD, id 7) [ 11485.404] (II) 3rd Button detected: disabling emulate3Button [ 0.000000] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 [ 0.000000] Command line: root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro [...] [ 15.096862] NET: Registered protocol family 10 [ 16.792594] [drm] nouveau 0000:01:00.0: plugged DVI-I-2 [ 26.054186] eth0: no IPv6 routers present A way to convert those timestamps to localtime or time delta[1] post-mortem via dmesg(8) would be good, too. [1] like in tcpdump -ttt From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 13:37:43 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3636B106566B for ; Fri, 14 Oct 2011 13:37:43 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 03C518FC16 for ; Fri, 14 Oct 2011 13:37:42 +0000 (UTC) Received: from [172.23.7.198] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p9EDbYMi034125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Oct 2011 06:37:41 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Marcel Moolenaar In-Reply-To: <4E97E9E5.2020908@FreeBSD.org> Date: Fri, 14 Oct 2011 06:37:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E580B14.7090208@FreeBSD.org> <1A828073-1D5F-4850-9379-4AB62CF3DAE3@xcllnt.net> <4E5B4BFB.9040907@FreeBSD.org> <4E5BF43A.5050306@FreeBSD.org> <4E5CB502.5020508@FreeBSD.org> <4E97E9E5.2020908@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1244.3) Cc: FreeBSD-Current Current Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 13:37:43 -0000 On Oct 14, 2011, at 12:51 AM, Andriy Gapon wrote: > on 30/08/2011 13:01 Andriy Gapon said the following: >>=20 >> So, just to re-iterate, I think that this is indeed a regression and = the one >> that could be particularly unhelpful for a new release - the time = when people >> are much more likely to end up at the mountroot prompt during an = installation of >> a new system or an upgrade. >=20 > Marcel, >=20 > is there any chance that this regression can be fixed before the = release? Probably, yes. How do you want to fix this? You haven't really expressed what you would like to see, other than mentioning that you think it's a regression from before. Arguably, the previous behaviour had a lot to be desired for so since you're worried about the user experience, thinking this through is important. > If not, then maybe it would be proper to pull the change that = introduced it out > of the release branch (r214006) ? Don't be ridiculous. --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 14:49:41 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1252106566B for ; Fri, 14 Oct 2011 14:49:41 +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 488D18FC12 for ; Fri, 14 Oct 2011 14:49:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA25901; Fri, 14 Oct 2011 17:49:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E984BF9.4000700@FreeBSD.org> Date: Fri, 14 Oct 2011 17:49:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marcel Moolenaar References: <4E580B14.7090208@FreeBSD.org> <1A828073-1D5F-4850-9379-4AB62CF3DAE3@xcllnt.net> <4E5B4BFB.9040907@FreeBSD.org> <4E5BF43A.5050306@FreeBSD.org> <4E5CB502.5020508@FreeBSD.org> <4E97E9E5.2020908@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Current Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 14:49:42 -0000 on 14/10/2011 16:37 Marcel Moolenaar said the following: > > On Oct 14, 2011, at 12:51 AM, Andriy Gapon wrote: > >> on 30/08/2011 13:01 Andriy Gapon said the following: >>> >>> So, just to re-iterate, I think that this is indeed a regression and the one >>> that could be particularly unhelpful for a new release - the time when people >>> are much more likely to end up at the mountroot prompt during an installation of >>> a new system or an upgrade. >> >> Marcel, >> >> is there any chance that this regression can be fixed before the release? > > Probably, yes. How do you want to fix this? Simple: revert to the previous behavior. If a user enters incorrect device name (i.e. root mounting fails), then return back to the prompt instead of panicing. > You haven't really expressed > what you would like to see, other than mentioning that you think it's a > regression from before. I thought that what I wrote above was kind of obvious. > Arguably, the previous behaviour had a lot to be > desired for so since you're worried about the user experience, thinking > this through is important. I didn't see anything bad with the previous behavior in this respect. >> If not, then maybe it would be proper to pull the change that introduced it out >> of the release branch (r214006) ? > > Don't be ridiculous. > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 07:55:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82C81065679 for ; Fri, 14 Oct 2011 07:55:30 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6F38FC1B for ; Fri, 14 Oct 2011 07:55:29 +0000 (UTC) Received: by eyd10 with SMTP id 10so1082338eyd.13 for ; Fri, 14 Oct 2011 00:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mir1AuZ0YZvO1PnpkO3lXPUejdN00MRal8qktwuEQZg=; b=my3LAbA5w3INw75pumzWWEzRZSqqDutd5Nwz3kux5bcQunZ3Ao6IbYFPUnnV3KiidT 5/EnU+e7OM5zMlnNm3i7Bilq6jxwhTMSOGr0w0Oja7+OHCwbZWOeU4Wo+3Ehz8oEr+jx meLv75PcBgWAeGuTWr/ryBx8xop1kClPZ2NNE= MIME-Version: 1.0 Received: by 10.223.7.18 with SMTP id b18mr2482543fab.31.1318578928993; Fri, 14 Oct 2011 00:55:28 -0700 (PDT) Received: by 10.152.11.195 with HTTP; Fri, 14 Oct 2011 00:55:28 -0700 (PDT) Date: Fri, 14 Oct 2011 11:55:28 +0400 Message-ID: From: Pavel Timofeev To: freebsd-current@freebsd.org X-Mailman-Approved-At: Fri, 14 Oct 2011 15:26:34 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: x.0 RELASE isn't for production. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 07:55:30 -0000 That's what most people think. Hi! I would like to say that most freebsd users don't try CURRENT, but try BETAs-x, RCs-x. Why? Because most users don't like compile new kernel and world. It's tediously. You need to download a CURRENT snapshot iso, to install, csup, and then to build kernel and world. FreeBSD project builds CURRENT snapshot every month, but not always. And this volatility is bad. Month is a big period. Very big, imo. For example, 10 day period would be great! And when BETA/RC time comes users rush like mad to test it. And they find errors and bugs. Writing PR, emails and even !pathes! But the lion's share of these pathes doesn't get into the coming BETA or RC. Maintainers say "I don't have time [to test it]" or "It's too late". Why is it late? I'm talking about only BUGS (PRs with pathes), not new features. Let's users test it! In coming BETA/RC. Where are we in a hurry? The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the only purpose of it. Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE. Because of this situation most people says "x.0 RELASE isn't for production." All the above applies only to the opening of a new STABLE branch, 9 for this time. I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 15:55:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770B4106564A; Fri, 14 Oct 2011 15:55:06 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5C18FC0C; Fri, 14 Oct 2011 15:55:05 +0000 (UTC) Received: by gyd8 with SMTP id 8so1617482gyd.13 for ; Fri, 14 Oct 2011 08:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=KbAsXSBKm8ebeuhcKyHCn2p8CGUj5lI3Dah2QGkKHQ4=; b=VydTM4U7EUWH6X9c2ej/Vsy8m61qVIeruw70y3HxwtHsQ6nkWnm9JTk3QhFRghKLqh AKoj27pUH0y+NbLpfyzDusM2mTCkbEGEBPkEZ3Or972GdTrBf7ztukXittPn2cCR79Qn 2AWh+QIKfXlERdS90m7iwxYQwd3dNSNWXkjIo= Received: by 10.42.108.136 with SMTP id h8mr17003170icp.43.1318607705198; Fri, 14 Oct 2011 08:55:05 -0700 (PDT) Received: from localhost.localdomain ([184.175.13.173]) by mx.google.com with ESMTPS id ge16sm9317678ibb.2.2011.10.14.08.55.03 (version=SSLv3 cipher=OTHER); Fri, 14 Oct 2011 08:55:04 -0700 (PDT) From: Arnaud Lacombe To: avg@freebsd.org Date: Fri, 14 Oct 2011 11:54:57 -0400 Message-Id: <1318607697-31950-1-git-send-email-lacombar@gmail.com> X-Mailer: git-send-email 1.7.6.153.g78432 In-Reply-To: <4E984BF9.4000700@FreeBSD.org> References: <4E984BF9.4000700@FreeBSD.org> Cc: FreeBSD Current , Arnaud Lacombe Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 15:55:06 -0000 Andry Gapon wrote: > Simple: revert to the previous behavior. If a user enters incorrect device name >(i.e. root mounting fails), then return back to the prompt instead of panicing. That should do the job. - Arnaud --- sys/kern/vfs_mountroot.c | 45 +++++++++++++++++++++++---------------------- 1 files changed, 23 insertions(+), 22 deletions(-) diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c index ccbcb33..ae3ffa7 100644 --- a/sys/kern/vfs_mountroot.c +++ b/sys/kern/vfs_mountroot.c @@ -481,28 +481,29 @@ parse_dir_ask(char **conf) printf("\n"); printf(" ? List valid disk boot devices\n"); printf(" . Yield 1 second (for background tasks)\n"); - printf(" Abort manual input\n"); + printf(" x Abort manual input)\n"); + + do { + error = EINVAL; + printf("\nmountroot> "); + gets(name, sizeof(name), GETS_ECHO); + if (name[0] == '?') { + printf("\nList of GEOM managed disk devices:\n "); + g_dev_print(); + continue; + } + if (name[0] == '.') { + pause("rmask", hz); + continue; + } + if (name[0] == 'x' && name[1] == '\0') + break; + mnt = name; + error = parse_mount(&mnt); + if (error < 0) + printf("Invalid specification.\n"); + } while (error != 0); - again: - printf("\nmountroot> "); - gets(name, sizeof(name), GETS_ECHO); - if (name[0] == '\0') - return (0); - if (name[0] == '?') { - printf("\nList of GEOM managed disk devices:\n "); - g_dev_print(); - goto again; - } - if (name[0] == '.') { - pause("rmask", hz); - goto again; - } - mnt = name; - error = parse_mount(&mnt); - if (error == -1) { - printf("Invalid specification.\n"); - goto again; - } return (error); } -- 1.7.6.153.g78432 From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 15:58:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B768F106566B; Fri, 14 Oct 2011 15:58:49 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5878FC0A; Fri, 14 Oct 2011 15:58:48 +0000 (UTC) Received: by wyj26 with SMTP id 26so4424181wyj.13 for ; Fri, 14 Oct 2011 08:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+eIfQRTlLjcB8OUuQPl+YMFivQGTptSwAr0lY/1vSfY=; b=jji1vMlouDO+6MXlJjiCvlNFQHDw9mSHxHqK+L2mG8MeLDhWV4FM9xaWHWP9X4BUhV v1RtcJOV1onblXC+7EIDZ4l+j0vrI6cu+9ApZKQgQlKZgqwm/sGv6B5azMhlaNVZGnrS fUQ9Gmbs/Y62GtxVm2QUE0shCb0ZLvyF/jMLk= MIME-Version: 1.0 Received: by 10.216.133.5 with SMTP id p5mr137293wei.34.1318607927784; Fri, 14 Oct 2011 08:58:47 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Fri, 14 Oct 2011 08:58:47 -0700 (PDT) In-Reply-To: <1318607697-31950-1-git-send-email-lacombar@gmail.com> References: <4E984BF9.4000700@FreeBSD.org> <1318607697-31950-1-git-send-email-lacombar@gmail.com> Date: Fri, 14 Oct 2011 11:58:47 -0400 Message-ID: From: Arnaud Lacombe To: avg@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Arnaud Lacombe Subject: Re: possible mountroot regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 15:58:49 -0000 Hi, On Fri, Oct 14, 2011 at 11:54 AM, Arnaud Lacombe wrote= : > Andry Gapon wrote: >> Simple: revert to the previous behavior. =A0If a user enters incorrect d= evice name >>(i.e. root mounting fails), then return back to the prompt instead of pan= icing. > That should do the job. > Actually, my primary interest in that patch was to be able to hit to be sure I had the prompt (think a serial console connecting after the message has been displayed), then enter the information. Not sure that'd suit what you expect though. - Arnaud > =A0- Arnaud > > --- > =A0sys/kern/vfs_mountroot.c | =A0 45 +++++++++++++++++++++++-------------= --------- > =A01 files changed, 23 insertions(+), 22 deletions(-) > > diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c > index ccbcb33..ae3ffa7 100644 > --- a/sys/kern/vfs_mountroot.c > +++ b/sys/kern/vfs_mountroot.c > @@ -481,28 +481,29 @@ parse_dir_ask(char **conf) > =A0 =A0 =A0 =A0printf("\n"); > =A0 =A0 =A0 =A0printf(" =A0? =A0 =A0 =A0 =A0 =A0 =A0 =A0 List valid disk = boot devices\n"); > =A0 =A0 =A0 =A0printf(" =A0. =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yield 1 second (= for background tasks)\n"); > - =A0 =A0 =A0 printf(" =A0 =A0 =A0Abort manual input\n"); > + =A0 =A0 =A0 printf(" =A0x =A0 =A0 =A0 =A0 =A0 =A0 =A0 Abort manual inpu= t)\n"); > + > + =A0 =A0 =A0 do { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D EINVAL; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\nmountroot> "); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 gets(name, sizeof(name), GETS_ECHO); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (name[0] =3D=3D '?') { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\nList of GEOM mana= ged disk devices:\n =A0"); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 g_dev_print(); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (name[0] =3D=3D '.') { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pause("rmask", hz); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (name[0] =3D=3D 'x' && name[1] =3D=3D '\= 0') > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mnt =3D name; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D parse_mount(&mnt); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (error < 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("Invalid specificati= on.\n"); > + =A0 =A0 =A0 } while (error !=3D 0); > > - again: > - =A0 =A0 =A0 printf("\nmountroot> "); > - =A0 =A0 =A0 gets(name, sizeof(name), GETS_ECHO); > - =A0 =A0 =A0 if (name[0] =3D=3D '\0') > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); > - =A0 =A0 =A0 if (name[0] =3D=3D '?') { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("\nList of GEOM managed disk devices= :\n =A0"); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 g_dev_print(); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto again; > - =A0 =A0 =A0 } > - =A0 =A0 =A0 if (name[0] =3D=3D '.') { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pause("rmask", hz); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto again; > - =A0 =A0 =A0 } > - =A0 =A0 =A0 mnt =3D name; > - =A0 =A0 =A0 error =3D parse_mount(&mnt); > - =A0 =A0 =A0 if (error =3D=3D -1) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("Invalid specification.\n"); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto again; > - =A0 =A0 =A0 } > =A0 =A0 =A0 =A0return (error); > =A0} > > -- > 1.7.6.153.g78432 > > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:05:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712F9106566B for ; Fri, 14 Oct 2011 16:05:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 39A358FC13 for ; Fri, 14 Oct 2011 16:05:48 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id p9EG5mPu009611; Fri, 14 Oct 2011 09:05:48 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id p9EG5mAk009610; Fri, 14 Oct 2011 09:05:48 -0700 (PDT) (envelope-from david) Date: Fri, 14 Oct 2011 09:05:48 -0700 From: David Wolfskill To: Pavel Timofeev Message-ID: <20111014160548.GD5065@albert.catwhisker.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qGV0fN9tzfkG3CxV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: x.0 RELASE isn't for production. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:05:49 -0000 --qGV0fN9tzfkG3CxV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2011 at 11:55:28AM +0400, Pavel Timofeev wrote: > That's what most people think. Could be. But to the extent that it's true, I have no reason to believe that it's a perspective that is held uniquely (or even principally) about FreeBSD. > Hi! >=20 > I would like to say that most freebsd users don't try CURRENT, but try > BETAs-x, RCs-x. Errr... I'll suggest that most folks who posit what "most folks" do don't actually determine this empirically. Some of them probably engage in something called "projection" (in lieu of performing appropriate polling, for example). > Why? Because most users don't like compile new kernel and world. It's > tediously. Errr... So what? Doing it doesn't prevent one from doing other things (within reason), and the process gets done when it's done. And it's the computer doing the tedious stuff -- which is something at which they excel. I'm in the habit of tracking stable/8, stable/9, and head on a daily basis on a personal "build machine" and on my laptop. I also update all of the installed ports on each machine daily. I don't expect "most" folks to do that; actually, I don't expect anyone else to do (precisely) that. > You need to download a CURRENT snapshot iso, to install, csup, and then to > build kernel and world. Really? I don't think I've ever used a snapshot. I do maintain a private mirror of the FreeBSD CVS & SVN repositories (and mirror those to my laptop). I find the "tracking" process fairly straightforward, and only rarely surprising (though usually, if it is "surprising," it's not in an especially "good" way -- but then I'm occasionally able to help at least provide some encouragement to fix the cause of the surprise). > FreeBSD project builds CURRENT snapshot every month, but not always. And > this volatility is bad. > Month is a big period. Very big, imo. For example, 10 day period would be > great! If you want finer-grained updates, one way is to use the source. The project still maintains the SVN-to-CVS exporting process, and a network of public CVS mirrors around the planet. The cvs program is in the FreeBSD base system. You have the resources necessary to do this, if you want to do so. > And when BETA/RC time comes users rush like mad to test it. And they find > errors and bugs. Writing PR, emails and even !pathes! There are certainly some folks whose first exposure to a new release is in the later stages of the release process. Changing parameters (such as the duration of the process) may affect the population distribution some, but it won't change the fact that there are some folks who will not test early enough to raise some valid objections or concerns in sufficient time to have them addressed in a completely satisfactory manner prior to the release. This is something that appears to involve rather deep-sewated aspects of human nature, and it is not in the power of any organization to prevent it. The best anyone (or any gropu) can do is find ways to mitigate it, nad learn to move on. > But the lion's share of these pathes doesn't get into the coming BETA or = RC. > Maintainers say "I don't have time [to test it]" or "It's too late". Given that the process is intended to produce a release, there comes a time when it is necessary to "draw the line" and cut the release. Software is rarely perfect. I'd venture that software of "sufficient complexity" is never "perfect." I'll also ventire that FreeBSD -- much as I enjoy using and working with it -- is sufficiently complex as to be imperfect. In fact, it is a work in progress. This ought not be either surprising or unfamiliar to anyone who has been on the planet long enough to recognize the parallels with humans -- remarkably few humans are perfect, either, after all. :-} [And yes, I include myself as "imperfect" -- certainly as long as I'm still breathing.] > Why is it late? I'm talking about only BUGS (PRs with pathes), not new > features. Let's users test it! In coming BETA/RC. Where are we in a hurry? > The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the only > purpose of it. > Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE. > Because of this situation most people says "x.0 RELASE isn't for > production." Much depends on the workload in question. There are folks who run CURRENT/head in "production" environments. (I'm not one of them.) I do, however, run stable/8 in a (small) production environment; for that, I update weekly (unless I have some reason to do otherwise). > All the above applies only to the opening of a new STABLE branch, 9 for t= his > time. > I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be > longer. Six months, for example. > New STABLE branch is very important! So is opening head up to allow developers to work on and commit new code. As with many things in engineering, there's a cost/benefit trade-off. RE is doing a remarkable job, IMO. Folks who care sufficiently will find ways to test early enough to be useful. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --qGV0fN9tzfkG3CxV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6YXdsACgkQmprOCmdXAD33NACeNciOC/N3OOKRvYHs+Q+iWJdO tPMAnjRI3LqQrrWOyfgQVnKr85nOWt7D =yxiT -----END PGP SIGNATURE----- --qGV0fN9tzfkG3CxV-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:14:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC6DA106564A for ; Fri, 14 Oct 2011 16:14:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 599D58FC08 for ; Fri, 14 Oct 2011 16:14:52 +0000 (UTC) Received: by wwi18 with SMTP id 18so378606wwi.31 for ; Fri, 14 Oct 2011 09:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=asp3U9r2lKPLW8quBDNDLCQc5Kk2cpqFwFvEK8AWDEU=; b=bWk3FWHBUuRdXp8rXzS8QLPzWH1ObM/Ul5qlqfyilhhQQ27pQX5Sn/Gocw6QXiuqNA AboU9sG6V1VzB3J92C4BpTNz3PE/7GFUpfBs+yTDx9O+1oSaW3VCTJHySEugfNhYuBA7 Pah+9MuUXjOtX5t/KFMtscUB/IXzLEdpX+Lag= MIME-Version: 1.0 Received: by 10.216.210.216 with SMTP id u66mr147036weo.49.1318608892163; Fri, 14 Oct 2011 09:14:52 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Fri, 14 Oct 2011 09:14:52 -0700 (PDT) In-Reply-To: <8662jrlor0.fsf@gmail.com> References: <20111014085609.GA3799@freebsd.org> <40448.1318582809@critter.freebsd.dk> <20111014092445.GA11785@freebsd.org> <20111014093406.GA13981@freebsd.org> <8662jrlor0.fsf@gmail.com> Date: Fri, 14 Oct 2011 12:14:52 -0400 Message-ID: From: Arnaud Lacombe To: Nali Toja Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Best , Poul-Henning Kamp , FreeBSD Current , Nikolay Denev Subject: Re: [RFC] Prepend timestamp in msgbuf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 16:14:54 -0000 Hi, On Fri, Oct 14, 2011 at 8:52 AM, Nali Toja wrote: > Alexander Best writes: > >>> On Fri Oct 14 11, Poul-Henning Kamp wrote: >>> > In message <20111014085609.GA3799@freebsd.org>, Alexander Best writes= : >>> > >>> > >1) would it be possible to prepend those timestamps to the actual co= nsole >>> > >output and not only to the output of demsg? maybe via a sysctl toggl= e? >>> > >>> > The kernel does not know enough about timezones to emit anything >>> > but UTC timestamps. >>> >>> hmm ok. >>> >>> > >>> > >2) my dmesg output contains a lot of these entries: "<118>" >>> > >>> > These are magic markers for syslogd(8) specifying priority. >>> >>> it would be nice, if their output could be turned off via a dmesg flag = imo. >>> >>> > >>> > >3) roughly the first 30 lines of my dmesg output have the timestamp = "[1.0]". >>> > >would it be possible to have more accuracy there? >>> > >>> > No, because we don't know the time until we've found the RTC chip. >>> >>> maybe prepending the output with [??] instead of [1.0] would make more = sense, >>> so users knows that those timestamps are bogus. >> >> maybe the granularity of the timestamps could be limited to a static val= ue? the >> following output doesn't really look pretty: >> >> [7.729516] <118>/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 b= locks, 0.7% fragmentation) >> [7.891512] <118>Mounting local file systems:WARNING: TMPFS is considered= to be a highly experimental feature in FreeBSD. >> [8.33519] . >> [9.440514] <118>Setting hostname: otaku. >> [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 >> [9.850516] <118>Starting wpa_supplicant. >> [10.335514] <118>Starting Network: lo0 ath0. >> >> so it would be nice, if trailing zeros got printed out, too. > > Why not make formatting similar to linux/xorg logs, e.g. > > =A0[ =A0 =A031.897] (**) Option "XkbLayout" "us" > =A0[ =A0 =A031.897] (II) XINPUT: Adding extended input device "" (type: KEYBOARD, id 7) > =A0[ 11485.404] (II) 3rd Button detected: disabling emulate3Button > > =A0[ =A0 =A00.000000] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc vers= ion 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 = CEST 2011 > =A0[ =A0 =A00.000000] Command line: root=3D/dev/disk/by-uuid/625db1f5-9b5= 1-4d2d-acb7-6726f4d7e199 ro > =A0[...] > =A0[ =A0 15.096862] NET: Registered protocol family 10 > =A0[ =A0 16.792594] [drm] nouveau 0000:01:00.0: plugged DVI-I-2 > =A0[ =A0 26.054186] eth0: no IPv6 routers present > > A way to convert those timestamps to localtime or time delta[1] post-mort= em > via dmesg(8) would be good, too. > well, I do not care for the "pretty" side of the thing, however, this is just a matter length modifier in the string format; should be trivial to fix. - Arnaud > [1] like in tcpdump -ttt > From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 16:20:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8497B106564A for ; Fri, 14 Oct 2011 16:20:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14C3C8FC0C for ; Fri, 14 Oct 2011 16:20:35 +0000 (UTC) Received: by wyj26 with SMTP id 26so4453435wyj.13 for ; Fri, 14 Oct 2011 09:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jMPO8xrUn6E9xgVHjCo7GmRBVSDtL2m5BhSbpGqaHk8=; b=Z+0RQzubL7BP+c3lemabZ1dUKnTPMCxNHj8zQpX6ePcmtu/CJVywYBWMcMW/A1L+q2 H4b+0VYD11PiGinsMlcvkHggHx7LrYZBJqX32hrwPX3Y1eSBf5w2I1fAp0Mq3wd1GTcy SEpA6H2D/kAiSJ7gga5nVhwLj46cUArsAwTkI= MIME-Version: 1.0 Received: by 10.227.32.73 with SMTP id b9mr1973966wbd.49.1318609234237; Fri, 14 Oct 2011 09:20:34 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Fri, 14 Oct 2011 09:20:34 -0700 (PDT) In-Reply-To: <20111014160548.GD5065@albert.catwhisker.org> References: <20111014160548.GD5065@albert.catwhisker.org> Date: Fri, 14 Oct 2011 12:20:34 -0400 Message-ID: From: Arnaud Lacombe To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pavel Timofeev , freebsd-current@freebsd.org Subject: Re: x.0 RELASE isn't for production. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 16:20:37 -0000 Hi, On Fri, Oct 14, 2011 at 12:05 PM, David Wolfskill wr= ote: > On Fri, Oct 14, 2011 at 11:55:28AM +0400, Pavel Timofeev wrote: >> That's what most people think. > > Could be. =A0But to the extent that it's true, I have no reason to believ= e > that it's a perspective that is held uniquely (or even principally) about > FreeBSD. > but this is far from being universal statement too, cf the Linux v3.0 release, which was just another regular kernel release. - Arnaud. ps: can you fix you MUA not to add "Reply-to: freebsd-current@freebsd.org" ? I replied to _you_, David Wolfskill, not an impersonal mailing list. Thanks. From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 17:35:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B3431065673; Fri, 14 Oct 2011 17:35:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9928FC08; Fri, 14 Oct 2011 17:35:21 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A4B2F183D4; Fri, 14 Oct 2011 10:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1318613721; bh=X1YVAe+yuM07G5BEzKRz3iCLNzbpBJBBLcRW465/3gI=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5pgcH6//xbdCZP4f6P7TbFqR+hRTO3T93QGRKKH6IDtzLC0AH4y6lbBg3roQhHx+T SV7OtA4m2+Pko22FRyohtOYMe+c6OPkIomRNGGp8YrNhqGMt/sWkHmgfac4vWZVHOr LwE6YcMA+8rJ/+XG8vN65Uf/TUSHtOIUZXNW4fdA= Message-ID: <4E9872D7.7050905@delphij.net> Date: Fri, 14 Oct 2011 10:35:19 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: John Baldwin References: <4E95B028.6090307@protected-networks.net> <4E976592.2060804@FreeBSD.org> <201110140735.52298.jhb@freebsd.org> In-Reply-To: <201110140735.52298.jhb@freebsd.org> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Barton , Michael Butler , FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 17:35:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/14/11 04:35, John Baldwin wrote: > On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: >> On 10/12/2011 08:20, Michael Butler wrote: >>> SVN r226302 solves the ichwd failure to attach issue .. >> >> Still failing for me: >> >> ichwd0: on isa0 >> ichwd0: unable to reserve GCS registers >> device_attach: ichwd0 attach returned 6 > > Yes, it can only fix it if the BIOS decides to list it as a system resource in > ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as > a workaround for lying BIOSes yes? I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOmHLXAAoJEATO+BI/yjfB7V8H+wdhIcXBKAfkyTNnWyj08AzT XkhR5LWbb/G/FF+Lgr9qBh0YGqbWJy7nPISGN38zIxerrt515SWOhP75k9B2kx45 MojrsDqDxxiU8p9JsuTayrt4t3mZ+mRIAOTvNLs5TL4Rkmuxr9YgJysHQDvk2OmS bslE1inEJ70tuu/NmvgxlZHgIsjgLTjuOOHxPK2rDznS/JYlp8pDznVl105kQR50 gt4AucI3/ovKGP5uscNLxHRVlau43FWzWTdOcWon183sbmmbwCrI9BmvQDYBaQLU SUT0iWVWC2R3/fVTVJVYjdYdlf9BDuenCK5VqLfLfHE6M2ZIWZvyMIvuqKvB6jE= =ETlJ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 17:38:18 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3C23106566B; Fri, 14 Oct 2011 17:38:18 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3A38FC13; Fri, 14 Oct 2011 17:38:18 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga-m.mahoroba.org [IPv6:2001:2f0:104:801c:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id p9EHc8QM081580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Oct 2011 02:38:12 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 15 Oct 2011 02:38:04 +0900 Message-ID: From: Hajimu UMEMOTO To: Hiroki Sato In-Reply-To: <20111014.170911.2032702506326503484.hrs@allbsd.org> References: <4E97CFFC.5020900@gibfest.dk> <20111014.151402.1498559224124829567.hrs@allbsd.org> <4E97D9F3.4020308@gibfest.dk> <20111014.170911.2032702506326503484.hrs@allbsd.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 15 Oct 2011 02:38:12 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: thomas@gibfest.dk, freebsd-current@FreeBSD.org Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 17:38:19 -0000 Hi, >>>>> On Fri, 14 Oct 2011 17:09:11 +0900 (JST) >>>>> Hiroki Sato said: hrs> Thomas Steen Rasmussen wrote hrs> in <4E97D9F3.4020308@gibfest.dk>: th> On 14.10.2011 08:14, Hiroki Sato wrote: hrs> th> > telnet www.freebsd.org 80 < /dev/null th> [tykling@tykburk ~]$ telnet www.freebsd.org 80 < /dev/null th> Trying 69.147.83.34... th> Connected to red.freebsd.org. th> Escape character is '^]'. th> Connection closed by foreign host. hrs> Thanks. There is no problem with the source address selection. The hrs> last questions are: hrs> % route get -inet www.freebsd.org hrs> % route get -inet6 www.freebsd.org hrs> % netstat -nrf inet6 hrs> % ndp -r hrs> I guess the second one returns "route: writing to routing socket: No hrs> such process" on your box. Is it correct? AFAIK, recent Firefox implements Happy Eyeballs. So, I suspect it doesn't obey RFC 3484, anymore. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 18:30:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 3D114106566C; Fri, 14 Oct 2011 18:30:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E4729150DD7; Fri, 14 Oct 2011 18:30:52 +0000 (UTC) Message-ID: <4E987FDC.10308@FreeBSD.org> Date: Fri, 14 Oct 2011 11:30:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: d@delphij.net References: <4E95B028.6090307@protected-networks.net> <4E976592.2060804@FreeBSD.org> <201110140735.52298.jhb@freebsd.org> <4E9872D7.7050905@delphij.net> In-Reply-To: <4E9872D7.7050905@delphij.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , Xin LI , FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 18:30:53 -0000 On 10/14/2011 10:35, Xin LI wrote: > On 10/14/11 04:35, John Baldwin wrote: >> On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: >>> On 10/12/2011 08:20, Michael Butler wrote: >>>> SVN r226302 solves the ichwd failure to attach issue .. >>> >>> Still failing for me: >>> >>> ichwd0: on isa0 >>> ichwd0: unable to reserve GCS registers >>> device_attach: ichwd0 attach returned 6 > >> Yes, it can only fix it if the BIOS decides to list it as a system resource in >> ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as >> a workaround for lying BIOSes yes? As I reported previously, that didn't work for me. I'll try it again next time I reboot JIC. FYI, I also have a Dell system, Optiplex 960. > I do have debug.acpi.disabled=hostres but it doesn't seem help in my > case (Dell Latitude D630): > > ichwd0: on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > ichwd0: at port 0x1030-0x1037,0x1060-0x107f > on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > > Is there something I should look at or additional information needed? > > Cheers, > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 18:53:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9FCC10656B0; Fri, 14 Oct 2011 18:53:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B07918FC22; Fri, 14 Oct 2011 18:53:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4B43B46B37; Fri, 14 Oct 2011 14:53:45 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D34E18A02F; Fri, 14 Oct 2011 14:53:44 -0400 (EDT) From: John Baldwin To: d@delphij.net Date: Fri, 14 Oct 2011 13:58:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E95B028.6090307@protected-networks.net> <201110140735.52298.jhb@freebsd.org> <4E9872D7.7050905@delphij.net> In-Reply-To: <4E9872D7.7050905@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110141358.28250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 14 Oct 2011 14:53:44 -0400 (EDT) Cc: Doug Barton , Michael Butler , FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 18:53:45 -0000 On Friday, October 14, 2011 1:35:19 pm Xin LI wrote: > On 10/14/11 04:35, John Baldwin wrote: > > On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: > >> On 10/12/2011 08:20, Michael Butler wrote: > >>> SVN r226302 solves the ichwd failure to attach issue .. > >> > >> Still failing for me: > >> > >> ichwd0: on isa0 > >> ichwd0: unable to reserve GCS registers > >> device_attach: ichwd0 attach returned 6 > > > > Yes, it can only fix it if the BIOS decides to list it as a system resource in > > ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as > > a workaround for lying BIOSes yes? > > I do have debug.acpi.disabled=hostres but it doesn't seem help in my > case (Dell Latitude D630): > > ichwd0: on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > ichwd0: at port 0x1030-0x1037,0x1060-0x107f > on isa0 > ichwd0: unable to reserve GCS registers > device_attach: ichwd0 attach returned 6 > > Is there something I should look at or additional information needed? Hmm, is your isab device behind a PCI-PCI bridge? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:03:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D748A106566C; Fri, 14 Oct 2011 19:03:01 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id B9E638FC1E; Fri, 14 Oct 2011 19:03:01 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 4B6B318C36; Fri, 14 Oct 2011 12:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1318618981; bh=RxeR8bbZTN2ftVSR1HvHQCQQh709bWD268DuE+RznIA=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ACX88RaHiu0c+DsJZoXuaIReeKWPAr6XlF3wLdd1I87W0Uwv5Ex55+WozyxXXYz3F l5A3GqBv9QGqRKhhjWpx3R699kZFrlm5DPTXPHzwVbPCNqjHBKSJ+gGSvKw/1f13mx JRiFI1ag8OGoIG/lpTb+w7bApO0zTF9HtXmPQQV8= Message-ID: <4E988764.2040904@delphij.net> Date: Fri, 14 Oct 2011 12:03:00 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: John Baldwin References: <4E95B028.6090307@protected-networks.net> <201110140735.52298.jhb@freebsd.org> <4E9872D7.7050905@delphij.net> <201110141358.28250.jhb@freebsd.org> In-Reply-To: <201110141358.28250.jhb@freebsd.org> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , Doug Barton , d@delphij.net, FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:03:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/14/11 10:58, John Baldwin wrote: > On Friday, October 14, 2011 1:35:19 pm Xin LI wrote: >> On 10/14/11 04:35, John Baldwin wrote: >>> On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: >>>> On 10/12/2011 08:20, Michael Butler wrote: >>>>> SVN r226302 solves the ichwd failure to attach issue .. >>>> >>>> Still failing for me: >>>> >>>> ichwd0: on isa0 ichwd0: unable >>>> to reserve GCS registers device_attach: ichwd0 attach >>>> returned 6 >>> >>> Yes, it can only fix it if the BIOS decides to list it as a >>> system resource in ACPI. However, using >>> 'debug.acpi.disabled=hostres' should still be working as a >>> workaround for lying BIOSes yes? >> >> I do have debug.acpi.disabled=hostres but it doesn't seem help in >> my case (Dell Latitude D630): >> >> ichwd0: on isa0 ichwd0: unable to >> reserve GCS registers device_attach: ichwd0 attach returned 6 >> ichwd0: at port >> 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS >> registers device_attach: ichwd0 attach returned 6 >> >> Is there something I should look at or additional information >> needed? > > Hmm, is your isab device behind a PCI-PCI bridge? Looks like it's not: pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 [...] isab0: at device 31.0 on pci0 isa0: on isab0 [...] ichwd0: on isa0 ichwd0: unable to reserve GCS registers nexus0 [...] acpi0 Interrupt request lines: 9 [...] pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2a00 subvendor=0x1028 subdevice=0x01f9 class=0x060000 at slot=0 function=0 pcib1 pnpinfo vendor=0x8086 device=0x2a01 subvendor=0x1028 subdevice=0x01f9 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.AGP_ I/O ports: 0xe000-0xefff I/O memory addresses: 0xe0000000-0xefffffff 0xf2000000-0xf6efffff pci1 vgapci0 pnpinfo vendor=0x10de device=0x042b subvendor=0x1028 subdevice=0x01f9 class=0x030000 at slot=0 function=0 handle=\_SB_.PCI0.AGP_.VID_ Interrupt request lines: 16 pcib1 I/O port window: 0xef00-0xef7f pcib1 memory window: 0xf2000000-0xf3ffffff 0xf5000000-0xf5ffffff pcib1 prefetch window: 0xe0000000-0xefffffff vgapm0 nvidia0 drm0 Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOmIdjAAoJEATO+BI/yjfBIcUH/jY7XImBpwLLlCxZub6G9rwR DhuxTPdGLF3lZTU1iGD+Ypdn15R1hjdA2FMKu88bFGAkBLWcmcrOThQoPv1f8mXf FOrKw2MMowpv/GO8kuGFADDZCoyXWRfdjIX9NNpTpcVgr/WxgSU+IFafSQpPm/dW nYjNVjCR8gbYvfTd6nHs12WZDFubs3qITOeRwboU51l60QlJgwIDe2FszP19RL7M RuAQZWdK7pqNdjdviGRxf0/IhZFLgrrJwtwAoO2bdMSat+qJan0F0vboR6KHfeTI YTJuw4zKDDuLSgMN7bBSgd+XEk/e28YSwOU6SaEUVWs+SaKTzhQgCeGKTc6YK5Q= =OibA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:15:38 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AE75106564A for ; Fri, 14 Oct 2011 19:15:38 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ixe-mta-27.emailfiltering.com (ixe-mta-27-tx.emailfiltering.com [194.116.199.158]) by mx1.freebsd.org (Postfix) with ESMTP id DDA098FC17 for ; Fri, 14 Oct 2011 19:15:37 +0000 (UTC) Received: from mail-gw5.york.ac.uk ([144.32.129.29]) by ixe-mta-27.emailfiltering.com with emfmta (version 4.8.5.33) by TLS id 1332817118 for ianf@clue.co.za;292b0507c9607bb3; Fri, 14 Oct 2011 19:58:10 +0100 Received: from ury.york.ac.uk ([144.32.108.81]:45018) by mail-gw5.york.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1REmxM-0007O6-6J; Fri, 14 Oct 2011 19:58:08 +0100 Received: from gavin (helo=localhost) by ury.york.ac.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1REmxM-0004SP-1a; Fri, 14 Oct 2011 19:58:08 +0100 Date: Fri, 14 Oct 2011 19:58:08 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Ian FREISLICH In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Cc: current@freebsd.org Subject: Re: 3 show-stopper issues with 9-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 19:15:38 -0000 On Wed, 5 Oct 2011, Ian FREISLICH wrote: > > In no particular order: It's a shame that nobody has yet picked up on this, it is a very useful list of bugs in 9.0. Is there any chance you could log these three issues as three separate PRs so that they don't get lost? Please tag them with [regression] in the subject if they are indeed regressions from a previous version (they sound like they are) so that they hopefully get onto the release engineering radar. > 1. bce(4) transmit and recieve ring buffer overruns > On a moderately busy router with a full BGP table and > aggregate throughput of between 200mbps and 800mbps, I get > these buffer overruns at an average rate of 28 per second > on the busiest interface. > > [firewall1.jnb1] ~ # sysctl dev.bce |grep com_no_buffers > dev.bce.0.com_no_buffers: 101 > dev.bce.1.com_no_buffers: 0 > dev.bce.2.com_no_buffers: 32547 > dev.bce.3.com_no_buffers: 444 > > I've tried increasing the TX_PAGES and RX_PAGES in > sys/dev/bce/if_bcereg.h as I've done in the past (to 64) > which is what resolved this problem on 8.2-STABLE to no avail. > It appears that there is a hard limit of 8 according to > bce_set_tunables() in if_bce.c. But no values to hw.bce.tx_pages > and hw.bce.rx_pages makes the slightest difference. > > 2. carp(4) on my backup router randomly takes over MASTER on the > standby host, but when ifconfig claims the carp interface > is master tcpdump shows that it's not broadcasting its > advertisement. The actual master still broadcasts and no > setting of advskew or advbase changes the 9-BETA host's > idea of who is actually master. I have to reboot the host > to reset the carp interfaces. destroying and re-creating > them just brings them up as backup for about a second and > then they regress to master. Is ipv6 involved in this? Do you have a couple of sample config files that I can drop onto two machines and recreate the issue, by any chance? > 3. PF doesn't expire state. The state table on my older host (pre > OpenBSD-4.5) has the following stats: > > Status: Enabled for 0 days 00:37:17 Debug: Urgent > State Table Total Rate > current entries 169546 > searches 94387451 42193.8/s > inserts 4012389 1793.6/s > removals 3842843 1717.9/s > > The 9-BETA3 host's current entries exactly match the number > of inserts until it hits the hard limit of 1.5M entries and > can add no more. It takes about 10 minutes to fill up and > then no new flows are routed. I've seen a few reports of this, and it's quite concerning. Please, can you submit this as a PR? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:22:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 74DB3106566C; Fri, 14 Oct 2011 19:22:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 06DD917A660; Fri, 14 Oct 2011 19:22:39 +0000 (UTC) Message-ID: <4E988BFF.1000802@FreeBSD.org> Date: Fri, 14 Oct 2011 12:22:39 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: d@delphij.net References: <4E95B028.6090307@protected-networks.net> <201110140735.52298.jhb@freebsd.org> <4E9872D7.7050905@delphij.net> <201110141358.28250.jhb@freebsd.org> <4E988764.2040904@delphij.net> In-Reply-To: <4E988764.2040904@delphij.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , Xin LI , FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 19:22:40 -0000 On 10/14/2011 12:03, Xin LI wrote: >> Hmm, is your isab device behind a PCI-PCI bridge? Me either: isab0: at device 31.0 on pci0 isa0: on isab0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:36:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEBF71065670 for ; Fri, 14 Oct 2011 19:36:46 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 79A7E8FC0C for ; Fri, 14 Oct 2011 19:36:46 +0000 (UTC) Received: by wwi18 with SMTP id 18so633465wwi.31 for ; Fri, 14 Oct 2011 12:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=nOF+PCgL21HspUKTbJmasesVwmVOfHdePKFN8C1n3v8=; b=KB4IVyfrlnPGru3xzeLv0v0d3BGVWuWul/vc5ymBWAZO23DDkmgPDEfqmqrNDTKqFd i+ldYYwRy4soFCz/NaFXLvf0x8GmeCuayN/FhWORR4X1SdIGBTaX5tTVlwzxmu32hjTN us1SFGOQE7wRbIC3gudfCF8onoGKnaZao3aak= MIME-Version: 1.0 Received: by 10.216.137.81 with SMTP id x59mr3284643wei.26.1318619436653; Fri, 14 Oct 2011 12:10:36 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Fri, 14 Oct 2011 12:10:36 -0700 (PDT) Date: Sat, 15 Oct 2011 00:40:36 +0530 X-Google-Sender-Auth: tvisJkRt_WnGfpvEjczlJmW-sic Message-ID: From: "Jayachandran C." To: Rafal Jaworowski , Marcel Moolenaar , FreeBSD Current Content-Type: multipart/mixed; boundary=0016e6d785301d9bdc04af470395 Cc: Subject: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 19:36:47 -0000 --0016e6d785301d9bdc04af470395 Content-Type: text/plain; charset=ISO-8859-1 I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. --0016e6d785301d9bdc04af470395 Content-Type: application/octet-stream; name="fdt-64-fix.patch" Content-Disposition: attachment; filename="fdt-64-fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gtrjnult0 Y29tbWl0IDMzMGVjM2ExMDZhNWFmZTliMWRmMTdmZmVkNzVjNzUyNWI0ZWRmMGIKQXV0aG9yOiBK YXlhY2hhbmRyYW4gQyA8amF5YWNoYW5kcmFuY0BuZXRsb2dpY21pY3JvLmNvbT4KRGF0ZTogICBX ZWQgT2N0IDEyIDEzOjA5OjI1IDIwMTEgKzA1MzAKCiAgICBGaXggRkRUIGNvZGUgZm9yIDY0IGJp dAogICAgCiAgICBVc2UgdGhlIG9mZnNldCBpbnRvIHRoZSBkZXZpY2UgdHJlZSBmcm9tIGZkdHAg YXMgdGhlIHBoYW5kbGUgaW5zdGVhZAogICAgb2YgdXNpbmcgcG9pbnRlciBpbnRvIHRoZSBkZXZp Y2UgdHJlZS4gIFRoaXMgd2lsbCBtYWtlIHN1cmUgIHRoYXQKICAgIHBoYW5kbGUgZml0cyBpbnRv IGEgdWludDMyX3QgdHlwZS4KCmRpZmYgLS1naXQgYS9zeXMvZGV2L29mdy9vZndfZmR0LmMgYi9z eXMvZGV2L29mdy9vZndfZmR0LmMKaW5kZXggNjhkMzE0OS4uZjljY2MzMiAxMDA2NDQKLS0tIGEv c3lzL2Rldi9vZncvb2Z3X2ZkdC5jCisrKyBiL3N5cy9kZXYvb2Z3L29md19mZHQuYwpAQCAtMTEy LDE5ICsxMTIsMzkgQEAgb2Z3X2ZkdF9pbml0KG9md190IG9mdywgdm9pZCAqZGF0YSkKICAqIERl dmljZSB0cmVlIGZ1bmN0aW9ucwogICovCiAKK3N0YXRpYyBwaGFuZGxlX3QKK2ZkdF9vZmZzZXRf cGhhbmRsZShpbnQgb2Zmc2V0KQoreworCWlmIChvZmZzZXQgPCAwKQorCQlyZXR1cm4gKDApOwor CXJldHVybiAoKHBoYW5kbGVfdClvZmZzZXQgKyBmZHRfb2ZmX2R0X3N0cnVjdChmZHRwKSk7Cit9 CisKIHN0YXRpYyBpbnQKIGZkdF9waGFuZGxlX29mZnNldChwaGFuZGxlX3QgcCkKIHsKLQljb25z dCBjaGFyICpkdF9zdHJ1Y3Q7CisJaW50IHBpbnQgPSAoaW50KXA7CisJaW50IGR0b2ZmID0gZmR0 X29mZl9kdF9zdHJ1Y3QoZmR0cCk7CisKKwlpZiAocGludCA8IGR0b2ZmKQorCQlyZXR1cm4gKC0x KTsKKwlyZXR1cm4gKHBpbnQgLSBkdG9mZik7Cit9CisKK3N0YXRpYyBpbnQKK2ZkdF9wb2ludGVy X29mZnNldChjb25zdCB2b2lkICpwdHIpCit7CisJdWludHB0cl90IGR0X3N0cnVjdCwgcDsKIAlp bnQgb2Zmc2V0OwogCi0JZHRfc3RydWN0ID0gKGNvbnN0IGNoYXIgKilmZHRwICsgZmR0X29mZl9k dF9zdHJ1Y3QoZmR0cCk7CisJcCA9ICh1aW50cHRyX3QpcHRyOworCWR0X3N0cnVjdCA9ICh1aW50 cHRyX3QpZmR0cCArIGZkdF9vZmZfZHRfc3RydWN0KGZkdHApOwogCi0JaWYgKCgoY29uc3QgY2hh ciAqKXAgPCBkdF9zdHJ1Y3QpIHx8Ci0JICAgIChjb25zdCBjaGFyICopcCA+IChkdF9zdHJ1Y3Qg KyBmZHRfc2l6ZV9kdF9zdHJ1Y3QoZmR0cCkpKQorCWlmICgocCA8IGR0X3N0cnVjdCkgfHwKKwkg ICAgcCA+IChkdF9zdHJ1Y3QgKyBmZHRfc2l6ZV9kdF9zdHJ1Y3QoZmR0cCkpKQogCQlyZXR1cm4g KC0xKTsKIAotCW9mZnNldCA9IChjb25zdCBjaGFyICopcCAtIGR0X3N0cnVjdDsKKwlvZmZzZXQg PSBwIC0gZHRfc3RydWN0OwogCWlmIChvZmZzZXQgPCAwKQogCQlyZXR1cm4gKC0xKTsKIApAQCAt MTM1LDE1ICsxNTUsMTMgQEAgZmR0X3BoYW5kbGVfb2Zmc2V0KHBoYW5kbGVfdCBwKQogc3RhdGlj IHBoYW5kbGVfdAogb2Z3X2ZkdF9wZWVyKG9md190IG9mdywgcGhhbmRsZV90IG5vZGUpCiB7Ci0J cGhhbmRsZV90IHA7CiAJaW50IGRlcHRoLCBvZmZzZXQ7CiAKIAlpZiAobm9kZSA9PSAwKSB7CiAJ CS8qIEZpbmQgcm9vdCBub2RlICovCiAJCW9mZnNldCA9IGZkdF9wYXRoX29mZnNldChmZHRwLCAi LyIpOwotCQlwID0gKHBoYW5kbGVfdClmZHRfb2Zmc2V0X3B0cihmZHRwLCBvZmZzZXQsIHNpemVv ZihwKSk7CiAKLQkJcmV0dXJuIChwKTsKKwkJcmV0dXJuIChmZHRfb2Zmc2V0X3BoYW5kbGUob2Zm c2V0KSk7CiAJfQogCiAJb2Zmc2V0ID0gZmR0X3BoYW5kbGVfb2Zmc2V0KG5vZGUpOwpAQCAtMTU1 LDEwICsxNzMsOCBAQCBvZndfZmR0X3BlZXIob2Z3X3Qgb2Z3LCBwaGFuZGxlX3Qgbm9kZSkKIAkg ICAgb2Zmc2V0ID0gZmR0X25leHRfbm9kZShmZHRwLCBvZmZzZXQsICZkZXB0aCkpIHsKIAkJaWYg KGRlcHRoIDwgMCkKIAkJCXJldHVybiAoMCk7Ci0JCWlmIChkZXB0aCA9PSAxKSB7Ci0JCQlwID0g KHBoYW5kbGVfdClmZHRfb2Zmc2V0X3B0cihmZHRwLCBvZmZzZXQsIHNpemVvZihwKSk7Ci0JCQly ZXR1cm4gKHApOwotCQl9CisJCWlmIChkZXB0aCA9PSAxKQorCQkJcmV0dXJuIChmZHRfb2Zmc2V0 X3BoYW5kbGUob2Zmc2V0KSk7CiAJfQogCiAJcmV0dXJuICgwKTsKQEAgLTE2OCw3ICsxODQsNiBA QCBvZndfZmR0X3BlZXIob2Z3X3Qgb2Z3LCBwaGFuZGxlX3Qgbm9kZSkKIHN0YXRpYyBwaGFuZGxl X3QKIG9md19mZHRfY2hpbGQob2Z3X3Qgb2Z3LCBwaGFuZGxlX3Qgbm9kZSkKIHsKLQlwaGFuZGxl X3QgcDsKIAlpbnQgZGVwdGgsIG9mZnNldDsKIAogCW9mZnNldCA9IGZkdF9waGFuZGxlX29mZnNl dChub2RlKTsKQEAgLTE4MCwxMCArMTk1LDggQEAgb2Z3X2ZkdF9jaGlsZChvZndfdCBvZncsIHBo YW5kbGVfdCBub2RlKQogCSAgICBvZmZzZXQgPSBmZHRfbmV4dF9ub2RlKGZkdHAsIG9mZnNldCwg JmRlcHRoKSkgewogCQlpZiAoZGVwdGggPCAwKQogCQkJcmV0dXJuICgwKTsKLQkJaWYgKGRlcHRo ID09IDEpIHsKLQkJCXAgPSAocGhhbmRsZV90KWZkdF9vZmZzZXRfcHRyKGZkdHAsIG9mZnNldCwg c2l6ZW9mKHApKTsKLQkJCXJldHVybiAocCk7Ci0JCX0KKwkJaWYgKGRlcHRoID09IDEpCisJCQly ZXR1cm4gKGZkdF9vZmZzZXRfcGhhbmRsZShvZmZzZXQpKTsKIAl9CiAKIAlyZXR1cm4gKDApOwpA QCAtMTkzLDcgKzIwNiw2IEBAIG9md19mZHRfY2hpbGQob2Z3X3Qgb2Z3LCBwaGFuZGxlX3Qgbm9k ZSkKIHN0YXRpYyBwaGFuZGxlX3QKIG9md19mZHRfcGFyZW50KG9md190IG9mdywgcGhhbmRsZV90 IG5vZGUpCiB7Ci0JcGhhbmRsZV90IHA7CiAJaW50IG9mZnNldCwgcGFyb2Zmc2V0OwogCiAJb2Zm c2V0ID0gZmR0X3BoYW5kbGVfb2Zmc2V0KG5vZGUpOwpAQCAtMjAxLDE1ICsyMTMsMTMgQEAgb2Z3 X2ZkdF9wYXJlbnQob2Z3X3Qgb2Z3LCBwaGFuZGxlX3Qgbm9kZSkKIAkJcmV0dXJuICgwKTsKIAog CXBhcm9mZnNldCA9IGZkdF9wYXJlbnRfb2Zmc2V0KGZkdHAsIG9mZnNldCk7Ci0JcCA9IChwaGFu ZGxlX3QpZmR0X29mZnNldF9wdHIoZmR0cCwgcGFyb2Zmc2V0LCBzaXplb2YocGhhbmRsZV90KSk7 Ci0JcmV0dXJuIChwKTsKKwlyZXR1cm4gKGZkdF9vZmZzZXRfcGhhbmRsZShwYXJvZmZzZXQpKTsK IH0KIAogLyogUmV0dXJuIHRoZSBwYWNrYWdlIGhhbmRsZSB0aGF0IGNvcnJlc3BvbmRzIHRvIGFu IGluc3RhbmNlIGhhbmRsZS4gKi8KIHN0YXRpYyBwaGFuZGxlX3QKIG9md19mZHRfaW5zdGFuY2Vf dG9fcGFja2FnZShvZndfdCBvZncsIGloYW5kbGVfdCBpbnN0YW5jZSkKIHsKLQlwaGFuZGxlX3Qg cDsKIAlpbnQgb2Zmc2V0OwogCiAJLyoKQEAgLTIyMyw4ICsyMzMsNyBAQCBvZndfZmR0X2luc3Rh bmNlX3RvX3BhY2thZ2Uob2Z3X3Qgb2Z3LCBpaGFuZGxlX3QgaW5zdGFuY2UpCiAJaWYgKG9mZnNl dCA8IDApCiAJCXJldHVybiAoLTEpOwogCi0JcCA9IChwaGFuZGxlX3QpZmR0X29mZnNldF9wdHIo ZmR0cCwgb2Zmc2V0LCBzaXplb2YocGhhbmRsZV90KSk7Ci0JcmV0dXJuIChwKTsKKwlyZXR1cm4g KGZkdF9vZmZzZXRfcGhhbmRsZShvZmZzZXQpKTsKIH0KIAogLyogR2V0IHRoZSBsZW5ndGggb2Yg YSBwcm9wZXJ0eSBvZiBhIHBhY2thZ2UuICovCkBAIC0zNDMsNyArMzUyLDcgQEAgb2Z3X2ZkdF9u ZXh0cHJvcChvZndfdCBvZncsIHBoYW5kbGVfdCBwYWNrYWdlLCBjb25zdCBjaGFyICpwcmV2aW91 cywgY2hhciAqYnVmLAogCWlmIChwcm9wID09IE5VTEwpCiAJCXJldHVybiAoLTEpOwogCi0Jb2Zm c2V0ID0gZmR0X3BoYW5kbGVfb2Zmc2V0KChwaGFuZGxlX3QpcHJvcCk7CisJb2Zmc2V0ID0gZmR0 X3BvaW50ZXJfb2Zmc2V0KHByb3ApOwogCXJ2ID0gZmR0X25leHRwcm9wKG9mZnNldCwgYnVmLCBz aXplKTsKIAlyZXR1cm4gKHJ2KTsKIH0KQEAgLTM3NCwxNCArMzgzLDEwIEBAIG9md19mZHRfY2Fu b24ob2Z3X3Qgb2Z3LCBjb25zdCBjaGFyICpkZXZpY2UsIGNoYXIgKmJ1Ziwgc2l6ZV90IGxlbikK IHN0YXRpYyBwaGFuZGxlX3QKIG9md19mZHRfZmluZGRldmljZShvZndfdCBvZncsIGNvbnN0IGNo YXIgKmRldmljZSkKIHsKLQlwaGFuZGxlX3QgcDsKIAlpbnQgb2Zmc2V0OwogCiAJb2Zmc2V0ID0g ZmR0X3BhdGhfb2Zmc2V0KGZkdHAsIGRldmljZSk7Ci0KLQlwID0gKHBoYW5kbGVfdClmZHRfb2Zm c2V0X3B0cihmZHRwLCBvZmZzZXQsIHNpemVvZihwKSk7Ci0KLQlyZXR1cm4gKHApOworCXJldHVy biAoZmR0X29mZnNldF9waGFuZGxlKG9mZnNldCkpOwogfQogCiAvKiBSZXR1cm4gdGhlIGZ1bGx5 IHF1YWxpZmllZCBwYXRobmFtZSBjb3JyZXNwb25kaW5nIHRvIGFuIGluc3RhbmNlLiAqLwo= --0016e6d785301d9bdc04af470395-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 19:43:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7720106564A; Fri, 14 Oct 2011 19:43:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BE3F28FC12; Fri, 14 Oct 2011 19:43:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7005546B3C; Fri, 14 Oct 2011 15:43:00 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0BEAA8A02E; Fri, 14 Oct 2011 15:43:00 -0400 (EDT) From: John Baldwin To: d@delphij.net Date: Fri, 14 Oct 2011 15:39:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E95B028.6090307@protected-networks.net> <201110141358.28250.jhb@freebsd.org> <4E988764.2040904@delphij.net> In-Reply-To: <4E988764.2040904@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110141539.58847.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 14 Oct 2011 15:43:00 -0400 (EDT) Cc: Doug Barton , Michael Butler , FreeBSD Current Subject: Re: Fixed: ichwd failure to attach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 19:43:01 -0000 On Friday, October 14, 2011 3:03:00 pm Xin LI wrote: > On 10/14/11 10:58, John Baldwin wrote: > > On Friday, October 14, 2011 1:35:19 pm Xin LI wrote: > >> On 10/14/11 04:35, John Baldwin wrote: > >>> On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: > >>>> On 10/12/2011 08:20, Michael Butler wrote: > >>>>> SVN r226302 solves the ichwd failure to attach issue .. > >>>> > >>>> Still failing for me: > >>>> > >>>> ichwd0: on isa0 ichwd0: unable > >>>> to reserve GCS registers device_attach: ichwd0 attach > >>>> returned 6 > >>> > >>> Yes, it can only fix it if the BIOS decides to list it as a > >>> system resource in ACPI. However, using > >>> 'debug.acpi.disabled=hostres' should still be working as a > >>> workaround for lying BIOSes yes? > >> > >> I do have debug.acpi.disabled=hostres but it doesn't seem help in > >> my case (Dell Latitude D630): > >> > >> ichwd0: on isa0 ichwd0: unable to > >> reserve GCS registers device_attach: ichwd0 attach returned 6 > >> ichwd0: at port > >> 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS > >> registers device_attach: ichwd0 attach returned 6 > >> > >> Is there something I should look at or additional information > >> needed? > > > > Hmm, is your isab device behind a PCI-PCI bridge? > > Looks like it's not: Hmm, the NEW_PCIB bits only affect two things: 1) Resource allocation for devices behind PCI-PCI bridges, and 2) Resource allocation for devices behind Host-PCI bridges (but debug.acpi.disabled="hostres" should turn that off). I'll see if I can't look in my old thread to see why the allocations are failing. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 20:04:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id BCB821065675; Fri, 14 Oct 2011 20:04:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 25C81151C1A; Fri, 14 Oct 2011 20:04:15 +0000 (UTC) Message-ID: <4E9895BE.6050808@FreeBSD.org> Date: Fri, 14 Oct 2011 13:04:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <4E97CFFC.5020900@gibfest.dk> <20111014.151402.1498559224124829567.hrs@allbsd.org> <4E97D9F3.4020308@gibfest.dk> <20111014.170911.2032702506326503484.hrs@allbsd.org> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: thomas@gibfest.dk, freebsd-current@FreeBSD.org, Hiroki Sato Subject: Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces="YES" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 20:04:15 -0000 On 10/14/2011 10:38, Hajimu UMEMOTO wrote: > AFAIK, recent Firefox implements Happy Eyeballs. So, I suspect it > doesn't obey RFC 3484, anymore. My understanding is that they added it, then turned it off because it didn't work as expected. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 20:04:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A19010656DA; Fri, 14 Oct 2011 20:04:27 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9075E8FC17; Fri, 14 Oct 2011 20:04:26 +0000 (UTC) Received: from vhoffman-macbooklocal.local ([10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id p9EK4LJK025364 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 14 Oct 2011 21:04:21 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4E9895C5.7030402@unsane.co.uk> Date: Fri, 14 Oct 2011 21:04:21 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Gavin Atkinson References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , current@freebsd.org Subject: Re: 3 show-stopper issues with 9-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 20:04:27 -0000 On 14/10/2011 19:58, Gavin Atkinson wrote: >> > 3. PF doesn't expire state. The state table on my older host (pre >> > OpenBSD-4.5) has the following stats: >> > >> > Status: Enabled for 0 days 00:37:17 Debug: Urgent >> > State Table Total Rate >> > current entries 169546 >> > searches 94387451 42193.8/s >> > inserts 4012389 1793.6/s >> > removals 3842843 1717.9/s >> > >> > The 9-BETA3 host's current entries exactly match the number >> > of inserts until it hits the hard limit of 1.5M entries and >> > can add no more. It takes about 10 minutes to fill up and >> > then no new flows are routed. > I've seen a few reports of this, and it's quite concerning. Please, can > you submit this as a PR? For tracking, this was a previous report with apparently a temporary workaround. http://lists.freebsd.org/pipermail/freebsd-pf/2011-October/006333.html I have a stable-9 virtual machine i can test on if needed but I have pf loaded as a module at the moment so dont have the issue. Vince From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 20:31:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2147106564A for ; Fri, 14 Oct 2011 20:31:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 830808FC16 for ; Fri, 14 Oct 2011 20:31:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LT200H00P0QD200@smtpauth3.wiscmail.wisc.edu>; Fri, 14 Oct 2011 15:31:38 -0500 (CDT) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LT200GDTP0PYB00@smtpauth3.wiscmail.wisc.edu>; Fri, 14 Oct 2011 15:31:37 -0500 (CDT) Date: Fri, 14 Oct 2011 15:31:36 -0500 From: Nathan Whitehorn In-reply-to: To: "Jayachandran C." Message-id: <4E989C28.3030606@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.14.202121, SenderIP=128.104.160.176 References: User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.22) Gecko/20110913 Thunderbird/3.1.14 Cc: Rafal Jaworowski , Marcel Moolenaar , FreeBSD Current Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 20:31:39 -0000 On 10/14/11 14:10, Jayachandran C. wrote: > I'm planning commit this -CURRENT if there an no objections. > > In the current implementation, phandle is used to store a pointer to > the location inside the device tree. Since phandle_t is u32, this > will not work on 64 bit platforms. With this fix, the phandle is the > offset from the start of device tree pointer 'fdtp', which will be 32 > bit. > > Review or testing from device tree users will be welcome. > > JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. -Nathan From owner-freebsd-current@FreeBSD.ORG Fri Oct 14 23:03:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 723E6106566B for ; Fri, 14 Oct 2011 23:03:03 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7AA8FC15 for ; Fri, 14 Oct 2011 23:03:03 +0000 (UTC) Received: by iaky10 with SMTP id y10so4071889iak.13 for ; Fri, 14 Oct 2011 16:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cu3pMx87yfu/6JHFA0VVaIDp8aVh8OFj8CSh745Cdmc=; b=sfpvQmghI83lOsB1gKTgHPBI5MuZeKEu6QjJDGcjHuEJPjR8vQe1BBUv24AWJh2qXa gLqcb0IyhHI29CVtAidH8qrIstje+vPhAHQYF90q5TIsHCOvQkA71f0nqGS5oTLmkaNz F+t/iSuplzLIiZ6umqlj50Ui6iYARvH1c0Htw= MIME-Version: 1.0 Received: by 10.43.130.133 with SMTP id hm5mr19655673icc.11.1318631562060; Fri, 14 Oct 2011 15:32:42 -0700 (PDT) Received: by 10.231.36.13 with HTTP; Fri, 14 Oct 2011 15:32:41 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Oct 2011 01:32:41 +0300 Message-ID: From: George Kontostanos To: Pavel Timofeev Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: x.0 RELASE isn't for production. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Oct 2011 23:03:03 -0000 On Fri, Oct 14, 2011 at 10:55 AM, Pavel Timofeev wrote: > That's what most people think. > I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be > longer. Six months, for example. > New STABLE branch is very important! IMHO different OS releases (Unix or not) are usually at the state of FreeBSD current regarding stability. FreeBSD late BETA and early RC are usually very stable. Therefore the approximate one month period between the first beta and the release is adequate time. Many users are reluctant to follow stable because they have to go through the wolrd && kernel procedure. Since freebsd-update exists as a means of binary upgrading a system through releases, I don't think that it would be a bad idea to be able to use is for stable as well. Let's assume that we would have monthly minor releases something like 9.0.1, 9.0.2 etc. That could ease the fear of .0 release. This is coming from someone who is using current all the time for workstations and stable for production servers and never uses freebsd-update! Best Regards -- George Kontostanos aisecure.net From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 06:12:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EFD2106564A; Sat, 15 Oct 2011 06:12:57 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D42888FC15; Sat, 15 Oct 2011 06:12:56 +0000 (UTC) Received: by wwi18 with SMTP id 18so1025900wwi.31 for ; Fri, 14 Oct 2011 23:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uv6eYispsUOxoGt2E9up5p+Ne+bDiU2VDyxJE0rOZ8I=; b=S7DYkp0H7kfvXjAc8MCcCjvYyjQPww1+JE8JqAtDTTpQNVKNlaD9baKcuavJw0LGCG ASx0xTYholri4fkHQ0qQEzp4ifhw6wmaQ2Hta6JVqJlCNV/QL870c2gwWSQqs5gp9flO fSGMNahKgezxI2jETd/nfrg3WG1S5luRWhzgk= MIME-Version: 1.0 Received: by 10.216.138.82 with SMTP id z60mr946208wei.11.1318659175698; Fri, 14 Oct 2011 23:12:55 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Fri, 14 Oct 2011 23:12:55 -0700 (PDT) In-Reply-To: <4E989C28.3030606@freebsd.org> References: <4E989C28.3030606@freebsd.org> Date: Sat, 15 Oct 2011 11:42:55 +0530 X-Google-Sender-Auth: s94nUBujAOEZi-RfSfjJXFRmuUo Message-ID: From: "Jayachandran C." To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rafal Jaworowski , Marcel Moolenaar , FreeBSD Current Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 06:12:57 -0000 On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn wrote: > On 10/14/11 14:10, Jayachandran C. wrote: >> >> I'm planning commit this -CURRENT if there an no objections. >> >> In the current implementation, phandle is used to store a pointer to >> the location inside the device tree. =A0Since phandle_t is u32, this >> will not work on 64 bit platforms. With this fix, the phandle is the >> offset from the start of device tree pointer 'fdtp', which will be 32 >> bit. >> >> Review or testing from device tree users will be welcome. >> >> JC. > > Why not use offsets into the FDT rather than full pointers? I believe hav= ing > phandles greater than 32 bits violates the FDT spec, and declaring that t= he > FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. JC. From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 07:32:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52B25106564A for ; Sat, 15 Oct 2011 07:32:10 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4948FC16 for ; Sat, 15 Oct 2011 07:32:09 +0000 (UTC) Received: (qmail 12572 invoked from network); 15 Oct 2011 07:32:08 -0000 Received: from pd9ec0540.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.5.64]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 15 Oct 2011 07:32:08 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id 1DF451BAC55; Sat, 15 Oct 2011 09:32:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1318663926; bh=SfRbMTSVKIH610Nxt6n1qMNl4WEnhedQ5eRICGN/qrk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: Mime-Version:Content-Type; b=i+R7FevUFusnqNVjDBZeh5djYnAAT5XcICRn/L1p7/BGdVVd1UjWJnAIuZgrQD+3h B8efTl6h0+GZOMGT/QEv7NwMwybsjaxmVeNUmWBBXi3S0+UPSKUTmhF/iU/5zLmfiJ BszGOkhe+i9p2090voePf0M8kIexluh53WUtrslQ= Date: Sat, 15 Oct 2011 09:31:59 +0200 From: Martin Sugioarto To: Pavel Timofeev Message-ID: <20111015093159.3679afd6@zelda.sugioarto.com> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/U3MQ=pQ2=FAG7WVLIWO1Npc"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org Subject: Re: x.0 RELASE isn't for production. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 07:32:10 -0000 --Sig_/U3MQ=pQ2=FAG7WVLIWO1Npc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 14 Oct 2011 11:55:28 +0400 schrieb Pavel Timofeev : > That's what most people think. Hi! I'm not thinking this. This is made up by users who only adapt slowly to changes and features. Look at the whole crowd which got furious about the new Microsoft Office. I tell you, in one year, no one will cry about it anymore. Sometimes, I feel like I am the only who is happy about good ideas, even when they change something drastically. The most people think "Whoa... I have to learn again!"... and then silently accept it when it is very late, because everyone else already migrated. This has nothing to do with release quality, because the efforts to make a production release of x.0 are much higher, in my opinion. So the quality is generally better, if you have enough time to make this release. For me the worst FreeBSD release ever was 5.3. Even 5.0 BETAs worked better on my hardware. I also stopped using FreeBSD at that time until 7.0 BETAs arrived. =20 > And when BETA/RC time comes users rush like mad to test it. And they > find errors and bugs. Writing PR, emails and even !pathes! > But the lion's share of these pathes doesn't get into the coming BETA > or RC. Yes. I'm waiting for my /sbin/dump fix to get verified and committed. It's really disappointing to see the next release without a functioning backup possibility (for my configuration here). Fortunately, I don't see a fixed release date, yet. I hope the developers fix as much as possible even when we see 9.0R in late 2012. -- Martin --Sig_/U3MQ=pQ2=FAG7WVLIWO1Npc Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJOmTb0AAoJEF8wvLx/5p/7IR4P/30qa/tSOaxvp4XzS9AnvBvX mflwXznlgvkMycgNYWBHF7mny9ky94WMniIKYXRRSxwpx88I+9Z8dVG4TmbmScN6 OAeaUNDaCVQB128SOxISwv+NxiaL6ldzXItjXPWWrpvNe+QVpNo+kih3RG6PeI1K zM0fxgJ/u5QZK2DdsglWIwNQrpkZsuiAFiV91nNdsJ8kCIyWd5UxIa1mGOJR/99k J0rmgFLk7ualIJ7B8pWpAcxBWJFl0V/ZcryHdeEwgafHBMJRDnLUj0466jSexqHX yWPOoyxRdb/YunoUbOj3KELxAThrMDmpW8BAwdOB8nE1fLvOD5Paq0o0/5bL7vwm qvocrKm3yCGZyw6T8toUmkAE3tYTMnx2z4Dx+KWvl0vkdH+ilEiFi4FZvAmVhPfS KvUbnolYJ+H0m2hylyqN/e6ZURt7pTrUQZ2lesmUMn00/bQ08zoylRdGxsKKQL2B kaZwVVu1PtxWyE0ymZSxyn0h4kNWk7WJXvorXN6JwjMi+sAHj7elx2TDttgClu8L ieJFDuntGCfTcXZYWBCUT/E576CBdcaMOusnCxOnVfgf4lkGBai77UKbPWvPUhv+ sNpteBCTfLiFiMCbO7WlVOnGGfukCk372rbKHAvdqUiBUaFCPYR2rmGkTVZ8BF74 iIWcHtXsOzhvy95rMZYd =C/QQ -----END PGP SIGNATURE----- --Sig_/U3MQ=pQ2=FAG7WVLIWO1Npc-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 09:22:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFB371065672 for ; Sat, 15 Oct 2011 09:22:59 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost04.isp.att.net (fmailhost04.isp.att.net [204.127.217.104]) by mx1.freebsd.org (Postfix) with ESMTP id DC8558FC13 for ; Sat, 15 Oct 2011 09:22:59 +0000 (UTC) Date: Sat, 15 Oct 2011 09:17:33 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-210-187-7.sdf.bellsouth.net[68.210.187.7]) by isp.att.net (frfwmhc04) with SMTP id <20111015091732H0400ir6nde>; Sat, 15 Oct 2011 09:17:32 +0000 X-Originating-IP: [68.210.187.7] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: Message-Id: <20111015092259.EFB371065672@hub.freebsd.org> Cc: Pavel Timofeev , George Kontostanos Subject: Re: x.0 RELASE isn't for production. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 09:23:00 -0000 > MHO different OS releases (Unix or not) are usually at the state of > FreeBSD current regarding stability. FreeBSD late BETA and early RC > are usually very stable. Therefore the approximate one month period > between the first beta and the release is adequate time. I see your point, especially after installing NetBSD on my new computer and having big problems, like not being able to startx or not neing able to boot at all. On the old computer, I also had big problems with NetBSD, including release, stable and current versions. Building FreeBSD or NetBSD from source might be not feasible on older computers short on RAM and/or disk space. There are more frequent current FreeBSD snapshots available on http://pub.allbsd.org/pub/FreeBSD-snapshots/ This site also has snapshots for other BSDs. Tom From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 10:49:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057CE106566C for ; Sat, 15 Oct 2011 10:49:52 +0000 (UTC) (envelope-from genre.roger@orange.fr) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) by mx1.freebsd.org (Postfix) with ESMTP id 640BB8FC0A for ; Sat, 15 Oct 2011 10:49:50 +0000 (UTC) Received: from P5E-WS.home ([90.25.195.186]) by mwinf5d33 with ME id kyKm1h00241mEVm03yKmPZ; Sat, 15 Oct 2011 12:19:47 +0200 X-ME-engine: default Message-ID: <4E995EA5.5050505@orange.fr> Date: Sat, 15 Oct 2011 12:21:25 +0200 From: Roger Genre User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; fr-FR; rv:1.9.1.16) Gecko/20110328 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ohartman@zedat.fu-berlin.de Subject: Re: 9.x installer and GPT vs geom, features in bsdinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 10:49:52 -0000 On 10/13/11, Oliver Hartman wrote: > On 10/13/11 10:39, Johan Hendriks wrote: >> > Hello all. >> > >> > I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. >> > However, and there has been some discussions about it, it would be nice >> > if the installer warns me that i could get in trouble if i want to use >> > gmirror and the like. >> > >> > Also i find it a little strange that the default mode, GPT in this case >> > is in some sort not compatible with the other default geom structure. >> > For a newcomer or for people who use gmirror and glabel on a regular >> > basis because there somewhat default, it could strike them if they start >> > using the default GPT. >> > >> > It is not logical. >> > Two default ways to do things that are in a way not compatible. >> > >> > So a warning at the installer level could make a lot of users aware of >> > this, and they can decide what to do, use GPT or go back to the old MBR. >> > They can start looking at the mailling list and so on to make the right >> > decision is GPT acceptable for me or not. >> > And not install FreeBSD and find out later that you could not use your >> > old gmirror and glabel tactics without corrupting the GPT structure. >> > >> > Just my thoughts about this. >> > >> > regards, >> > Johan Hendriks >> > >> > Shouldn't be there also a warning that GPT can not be used with the > FreeBSD native bootselector? I had trouble installing FreeBSD > 9.0-CURRENT a while ago with default being GPT on my notebook and also > wanting a Windows 7/x64 for presentations, selectable via the FreeBSD > bootselector. This was possible with MBR, but it seems gone with GPT. > > > Regards, > Oliver > GPT shouldn't be installed with ANY bootselector present on the same device ! But, I noticed that when installing 9.0B1 on 2nd slice of a MBR disk (1st slice with 8.2), using "expert" mode in Bsdinstall, (so selecting a MBR installation), I did not have the expected choice (like in sysinstall) between a MBR bootloader, a standard MBR , or "don't touch to bootsector"; (no damage for me, as my bootselector --grub--is installed on a separate disk dedicated to rescue and booting, allowing me to be more safe when testing newer releases); could this usefull previous choice be merged in Bsdinstall ? Later, I installed the 9.0B3 on a free disk, using the "guided" mode in Bsdinstall, and selecting an GPT installation, that worked fine; but I found very few differences between "guided" and "expert" mode (both require a minimal expertise). The use of "auto" choice would be too more documented, instead of letting the user to "see what will happen" ?. I agree with the suggestion to introduce warnings in the installer itself, against the most dangerous incompatibilities, between gpt and geom, or whatever that could appear during the beta testing; but more generally the question is : what level of information need to be present in the installation medium, apart of the installer, allowing non-expert to succed installation whit a minimum of mistakes; it is obvious that having a look on the mailing lists BEFORE to begin is very helpfull, and a digest of the most important threads could appear as a README-1st or an installation-FAQ with the proper comments, at the ordinary-user level? Regards Roger From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 11:40:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035BB106566C; Sat, 15 Oct 2011 11:40:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id B648B8FC08; Sat, 15 Oct 2011 11:40:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1RF2bd-0004eo-Q6>; Sat, 15 Oct 2011 13:40:45 +0200 Received: from e178015218.adsl.alicedsl.de ([85.178.15.218] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1RF2bd-0007eD-N0>; Sat, 15 Oct 2011 13:40:45 +0200 Message-ID: <4E99713D.9000707@zedat.fu-berlin.de> Date: Sat, 15 Oct 2011 13:40:45 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111013 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current , freebsd-questions@FreeBSD.ORG Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.15.218 Cc: Subject: portsnap fails: look: tINDEX.new: File too large X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 11:40:50 -0000 Since today's morning I receive on every box this message shown below while doing a 'portsnap fetch'. What's wrong and how to repair? Regards, Oliver Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. look: tINDEX.new: File too large Portsnap metadata appears bogus. Cowardly refusing to proceed any further. From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 15:13:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C262106564A; Sat, 15 Oct 2011 15:13:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 40D928FC17; Sat, 15 Oct 2011 15:13:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LT400G004YIJD00@smtpauth3.wiscmail.wisc.edu>; Sat, 15 Oct 2011 10:13:30 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-76-208-70-34.dsl.mdsnwi.sbcglobal.net [76.208.70.34]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LT4009KG4YHMB10@smtpauth3.wiscmail.wisc.edu>; Sat, 15 Oct 2011 10:13:30 -0500 (CDT) Date: Sat, 15 Oct 2011 10:13:29 -0500 From: Nathan Whitehorn In-reply-to: To: "Jayachandran C." Message-id: <4E99A319.20801@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.208.70.34 X-Spam-PmxInfo: Server=avs-14, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.15.150015, SenderIP=76.208.70.34 References: <4E989C28.3030606@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 Cc: Rafal Jaworowski , Marcel Moolenaar , FreeBSD Current Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 15:13:31 -0000 On 10/15/11 01:12, Jayachandran C. wrote: > On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn > wrote: >> On 10/14/11 14:10, Jayachandran C. wrote: >>> I'm planning commit this -CURRENT if there an no objections. >>> >>> In the current implementation, phandle is used to store a pointer to >>> the location inside the device tree. Since phandle_t is u32, this >>> will not work on 64 bit platforms. With this fix, the phandle is the >>> offset from the start of device tree pointer 'fdtp', which will be 32 >>> bit. >>> >>> Review or testing from device tree users will be welcome. >>> >>> JC. >> Why not use offsets into the FDT rather than full pointers? I believe having >> phandles greater than 32 bits violates the FDT spec, and declaring that the >> FDT can't itself be larger than 4 GB seems reasonable. > I am actually using the offset from the beginning of FDT (fdtp) as > phandle. I cannot use the usual fdt offset (after off_dt_struct) as > phandle, because in that case offset of 0 is valid, but phandle 0 > should not be valid. Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one of the problems with our existing FDT code -- it makes all kinds of wrong assumptions like this about IEEE 1275. -Nathan From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 16:33:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA2EF106564A; Sat, 15 Oct 2011 16:33:06 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0288FC15; Sat, 15 Oct 2011 16:33:05 +0000 (UTC) Received: by wwi18 with SMTP id 18so1406299wwi.31 for ; Sat, 15 Oct 2011 09:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pI1eEBl/0LpQ/1OnaWUj22ELIHWRyXBgzVVJtcbFG00=; b=EXofEtCTXvapQ62NM+YzwIEOi0SJSYsAJUrsRutkGN8fdi1sSBubDw4RuFXRVAAOyn kevlvLY591GgMRrLWJSXZ9ENvGpudhKYAEd5fQ61w0gR7SHgI8p1ahrOIBZmh66vE3Ph 8gs1BGeleJyhRaUohVjciz1WRDuJm9iqvkVWM= MIME-Version: 1.0 Received: by 10.216.135.207 with SMTP id u57mr1506321wei.56.1318696384883; Sat, 15 Oct 2011 09:33:04 -0700 (PDT) Sender: c.jayachandran@gmail.com Received: by 10.216.188.3 with HTTP; Sat, 15 Oct 2011 09:33:04 -0700 (PDT) In-Reply-To: <4E99A319.20801@freebsd.org> References: <4E989C28.3030606@freebsd.org> <4E99A319.20801@freebsd.org> Date: Sat, 15 Oct 2011 22:03:04 +0530 X-Google-Sender-Auth: DYuotYzwOGrdsM_UEK6w_-6lxcQ Message-ID: From: "Jayachandran C." To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rafal Jaworowski , Marcel Moolenaar , FreeBSD Current Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 16:33:06 -0000 On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn wrote: > On 10/15/11 01:12, Jayachandran C. wrote: >> >> On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn >> =A0wrote: >>> >>> On 10/14/11 14:10, Jayachandran C. wrote: >>>> >>>> I'm planning commit this -CURRENT if there an no objections. >>>> >>>> In the current implementation, phandle is used to store a pointer to >>>> the location inside the device tree. =A0Since phandle_t is u32, this >>>> will not work on 64 bit platforms. With this fix, the phandle is the >>>> offset from the start of device tree pointer 'fdtp', which will be 32 >>>> bit. >>>> >>>> Review or testing from device tree users will be welcome. >>>> >>>> JC. >>> >>> Why not use offsets into the FDT rather than full pointers? I believe >>> having >>> phandles greater than 32 bits violates the FDT spec, and declaring that >>> the >>> FDT can't itself be larger than 4 GB seems reasonable. >> >> I am actually using the offset from the beginning of FDT (fdtp) as >> phandle. =A0I cannot use the usual fdt offset (after off_dt_struct) as >> phandle, because in that case offset of 0 is valid, but phandle 0 >> should not be valid. > > Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one = of > the problems with our existing FDT code -- it makes all kinds of wrong > assumptions like this about IEEE 1275. Well, the existing FDT code returns 0 as the invalid handle and I do not want to change that in this commit. If the return value is really wrong, we will need a bigger exercise to change the return value and fix any callers which are affected by that change. JC. From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 16:48:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 135B2106564A; Sat, 15 Oct 2011 16:48:26 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id AF8CD8FC12; Sat, 15 Oct 2011 16:48:25 +0000 (UTC) Received: from [172.23.7.198] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p9FGmEY5039838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Oct 2011 09:48:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: Date: Sat, 15 Oct 2011 09:48:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82FC5404-7B93-426B-9303-14BD8BC37542@xcllnt.net> References: <4E989C28.3030606@freebsd.org> <4E99A319.20801@freebsd.org> To: "Jayachandran C." X-Mailer: Apple Mail (2.1244.3) Cc: Rafal Jaworowski , FreeBSD Current , Nathan Whitehorn , Andrew Duane Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 16:48:26 -0000 On Oct 15, 2011, at 9:33 AM, Jayachandran C. wrote: > On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn > wrote: >> On 10/15/11 01:12, Jayachandran C. wrote: >>>=20 >>> On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn >>> wrote: >>>>=20 >>>> On 10/14/11 14:10, Jayachandran C. wrote: >>>>>=20 >>>>> I'm planning commit this -CURRENT if there an no objections. >>>>>=20 >>>>> In the current implementation, phandle is used to store a pointer = to >>>>> the location inside the device tree. Since phandle_t is u32, this >>>>> will not work on 64 bit platforms. With this fix, the phandle is = the >>>>> offset from the start of device tree pointer 'fdtp', which will be = 32 >>>>> bit. >>>>>=20 >>>>> Review or testing from device tree users will be welcome. >>>>>=20 >>>>> JC. >>>>=20 >>>> Why not use offsets into the FDT rather than full pointers? I = believe >>>> having >>>> phandles greater than 32 bits violates the FDT spec, and declaring = that >>>> the >>>> FDT can't itself be larger than 4 GB seems reasonable. >>>=20 >>> I am actually using the offset from the beginning of FDT (fdtp) as >>> phandle. I cannot use the usual fdt offset (after off_dt_struct) as >>> phandle, because in that case offset of 0 is valid, but phandle 0 >>> should not be valid. >>=20 >> Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is = one of >> the problems with our existing FDT code -- it makes all kinds of = wrong >> assumptions like this about IEEE 1275. >=20 > Well, the existing FDT code returns 0 as the invalid handle and I do > not want to change that in this commit. >=20 > If the return value is really wrong, we will need a bigger exercise to > change the return value and fix any callers which are affected by that > change. It should be fairly easy to change the base from fdtp to the "usual" fdt offset, so let me propose the following: 1. JC commits what he has and based on the current code. 2. We get all the facts on the table. I say this because I read different and contradictory things (0 being an invalid phandle in OF, negative phandles exist, etc). 3. We change the implementation, if such is warranted, in a separate effort. The point really is that 0 is an invalid phandle right now, right or wrong, and JCs changes are based on that. I see no problem proceeding on the path we're on, while we discuss what's the correct implementation and whether or not we should have a course change... Thoughts? --=20 Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 17:12:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3A99106566B; Sat, 15 Oct 2011 17:12:16 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 289438FC16; Sat, 15 Oct 2011 17:12:15 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id E592BD9C47; Sat, 15 Oct 2011 18:55:25 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id SMT8po5yKUqL; Sat, 15 Oct 2011 18:55:25 +0200 (CEST) Received: from [10.0.0.112] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id C51D2D9C42; Sat, 15 Oct 2011 18:55:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <82FC5404-7B93-426B-9303-14BD8BC37542@xcllnt.net> Date: Sat, 15 Oct 2011 18:55:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E989C28.3030606@freebsd.org> <4E99A319.20801@freebsd.org> <82FC5404-7B93-426B-9303-14BD8BC37542@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) Cc: "Jayachandran C." , FreeBSD Current , Nathan Whitehorn , Andrew Duane Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 17:12:16 -0000 On 2011-10-15, at 18:48, Marcel Moolenaar wrote: >=20 > On Oct 15, 2011, at 9:33 AM, Jayachandran C. wrote: >=20 >> On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn >> wrote: >>> On 10/15/11 01:12, Jayachandran C. wrote: >>>>=20 >>>> On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn >>>> wrote: >>>>>=20 >>>>> On 10/14/11 14:10, Jayachandran C. wrote: >>>>>>=20 >>>>>> I'm planning commit this -CURRENT if there an no objections. >>>>>>=20 >>>>>> In the current implementation, phandle is used to store a pointer = to >>>>>> the location inside the device tree. Since phandle_t is u32, = this >>>>>> will not work on 64 bit platforms. With this fix, the phandle is = the >>>>>> offset from the start of device tree pointer 'fdtp', which will = be 32 >>>>>> bit. >>>>>>=20 >>>>>> Review or testing from device tree users will be welcome. >>>>>>=20 >>>>>> JC. >>>>>=20 >>>>> Why not use offsets into the FDT rather than full pointers? I = believe >>>>> having >>>>> phandles greater than 32 bits violates the FDT spec, and declaring = that >>>>> the >>>>> FDT can't itself be larger than 4 GB seems reasonable. >>>>=20 >>>> I am actually using the offset from the beginning of FDT (fdtp) as >>>> phandle. I cannot use the usual fdt offset (after off_dt_struct) = as >>>> phandle, because in that case offset of 0 is valid, but phandle 0 >>>> should not be valid. >>>=20 >>> Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is = one of >>> the problems with our existing FDT code -- it makes all kinds of = wrong >>> assumptions like this about IEEE 1275. >>=20 >> Well, the existing FDT code returns 0 as the invalid handle and I do >> not want to change that in this commit. >>=20 >> If the return value is really wrong, we will need a bigger exercise = to >> change the return value and fix any callers which are affected by = that >> change. >=20 > It should be fairly easy to change the base from fdtp to the "usual" > fdt offset, so let me propose the following: >=20 > 1. JC commits what he has and based on the current code. > 2. We get all the facts on the table. I say this because I > read different and contradictory things (0 being an > invalid phandle in OF, negative phandles exist, etc). > 3. We change the implementation, if such is warranted, in > a separate effort. >=20 > The point really is that 0 is an invalid phandle right now, > right or wrong, and JCs changes are based on that. I see no > problem proceeding on the path we're on, while we discuss > what's the correct implementation and whether or not we > should have a course change... >=20 > Thoughts? The patch looks fine to me, but we didn't have a chance yet to test it = on any PPC/ARM system, have you, Marcel? Regarding the phandle validity = I need to recall the context as this was a while back and I don't quite = remember all constraints and motivations. Rafal From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 20:09:28 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C36D106564A for ; Sat, 15 Oct 2011 20:09:28 +0000 (UTC) (envelope-from chmiels@o2.pl) Received: from moh1-ve2.go2.pl (moh1-ve2.go2.pl [193.17.41.132]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1438FC0C for ; Sat, 15 Oct 2011 20:09:27 +0000 (UTC) Received: from moh1-ve2.go2.pl (unknown [10.0.0.132]) by moh1-ve2.go2.pl (Postfix) with ESMTP id E389A104400F for ; Sat, 15 Oct 2011 22:09:22 +0200 (CEST) Received: from unknown (unknown [10.0.0.108]) by moh1-ve2.go2.pl (Postfix) with SMTP for ; Sat, 15 Oct 2011 22:09:22 +0200 (CEST) Received: from mail-gy0-f182.google.com [209.85.160.182] by poczta.o2.pl with ESMTP id rlvfUC; Sat, 15 Oct 2011 22:11:06 +0200 Received: by gyd8 with SMTP id 8so2621865gyd.13 for ; Sat, 15 Oct 2011 13:09:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.86.232 with SMTP id s8mr7687767obz.58.1318709358696; Sat, 15 Oct 2011 13:09:18 -0700 (PDT) Received: by 10.182.48.9 with HTTP; Sat, 15 Oct 2011 13:09:18 -0700 (PDT) In-Reply-To: <20110913073153.0a66866f@o2.pl> References: <20110913073153.0a66866f@o2.pl> Date: Sat, 15 Oct 2011 22:09:18 +0200 Message-ID: From: Sebastian Chmielewski To: freebsd-current@freebsd.org X-O2-Trust: 2, 61 X-O2-SPF: neutral Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: -CURRENT (BETA1) zfs pool recognized as corrupted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chmiels@o2.pl List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 20:09:28 -0000 Currently I have a strange situation when I have running system on my zroot but I can't import this pool when booted from memstick. I was trying to understand what is going on and here are my observations. My partition table is: gpart show -l => 34 250069613 ada0 GPT (119G) 34 128 1 (null) (64k) 162 1886 5 (null) (943k) 2048 16777216 2 linux0 (8.0G) 16779264 33554432 3 home0 (16G) 50333696 199735951 4 disk0 (95G) but in /dev/gpt I only see: ls /dev/gpt/* /dev/gpt/home0 /dev/gpt/home0.eli /dev/gpt/linux0 (home is encrypted). I have a regular system installed and running on this pool. Filesystem to boot from is called 'zroot' and it can only boot when my whole loader.conf is used. With only zfs.ko booting stops with boot prompt asking for filesystem to boot from, menu shows all my gpt partitions and id's correctly so I don't understand why it can't find it. Below is my loader.conf: # Kernel Options kern.ipc.shmseg=1024 kern.ipc.shmmni=1024 kern.maxproc=10000 # GEOM encrypted device geom_eli_load="YES" geom_label_load="YES" geom_mbr_load="YES" # Intel System management bus smb_load="YES" smbus_load="YES" ichsmb_load="YES" ichwd_load="YES" # Use AHCI instead of ataahci ahci_load="YES" # AHCI deprecated ataahci #ataahci_load="NO" ataintel_load="YES" # Intel HDA sound driver snd_hda_load="YES" # PS/2 Mouse psm_load="NO" # USB ehci_load="YES" ohci_load="YES" uhci_load="YES" # USB mouse ums_load="YES" # POSIX Semaphores # Required by Firefox sem_load="YES" # ACPI drivers acpi_load="YES" acpi_video_load="YES" acpi_ibm_load="YES" acpi_dock_load="YES" # Linuxulator linux_load="YES" # Linux specific pseudo-devices lindev_load="YES" # Bluetooth driver ng_ubt_load="YES" # Intel Centrino driver iwn6000fw_load="YES" iwn6050fw_load="YES" if_iwn_load="YES" # Realtek driver if_re_load="YES" # Intel wireless driver #if_wpi_load="YES" legal.intel_ipw.license_ack=1 legal.intel_iwi.license_ack=1 legal.intel_wpi.license_ack=1 legal.intel_iwn.license_ack=1 # Virtualbox driver (kmod) vboxdrv_load="YES" # ATAPICAM module # required to write DVD atapicam_load="YES" # USB Printer # required by HP D2360 ulpt_load="NO" ugen_load="YES" # Network pseudo-interface which supports failover if_lagg_load="YES" # Joystick support joy_load="YES" # Thermal sensor for Core2 Duo coretemp_load="YES" # Be verbose on ACPI hw.acpi.verbose="1" hw.acpi.reset_video="0" debug.acpi.resume_beep="1" # Firewire drivers firewire_load="YES" fwe_load="YES" fwip_load="YES" # PF firewall driver, # be carefull, when enabled it disables all network traffic, even ping ipfw_load="NO" pf_load="NO" # Trusted Platform Module tpm_load="YES" # TMPFS driver # I'm using mdmfs for /tmp now tmpfs_load="NO" # Boot splash screen #hint.sc.0.flags=0x0180 #hint.sc.0.vesa_mode=0x0118 loader_logo="beastie" #vesa_load="YES" #splash_pcx_load="YES" #bitmap_load="YES" #bitmap_name="/boot/splash.pcx" # Kernel debugger through firewire and dcons dcons_load="YES" dcons_gdb=1 dcons_crom_load="YES" boot_multicons="YES" hw.firewire.phydma_enable=1 #hw.firewire.dcons_crom.force_console=1 # ZFS driver and settings zfs_load="YES" # Disable ZFS prefetching # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html # Increases overall speed of ZFS, but when disk flushing/writes occur, # system is less responsive (due to extreme disk I/O). # NOTE: 8.0-RC1 disables this by default on systems <= 4GB RAM anyway vfs.zfs.prefetch_disable=1 # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. #vm.kmem_size="512M" #vm.kmem_size_max="1024M" #vfs.zfs.arc_max="100M" # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html #vfs.zfs.zio.use_uma="0" # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the "bursty" stalls that # happen during immense I/O with ZFS. # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout="5" # WebCam and DVB support cuse4bsd_load="YES" # Memory Stick and SD Card controller mmc_load="YES" mmcsd_load="YES" sdhci_load="YES" # 3G modem card u3g_load="YES" # Load File-System Support libiconv_load="YES" libmchain_load="YES" cd9660_iconv_load="YES" msdosfs_iconv_load="YES" ntfs_load="NO" ntfs_iconv_load="NO" udf_load="YES" udf_iconv_load="YES" # Desktop optimizations # see http://forums.freebsd.org/showthread.php?p=123657#post123657 # boot delay autoboot_delay=10 beastie_disable="NO" # page share factor per proc vm.pmap.shpgperproc=512 # open files kern.maxfiles=49312 kern.maxfilesperproc=16384 # avoid additional 128 interrupts per second per core hint.atrtc.0.clock=0 # do not power devices without driver hw.pci.do_power_nodriver=3 # reduce sound generated interrupts hint.pcm.0.buffersize=65536 hint.pcm.1.buffersize=65536 hint.pcm.2.buffersize=65536 hw.snd.feeder_buffersize=65536 hw.snd.latency=7 # ahci power management # check: dmesg | grep ahcich hint.ahcich.0.pm_level=5 hint.ahcich.1.pm_level=5 hint.ahcich.2.pm_level=5 hint.ahcich.3.pm_level=5 # Disable throttling, use C2 instead (in rc.conf) #hint.p4tcc.0.disabled=1 #hint.acpi_throttle.0.disabled=1 # To increase inactivity periods we should reduce interrupt rate as much as possible by adding to loader.conf # http://wiki.freebsd.org/TuningPowerConsumption kern.hz=100 # Enable support for synaptics touchpad hw.psm.synaptics_support="1" debug.psm.loglevel="1" # ZFS Root file system vfs.root.mountfrom="zfs:zroot" 2011/9/13 Sebastian Chmielewski > On Wed, 7 Sep 2011 23:55:23 +0200 > Sebastian Chmielewski wrote: > > > hi > > I've tried to import my zfs pool on: > > FreeBSD-9.0-BETA1-amd64-memstick.img > > My system currently runs 9.0-BETA1 and pool works correctly. > > zpool import returns: > > > > pool: zroot > > id: 3239789026273107181 > > state: FAULTED > > status: One or more devices contains corrupted data. > > action: The pool cannot be imported due to damaged devices or data. > > The pool may be active on another system, but can be imported using > > the '-f' flag. > > see: http://www.sun.com/msg/ZFS-8000-5E > > config: > > > > zroot FAULTED corrupted data > > 9327291201483595311 UNAVAIL corrupted data > > > > The same symptoms are for FreeBSD-9.0-BETA2-amd64-memstick.img. > > Andriy Gapon suggests that it's the same as issue described in this thread, > http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024888.html > I've checked that mounting root and importing pool from command line > doesn't > work. > Pool can be imported and used on 8.2 and I'm running 9.0 r225439M, only > when > booted from memstick I can't import it. > > best regards, > -- > Sebastian Chmielewski * jid:chmielsster@gmail.com * gg:3336919 * > icq:224161389 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 20:56:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A6A106564A; Sat, 15 Oct 2011 20:56:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id BAE268FC08; Sat, 15 Oct 2011 20:56:17 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9FKuG07091132; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9FKuGRK091131; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius) Date: Sat, 15 Oct 2011 22:56:16 +0200 From: Marius Strobl To: current@freebsd.org, net@freebsd.org, stable@freebsd.org Message-ID: <20111015205616.GL39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014203226.GA16192@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: Subject: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 20:56:18 -0000 Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 20:57:47 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E76E106566B; Sat, 15 Oct 2011 20:57:47 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from core.impulsive.hu (core.impulsive.hu [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id A145C8FC1D; Sat, 15 Oct 2011 20:57:46 +0000 (UTC) Received: by core.impulsive.hu (Postfix, from userid 143) id 7C652DC0F8; Sat, 15 Oct 2011 20:58:38 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by core.impulsive.hu (Postfix) with ESMTP id 39412DC0BC for ; Sat, 15 Oct 2011 20:58:36 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C9EFD16463C; Sat, 15 Oct 2011 20:56:32 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D7B2C10657DF; Sat, 15 Oct 2011 20:56:31 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A6A106564A; Sat, 15 Oct 2011 20:56:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id BAE268FC08; Sat, 15 Oct 2011 20:56:17 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9FKuG07091132; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9FKuGRK091131; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius) Date: Sat, 15 Oct 2011 22:56:16 +0200 From: Marius Strobl To: current@freebsd.org, net@freebsd.org, stable@freebsd.org Message-ID: <20111015205616.GL39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014203226.GA16192@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Subject: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-current@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: Sat, 15 Oct 2011 20:57:47 -0000 Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 22:02:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C83A7106566B; Sat, 15 Oct 2011 22:02:18 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7FA008FC08; Sat, 15 Oct 2011 22:02:18 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 269826AD3B; Sat, 15 Oct 2011 23:45:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id diOzTFomYuqe; Sat, 15 Oct 2011 23:45:47 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn189.78-99-200.t-com.sk [78.99.200.189]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id B02E86AD18; Sat, 15 Oct 2011 23:45:47 +0200 (CEST) Message-ID: <4E99FF0B.6080101@FreeBSD.org> Date: Sat, 15 Oct 2011 23:45:47 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.24pre) Gecko/20111009 Lanikai/3.1.16pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: Call for FreeBSD Status Reports - 3Q/2011 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 15 Oct 2011 22:02:18 -0000 Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2011 were due on October 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports as soon as possible, so that we can compile the report in a timely fashion. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo