From owner-freebsd-current@FreeBSD.ORG Sun May 26 00:53:02 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA3EDF31 for ; Sun, 26 May 2013 00:53:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 9002815C for ; Sun, 26 May 2013 00:53:02 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id 16so15782028iea.31 for ; Sat, 25 May 2013 17:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aYSpbisi8sMh9vXu3ep4YoCloW76BLQ391KbWjm86h8=; b=U/OwzGPVuV1I0G2BNkUi1hVa96+SyEKs2YPK0jKCIDnoL6vU+LjYfnY74dWROFaX8X uXbNN+6rVlvvLHxHqDlArERdKm33KwR11QYhVVrnY396eMmXtqUTFEod8PUZIZyfByDn lPlo6jIfa9QNH7LsNmTaLl0mSepORKTp42LkOdxwkq9x7/RdtfhFkfqlb7b6K5/B0vqk HZ1eDbb9O908r/3ES/AuZddiy2IYXI6lsSFrcwl+JANDsL7cGbLHjF2THBya/MhSa/QS BIGsVDZUEyUT0jTmXB4hsNdlFb521D16KjHMRydfiHPDHF/NS9yevpg7UC0Eb6Ms0nRL cY6g== MIME-Version: 1.0 X-Received: by 10.42.168.198 with SMTP id x6mr15258252icy.45.1369529581998; Sat, 25 May 2013 17:53:01 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.253.129 with HTTP; Sat, 25 May 2013 17:53:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 May 2013 02:53:01 +0200 X-Google-Sender-Auth: _x-tPpz0aj41jSOVoRfEuTWc1Kk Message-ID: Subject: Re: Incorrect comparison of ticks in deadlkres From: Attilio Rao To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , arao@freebsd.og X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@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, 26 May 2013 00:53:02 -0000 On Sat, May 25, 2013 at 11:55 PM, Ryan Stone wrote: > Currently deadlkres performs the following comparison when trying to check > for threads that have been blocked on a mutex or sleeping on an sx lock: > > if (TD_ON_LOCK(td) && ticks < td->td_blktick) { > /* check for deadlock...*/ Yes the check looks indeed inverted. > > > The test against ticks is incorrect. It results in deadlkres only > signaling a deadlock after ticks has rolled over; at 1000 hz this will take > up to 49 days. From looking at the history of the code this test appears > to be a attempt to deal with ticks rollover. However this is necessary; > later on the code calculates the amount of time that has passed with: > tticks = ticks - td->td_blktick; > > ticks was designed to exploit integer underflow in the case of rollover to > guarantee that subtraction produces correct results in all cases (other > than a double rollover, of course). I am going to remove the two incorrect > tests unless somebody can point out a overflow/underflow case that I > haven't considered. I'm not sure I follow what are you saying. Assume that when thread td goes to sleep, ticks is very close to the 32 bits limit. Then thread td goes to sleep and td->td_blktick is set to a value very close to 32 bits limits. After a while deadlkres thread kicks in and in the while "ticks" counter overflowed, rolling back to a very low value. How are you supposed to compute a valid value from this situation? I think that you need to still guard about overflow of ticks for such cases. Additively, if you really want to improve deadlkres, you should bring into the logic a fix for the adaptive spinning. Think about the schematic LOR case. Because of the adaptive spinning what will happen is that 2 threads getting a deadlock on 2 different locks will just end up spinning. I think you should import some sort of checks just like spinmutexes do, but with much higher time threshhold. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun May 26 02:34:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D2A9FB5; Sun, 26 May 2013 02:34:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EF6FE352; Sun, 26 May 2013 02:34:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r4Q2YKJu061676; Sat, 25 May 2013 22:34:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r4Q2YKh1061671; Sun, 26 May 2013 02:34:20 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 26 May 2013 02:34:20 GMT Message-Id: <201305260234.r4Q2YKh1061671@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 02:34:31 -0000 TB --- 2013-05-26 00:41:35 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-26 00:41:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-26 00:41:35 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-26 00:41:35 - cleaning the object tree TB --- 2013-05-26 00:43:02 - /usr/local/bin/svn stat /src TB --- 2013-05-26 00:43:06 - At svn revision 250991 TB --- 2013-05-26 00:43:07 - building world TB --- 2013-05-26 00:43:07 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 00:43:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 00:43:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 00:43:07 - SRCCONF=/dev/null TB --- 2013-05-26 00:43:07 - TARGET=ia64 TB --- 2013-05-26 00:43:07 - TARGET_ARCH=ia64 TB --- 2013-05-26 00:43:07 - TZ=UTC TB --- 2013-05-26 00:43:07 - __MAKE_CONF=/dev/null TB --- 2013-05-26 00:43:07 - cd /src TB --- 2013-05-26 00:43:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun May 26 00:43:15 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 26 02:14:09 UTC 2013 TB --- 2013-05-26 02:14:09 - generating LINT kernel config TB --- 2013-05-26 02:14:09 - cd /src/sys/ia64/conf TB --- 2013-05-26 02:14:09 - /usr/bin/make -B LINT TB --- 2013-05-26 02:14:09 - cd /src/sys/ia64/conf TB --- 2013-05-26 02:14:09 - /usr/sbin/config -m LINT TB --- 2013-05-26 02:14:09 - building LINT kernel TB --- 2013-05-26 02:14:09 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 02:14:09 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 02:14:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 02:14:09 - SRCCONF=/dev/null TB --- 2013-05-26 02:14:09 - TARGET=ia64 TB --- 2013-05-26 02:14:09 - TARGET_ARCH=ia64 TB --- 2013-05-26 02:14:09 - TZ=UTC TB --- 2013-05-26 02:14:09 - __MAKE_CONF=/dev/null TB --- 2013-05-26 02:14:09 - cd /src TB --- 2013-05-26 02:14:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 26 02:14:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-26 02:34:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-26 02:34:20 - ERROR: failed to build LINT kernel TB --- 2013-05-26 02:34:20 - 5433.59 user 888.88 system 6765.48 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun May 26 13:33:21 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B36D3FED; Sun, 26 May 2013 13:33:21 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id A0C1A825; Sun, 26 May 2013 13:33:21 +0000 (UTC) Received: from [10.0.10.1] ([173.88.196.224]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 May 2013 06:33:13 -0700 Message-ID: <51A20F19.4080807@a1poweruser.com> Date: Sun, 26 May 2013 09:33:13 -0400 From: Joe User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Alexander Leidinger Subject: Re: A PRIV_* flag for /dev/mem? References: <5196818F.8080201@FreeBSD.org> <20130518114357.GK3047@kib.kiev.ua> <519783C1.2010601@FreeBSD.org> <20130525220710.000041b5@unknown> In-Reply-To: <20130525220710.000041b5@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2013 13:33:13.0984 (UTC) FILETIME=[928CD800:01CE5A15] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: Konstantin Belousov , FreeBSD Current , Jamie Gritton X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 13:33:21 -0000 Alexander Leidinger wrote: > On Sat, 18 May 2013 07:36:01 -0600 > Jamie Gritton wrote: > >> On 05/18/13 05:43, Konstantin Belousov wrote: >>> On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote: >>>> I'm considering Alexander Leidinger's patch to make X11 work >>>> inside a jail >>>> (http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It >>>> allows a jail to optionally have access to /dev/io and DRI >>>> (provided the requisite device files are visible in the devfs >>>> ruleset). >>>> >>>> I'm planning on putting this under a single jail permission, which >>>> would group those two together as device access that allows >>>> messing with kernel memory. It seems more complete to >>>> put /dev/mem under that same umbrella, with the side benefit of >>>> letting me call it "allow.dev_mem". >>>> >>>> Currently, access is controlled only by device file permission and >>>> a securelevel check. Jail access is allowed as long as >>>> the /dev/mem is in the jail's ruleset (it isn't by default). >>>> Adding a prison_priv_check() call would allow some finer control >>>> over this. Something like: >>>> >>>> int >>>> memopen(struct cdev *dev __unused, int flags, int fmt __unused, >>>> struct thread *td) >>>> { >>>> int error; >>>> >>>> error = priv_check(td, PRIV_FOO); >>>> if (error != 0&& (flags& FWRITE)) >>>> error = securelevel_gt(td->td_ucred, 0); >>>> >>>> return (error); >>>> } >>>> >>>> The main question I'm coming up with here is, what PRIV_* flag >>>> should I use. Does PRIV_IO make sense? PRIV_DRIVER? Something >>>> new like PRIV_KMEM? Also, I'd appreciate if anyone familiar with >>>> this interface can tell me if memopen() is the right/only place to >>>> make this change. >>> Why do we need the PRIV check there at all, esp. for DRM ? >>> Why the devfs rulesets are not enough ? >> At least for the reason Alexander's patch was first made, X11 working >> inside a jail, there's already a need to get past PRIV_IO and >> PRIV_DRIVER - those checks are already made so in that case the >> presence of device files isn't sufficient. His solution was to >> special-case PRIV_DRIVER for drm, and then add jail permission bits >> that allowed PRIV_IO and PRIV_DRI_DRIVER. A largish but apparently >> arbitrary set of of devices use PRIV_DRIVER, so it makes sense to >> separate out this one that's necessary. >> >> So while there may be a question as to why /dev/io and DRM should have >> PRIV checks, the fact of the matter is they already do. >> >> Now as to the change I'm considering: kmem. Since the main danger of >> the existing checks (io and drm) is that they can allow you to stomp >> on kernel memory, I thought it reasonable to combine them into a >> single jail flag that allowed that behavior. In coming up with a >> succinct name for it, I decided on allow.dev_mem (permission for >> devices that work with system memory), and that brought up the >> question for /dev/mem. No, I don't need to add a priv check to it; >> but it seems that if such checks as PRIV_IO and PRIV_DRIVER exist for > > Info: > I spoke with the author of the dri1 driver loooong ago, and it was OK > for him if I would change the PRIV_DRIVER in DRI to something else. > >> devices already, then an architectural decision has already been made >> that device file access isn't the only level of control we'd like to >> have. Really I'm surprised something as potentially damaging as kmem >> didn't already have a priv_check associated with it. >> >> Now I could certainly add his patch with no changes (or with very >> few), and just put in a jail flag that's X11-specific. The /dev/mem > > I wouldn't be happy if my patch is committed as is. Your suggestion > sounds much better. > > I would suggest "allow.kmem" or "allow.kmem_devs". The reason is that > "dev_mem" could be seen as "/dev/mem" only. > >> change isn't necessary to this, but it just seemed a good time to add >> something that feels like a hole in the paradigm. > > Bye, > Alexander. > I have 2 comments on this subject. If I understand correctly, all the names being suggested are for an internal flag name. What it's called internally does not interest me. But using the internal flag name as the jail(8) parameter name would be misleading and confusing. The single purpose of this patch is to enable xorg to run in a jail. Naming it after some internal nob that the patch tweaks makes no sense. Naming it "allow.xorg" identifies it's intended purpose in a user-friendly way and is crystal clear to every one no matter their level of technical knowledge. Correct me if I am wrong here, but what this patch does internally breaks the security of the jail container. There are already jail(8) parameters that do this, so this is not new. I strongly suggest that the documentation on this new parameter contains strong wording that informs the reader of this security exposure and that it should NOT be used on a jail exposed to public internet access. From owner-freebsd-current@FreeBSD.ORG Sun May 26 13:48:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72BB5561; Sun, 26 May 2013 13:48:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB5A8BE; Sun, 26 May 2013 13:48:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r4QDmW9w031666; Sun, 26 May 2013 09:48:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r4QDmWLc031658; Sun, 26 May 2013 13:48:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 26 May 2013 13:48:32 GMT Message-Id: <201305261348.r4QDmWLc031658@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 13:48:36 -0000 TB --- 2013-05-26 11:55:22 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-26 11:55:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-26 11:55:22 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-26 11:55:22 - cleaning the object tree TB --- 2013-05-26 11:56:55 - /usr/local/bin/svn stat /src TB --- 2013-05-26 11:56:58 - At svn revision 250994 TB --- 2013-05-26 11:56:59 - building world TB --- 2013-05-26 11:56:59 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 11:56:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 11:56:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 11:56:59 - SRCCONF=/dev/null TB --- 2013-05-26 11:56:59 - TARGET=ia64 TB --- 2013-05-26 11:56:59 - TARGET_ARCH=ia64 TB --- 2013-05-26 11:56:59 - TZ=UTC TB --- 2013-05-26 11:56:59 - __MAKE_CONF=/dev/null TB --- 2013-05-26 11:56:59 - cd /src TB --- 2013-05-26 11:56:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun May 26 11:57:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun May 26 13:28:10 UTC 2013 TB --- 2013-05-26 13:28:10 - generating LINT kernel config TB --- 2013-05-26 13:28:10 - cd /src/sys/ia64/conf TB --- 2013-05-26 13:28:10 - /usr/bin/make -B LINT TB --- 2013-05-26 13:28:11 - cd /src/sys/ia64/conf TB --- 2013-05-26 13:28:11 - /usr/sbin/config -m LINT TB --- 2013-05-26 13:28:11 - building LINT kernel TB --- 2013-05-26 13:28:11 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 13:28:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 13:28:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 13:28:11 - SRCCONF=/dev/null TB --- 2013-05-26 13:28:11 - TARGET=ia64 TB --- 2013-05-26 13:28:11 - TARGET_ARCH=ia64 TB --- 2013-05-26 13:28:11 - TZ=UTC TB --- 2013-05-26 13:28:11 - __MAKE_CONF=/dev/null TB --- 2013-05-26 13:28:11 - cd /src TB --- 2013-05-26 13:28:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 26 13:28:11 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-26 13:48:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-26 13:48:31 - ERROR: failed to build LINT kernel TB --- 2013-05-26 13:48:31 - 5437.93 user 885.52 system 6788.98 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun May 26 15:40:56 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B481C7D1 for ; Sun, 26 May 2013 15:40:56 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2C270 for ; Sun, 26 May 2013 15:40:56 +0000 (UTC) Received: from glorfindel.gritton.org (c-24-10-224-248.hsd1.ut.comcast.net [24.10.224.248]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r4QFehKT003090; Sun, 26 May 2013 09:40:44 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <51A22CFA.7090809@FreeBSD.org> Date: Sun, 26 May 2013 09:40:42 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Joe Subject: Re: A PRIV_* flag for /dev/mem? References: <5196818F.8080201@FreeBSD.org> <20130518114357.GK3047@kib.kiev.ua> <519783C1.2010601@FreeBSD.org> <20130525220710.000041b5@unknown> <51A20F19.4080807@a1poweruser.com> In-Reply-To: <51A20F19.4080807@a1poweruser.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Alexander Leidinger , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 15:40:56 -0000 On 05/26/13 07:33, Joe wrote: > Alexander Leidinger wrote: >> On Sat, 18 May 2013 07:36:01 -0600 >> Jamie Gritton wrote: >> >>> On 05/18/13 05:43, Konstantin Belousov wrote: >>>> On Fri, May 17, 2013 at 01:14:23PM -0600, Jamie Gritton wrote: >>>>> I'm considering Alexander Leidinger's patch to make X11 work >>>>> inside a jail >>>>> (http://leidinger.net/FreeBSD/current-patches/0_jail.diff). It >>>>> allows a jail to optionally have access to /dev/io and DRI >>>>> (provided the requisite device files are visible in the devfs >>>>> ruleset). >>>>> >>>>> I'm planning on putting this under a single jail permission, which >>>>> would group those two together as device access that allows >>>>> messing with kernel memory. It seems more complete to >>>>> put /dev/mem under that same umbrella, with the side benefit of >>>>> letting me call it "allow.dev_mem". >>>>> >>>>> Currently, access is controlled only by device file permission and >>>>> a securelevel check. Jail access is allowed as long as >>>>> the /dev/mem is in the jail's ruleset (it isn't by default). >>>>> Adding a prison_priv_check() call would allow some finer control >>>>> over this. Something like: >>>>> >>>>> int >>>>> memopen(struct cdev *dev __unused, int flags, int fmt __unused, >>>>> struct thread *td) >>>>> { >>>>> int error; >>>>> >>>>> error = priv_check(td, PRIV_FOO); >>>>> if (error != 0&& (flags& FWRITE)) >>>>> error = securelevel_gt(td->td_ucred, 0); >>>>> >>>>> return (error); >>>>> } >>>>> >>>>> The main question I'm coming up with here is, what PRIV_* flag >>>>> should I use. Does PRIV_IO make sense? PRIV_DRIVER? Something >>>>> new like PRIV_KMEM? Also, I'd appreciate if anyone familiar with >>>>> this interface can tell me if memopen() is the right/only place to >>>>> make this change. >>>> Why do we need the PRIV check there at all, esp. for DRM ? >>>> Why the devfs rulesets are not enough ? >>> At least for the reason Alexander's patch was first made, X11 working >>> inside a jail, there's already a need to get past PRIV_IO and >>> PRIV_DRIVER - those checks are already made so in that case the >>> presence of device files isn't sufficient. His solution was to >>> special-case PRIV_DRIVER for drm, and then add jail permission bits >>> that allowed PRIV_IO and PRIV_DRI_DRIVER. A largish but apparently >>> arbitrary set of of devices use PRIV_DRIVER, so it makes sense to >>> separate out this one that's necessary. >>> >>> So while there may be a question as to why /dev/io and DRM should have >>> PRIV checks, the fact of the matter is they already do. >>> >>> Now as to the change I'm considering: kmem. Since the main danger of >>> the existing checks (io and drm) is that they can allow you to stomp >>> on kernel memory, I thought it reasonable to combine them into a >>> single jail flag that allowed that behavior. In coming up with a >>> succinct name for it, I decided on allow.dev_mem (permission for >>> devices that work with system memory), and that brought up the >>> question for /dev/mem. No, I don't need to add a priv check to it; >>> but it seems that if such checks as PRIV_IO and PRIV_DRIVER exist for >> >> Info: >> I spoke with the author of the dri1 driver loooong ago, and it was OK >> for him if I would change the PRIV_DRIVER in DRI to something else. >> >>> devices already, then an architectural decision has already been made >>> that device file access isn't the only level of control we'd like to >>> have. Really I'm surprised something as potentially damaging as kmem >>> didn't already have a priv_check associated with it. >>> >>> Now I could certainly add his patch with no changes (or with very >>> few), and just put in a jail flag that's X11-specific. The /dev/mem >> >> I wouldn't be happy if my patch is committed as is. Your suggestion >> sounds much better. >> >> I would suggest "allow.kmem" or "allow.kmem_devs". The reason is that >> "dev_mem" could be seen as "/dev/mem" only. >> >>> change isn't necessary to this, but it just seemed a good time to add >>> something that feels like a hole in the paradigm. >> >> Bye, >> Alexander. >> > > I have 2 comments on this subject. > > If I understand correctly, all the names being suggested are for an > internal flag name. What it's called internally does not interest me. > But using the internal flag name as the jail(8) parameter name would be > misleading and confusing. The single purpose of this patch is to enable > xorg to run in a jail. Naming it after some internal nob that the patch > tweaks makes no sense. Naming it "allow.xorg" identifies it's intended > purpose in a user-friendly way and is crystal clear to every one no > matter their level of technical knowledge. The function of the proposed jail flag is to allow changes to kernel-level memory. The current best use for this might be to run an X11 server. Currently, the X11 server in favor is Xorg. So we should call it allow.xorg? Good thing we didn't do it a few years ago, or it would confusingly be called allow.xfree86. Perhaps some other X11 server will fall into favor. Perhaps some other graphics system will become more popular than the aging X11 (admittedly not likely). And someone may have some other reason to have a jail that has kernel memory permission. So, no. Changing the name from function to "purpose" is not at all clear. > Correct me if I am wrong here, but what this patch does internally > breaks the security of the jail container. There are already jail(8) > parameters that do this, so this is not new. I strongly suggest that the > documentation on this new parameter contains strong wording that informs > the reader of this security exposure and that it should NOT be used on a > jail exposed to public internet access. True. I don't know about "strong" wording, but it least it should be mentioned. - Jamie From owner-freebsd-current@FreeBSD.ORG Sun May 26 19:21:05 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E5AE5BC; Sun, 26 May 2013 19:21:05 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 81B0C955; Sun, 26 May 2013 19:21:04 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id k11so3503102eaj.21 for ; Sun, 26 May 2013 12:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:subject:from:cc:x-mailer:mime-version :content-type:content-transfer-encoding; bh=jBuaBYnWSDMxWIxiE9tp7XSsuXquwHDpizOwVsHOdYg=; b=a1ECqgOPXBUUMGyBx4NeEgoaK6oR5bSAO44THC679lnzFFZyIU8gmjSr8Ax8H8kidV dtzxY2zrlaXWdOvNrxEfoN9Z45aAOKBW2dbSkPlT6Tb/wocGN+VFWXMSMcGXdhNkC/JD KT/KZ1Aoy00lnAhyuTavxV3il0Mc/PtuZaeUj7bGnutZVdxI1SCVGoccf/eOPKAqVbAM LlCWF+F+wUZE5JdZV+vheI+KRCix0X+BfeW1pRmyU4QaXRpSAb+g9f+p6bW4sXHa82d5 iYnGpxz0naBmiXx2EyRq6bZPclDhl3TXB7xUakhP9RrFPJxIwbDrkyfuUQ3QJA2n7xRD qafg== X-Received: by 10.14.107.200 with SMTP id o48mr51325278eeg.35.1369596062593; Sun, 26 May 2013 12:21:02 -0700 (PDT) Received: from jedi.localdomain (pat-ip-195-91-17-204.gprs.as5628.telecom.sk. [195.91.17.204]) by mx.google.com with ESMTPSA id s43sm36993777eem.13.2013.05.26.12.21.00 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 May 2013 12:21:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jedi.localdomain (Postfix) with ESMTP id 6BDA71144E; Sun, 26 May 2013 21:20:57 +0200 (CEST) Date: Sun, 26 May 2013 21:20:56 +0200 (CEST) Message-Id: <20130526.212056.1568838938154192561.koren@tempest.sk> To: Glen Barber Subject: Re: HP 2570p installation From: Ludovit Koren X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 19:21:05 -0000 I am sorry for the delay. >>>>> On Sat, 25 May 2013 19:14:43 -0400 >>>>> gjb@FreeBSD.org(Glen Barber) said: > > [[PGP Signed Part:No public key for 524F0C37A0B946A3 created at 2013-05-26T01:14:43+0200 using RSA]] > On Sun, May 26, 2013 at 12:54:09AM +0200, Ludovit Koren wrote: > > After Setting BIOS to legacy, with the 9.1-RELEASE-amd64-memstick.img, > > I succeeded to boot. The 10-CURRENT has still problems to boot to > > installation window. > > > > Where does it stop? The same place? > no. Before, it stopped right after beginning phase: bios control transfering to boot. Now, right before gtk? install phase. thanks. lk From owner-freebsd-current@FreeBSD.ORG Sun May 26 19:28:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3AC1B9DE; Sun, 26 May 2013 19:28:19 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9109B1; Sun, 26 May 2013 19:28:17 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,746,1363132800"; d="scan'208,223";a="4997408" Received: from lonpex01cl02.citrite.net ([10.30.203.102]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 26 May 2013 19:28:07 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL02.citrite.net (10.30.203.102) with Microsoft SMTP Server id 14.2.342.3; Sun, 26 May 2013 20:28:06 +0100 Message-ID: <51A26245.9060707@citrix.com> Date: Sun, 26 May 2013 21:28:05 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: FreeBSD-HEAD gets stuck on vnode operations References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> In-Reply-To: <51A0FA43.2040503@citrix.com> Content-Type: multipart/mixed; boundary="------------090606090603060600080202" X-Originating-IP: [10.30.203.1] Cc: Konstantin Belousov , freebsd-current@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 19:28:19 -0000 --------------090606090603060600080202 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit On 25/05/13 19:52, Roger Pau Monné wrote: > On 20/05/13 20:34, John Baldwin wrote: >> On Tuesday, May 14, 2013 1:15:47 pm Roger Pau Monné wrote: >>> On 14/05/13 18:31, Konstantin Belousov wrote: >>>> On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: >>>>> On 13/05/13 17:00, Konstantin Belousov wrote: >>>>>> On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: >>>>>>> On 13/05/13 13:18, Roger Pau Monn? wrote: >>>>> >>>>> Thanks for taking a look, >>>>> >>>>>>> I would like to explain this a little bit more, the syncer process >>>>>>> doesn't get blocked on the _mtx_trylock_flags_ call, it just continues >>>>>>> looping forever in what seems to be an endless loop around >>>>>>> mnt_vnode_next_active/ffs_sync. Also while in this state there is no >>>>>>> noticeable disk activity, so I'm unsure of what is happening. >>>>>> How many CPUs does your VM have ? >>>>> >>>>> 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. >>>>> >>>>>> >>>>>> The loop you describing means that other thread owns the vnode >>>>>> interlock. Can you track what this thread does ? E.g. look at the >>>>>> vp->v_interlock.mtx_lock, which is basically a pointer to the struct >>>>>> thread owning the mutex, clear low bits as needed. Then you can >>>>>> inspect the thread and get a backtrace. >>>>> >>>>> There are no other threads running, only syncer is running on CPU 1 (see >>>>> ps in previous email). All other CPUs are idle, and as seen from the ps >>>>> quite a lot of threads are blocked in vnode related operations, either >>>>> "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output >>>>> of alllocks in the previous email. >>>> This is not useful. You need to look at the mutex which fails the >>>> trylock operation in the mnt_vnode_next_active(), see who owns it, >>>> and then 'unwind' the locking dependencies from there. >>> >>> Sorry, now I get it, let's see if I can find the locked vnodes and the >>> thread that owns them... >> >> You can use 'show lock
v_interlock>' to find an owning >> thread and then use 'show sleepchain '. If you are using kgdb on the >> live system (probably easier) then you can grab my scripts at >> www.freebsd.org/~jhb/gdb/ (do 'cd /path/to/scripts; source gdb6'). You can >> then find the offending thread and do 'mtx_owner &vp->v_interlock' and then >> 'sleepchain ' Hello, I've been looking into this issue a little bit more, and the lock dependencies look right to me, the lockup happens when the thread owning the v_interlock mutex tries to acquire the vnode_free_list_mtx mutex which is already owned by the syncer thread, at this point, the thread owning the v_interlock mutex goes to sleep, and the syncer process will start doing a sequence of: VI_TRYLOCK -> mtx_unlock vnode_free_list_mtx -> kern_yield -> mtx_lock vnode_free_list_mtx ... It seems like kern_yield, which I assume is placed there in order to allow the thread owning v_interlock to be able to also lock vnode_free_list_mtx, doesn't get a window big enough to wake up the waiting thread and get the vnode_free_list_mtx mutex. Since the syncer is the only process runnable on the CPU there is no context switch, and the syncer process continues to run. Relying on kern_yield to provide a window big enough that allows any other thread waiting on vnode_free_list_mtx to run doesn't seem like a good idea on SMP systems. I've not tested this on bare metal, but waking up an idle CPU in a virtualized environment might be more expensive than doing it on bare metal. Bear in mind that I'm not familiar with either the scheduler or the ufs code, my proposed naive fix is to replace the kern_yield call with a pause, that will allow any other threads waiting on vnode_free_list_mtx to lock the vnode_free_list_mtx mutex and finish whatever they are doing and release the v_interlock mutex, so the syncer thread can also finish it's work. I've tested the patch for a couple of hours and seems to be fine, I haven't been able to reproduce the issue anymore. --------------090606090603060600080202 Content-Type: text/plain; charset="UTF-8"; x-mac-type=0; x-mac-creator=0; name="0001-mnt_vnode_next_active-replace-kern_yield-with-pause.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-mnt_vnode_next_active-replace-kern_yield-with-pause.pat"; filename*1="ch" >From fec90f7bb9cdf05b49d11dbe4930d3c595c147f5 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Sun, 26 May 2013 19:55:43 +0200 Subject: [PATCH] mnt_vnode_next_active: replace kern_yield with pause On SMP systems there is no way to assure that a kern_yield will allow any other threads waiting on the vnode_free_list_mtx to be able to acquire it. The syncer process can get stuck in a loop trying to lock the v_interlock mutex, without allowing other threads waiting on vnode_free_list_mtx to run. Replace the kern_yield with a pause, that should allow any thread owning v_interlock and waiting on vnode_free_list_mtx to finish it's work and release v_interlock. --- sys/kern/vfs_subr.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 0da6764..597f4b7 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4703,7 +4703,15 @@ restart: if (mp_ncpus == 1 || should_yield()) { TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); mtx_unlock(&vnode_free_list_mtx); - kern_yield(PRI_USER); + /* + * There is another thread owning the + * v_interlock mutex and possibly waiting on + * vnode_free_list_mtx, so pause in order for + * it to acquire the vnode_free_list_mtx + * mutex and finish the work, releasing + * v_interlock when finished. + */ + pause("vi_lock", 1); mtx_lock(&vnode_free_list_mtx); goto restart; } -- 1.7.7.5 (Apple Git-26) --------------090606090603060600080202-- From owner-freebsd-current@FreeBSD.ORG Sun May 26 20:13:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3EEF6439; Sun, 26 May 2013 20:13:31 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id DBBE2B2F; Sun, 26 May 2013 20:13:30 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id DC5C923F804; Sun, 26 May 2013 16:13:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us DC5C923F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 26 May 2013 16:13:24 -0400 From: Glen Barber To: Ludovit Koren Subject: Re: HP 2570p installation Message-ID: <20130526201324.GD1586@glenbarber.us> References: <20130526.212056.1568838938154192561.koren@tempest.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pZs/OQEoSSbxGlYw" Content-Disposition: inline In-Reply-To: <20130526.212056.1568838938154192561.koren@tempest.sk> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:13:31 -0000 --pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 26, 2013 at 09:20:56PM +0200, Ludovit Koren wrote: >=20 > I am sorry for the delay. >=20 Acutally, I did get your original reply. Sorry I did not repsond sooner. > > > After Setting BIOS to legacy, with the 9.1-RELEASE-amd64-memstick.img, > > > I succeeded to boot. The 10-CURRENT has still problems to boot to > > > installation window. > > >=20 > >=20 > > Where does it stop? The same place? > >=20 >=20 > no. Before, it stopped right after beginning phase: bios control > transfering to boot. Now, right before gtk? install phase. >=20 Are you able to see what is on the screen right before the installation screen? FWIW, I did test this image, and was able to get to the initial installation screen, and was able to get to the live cd. Can you also try pressing [CTRL][ALT][F4]? I think there is an emergency TTY set up, same as with the 8.x images. Also, what options do you have for the SATA controller on this machine? Can you toggle between AHCI and ATA to see if you can get past this hang? Glen --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJRomzkAAoJEFJPDDeguUajfboIAJZP0K+OPdDWrqfHVDOJ3lKu llYaj1Gv2RChBOdELc/mhu9inIoYFSeCt6xL2eRHNIWUtUeO/L/Ug2f8qGC8/SM+ nusGvfBP0k4oNCsn2qDoQs1Btws2USCn1zY/qRLpZkpHSvRsyAWpeFrVZe35GsOk DBWdRJKehFWUznUOaEnwpsVdkNYaglcrF5F5E53NQ2xy+eHtYSZcE287yDlp0SWK ZLcpqt3+75QsRP4zh6ShOdOMClArrhsgqZITXmJTcfUs7ofPBHglDDHlqpJBodDm GVTr6/jdBOlPLaywxr1XXv71qMspHZvo8DJdI8YUzlsgjsZNoETp78tQO7VlLnI= =Ewuh -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw-- From owner-freebsd-current@FreeBSD.ORG Sun May 26 20:21:23 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7ABD8788; Sun, 26 May 2013 20:21:23 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id F142ABF1; Sun, 26 May 2013 20:21:22 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C6D3512013C; Sun, 26 May 2013 22:21:01 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 9EC1B28493; Sun, 26 May 2013 22:20:58 +0200 (CEST) Date: Sun, 26 May 2013 22:20:58 +0200 From: Jilles Tjoelker To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: FreeBSD-HEAD gets stuck on vnode operations Message-ID: <20130526202058.GA40375@stack.nl> References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51A26245.9060707@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-current@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:21:23 -0000 On Sun, May 26, 2013 at 09:28:05PM +0200, Roger Pau Monné wrote: > On 25/05/13 19:52, Roger Pau Monné wrote: > > On 20/05/13 20:34, John Baldwin wrote: > >> On Tuesday, May 14, 2013 1:15:47 pm Roger Pau Monné wrote: > >>> On 14/05/13 18:31, Konstantin Belousov wrote: > >>>> On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: > >>>>> On 13/05/13 17:00, Konstantin Belousov wrote: > >>>>>> On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: > >>>>>>> On 13/05/13 13:18, Roger Pau Monn? wrote: > >>>>> Thanks for taking a look, > >>>>>>> I would like to explain this a little bit more, the syncer process > >>>>>>> doesn't get blocked on the _mtx_trylock_flags_ call, it just continues > >>>>>>> looping forever in what seems to be an endless loop around > >>>>>>> mnt_vnode_next_active/ffs_sync. Also while in this state there is no > >>>>>>> noticeable disk activity, so I'm unsure of what is happening. > >>>>>> How many CPUs does your VM have ? > >>>>> 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. > >>>>>> The loop you describing means that other thread owns the vnode > >>>>>> interlock. Can you track what this thread does ? E.g. look at the > >>>>>> vp->v_interlock.mtx_lock, which is basically a pointer to the struct > >>>>>> thread owning the mutex, clear low bits as needed. Then you can > >>>>>> inspect the thread and get a backtrace. > >>>>> There are no other threads running, only syncer is running on CPU 1 (see > >>>>> ps in previous email). All other CPUs are idle, and as seen from the ps > >>>>> quite a lot of threads are blocked in vnode related operations, either > >>>>> "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output > >>>>> of alllocks in the previous email. > >>>> This is not useful. You need to look at the mutex which fails the > >>>> trylock operation in the mnt_vnode_next_active(), see who owns it, > >>>> and then 'unwind' the locking dependencies from there. > >>> Sorry, now I get it, let's see if I can find the locked vnodes and the > >>> thread that owns them... > >> You can use 'show lock
v_interlock>' to find an owning > >> thread and then use 'show sleepchain '. If you are using kgdb on the > >> live system (probably easier) then you can grab my scripts at > >> www.freebsd.org/~jhb/gdb/ (do 'cd /path/to/scripts; source gdb6'). You can > >> then find the offending thread and do 'mtx_owner &vp->v_interlock' and then > >> 'sleepchain ' > I've been looking into this issue a little bit more, and the lock > dependencies look right to me, the lockup happens when the thread owning > the v_interlock mutex tries to acquire the vnode_free_list_mtx mutex > which is already owned by the syncer thread, at this point, the thread > owning the v_interlock mutex goes to sleep, and the syncer process will > start doing a sequence of: > VI_TRYLOCK -> mtx_unlock vnode_free_list_mtx -> kern_yield -> mtx_lock > vnode_free_list_mtx ... > It seems like kern_yield, which I assume is placed there in order to > allow the thread owning v_interlock to be able to also lock > vnode_free_list_mtx, doesn't get a window big enough to wake up the > waiting thread and get the vnode_free_list_mtx mutex. Since the syncer > is the only process runnable on the CPU there is no context switch, and > the syncer process continues to run. > Relying on kern_yield to provide a window big enough that allows any > other thread waiting on vnode_free_list_mtx to run doesn't seem like a > good idea on SMP systems. I've not tested this on bare metal, but waking > up an idle CPU in a virtualized environment might be more expensive than > doing it on bare metal. > Bear in mind that I'm not familiar with either the scheduler or the ufs > code, my proposed naive fix is to replace the kern_yield call with a > pause, that will allow any other threads waiting on vnode_free_list_mtx > to lock the vnode_free_list_mtx mutex and finish whatever they are doing > and release the v_interlock mutex, so the syncer thread can also finish > it's work. I've tested the patch for a couple of hours and seems to be > fine, I haven't been able to reproduce the issue anymore. Instead of a pause() that may be too short or too long, how about waiting for the necessary lock? In other words, replace the kern_yield() call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach to acquire two locks without imposing an order between them. I expect blocking on a mutex to be safe enough; a mutex may not be held across waiting for hardware or other events. > >From fec90f7bb9cdf05b49d11dbe4930d3c595c147f5 Mon Sep 17 00:00:00 2001 > From: Roger Pau Monne > Date: Sun, 26 May 2013 19:55:43 +0200 > Subject: [PATCH] mnt_vnode_next_active: replace kern_yield with pause > > On SMP systems there is no way to assure that a kern_yield will allow > any other threads waiting on the vnode_free_list_mtx to be able to > acquire it. The syncer process can get stuck in a loop trying to lock > the v_interlock mutex, without allowing other threads waiting on > vnode_free_list_mtx to run. Replace the kern_yield with a pause, that > should allow any thread owning v_interlock and waiting on > vnode_free_list_mtx to finish it's work and release v_interlock. > --- > sys/kern/vfs_subr.c | 10 +++++++++- > 1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c > index 0da6764..597f4b7 100644 > --- a/sys/kern/vfs_subr.c > +++ b/sys/kern/vfs_subr.c > @@ -4703,7 +4703,15 @@ restart: > if (mp_ncpus == 1 || should_yield()) { > TAILQ_INSERT_BEFORE(vp, *mvp, v_actfreelist); > mtx_unlock(&vnode_free_list_mtx); > - kern_yield(PRI_USER); > + /* > + * There is another thread owning the > + * v_interlock mutex and possibly waiting on > + * vnode_free_list_mtx, so pause in order for > + * it to acquire the vnode_free_list_mtx > + * mutex and finish the work, releasing > + * v_interlock when finished. > + */ > + pause("vi_lock", 1); > mtx_lock(&vnode_free_list_mtx); > goto restart; > } > -- > 1.7.7.5 (Apple Git-26) -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun May 26 20:47:08 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80CE1D19; Sun, 26 May 2013 20:47:08 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by mx1.freebsd.org (Postfix) with ESMTP id E6169D27; Sun, 26 May 2013 20:47:07 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id c1so3589954eek.12 for ; Sun, 26 May 2013 13:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:subject:from:cc:x-mailer:mime-version :content-type:content-transfer-encoding; bh=fjHEeiUu17557vCaU1nXz7SA6eBPkPdFkp3XDazKzIE=; b=VsVlae9TnyEwtjFgfY6w5BXpnZlw1tfjUtOl5GWayC6n6KQ3P2D+cHavNzsP3O9jES YdtrbbEgY6WcMZzOml2lWIkBAWLvqp8SFyHUlt+dZ2CslZgF4CgH5TJjDc/TnztFGVPq LwOPHpIk4nEmvPtPPgPmKqYCJ9iOkFikRbmmozM2J+GdY/+gmTe5bikU8s5gJAutuEDa uSybOd0mFlIK8fQr6GWXqeDycrKyqLEBsbMJD2I3PScIF8wW1kqaMPTkSHK1xTN2KOIh Ko6BgokQl3Kglv+tutGXQLlAPEKfFwulSZ3NW+rN57oK8HYiYKmDjChssfKv/mkVDt9c rTMg== X-Received: by 10.15.32.68 with SMTP id z44mr7450740eeu.103.1369601219316; Sun, 26 May 2013 13:46:59 -0700 (PDT) Received: from jedi.localdomain (pat-ip-195-91-17-204.gprs.as5628.telecom.sk. [195.91.17.204]) by mx.google.com with ESMTPSA id t9sm37511429eeo.11.2013.05.26.13.46.57 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 May 2013 13:46:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by jedi.localdomain (Postfix) with ESMTP id 6F4A711455; Sun, 26 May 2013 22:46:53 +0200 (CEST) Date: Sun, 26 May 2013 22:46:52 +0200 (CEST) Message-Id: <20130526.224652.1305564732068167605.koren@tempest.sk> To: Glen Barber Subject: Re: HP 2570p installation From: Ludovit Koren X-Mailer: xcite1.57> Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:47:08 -0000 >>>>> On Sun, 26 May 2013 16:13:24 -0400 >>>>> gjb@FreeBSD.org(Glen Barber) said: > > [[PGP Signed Part:No public key for 524F0C37A0B946A3 created at 2013-05-26T22:13:24+0200 using RSA]] > On Sun, May 26, 2013 at 09:20:56PM +0200, Ludovit Koren wrote: > > > > I am sorry for the delay. > > > > Acutally, I did get your original reply. Sorry I did not repsond > sooner. > > > > > After Setting BIOS to legacy, with the 9.1-RELEASE-amd64-memstick.img, > > > > I succeeded to boot. The 10-CURRENT has still problems to boot to > > > > installation window. > > > > > > > > > > Where does it stop? The same place? > > > > > > > no. Before, it stopped right after beginning phase: bios control > > transfering to boot. Now, right before gtk? install phase. > > > > Are you able to see what is on the screen right before the installation > screen? FWIW, I did test this image, and was able to get to the initial > installation screen, and was able to get to the live cd. > > Can you also try pressing [CTRL][ALT][F4]? I think there is an > emergency TTY set up, same as with the 8.x images. > In 9.1, I can switch to the shell... > Also, what options do you have for the SATA controller on this machine? > Can you toggle between AHCI and ATA to see if you can get past this > hang? > when in ahci I cannot boot. If in the IDE, it stops in mountroot> lk From owner-freebsd-current@FreeBSD.ORG Sun May 26 20:52:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E5ACEE2; Sun, 26 May 2013 20:52:16 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id A8760D72; Sun, 26 May 2013 20:52:14 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,746,1363132800"; d="scan'208";a="4997689" Received: from lonpex01cl01.citrite.net ([10.30.203.101]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 26 May 2013 20:52:10 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.3; Sun, 26 May 2013 21:52:08 +0100 Message-ID: <51A275F7.9030401@citrix.com> Date: Sun, 26 May 2013 22:52:07 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jilles Tjoelker Subject: Re: FreeBSD-HEAD gets stuck on vnode operations References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> In-Reply-To: <20130526202058.GA40375@stack.nl> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: Konstantin Belousov , freebsd-current@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 20:52:16 -0000 On 26/05/13 22:20, Jilles Tjoelker wrote: > Instead of a pause() that may be too short or too long, how about > waiting for the necessary lock? In other words, replace the kern_yield() > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? > I expect blocking on a mutex to be safe enough; a mutex may not be held > across waiting for hardware or other events. > From owner-freebsd-current@FreeBSD.ORG Sun May 26 22:22:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5676FDBA; Sun, 26 May 2013 22:22:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 17B5EF8F; Sun, 26 May 2013 22:22:56 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 8A225359319; Mon, 27 May 2013 00:22:54 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 6AEF728493; Mon, 27 May 2013 00:22:54 +0200 (CEST) Date: Mon, 27 May 2013 00:22:54 +0200 From: Jilles Tjoelker To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: FreeBSD-HEAD gets stuck on vnode operations Message-ID: <20130526222254.GB40375@stack.nl> References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> <51A275F7.9030401@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51A275F7.9030401@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-current@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2013 22:22:56 -0000 On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monné wrote: > On 26/05/13 22:20, Jilles Tjoelker wrote: > > Instead of a pause() that may be too short or too long, how about > > waiting for the necessary lock? In other words, replace the kern_yield() > > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > > to acquire two locks without imposing an order between them. > Since there might be more than one locked vnode, waiting on a specific > locked vnode seemed rather arbitrary, but I agree that the pause is also > rather arbitrary. > Also, can we be sure that the v_interlock mutex will not be destroyed > while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Mon May 27 00:28:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0A674E22 for ; Mon, 27 May 2013 00:28:32 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mx1.freebsd.org (Postfix) with ESMTP id D1DEF684 for ; Mon, 27 May 2013 00:28:31 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id j6so8079967oag.4 for ; Sun, 26 May 2013 17:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n/6YwhrFzoWXYULjQojZPfrtNwH/PUb0SyOSzpGANtc=; b=Eg4FxrLUyaXmj8DtVp0s8aroYxewywahSuddyYBlH7UeecAsh/MHe9oWOO2u5IwAhF lIevyyNBlw1i+7XythqF9BYNkreT1Tet6mhCQMxTL+vaqrySNCDHU2zlQGVCg69IUMmV hRJn2vcrZ1cOH/b+4+gOrF19HDQAnbqdOghTC4NYg/NP6ZtL/SdVEoEP/PVw5ho1THp0 ZDnZ5TdUD4zzIEC0G060dniVmQXaSo+5jrajBuZr9yJoZhavIVLveA03ddAnOCOvGe7T ShOmUTRPDXBr4KHfNKFZJpG5/7xN1m+xIdRRCz0Ev1QvfHPoKjrad0p49uF9z7O7M2fq IA5Q== MIME-Version: 1.0 X-Received: by 10.182.225.199 with SMTP id rm7mr17283703obc.20.1369614511036; Sun, 26 May 2013 17:28:31 -0700 (PDT) Received: by 10.182.53.231 with HTTP; Sun, 26 May 2013 17:28:30 -0700 (PDT) Date: Sun, 26 May 2013 20:28:30 -0400 Message-ID: Subject: Building of libc in /usr/src/lib/libc results in error From: Super Bisquit To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 00:28:32 -0000 Because the last message was over the limit, I will only post the end of file error here. building shared library libc.so.7 /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libc.so.7] Error code 1 Stop in /usr/src/lib/libc. From owner-freebsd-current@FreeBSD.ORG Mon May 27 00:39:43 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FFEAFF2 for ; Mon, 27 May 2013 00:39:43 +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 23911754 for ; Mon, 27 May 2013 00:39:43 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id DC5F26127 for ; Sun, 26 May 2013 20:39:38 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=CR8T0uWNjTGiuWquBxe2PXrSEuWLBwyndxjy7b7dfVtBmYcQuhZmK97gHJyZlhF74 Q1yxibuZMoia+c5pGDPGTTENNfBV3lCRV/LyhxtsFPTC6UUSANZoOJ+JBbX/A2x Message-ID: <51A2AB48.6030101@protected-networks.net> Date: Sun, 26 May 2013 20:39:36 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130518 Thunderbird/17.0.6 MIME-Version: 1.0 To: current@FreeBSD.org Subject: make: "/usr/ports/mail/postfix/Makefile" line 92: warning: Couldn't read shell's output ... X-Enigmail-Version: 1.5.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 00:39:43 -0000 What's up with this? imb@toshi:/home/imb> sudo portupgrade -aR make: "/usr/ports/mail/postfix/Makefile" line 92: warning: Couldn't read shell's output for "/usr/bin/grep -m 1 '^purgestat' /etc/mail/mailer.conf || true" imb From owner-freebsd-current@FreeBSD.ORG Mon May 27 00:55:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9315C476; Mon, 27 May 2013 00:55:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 50EA67C9; Mon, 27 May 2013 00:55:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r4R0tFa7000971; Sun, 26 May 2013 20:55:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r4R0tFu4000953; Mon, 27 May 2013 00:55:15 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 27 May 2013 00:55:15 GMT Message-Id: <201305270055.r4R0tFu4000953@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 00:55:19 -0000 TB --- 2013-05-26 23:02:01 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-26 23:02:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-26 23:02:01 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-05-26 23:02:02 - cleaning the object tree TB --- 2013-05-26 23:03:34 - /usr/local/bin/svn stat /src TB --- 2013-05-26 23:03:38 - At svn revision 251002 TB --- 2013-05-26 23:03:39 - building world TB --- 2013-05-26 23:03:39 - CROSS_BUILD_TESTING=YES TB --- 2013-05-26 23:03:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-26 23:03:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-26 23:03:39 - SRCCONF=/dev/null TB --- 2013-05-26 23:03:39 - TARGET=ia64 TB --- 2013-05-26 23:03:39 - TARGET_ARCH=ia64 TB --- 2013-05-26 23:03:39 - TZ=UTC TB --- 2013-05-26 23:03:39 - __MAKE_CONF=/dev/null TB --- 2013-05-26 23:03:39 - cd /src TB --- 2013-05-26 23:03:39 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun May 26 23:03:46 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon May 27 00:34:57 UTC 2013 TB --- 2013-05-27 00:34:57 - generating LINT kernel config TB --- 2013-05-27 00:34:57 - cd /src/sys/ia64/conf TB --- 2013-05-27 00:34:57 - /usr/bin/make -B LINT TB --- 2013-05-27 00:34:57 - cd /src/sys/ia64/conf TB --- 2013-05-27 00:34:57 - /usr/sbin/config -m LINT TB --- 2013-05-27 00:34:57 - building LINT kernel TB --- 2013-05-27 00:34:57 - CROSS_BUILD_TESTING=YES TB --- 2013-05-27 00:34:57 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-27 00:34:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-27 00:34:57 - SRCCONF=/dev/null TB --- 2013-05-27 00:34:57 - TARGET=ia64 TB --- 2013-05-27 00:34:57 - TARGET_ARCH=ia64 TB --- 2013-05-27 00:34:57 - TZ=UTC TB --- 2013-05-27 00:34:57 - __MAKE_CONF=/dev/null TB --- 2013-05-27 00:34:57 - cd /src TB --- 2013-05-27 00:34:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon May 27 00:34:57 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] *** Error code 1 Stop. make: stopped in /obj/ia64.ia64/src/sys/LINT *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-27 00:55:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-27 00:55:15 - ERROR: failed to build LINT kernel TB --- 2013-05-27 00:55:15 - 5435.63 user 884.82 system 6793.12 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon May 27 06:07:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD16D554; Mon, 27 May 2013 06:07:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 31BEA34E; Mon, 27 May 2013 06:07:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4R67RcZ058612; Mon, 27 May 2013 09:07:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4R67RcZ058612 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4R67R4J058611; Mon, 27 May 2013 09:07:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 May 2013 09:07:27 +0300 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: FreeBSD-HEAD gets stuck on vnode operations Message-ID: <20130527060727.GW3047@kib.kiev.ua> References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> <51A275F7.9030401@citrix.com> <20130526222254.GB40375@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JVkQSGY1i+HoDREx" Content-Disposition: inline In-Reply-To: <20130526222254.GB40375@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, "current@freebsd.org" , Roger Pau Monn? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 06:07:44 -0000 --JVkQSGY1i+HoDREx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: > On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: > > On 26/05/13 22:20, Jilles Tjoelker wrote: > > > Instead of a pause() that may be too short or too long, how about > > > waiting for the necessary lock? In other words, replace the kern_yiel= d() > > > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > > > to acquire two locks without imposing an order between them. >=20 > > Since there might be more than one locked vnode, waiting on a specific > > locked vnode seemed rather arbitrary, but I agree that the pause is also > > rather arbitrary. >=20 > > Also, can we be sure that the v_interlock mutex will not be destroyed > > while the syncer process is waiting for it to be unlocked? >=20 > I think this is a major problem. My idea was too easy and will not work. >=20 > That said, the code in mnt_vnode_next_active() appears to implement some > sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms > (default value of hogticks) and then yields. This is far too long for a > mutex lock and if it takes that long it means that either the thread > owning the lock is blocked by us somehow or someone is abusing a mutex > to work like a sleepable lock such as by spinning or DELAY. >=20 > Given that it has been spinning for 200ms, it is not so bad to pause for > one additional microsecond. >=20 > The adaptive spinning was added fairly recently, so apparently it > happens fairly frequently that VI_TRYLOCK fails transiently. > Unfortunately, the real adaptive spinning code cannot be used because it > will spin forever as long as the thread owning v_interlock is running, > including when that is because it is spinning for vnode_free_list_mtx. > Perhaps we can try to VI_TRYLOCK a certain number of times. It is also > possible to check the contested bit of vnode_free_list_mtx > (sys/netgraph/netflow/netflow.c does something similar) and stop > spinning in that case. >=20 > A cpu_spinwait() invocation should also be added to the spin loop. There are two 'proper' solutions for this issue: One is to change the handling of the vnode lifecycle to allow the safe block for the vnode interlock acquisition. In particular, the change would add some stability of the vnode memory when vnode is put on the free list. As example, the vnode zone could be marked as type-stable again, and then the vnode interlock can be obtained with dropped free list lock. Arguably, marking the zone as non-freeable would be a regression, esp. for the zone which accounts for largest allocation on the kernel memory. Another one is to somehow ensure that the priority is properly propagated from the spinning thread to the vnode interlock owner. I think that it is desirable to donate some amount of priority =66rom the spinning thread. Unfortunately, I was unable to come up with elegant solution for this which would be also contained and did not require rewamp of the mutex interfaces. BTW, if anybody come up with the idea of the restructuring the free list handling to avoid the free list/vnode interlock LOR altogether, it would be the best. I do not have objections against the pause() addition, but I would argue that should_yield() should be removed then, switching the code to unconditionally pause when the collision detected. --JVkQSGY1i+HoDREx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRovgfAAoJEJDCuSvBvK1BmNIP/je3R6P5ySJnhK1RdeHvYCuV GElJUmlP7IC8b+PLK3Hr+FcjWITFPIpGsjDR4znGJ1tgrbBlEA41BbZbZYHMhBG2 2VrK4yJmFZVSV2SAMjaFEORqz8vbI9fJrt7SUSbYFUtPudM3Iyt6KtBjuEfR5oWA t2NYpN8T5Kxp027kKr5Yy335bDhLYSOSQ0OoFdJjcCle4ZHjSfKzPYNW/NJ6QVVE m4VXvHXSzWznKwl2M9lgvVb6PLFgwkoNEYqNb1qVgtrGSehJAdfBfm/1XoJbnt7F Jm7jOKBNfnttY26DH3gJLFN02dw6G0BLwJ3Krf/a6xmUxtNAWOMxNHd4/u33yqD+ oxM3QQh/Sbb4GwRpRYxsh97qZ7vuGLuhQ5OwneJ1colRobktHkfhvxM12VGRf/iX +s06qmBIeRdpjv78SvCGFdpQGUuaKQH0w3XCnEZ5uA9h5WFCptB888EKGpoPRnCO R8cjgZ3FiJTmEpHRPhWDZdAvxoEiNaRVPJuoPYKR3UnCJ+QJMLkC4xgQflzZAs94 WjwBKc4JVbz4AV4YDjYkkWok5Tz2O9ZKP8vxJv1UAEhqAu+mzLcr3nbdhdOUoIw3 uKh5z6AwpCa+TPju2wm5mZPpjt26jb94sKpL0yGk74xTFZNAzjh6AwUY/rvAxLP4 +wdJmMMp5HXNhOQnaada =B3in -----END PGP SIGNATURE----- --JVkQSGY1i+HoDREx-- From owner-freebsd-current@FreeBSD.ORG Mon May 27 06:25:05 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E81DB8C7 for ; Mon, 27 May 2013 06:25:05 +0000 (UTC) (envelope-from gber@freebsd.org) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id A329D5E6 for ; Mon, 27 May 2013 06:25:05 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 8110AC4C84; Mon, 27 May 2013 08:24:58 +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 tDWnlgk0IkGw; Mon, 27 May 2013 08:24:57 +0200 (CEST) Received: from [10.0.0.93] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 60E37C4C93; Mon, 27 May 2013 08:24:57 +0200 (CEST) Message-ID: <51A317AE.7000806@freebsd.org> Date: Mon, 27 May 2013 10:22:06 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120127 Thunderbird/3.1.16 MIME-Version: 1.0 To: current@freebsd.org, alexander.fedorov@rtlservice.com Subject: Re: NAND Framework ONFI chip detection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 06:25:06 -0000 >> From: Alexander Fedorov >> Date: 24 maja 2013 03:51:58 GMT-07:00 >> To: current@freebsd.org >> Subject: Re: [PATCH] NAND Framework ONFI chip detection >> >> Hi, current! >> >> I received a positive feedback from Grzegorz Bernacki (semihalf). >> He said that my patch is ok. Can anyone commit a proposed patch? > Hi Alexander, I've just submitted your patch. Thanks for fixing it. regards, grzesiek From owner-freebsd-current@FreeBSD.ORG Mon May 27 07:29:19 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 152AEA46 for ; Mon, 27 May 2013 07:29:19 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by mx1.freebsd.org (Postfix) with ESMTP id F3EB894A for ; Mon, 27 May 2013 07:29:18 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,749,1363158000"; d="scan'208";a="260406075" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 27 May 2013 00:28:11 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4R7SBAK003847 for ; Mon, 27 May 2013 00:28:11 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.208]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 27 May 2013 00:28:11 -0700 From: "Eggert, Lars" To: "current@freebsd.org" Subject: port building & warnings about compat.ia32.maxvmem Thread-Topic: port building & warnings about compat.ia32.maxvmem Thread-Index: AQHOWqu9FAf/a0qMZEC4bi3zNdwW9g== Date: Mon, 27 May 2013 07:28:10 +0000 Message-ID: <81925106-B46B-4928-8F84-84076872048B@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <473556D280C82F44822AAF54E9AA9570@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 07:29:19 -0000 Hi, when I try to build ports on -CURRENT, I've been seeing tons of these messa= ges since the past week or so: make: "/usr/ports/Mk/bsd.port.mk" line 1633: warning: Couldn't read shell's= output for "if /sbin/sysctl -n compat.ia32.maxvmem >/dev/null 2>&1; then e= cho YES; fi" The amd64 kernel I'm building this on doesn't have COMPAT_FREEBSD32 defined= . Lars= From owner-freebsd-current@FreeBSD.ORG Mon May 27 08:19:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 870D0AFD; Mon, 27 May 2013 08:19:58 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id 01991BD5; Mon, 27 May 2013 08:19:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,749,1363132800"; d="scan'208";a="5004764" Received: from lonpex01cl03.citrite.net ([10.30.203.103]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 27 May 2013 08:19:53 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL03.citrite.net (10.30.203.103) with Microsoft SMTP Server id 14.2.342.3; Mon, 27 May 2013 09:19:52 +0100 Message-ID: <51A31727.9040909@citrix.com> Date: Mon, 27 May 2013 10:19:51 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: FreeBSD-HEAD gets stuck on vnode operations References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> <51A275F7.9030401@citrix.com> <20130526222254.GB40375@stack.nl> <20130527060727.GW3047@kib.kiev.ua> In-Reply-To: <20130527060727.GW3047@kib.kiev.ua> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: freebsd-current@freebsd.org, "current@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 08:19:58 -0000 On 27/05/13 08:07, Konstantin Belousov wrote: > On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: >> On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: >>> On 26/05/13 22:20, Jilles Tjoelker wrote: >>>> Instead of a pause() that may be too short or too long, how about >>>> waiting for the necessary lock? In other words, replace the kern_yield() >>>> call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach >>>> to acquire two locks without imposing an order between them. >> >>> Since there might be more than one locked vnode, waiting on a specific >>> locked vnode seemed rather arbitrary, but I agree that the pause is also >>> rather arbitrary. >> >>> Also, can we be sure that the v_interlock mutex will not be destroyed >>> while the syncer process is waiting for it to be unlocked? >> >> I think this is a major problem. My idea was too easy and will not work. >> >> That said, the code in mnt_vnode_next_active() appears to implement some >> sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms >> (default value of hogticks) and then yields. This is far too long for a >> mutex lock and if it takes that long it means that either the thread >> owning the lock is blocked by us somehow or someone is abusing a mutex >> to work like a sleepable lock such as by spinning or DELAY. >> >> Given that it has been spinning for 200ms, it is not so bad to pause for >> one additional microsecond. >> >> The adaptive spinning was added fairly recently, so apparently it >> happens fairly frequently that VI_TRYLOCK fails transiently. >> Unfortunately, the real adaptive spinning code cannot be used because it >> will spin forever as long as the thread owning v_interlock is running, >> including when that is because it is spinning for vnode_free_list_mtx. >> Perhaps we can try to VI_TRYLOCK a certain number of times. It is also >> possible to check the contested bit of vnode_free_list_mtx >> (sys/netgraph/netflow/netflow.c does something similar) and stop >> spinning in that case. >> >> A cpu_spinwait() invocation should also be added to the spin loop. > > There are two 'proper' solutions for this issue: > > One is to change the handling of the vnode lifecycle to allow the > safe block for the vnode interlock acquisition. In particular, the > change would add some stability of the vnode memory when vnode is > put on the free list. As example, the vnode zone could be marked as > type-stable again, and then the vnode interlock can be obtained with > dropped free list lock. Arguably, marking the zone as non-freeable would > be a regression, esp. for the zone which accounts for largest allocation > on the kernel memory. > > Another one is to somehow ensure that the priority is properly > propagated from the spinning thread to the vnode interlock owner. > I think that it is desirable to donate some amount of priority > from the spinning thread. Unfortunately, I was unable to come > up with elegant solution for this which would be also contained > and did not require rewamp of the mutex interfaces. > > BTW, if anybody come up with the idea of the restructuring the free list > handling to avoid the free list/vnode interlock LOR altogether, it would > be the best. > > I do not have objections against the pause() addition, but I would > argue that should_yield() should be removed then, switching the code to > unconditionally pause when the collision detected. Taking the idea from Jilles, what about replacing should_yield with a check to see if the vnode_free_list_mtx mutex is contented? That would prevent us from doing unnecessary pauses, and only releasing the vnode_free_list_mtx mutex when there's someone else that actually needs it. From owner-freebsd-current@FreeBSD.ORG Mon May 27 10:23:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A8D74A2; Mon, 27 May 2013 10:23:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A1FC6240; Mon, 27 May 2013 10:23:21 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4RAN6Ur011329; Mon, 27 May 2013 13:23:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4RAN6Ur011329 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4RAN6gE011328; Mon, 27 May 2013 13:23:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 May 2013 13:23:06 +0300 From: Konstantin Belousov To: Roger Pau Monn? Subject: Re: FreeBSD-HEAD gets stuck on vnode operations Message-ID: <20130527102306.GB3047@kib.kiev.ua> References: <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> <51A275F7.9030401@citrix.com> <20130526222254.GB40375@stack.nl> <20130527060727.GW3047@kib.kiev.ua> <51A31727.9040909@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xcDMtsbEj34k8mAw" Content-Disposition: inline In-Reply-To: <51A31727.9040909@citrix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org, "current@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:23:22 -0000 --xcDMtsbEj34k8mAw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 27, 2013 at 10:19:51AM +0200, Roger Pau Monn? wrote: > On 27/05/13 08:07, Konstantin Belousov wrote: > > On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: > >> On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: > >>> On 26/05/13 22:20, Jilles Tjoelker wrote: > >>>> Instead of a pause() that may be too short or too long, how about > >>>> waiting for the necessary lock? In other words, replace the kern_yie= ld() > >>>> call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approa= ch > >>>> to acquire two locks without imposing an order between them. > >> > >>> Since there might be more than one locked vnode, waiting on a specific > >>> locked vnode seemed rather arbitrary, but I agree that the pause is a= lso > >>> rather arbitrary. > >> > >>> Also, can we be sure that the v_interlock mutex will not be destroyed > >>> while the syncer process is waiting for it to be unlocked? > >> > >> I think this is a major problem. My idea was too easy and will not wor= k. > >> > >> That said, the code in mnt_vnode_next_active() appears to implement so= me > >> sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms > >> (default value of hogticks) and then yields. This is far too long for a > >> mutex lock and if it takes that long it means that either the thread > >> owning the lock is blocked by us somehow or someone is abusing a mutex > >> to work like a sleepable lock such as by spinning or DELAY. > >> > >> Given that it has been spinning for 200ms, it is not so bad to pause f= or > >> one additional microsecond. > >> > >> The adaptive spinning was added fairly recently, so apparently it > >> happens fairly frequently that VI_TRYLOCK fails transiently. > >> Unfortunately, the real adaptive spinning code cannot be used because = it > >> will spin forever as long as the thread owning v_interlock is running, > >> including when that is because it is spinning for vnode_free_list_mtx. > >> Perhaps we can try to VI_TRYLOCK a certain number of times. It is also > >> possible to check the contested bit of vnode_free_list_mtx > >> (sys/netgraph/netflow/netflow.c does something similar) and stop > >> spinning in that case. > >> > >> A cpu_spinwait() invocation should also be added to the spin loop. > >=20 > > There are two 'proper' solutions for this issue: > >=20 > > One is to change the handling of the vnode lifecycle to allow the > > safe block for the vnode interlock acquisition. In particular, the > > change would add some stability of the vnode memory when vnode is > > put on the free list. As example, the vnode zone could be marked as > > type-stable again, and then the vnode interlock can be obtained with > > dropped free list lock. Arguably, marking the zone as non-freeable would > > be a regression, esp. for the zone which accounts for largest allocation > > on the kernel memory. > >=20 > > Another one is to somehow ensure that the priority is properly > > propagated from the spinning thread to the vnode interlock owner. > > I think that it is desirable to donate some amount of priority > > from the spinning thread. Unfortunately, I was unable to come > > up with elegant solution for this which would be also contained > > and did not require rewamp of the mutex interfaces. > >=20 > > BTW, if anybody come up with the idea of the restructuring the free list > > handling to avoid the free list/vnode interlock LOR altogether, it would > > be the best. > >=20 > > I do not have objections against the pause() addition, but I would > > argue that should_yield() should be removed then, switching the code to > > unconditionally pause when the collision detected. >=20 > Taking the idea from Jilles, what about replacing should_yield with a > check to see if the vnode_free_list_mtx mutex is contented? >=20 > That would prevent us from doing unnecessary pauses, and only releasing > the vnode_free_list_mtx mutex when there's someone else that actually > needs it. This would still be racy, and possibly allows the lock convoy in the same manner as the current code. Also, AFAIR, the real problem was when two iterators start synchronized, it usually ended in live-lock. If you are willing, try this, of course, but I tend to agree with just an addition of pause() for now. --xcDMtsbEj34k8mAw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRozQJAAoJEJDCuSvBvK1B1mwP/1llpTg+aF+mzgnLt7f+uP4u QSpSmB6D5tdDnGZWVgS+cMv3oR/SiQsS8yi65gFhskqPJputimSK52sy/Uq/VwJO lxnnWwrIc72fSmBu/b1kr9V8roXpDgKt6o9/eSvRqk1WNBXSw4zfOXz96t6hfajU 3mAfOIBjnXg/y0umt/ymaKVxLPhie6KHsxIBxaCtP+VTgt2VoSxOJvYx5G2LkCq7 6Lr68qi+aDADRsaZq9xmdqfsHNYUJrW+0ewtmeHHLlV/RTQPx6Zn9wXbBP+uPwRA 1YVz0pNae0+wTQ+twlWPVycz2tZKYrItcw9eIYUKJxGkPZ+RUaAFNympGgUkJD0l S2aOG33nK9moodCu1ThwgEdndIhsaFyeQnfqa3p2v2SdSZBcfbvzjsijFf3K7ZYL MXfsx5hxPQ8RRBkSn1864mv5N3BfV/ZyjR0OIsmdEyocBqceYFYXeY8NN6hc5Oor 8L/CK8vOdEEbPtfcsKFyA5s0cN7uICyk9t4T1OhjElorrXU+AXArcoAn16Nhbdqm Q4FGQQz4eODd2PdFmOOAo+UB68lYDMKBhx+pSz7/AYvw2a9I7rI3k7fnmuh3puqS I7UIlJidCJknA+ulhiPIe6hnpexjrsA3TYbhvKn1o3BAEt33DlWltkuYyUO37p/Y pyJ9nFTEcsmZ8mV7JPnF =WTjv -----END PGP SIGNATURE----- --xcDMtsbEj34k8mAw-- From owner-freebsd-current@FreeBSD.ORG Mon May 27 10:35:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC217BFD; Mon, 27 May 2013 10:35:22 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id 51DF02F8; Mon, 27 May 2013 10:35:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,750,1363132800"; d="scan'208";a="5009822" Received: from lonpex01cl01.citrite.net ([10.30.203.101]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 27 May 2013 10:35:17 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.3; Mon, 27 May 2013 11:35:16 +0100 Message-ID: <51A336E4.9050200@citrix.com> Date: Mon, 27 May 2013 12:35:16 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: FreeBSD-HEAD gets stuck on vnode operations References: <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> <51A275F7.9030401@citrix.com> <20130526222254.GB40375@stack.nl> <20130527060727.GW3047@kib.kiev.ua> <51A31727.9040909@citrix.com> <20130527102306.GB3047@kib.kiev.ua> In-Reply-To: <20130527102306.GB3047@kib.kiev.ua> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: freebsd-current@freebsd.org, "current@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 10:35:23 -0000 On 27/05/13 12:23, Konstantin Belousov wrote: > On Mon, May 27, 2013 at 10:19:51AM +0200, Roger Pau Monn? wrote: >> On 27/05/13 08:07, Konstantin Belousov wrote: >>> On Mon, May 27, 2013 at 12:22:54AM +0200, Jilles Tjoelker wrote: >>>> On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monn? wrote: >>>>> On 26/05/13 22:20, Jilles Tjoelker wrote: >>>>>> Instead of a pause() that may be too short or too long, how about >>>>>> waiting for the necessary lock? In other words, replace the kern_yield() >>>>>> call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach >>>>>> to acquire two locks without imposing an order between them. >>>> >>>>> Since there might be more than one locked vnode, waiting on a specific >>>>> locked vnode seemed rather arbitrary, but I agree that the pause is also >>>>> rather arbitrary. >>>> >>>>> Also, can we be sure that the v_interlock mutex will not be destroyed >>>>> while the syncer process is waiting for it to be unlocked? >>>> >>>> I think this is a major problem. My idea was too easy and will not work. >>>> >>>> That said, the code in mnt_vnode_next_active() appears to implement some >>>> sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms >>>> (default value of hogticks) and then yields. This is far too long for a >>>> mutex lock and if it takes that long it means that either the thread >>>> owning the lock is blocked by us somehow or someone is abusing a mutex >>>> to work like a sleepable lock such as by spinning or DELAY. >>>> >>>> Given that it has been spinning for 200ms, it is not so bad to pause for >>>> one additional microsecond. >>>> >>>> The adaptive spinning was added fairly recently, so apparently it >>>> happens fairly frequently that VI_TRYLOCK fails transiently. >>>> Unfortunately, the real adaptive spinning code cannot be used because it >>>> will spin forever as long as the thread owning v_interlock is running, >>>> including when that is because it is spinning for vnode_free_list_mtx. >>>> Perhaps we can try to VI_TRYLOCK a certain number of times. It is also >>>> possible to check the contested bit of vnode_free_list_mtx >>>> (sys/netgraph/netflow/netflow.c does something similar) and stop >>>> spinning in that case. >>>> >>>> A cpu_spinwait() invocation should also be added to the spin loop. >>> >>> There are two 'proper' solutions for this issue: >>> >>> One is to change the handling of the vnode lifecycle to allow the >>> safe block for the vnode interlock acquisition. In particular, the >>> change would add some stability of the vnode memory when vnode is >>> put on the free list. As example, the vnode zone could be marked as >>> type-stable again, and then the vnode interlock can be obtained with >>> dropped free list lock. Arguably, marking the zone as non-freeable would >>> be a regression, esp. for the zone which accounts for largest allocation >>> on the kernel memory. >>> >>> Another one is to somehow ensure that the priority is properly >>> propagated from the spinning thread to the vnode interlock owner. >>> I think that it is desirable to donate some amount of priority >>> from the spinning thread. Unfortunately, I was unable to come >>> up with elegant solution for this which would be also contained >>> and did not require rewamp of the mutex interfaces. >>> >>> BTW, if anybody come up with the idea of the restructuring the free list >>> handling to avoid the free list/vnode interlock LOR altogether, it would >>> be the best. >>> >>> I do not have objections against the pause() addition, but I would >>> argue that should_yield() should be removed then, switching the code to >>> unconditionally pause when the collision detected. >> >> Taking the idea from Jilles, what about replacing should_yield with a >> check to see if the vnode_free_list_mtx mutex is contented? >> >> That would prevent us from doing unnecessary pauses, and only releasing >> the vnode_free_list_mtx mutex when there's someone else that actually >> needs it. > This would still be racy, and possibly allows the lock convoy in the same > manner as the current code. Also, AFAIR, the real problem was when > two iterators start synchronized, it usually ended in live-lock. > > If you are willing, try this, of course, but I tend to agree with just > an addition of pause() for now. OK, I've tested replacing kern_yield with a pause the whole night and that seems to be working as expected, I did no longer see any lockups, usually during a whole night run I saw at least 3 or 4 lockups. If you are happy (and others) with the replacement you can commit it and we can replace the should_yield call later if needed. Thanks, Roger. From owner-freebsd-current@FreeBSD.ORG Mon May 27 11:26:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E1423CC; Mon, 27 May 2013 11:26:38 +0000 (UTC) (envelope-from weiss@uni-mainz.de) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id 897139AF; Mon, 27 May 2013 11:26:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1369653998; x=1401189998; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6FKUrFoArc26/tewAGT0wbPgGsXSFgVF49mh/eG19e0=; b=jYTBZ06l6lujsZddaunN5MZuVX2rfOAasYlKmg5nvUGSGzcv0/a0bgph NGVjaiCCj5tbuWCcvwCi/Cc3AWj9jndcG7oqps3V36/3L7L/sc4GC8MAB F3vYneFN6nOt4KvNxy8ljx6XzVLEPKmsZCgNkdLCaZnacjK39fZcfVIDa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMFAGRCo1EKXgZY/2dsb2JhbABagwgwgzu+Sg14Fm0HgiMBAQEEAQEBIBEaIAsMBAIBBQECEQQBAQMCBh0DAgICJQEJARQBCAgCBAgGAQQBBxUEh2wMkDybKJEugSaMRYEBFhsHBoI7MmEDlHeDbZAXgw88MoEDNg Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 27 May 2013 13:26:30 +0200 Received: from E14MDB-02.zdv.Uni-Mainz.DE ([fe80::1b:21ff:fe65:4560]) by E14HUB-02.zdv.Uni-Mainz.DE ([fe80::21d:d8ff:feb7:1c60%9]) with mapi id 14.03.0123.003; Mon, 27 May 2013 13:26:29 +0200 From: =?utf-8?B?V2Vpw58sIErDvHJnZW4=?= To: "lev@FreeBSD.org" Subject: RE: Intel D2500CC motherboard and strange RS232/UART behavior Thread-Topic: Intel D2500CC motherboard and strange RS232/UART behavior Thread-Index: AQHOWLr+RGJp4UVRskiZKLoomm2bqZkY2Xfw Date: Mon, 27 May 2013 11:26:29 +0000 Message-ID: References: <682782182.20130525001205@serebryakov.spb.ru> In-Reply-To: <682782182.20130525001205@serebryakov.spb.ru> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'freebsd-current@freebsd.org'" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 11:26:38 -0000 SGVsbG8gTGV2LA0KDQp0byBiZSBwcmVjaXNlLCBJIGRpc2FibGVkIHNlcmlhbCBwb3J0cyAzIGFu ZCA0IGFuZA0Kc3dhcHBlZCBwb3J0cyAxIGFuZCAyIHRvIHRoZSBiYWNrIHBhbmVsIGluIHRoZQ0K bWFjaGluZSdzIEJJT1MuIA0KDQpUaGVuIEkgYWRkZWQgYSB0ZXN0IHRvIHRoZSBpb2FwaWNfY29u ZmlnX2ludHIgZnVuY3Rpb24NCnRvIGRldGVjdCB0aGUgIHRyaWcgPT0gSU5UUl9UUklHR0VSX0VE R0UgYW5kDQpwb2wgPT0gSU5UUl9QT0xBUklUWV9MT1cgY2FzZSBhbmQgdG8gcmV3cml0ZSBpdCB0 bw0KSU5UUl9UUklHR0VSX0VER0UgYW5kIElOVFJfVFJJR0dFUl9ISUdILg0KDQpJIGhhdmUgbm90 IHRyaWVkIHRvIGVuYWJsZSBwb3J0IDMgYW5kIDQgYmVjYXVzZSBJDQpjYW5ub3QgdGVzdCB0aGVt IChjb3VsZCBub3QgZmluZCB0aGUgbmVjZXNzYXJ5DQpjb25uZWN0b3JzKS4NCg0KUmVnYXJkcw0K DQpKdWVyZ2VuIFdlaXNzICAgICAgfFVuaXZlcnNpdGFldCBNYWlueiwgWmVudHJ1bSBmdWVyIERh dGVudmVyYXJiZWl0dW5nLA0Kd2Vpc3NAdW5pLW1haW56LmRlIHw1NTA5OSBNYWlueiwgVGVsOiAr NDkoNjEzMSkzOS0yNjM2MSwgRkFYOiArNDkoNjEzMSkzOS0yNjQwNw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIFtt YWlsdG86b3duZXItZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnXSBPbiBCZWhhbGYgT2YgTGV2 IFNlcmVicnlha292DQpTZW50OiBGcmlkYXksIE1heSAyNCwgMjAxMyAxMDoxMiBQTQ0KVG86IFdl acOfLCBKw7xyZ2VuDQpDYzogJ2ZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZycNClN1YmplY3Q6 IFJlOiBJbnRlbCBEMjUwMENDIG1vdGhlcmJvYXJkIGFuZCBzdHJhbmdlIFJTMjMyL1VBUlQgYmVo YXZpb3INCg0KSGVsbG8sIErDvHJnZW4uDQpZb3Ugd3JvdGUgMjQg0LzQsNGPIDIwMTMg0LMuLCAy MzoxNToxNzoNCg0KV0o+IEFjY29yZGluZyB0byB0aGUgQUNQSSBvZiB0aGUgYm9hcmQsIHVhcnQw IGFuZCB1YXJ0IDINCldKPiB1c2UgSVJRIDMgYW5kDQpXSj4gICAgICBJUlEgKEVkZ2UsIEFjdGl2 ZUxvdywgU2hhcmVkLCApDQpXSj4gICAgICAgIHszfQ0KV0o+IHVhcnQxIGFuZCB1YXJ0MyB1c2Ug SVJRIDQNCldKPiAgICAgIElSUSAoRWRnZSwgQWN0aXZlTG93LCBTaGFyZWQsICkNCldKPiAgICAg ICAgezR9DQoNCldKPiBpb2FwaWNfY29uZmlnX2ludHIgaXMgY2FsbGVkIHdpdGggdHJpZyA9PSBJ TlRSX1RSSUdHRVJfRURHRSBhbmQNCldKPiAgcG9sID09IElOVFJfUE9MQVJJVFlfTE9XLg0KDQpX Sj4gVGhlIGNvbWJpbmF0YXRpb24gb2YgRWRnZSBhbmQgQWN0aXZlTG93IHNlZW1zIGtpbmQgb2Yg YnJva2VuLg0KV0o+IEZvcmNpbmcgdGhlIHBvbGFyaXR5IGluIGlvYXBpY19jb25maWdfaW50ciB0 byBJTlRSX1BPTEFSSVRZX0hJR0gNCldKPiBhbmQgZGlzYWJsaW5nIHVhcnQgMiBhbmQgdWFydCAz IHJlc3VsdHMgaW4gdHdvIHdvcmtpbmcgc2VyaWFsDQpXSj4gaW50ZXJmYWNlcy4NCldKPiBTbyB3 aGF0IGlzIHRoZSBjb3JyZWN0IGZpeCB0byB0aGlzPw0KICAgIEkndmUgdHJpZWQgdG8gZGlzYWJs ZSBBQ1BJIGFjY2VzcyB0byB0aGVzZSBVQVJUcyBhdCBhbGwsIHRoZW4gb25seQ0KICB0d28gb2Yg dGhlbSBhcmUgZGV0ZWN0ZWQsIGJ1dCB0aGV5IGRvbid0IHdvcmsgZWl0aGVyLiBBbmQgSSBjYW5u b3QNCiAgZGlzYWJsZSAyIGFuZCAzLCBhcyBzY3JlZW4gSSBoYXZlIGF0dGFjaGVkIHRvIHRoaXMg Ym94IChvbGQgSUJNLW1hZGUNCiAgTENEIGZyb20gcmVnaXN0ZXIvY2FzaGllciBtYWNoaW5lLCB3 aGljaCB3b3JrcyBwZXJmZWN0bHkgd2l0aCBGcmVlQlNEDQogIGRlZmF1bHQgdGV4dCBjb25zb2xl IG9uIHRoaXMgTW9CbykgY2Fubm90IHNob3cgdGV4dCAoISkgQklPUyBzZXR1cA0KICBzY3JlZW4g dG8gbWUgLS0gaXQgc2hvd3Mgb25seSBibHVlIG5vaXNlIGFuZCBsb29rcyBsaWtlIGNvbXBlbHRl bHkNCiAgb3V0LW9mLXN5bmMuICBJIG5lZWQgdG8gYnJpbmcgdGhpcyBib3ggdG8gc29tZSBvdGhl ciBkaXNwYWx5IGFuZCB0cnkNCiAgdG8gZGlzYWJsZSB0aGVzZSB0d28gVUFSVHMgQU5EIGRpc2Fi bGUgQUNQSSBmb3IgdGhlbSB3aXRoIGxvYWRlcg0KICB0dW5hYmxlLg0KDQotLSANCi8vIEJsYWNr IExpb24gQUtBIExldiBTZXJlYnJ5YWtvdiA8bGV2QEZyZWVCU0Qub3JnPg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZnJlZWJzZC1jdXJyZW50QGZy ZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4v bGlzdGluZm8vZnJlZWJzZC1jdXJyZW50DQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0 byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-current@FreeBSD.ORG Mon May 27 12:13:49 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96577605 for ; Mon, 27 May 2013 12:13:49 +0000 (UTC) (envelope-from micchie@sfc.wide.ad.jp) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mx1.freebsd.org (Postfix) with ESMTP id 66AA8DD7 for ; Mon, 27 May 2013 12:13:48 +0000 (UTC) Received: from epi.lan (prova.iet.unipi.it [131.114.58.86]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 00A4A2780A9; Mon, 27 May 2013 21:13:42 +0900 (JST) Subject: Re: Changing CPU frequency for Xeon processors Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: <5197DF7C.1040305@vangyzen.net> Date: Mon, 27 May 2013 14:13:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1280DF1A-1DAC-43F1-A62D-B4DC9378FF88@sfc.wide.ad.jp> <5197DF7C.1040305@vangyzen.net> To: Eric van Gyzen X-Mailer: Apple Mail (2.1283) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 12:13:49 -0000 Thanks Eric, in case of HP Proliant DL120 G7 server, BIOS's = configuration needs to be "OS Control Mode". The similar would apply to other systems. Cheers, - Michio On May 18, 2013, at 10:07 PM, Eric van Gyzen wrote: > On 05/18/2013 10:09 AM, Michio Honda wrote: >> Hi, >>=20 >> I'm trying to experiment with downclocking CPU. >> My environment is 10.0-CURRENT amd64. >>=20 >> However, my CPU (Xeon E31220) seems not to be supported by the = cpufreq module, thus dmesg shows: >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >>=20 >> As a result, although sysctl -a shows the list of available frequency = values (dev.cpu.0.freq_levels: 3093/-1 2706/-1 2319/-1 1933/-1 1546/-1 = 1159/-1 773/-1 386/-1 >> dev.), I cannot set the value (the error message is "sysctl: = dev.cpu.0.freq=3D773: Device not configured"). >>=20 >> Do you have any idea to change CPU frequency for this CPU? >=20 > In my experience, the "not recognized" message indicates that the = feature is not enabled in the BIOS. >=20 > Eric > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@FreeBSD.ORG Mon May 27 13:34:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFACAC5D for ; Mon, 27 May 2013 13:34:00 +0000 (UTC) (envelope-from odeds@mellanox.com) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) by mx1.freebsd.org (Postfix) with ESMTP id 396C825D for ; Mon, 27 May 2013 13:33:59 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKUaNgrBg9kH8LlugUcS4y2+7x8ptk3TQq@postini.com; Mon, 27 May 2013 13:34:00 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Mon, 27 May 2013 16:33:31 +0300 From: Oded Shanoon To: "freebsd-current@freebsd.org" Subject: FreeBSD-10.0 code freeze Thread-Topic: FreeBSD-10.0 code freeze Thread-Index: Ac5a3lEVKtMrb1toS6y9Yju3Pr0wOg== Date: Mon, 27 May 2013 13:33:30 +0000 Message-ID: <058596FC127BDB469D7D60F04E37C63F7345AAB1@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 27 May 2013 13:40:49 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:34:01 -0000 Hi, I heard a rumor that the 10.0 code freeze will be in the end of July. Is that true? Can anyone tell me when does it plan to be? Regards, Oded Shanoon Ofed-FreeBSD team Mellanox Technologies, Raanana From owner-freebsd-current@FreeBSD.ORG Mon May 27 13:45:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B4C552AB; Mon, 27 May 2013 13:45:59 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6BCB3354; Mon, 27 May 2013 13:45:59 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r4RDjtnK032708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 May 2013 08:45:55 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Mon, 27 May 2013 08:45:55 -0500 From: "Teske, Devin" To: Oded Shanoon Subject: Re: FreeBSD-10.0 code freeze Thread-Topic: FreeBSD-10.0 code freeze Thread-Index: Ac5a3lEVKtMrb1toS6y9Yju3Pr0wOgALBm4A Date: Mon, 27 May 2013 13:45:54 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F62C7A@ltcfiswmsgmb21> References: <058596FC127BDB469D7D60F04E37C63F7345AAB1@MTLDAG01.mtl.com> In-Reply-To: <058596FC127BDB469D7D60F04E37C63F7345AAB1@MTLDAG01.mtl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-27_03:2013-05-27,2013-05-27,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:45:59 -0000 On May 27, 2013, at 6:33 AM, Oded Shanoon wrote: > Hi, >=20 > I heard a rumor that the 10.0 code freeze will be in the end of July. > Is that true? No. The release engineering team will shift focus to 9.2-R after the current fo= cus of 8.4-R. > Can anyone tell me when does it plan to be? >=20 10 will be the focal point sometime after 9.2-R. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Mon May 27 17:10:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A5B8347 for ; Mon, 27 May 2013 17:10:48 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 03C6BF0A for ; Mon, 27 May 2013 17:10:48 +0000 (UTC) Received: from [192.168.1.80] ([78.92.216.13]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LvPgd-1UFklJ497j-010YjN for ; Mon, 27 May 2013 19:10:47 +0200 Message-ID: <51A3938D.5000707@gmx.com> Date: Mon, 27 May 2013 19:10:37 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: bsd.qt.mk "(cc --version [...])" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qoAGhisd2bHw45h7OoAFDYNo5Sou4ZXWvUE5FIYRmo10oC4WOMg gGnn1qUykqezhOrivgz+eChHJrjPoYWfDf/KVL5Nd8Km9xU17n9mnsb1z/P948frH7hu+Cq NEuPGL/7yDPln/4x35a01AMsU4KQvHGMY1mlp6O44xBA2ibRa6N+tOnsTiKMPh8bcMU5bxo 5QkuWJ2xJDkMfhbIPc6pg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:10:48 -0000 There is no cc executable in the path (eg., there is no /usr/bin/cc) and the CC make-variable is set to an absolute path to the C compiler (Clang) in /etc/make.conf. Then, for example, cd /usr/ports/www/seamonkey && make config results in the following output: make: "/usr/ports/Mk/bsd.qt.mk" line 313: warning: Couldn't read shell's output for "(cc --version 2> /dev/null | /usr/bin/awk 'NR == 1 { gsub(/[()]/, "", $2); print $2 }') || echo "gcc"" TODO: fix. From owner-freebsd-current@FreeBSD.ORG Mon May 27 17:21:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 969608A0 for ; Mon, 27 May 2013 17:21:24 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 374C0FA3 for ; Mon, 27 May 2013 17:21:24 +0000 (UTC) Received: from [192.168.1.80] ([78.92.216.13]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LlpJU-1U7gM81bWq-00ZRJS for ; Mon, 27 May 2013 19:21:16 +0200 Message-ID: <51A39602.7010604@gmx.com> Date: Mon, 27 May 2013 19:21:06 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Building of libc in /usr/src/lib/libc results in error References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WGCMGd8J/8yArS3BSs31xaE7iJvocCYtRHnCnZ+wObjcczwtZzK yOHUdLQ5uR/VJaZkdVM2WkN+A4HJ/PKaQ6uWsXqxkbFAAhuDQWKyuQW5rIlKNA7px7BJtY4 22SDXQF0jAcPhZCW4f3ki/rrMcvt9ZWYdsNBqLviyyC6+s4eU93VFnFJK6d4+t2VUciZvsI Dr0v7sNcLTE5dxqeDavIw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 17:21:24 -0000 On 05/27/2013 02:28, Super Bisquit wrote: > building shared library libc.so.7 > /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. I have run into this issue multiple times in the past -- its occurrence seems to be correlated with header updates. As an instant workaround, you can add ALLOW_SHARED_TEXTREL=1 to /etc/make.conf for one buildworld&installworld run, and then do another run, for which ALLOW_SHARED_TEXTREL=1 will empirically not be required. From owner-freebsd-current@FreeBSD.ORG Mon May 27 20:08:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5ABE1FF8 for ; Mon, 27 May 2013 20:08:44 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2091B9A0 for ; Mon, 27 May 2013 20:08:43 +0000 (UTC) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3E62A5C44; Mon, 27 May 2013 22:08:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Building of libc in /usr/src/lib/libc results in error From: Dimitry Andric In-Reply-To: <51A39602.7010604@gmx.com> Date: Mon, 27 May 2013 22:08:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A39602.7010604@gmx.com> To: dt71@gmx.com X-Mailer: Apple Mail (2.1503) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 20:08:44 -0000 On May 27, 2013, at 19:21, dt71@gmx.com wrote: > On 05/27/2013 02:28, Super Bisquit wrote: >> building shared library libc.so.7 >> /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. >=20 > I have run into this issue multiple times in the past -- its = occurrence seems to be correlated with header updates. As an instant = workaround, you can add ALLOW_SHARED_TEXTREL=3D1 to /etc/make.conf for = one buildworld&installworld run, and then do another run, for which = ALLOW_SHARED_TEXTREL=3D1 will empirically not be required. This may work around the issue, but it will not solve the root cause. Normally, you should never get these warnings, so there must be something special about your environment. Can you post your make.conf, src.conf and any other relevant settings? -Dimitry From owner-freebsd-current@FreeBSD.ORG Mon May 27 21:17:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 550BAB34; Mon, 27 May 2013 21:17:56 +0000 (UTC) (envelope-from kczekirda@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id B1993DD0; Mon, 27 May 2013 21:17:55 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi5so1906797wib.14 for ; Mon, 27 May 2013 14:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8A7MNetZVlKd/QBVP8aIJvDwPS1PRTcI2VBFR0mMM3E=; b=cyMeLV+cbOKCn0NZOV3L8lX60WealyxnUDEDnC9PqfpUr+IHJYg/9Iqd21NbltCRpl JqatnKrQyHrFUhPTnMRnbsYPYk+sxpQ3OAGYPjsNYXrTesi18oJ9Duw9/ZyzonrSCGFE OrKhHNnGbRuQLzZK2Yti5WPHGqBNMOF+ZyQ1OAAUqAw46EX/cymIvVv28dNAHG8BZg4k ZgZ2G3HRiOB/tRCZd4orR9OX8QPIwf5i9r0hCcmz2OE7546kRA8dSGBwEWPZ5EfEQacC Barkyezxv2PphNOWcWuNzWP/sj0tuTWAyZkpFNrksFHM2kOgV+N2QBMi7uvCS9vCjuKN URow== MIME-Version: 1.0 X-Received: by 10.180.74.207 with SMTP id w15mr9583499wiv.19.1369689473908; Mon, 27 May 2013 14:17:53 -0700 (PDT) Received: by 10.194.94.129 with HTTP; Mon, 27 May 2013 14:17:53 -0700 (PDT) In-Reply-To: References: <201304291221.19725.jhb@freebsd.org> <201305090816.11525.jhb@freebsd.org> Date: Mon, 27 May 2013 23:17:53 +0200 Message-ID: Subject: Re: FreeBSD & Intel AMT From: Kamil Czekirda To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:17:56 -0000 >From observation: volt% amttool-tng k5 rem_control info ## 'k5' :: AMT Remote Control FAULT: 500 Can't connect to k5:16992 (Invalid argument) (1) k5% sudo ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=4219b ether e8:40:f2:ec:60:5e inet 10.146.103.5 netmask 255.255.0.0 broadcast 10.146.255.255 media: Ethernet autoselect (1000baseT ) status: active k5% sudo ifconfig em0 -tso4 Doesn't work immediately, but AMT starts to work. volt% amttool-tng k5 rem_control info ## 'k5' :: AMT Remote Control FAULT: 500 Can't connect to k5:16992 (Invalid argument) (1) volt% amttool-tng k5 rem_control info ## 'k5' :: AMT Remote Control # Remote Control Info :: AMT Remote Control Powerstate: S0 Watchdog Expired: No Power Source: AC Remote Control Capabilities: Control Commands Supported powerCycle powerDown powerUp reset IanaOemNumber 343 Special Commands Supported PXE-boot HD-boot CD-boot Special Commands (Oem) IDER SOL BiosReflash BiosSetup BiosPause SystemFirmwareCapabilities LockKeyboard UserPasswordBypass ForcedProgressEvents VerbosityVerbose VerbosityQuiet VerbosityScreenBlank Is it normal? When KVM sesion is open network card works only on 10baseT standard. You cannot change speed: k8% # ifconfig em0 media 1000baseT & k8% # lo kernel -2 May 25 01:01:14 k8 kernel: em0: Media change is blocked due to SOL/IDER session. May 25 01:02:16 k8 kernel: em0: Media change is blocked due to SOL/IDER session. After closig KVM connection with VNC Viewer: k8% # ifconfig em0 media 1000baseT k8% ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=4219b inet 10.146.103.8 netmask 255.255.0.0 broadcast 10.146.255.255 media: Ethernet 1000baseT (1000baseT ) status: active And very important: after speed change AMT works fine. Any kind of reset network card makes AMT good, for example: ifconfig em0 -txcsum 2013/5/14 Kamil Czekirda : > Motherboard: Intel DQ77KB, the latest BIOS & AMT fw. > both ethernet interfaces connected, > DHCP configured only the the first (managment) or only the second - the > same result: > after appr. 5 min ? AMT can't be accesed. > (Same result on a few such a PCs which we have about ten in lab) > > FreeBSD: > 9.1 amd64, SVN-updated and recompiled (kernel+world) on 11 May: > > if_em driver: > em0: port 0xf080-0xf09f mem > 0xf7e00000-0xf7e1ffff, > 0xf7e39000-0xf7e39fff irq 20 at d > em1: port 0xe000-0xe01f mem > 0xf7c00000-0xf7c1ffff,0xf7c20000-0xf7c23fff irq 18 at d > > k1% uname -a > FreeBSD k1 9.1-STABLE FreeBSD 9.1-STABLE #0: Sat May 11 23:22:00 CEST 2013 > > k1% biosver > Version: KBQ7710H.86A.0049.2013.0130.1732 > Release Date: 01/30/2013 > smbios.bios.reldate="01/30/2013" > smbios.bios.vendor="Intel Corp." > smbios.bios.version="KBQ7710H.86A.0049.2013.0130.1732" > smbios.chassis.maker=" " > smbios.chassis.serial=" " > smbios.chassis.tag=" " > smbios.chassis.version=" " > smbios.memory.enabled="4194304" > smbios.planar.maker="Intel Corporation" > smbios.planar.product="DQ77KB" > smbios.planar.serial="BTKB22100SUJ" > smbios.planar.version="AAG40294-401" > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker=" " > smbios.system.product=" " > smbios.system.serial=" " > smbios.system.uuid="7fe1575d-31a4-e111-9b80-6431503407e9" > smbios.system.version=" " > smbios.version="2.7" > > k1% # lspci > 00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09) > 00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics > Controller (rev 09) > 00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host > Controller (rev 04) > 00:16.0 Communication controller: Intel Corporation Panther Point MEI > Controller #1 (rev 04) > 00:16.3 Serial controller: Intel Corporation Panther Point KT Controller > (rev 04) > 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network > Connection (rev 04) > 00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host > Controller #2 (rev 04) > 00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio > Controller (rev 04) > 00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 > (rev c4) > 00:1c.2 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 3 > (rev c4) > 00:1c.6 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 7 > (rev c4) > 00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host > Controller #1 (rev 04) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) > 00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04) > 00:1f.2 SATA controller: Intel Corporation Panther Point 6 port SATA > Controller [AHCI mode] (rev 04) > 00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04) > 02:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev > 35) > 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > > I can provide you all info, and ssh/vnc acces (with root) to this diskeless > PCs if you prefer. > > > 2013/5/14 Jack Vogel >> >> I need to know the details on the hardware this is on, and was it working >> on some previous >> version of FreeBSD and broke in STABLE or what? >> >> Jack >> >> >> >> On Mon, May 13, 2013 at 2:44 PM, Kamil Czekirda >> wrote: >>> >>> Jack, do you have any ideas to resolve problem, on new Debian 7 and >>> Ubuntu 13.10 AMT working fine. >>> >>> >>> 2013/5/9 John Baldwin >>>> >>>> On Thursday, May 09, 2013 4:34:16 am Kamil Czekirda wrote: >>>> > Do you have any ideas to resolve the problem? >>>> >>>> I have no idea what part of e1000 common code deals with AMT/IPMI and >>>> what you >>>> might need to do to make this work. I was hoping Jack would be be able >>>> to >>>> respond here. >>>> >>>> > 2013/4/29 John Baldwin >>>> > >>>> > > On Friday, April 26, 2013 5:17:34 pm Kamil Czekirda wrote: >>>> > > > We have a problem with Intel AMT and FreeBSD. We have AMT version: >>>> > > > 8.1.20-build 1336. AMT stop responding about five minutes after >>>> > > > booting >>>> > > > FreeBSD, it's FreeBSD 9.1-STABLE, 64 bit. >>>> > > > On Linux AMT works fine. We suspect driver, but it's similar like >>>> > > > on >>>> > > Linux. >>>> > > > Can you show us the way to resolve this problem? >>>> > > >>>> > > While the e1000 drivers share the same common code, there are some >>>> > > differences >>>> > > in the OS-dependent bits (e.g. if_igb.c, etc.). I've cc'd Jack >>>> > > Vogel who >>>> > > maintains the e1000 drivers in FreeBSD. >>>> > > >>>> > > -- >>>> > > John Baldwin >>>> > > >>>> > >>>> >>>> -- >>>> John Baldwin >>> >>> >> > From owner-freebsd-current@FreeBSD.ORG Mon May 27 23:35:24 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4D37A49E for ; Mon, 27 May 2013 23:35:24 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 11E0F372 for ; Mon, 27 May 2013 23:35:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DF47D7300A; Tue, 28 May 2013 01:38:01 +0200 (CEST) Date: Tue, 28 May 2013 01:38:01 +0200 From: Luigi Rizzo To: current@freebsd.org Subject: copyin+copyout in one step ? Message-ID: <20130527233801.GA32042@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 23:35:24 -0000 Hi, say a process P1 wants to use the kernel to copy the content of a buffer SRC (in its user address space) to a buffer DST (in the address space of another process P2), and assume that P1 issues the request to the kernel when P2 has already told the kernel where the data should go: P1 P2 +------+ +--------+ | SRC | | DST | +--v---+ +--^-----+ --------|------------------------|---------- | | kernel | ^ | | | +--------+ | +----->| tmpbuf +--------+ copyin| | copyout P1 ctx+--------+ P2 ctx I guess the one above is the canonical way: P1 does a copyin() to a temporary buffer, then notifies P2 which can then issue or complete a syscall to do a copyout from tmpbuf to DST in P2's context. But I wonder, is it possible to do it as follows: P2 tells the kernel where the data should go (DST); later, P1 issues a system call and through a combined "copyinout()" moves data directly from SRC to DST, operating in the context of P1. | copyinout() ? | +------------>-----------+ issued by P1 Is this doable at all ? I suspect that "tell DST to the kernel" might be especially expensive as it needs to pin the page so it is accessible while doing the syscall for P1 ? (the whole point for this optimization is saving the extra copy through the buffer, but it may be pointless if pinning the memory is more expensive than the copy) cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon May 27 23:56:11 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC6ED95F for ; Mon, 27 May 2013 23:56:11 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CBD0D616 for ; Mon, 27 May 2013 23:56:11 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 536FA1A3D15; Mon, 27 May 2013 16:56:08 -0700 (PDT) Message-ID: <51A3F297.5000201@mu.org> Date: Mon, 27 May 2013 16:56:07 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: copyin+copyout in one step ? References: <20130527233801.GA32042@onelab2.iet.unipi.it> In-Reply-To: <20130527233801.GA32042@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 23:56:11 -0000 On 5/27/13 4:38 PM, Luigi Rizzo wrote: > Hi, > say a process P1 wants to use the kernel to copy the content of a > buffer SRC (in its user address space) to a buffer DST (in the > address space of another process P2), and assume that P1 issues the > request to the kernel when P2 has already told the kernel where the > data should go: > > P1 P2 > +------+ +--------+ > | SRC | | DST | > +--v---+ +--^-----+ > --------|------------------------|---------- > | | kernel > | ^ > > | | > | +--------+ | > +----->| tmpbuf +--------+ > copyin| | copyout > P1 ctx+--------+ P2 ctx > > I guess the one above is the canonical way: P1 does a copyin() to a > temporary buffer, then notifies P2 which can then issue or complete > a syscall to do a copyout from tmpbuf to DST in P2's context. > > > But I wonder, is it possible to do it as follows: P2 tells the kernel > where the data should go (DST); later, P1 issues a system call and > through a combined "copyinout()" moves data directly from SRC to DST, > operating in the context of P1. > > | copyinout() ? | > +------------>-----------+ > issued by P1 > > > Is this doable at all ? I suspect that "tell DST to the kernel" > might be especially expensive as it needs to pin the page > so it is accessible while doing the syscall for P1 ? > (the whole point for this optimization is saving the extra > copy through the buffer, but it may be pointless if pinning > the memory is more expensive than the copy) > I suspect you'll want to use something like vslock(9) and sf_bufs. Have a look at vm/vm_glue.c -> vslock() vm_imgact_hold_page(). On amd64, I *think* mapping an sfbuf or if you are really evil you can optimistically wire the page in the vm (cheap). If it's present then you can just use the direct map to access it. However, if it's not present, then fall back to another method, or maybe just fault it in (which will have to happen anyhow) and then retry. Sounds like a cool project! -Alfred From owner-freebsd-current@FreeBSD.ORG Tue May 28 01:10:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F3BCC77 for ; Tue, 28 May 2013 01:10:15 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5186EC17 for ; Tue, 28 May 2013 01:10:15 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 9978E1A3C3F; Mon, 27 May 2013 18:10:11 -0700 (PDT) Message-ID: <51A403F3.1080905@mu.org> Date: Mon, 27 May 2013 18:10:11 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: copyin+copyout in one step ? References: <20130527233801.GA32042@onelab2.iet.unipi.it> <51A3F297.5000201@mu.org> In-Reply-To: <51A3F297.5000201@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 01:10:15 -0000 On 5/27/13 4:56 PM, Alfred Perlstein wrote: > On 5/27/13 4:38 PM, Luigi Rizzo wrote: >> Hi, >> say a process P1 wants to use the kernel to copy the content of a >> buffer SRC (in its user address space) to a buffer DST (in the >> address space of another process P2), and assume that P1 issues the >> request to the kernel when P2 has already told the kernel where the >> data should go: >> >> P1 P2 >> +------+ +--------+ >> | SRC | | DST | >> +--v---+ +--^-----+ >> --------|------------------------|---------- >> | | kernel >> | ^ >> >> | | >> | +--------+ | >> +----->| tmpbuf +--------+ >> copyin| | copyout >> P1 ctx+--------+ P2 ctx >> >> I guess the one above is the canonical way: P1 does a copyin() to a >> temporary buffer, then notifies P2 which can then issue or complete >> a syscall to do a copyout from tmpbuf to DST in P2's context. >> >> >> But I wonder, is it possible to do it as follows: P2 tells the kernel >> where the data should go (DST); later, P1 issues a system call and >> through a combined "copyinout()" moves data directly from SRC to DST, >> operating in the context of P1. >> >> | copyinout() ? | >> +------------>-----------+ >> issued by P1 >> >> >> Is this doable at all ? I suspect that "tell DST to the kernel" >> might be especially expensive as it needs to pin the page >> so it is accessible while doing the syscall for P1 ? >> (the whole point for this optimization is saving the extra >> copy through the buffer, but it may be pointless if pinning >> the memory is more expensive than the copy) >> > I suspect you'll want to use something like vslock(9) and sf_bufs. > > Have a look at vm/vm_glue.c -> vslock() vm_imgact_hold_page(). > > On amd64, I *think* mapping an sfbuf or if you are really evil you can > optimistically wire the page in the vm (cheap). If it's present then > you can just use the direct map to access it. However, if it's not > present, then fall back to another method, or maybe just fault it in > (which will have to happen anyhow) and then retry. > > Sounds like a cool project! > > -Alfred Oh, one other thing.. look at the pipe code. It used to do what you suggest, I think however it was driven by the READER pinning the WRITER's address space and doing a direct copy. However it may not be optimized for NOT-mapping into kva as I suggested doing. -Alfred From owner-freebsd-current@FreeBSD.ORG Tue May 28 04:30:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58998B31 for ; Tue, 28 May 2013 04:30:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A9F3B6DA for ; Tue, 28 May 2013 04:30:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4S4UKo4054903; Tue, 28 May 2013 07:30:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4S4UKo4054903 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4S4UKjm054900; Tue, 28 May 2013 07:30:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 May 2013 07:30:20 +0300 From: Konstantin Belousov To: Luigi Rizzo Subject: Re: copyin+copyout in one step ? Message-ID: <20130528043020.GK3047@kib.kiev.ua> References: <20130527233801.GA32042@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r8byAqrdRIFBlIsc" Content-Disposition: inline In-Reply-To: <20130527233801.GA32042@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 04:30:35 -0000 --r8byAqrdRIFBlIsc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 28, 2013 at 01:38:01AM +0200, Luigi Rizzo wrote: > Hi, > say a process P1 wants to use the kernel to copy the content of a > buffer SRC (in its user address space) to a buffer DST (in the > address space of another process P2), and assume that P1 issues the > request to the kernel when P2 has already told the kernel where the > data should go: >=20 > P1 P2 > +------+ +--------+ > | SRC | | DST | > +--v---+ +--^-----+ > --------|------------------------|---------- > | | kernel > | ^ >=20 > | | > | +--------+ | > +----->| tmpbuf +--------+ > copyin| | copyout > P1 ctx+--------+ P2 ctx >=20 > I guess the one above is the canonical way: P1 does a copyin() to a > temporary buffer, then notifies P2 which can then issue or complete > a syscall to do a copyout from tmpbuf to DST in P2's context. >=20 >=20 > But I wonder, is it possible to do it as follows: P2 tells the kernel > where the data should go (DST); later, P1 issues a system call and > through a combined "copyinout()" moves data directly from SRC to DST, > operating in the context of P1. >=20 > | copyinout() ? |=20 > +------------>-----------+ > issued by P1 >=20 >=20 > Is this doable at all ? I suspect that "tell DST to the kernel" > might be especially expensive as it needs to pin the page > so it is accessible while doing the syscall for P1 ? > (the whole point for this optimization is saving the extra > copy through the buffer, but it may be pointless if pinning > the memory is more expensive than the copy) Yes, it is doable. If the copy can happen when either P1 or P2 are active context, then proc_rwmem() already perform exactly what you want. The virtual address in the address space of the 'other process' is specified as uio->uio_offset. The iov specifies the region(s) for the current process. If you want to perform the copy from P1 to P2 while some other context P3 is active, the same structure as proc_rwmem() would work, but you=20 obviously would need to do vm_fault_hold() for both sides, and use pmap_copy_pages() instead of uiomove_fromphys(). In either case, you get copy without temporal buffer, but the setup cost could be non-trivial. You never know until measured. --r8byAqrdRIFBlIsc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRpDLbAAoJEJDCuSvBvK1BicIP/1HZ6RCNYOptpCPACQSbbmlS ZxI5JNperAKY9c1eTaAH1FhaSAfdXs47NCf1Lf+vfZTo6eSUEvbP0GAfPEMCI1r5 QVlGZVbShP626DwnrEfmaAuv9Es8vANOm259Coi/3G5LN/NxurHs+1RgLvHu48tD j0dZnfsWmlvwR0XEjPQPn4SZXfUr5Poj0ezf9s8Vz4foA2RJSA3RZo79HwYFSBbp ppM0gJzGMYa/XQtiSfxwa1M13GCnwJ9H4oUJCgQ+fnO6GWJS/jJbDezhi+Ec3A1O 6VfmIL58v19PmqPsH/k0hMvLXOZeqPDfuhf7ClmSjXOLSB4EVVojf1bd1JkM3v5R 65UuGne2C/0FfWwbznkL4ut8DavF3oZO9K+Lc3X6z7303E1Iq9fMn2beB9IevWpC bWh6ggFLcS3KFbb+T1dSNLwJhJbE0H8eOWMWyZ6mh/w00iQdHVDklywhBigfKTv2 o71ODhpvFVgzB0DmVDmLovyXM/xlZCNZq28a49kYzCJKAH8j7IQjL+PQ6eX3SjgR yyxjxpQNjMUAtJR8VR+t4EcVCx710OKQ44c6tavseNox8w8Kvn6Xxu00kX+UJSHS R3l0awZbI6WLnd5XH5ONdsMRiut2zigkOUubKv1daSG6ISnY0IDO44vK71litOnq 9m8cn8ntoFMEmJzPNWJq =Jz0x -----END PGP SIGNATURE----- --r8byAqrdRIFBlIsc-- From owner-freebsd-current@FreeBSD.ORG Tue May 28 04:56:56 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7AD6F559 for ; Tue, 28 May 2013 04:56:56 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id 40B8080D for ; Tue, 28 May 2013 04:56:56 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id ht10so5134005vcb.4 for ; Mon, 27 May 2013 21:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vti4IgqM6crQ6kGenJwitKhwsJMpwWVEwvH1YtWWX+s=; b=KIPyqGZDzjdOjStHgjvnqmrufgXcMSnKxw8vZ7cxwf+Ia0lxk75yIG8zL6Vyj3uDCV r9WsHLMEEhsGjp41ckgTyJojdvmcQwRz41udeCiqY92V84PSdsH7DlnpnF6kDW538RaS nxoGgrysvLMl/kj7qCtm88dEK75+rdXv+GNk5p9vUHRj9X5KlZ0oSEhW40ndi5A5kvx0 yUkwIxQqOiWQ8fIm+K2AbwQFUwrSunWrSl/DQUcTykO8b+xTdS5ZkVaCeIUdhT+Op7xR jr3Uw4an9//CTHnG36aIkTeMjWL/bL8Oyygw5qVyuGxJ71IOZ947tdo/+1DXGBwJqTXG KE8w== MIME-Version: 1.0 X-Received: by 10.220.73.135 with SMTP id q7mr16856841vcj.33.1369717014499; Mon, 27 May 2013 21:56:54 -0700 (PDT) Received: by 10.220.123.6 with HTTP; Mon, 27 May 2013 21:56:54 -0700 (PDT) In-Reply-To: <20130527233801.GA32042@onelab2.iet.unipi.it> References: <20130527233801.GA32042@onelab2.iet.unipi.it> Date: Tue, 28 May 2013 00:56:54 -0400 Message-ID: Subject: Re: copyin+copyout in one step ? From: Zaphod Beeblebrox To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 04:56:56 -0000 On Mon, May 27, 2013 at 7:38 PM, Luigi Rizzo wrote: > > say a process P1 wants to use the kernel to copy the content of a > buffer SRC (in its user address space) to a buffer DST (in the > address space of another process P2), and assume that P1 issues the > request to the kernel when P2 has already told the kernel where the > data should go: > Urm... Isn't the use of shared memory the more obvious way to transfer data between processes? Am I missing some nuance? From owner-freebsd-current@FreeBSD.ORG Tue May 28 09:43:35 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DF446B0 for ; Tue, 28 May 2013 09:43:35 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 32B6A838 for ; Tue, 28 May 2013 09:43:34 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r4S9hNLl041676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 09:43:24 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: copyin+copyout in one step ? From: David Chisnall In-Reply-To: Date: Tue, 28 May 2013 10:43:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D03D7B6-7530-4CCD-859B-FD6374E40424@FreeBSD.org> References: <20130527233801.GA32042@onelab2.iet.unipi.it> To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1503) Cc: Luigi Rizzo , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 09:43:35 -0000 On 28 May 2013, at 05:56, Zaphod Beeblebrox wrote: > Urm... Isn't the use of shared memory the more obvious way to transfer = data > between processes? Am I missing some nuance? I can't speak for Luigi's use-case, but the Binder APIs in BeOS and = Android call for this kind of copy. The receiving process contains a = ring buffer and the messages are pushed into it. You could implement = this in shared memory, but only if you trusted the sender not to modify = the data at incorrect times or write invalid values into the metadata = (or, in the case of Binder, to forge the pid / uid of the sender, which = it attached to each message). The kernel must act as an intermediary to = enforce correct use of the buffer and also to allow the caller to block = until space is available (perhaps by scheduling the receiver to run for = a bit) without spinning and to allow multiple writers to be queued when = there is no space, rather than have them racing. The buffers are in the = receiver's memory space because it is designed for resource constrained = environments and for malicious parties to communicate, so it avoids a = potential DoS by filling up kmem with buffers - a process that create a = load of receive ports will simply fill up its own address space and die. In the specific case of binder, you can avoid the overhead of extra VM = lookups by mapping the buffer into the address space of every sender = when you open the connection, but marking its access as privileged mode = only. This means that you'll be doing a simple copy. You can also = align the receive buffer in such a way that the consume counter is on a = different page to the rest of the data structure, allowing you to get a = page fault when the buffer transitions from full to non-full and there = are messages waiting. David From owner-freebsd-current@FreeBSD.ORG Tue May 28 09:51:58 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CF7BB10 for ; Tue, 28 May 2013 09:51:58 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id EC8608BE for ; Tue, 28 May 2013 09:51:57 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id t10so7585185lbi.32 for ; Tue, 28 May 2013 02:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OkWxA6bErHtDlXWo7Q1sWODMuUXQQ98sX3oNBx7FSKo=; b=mf07nE2C2cJ1ZO4lghnjhEuO4SkFyzVhl5Uq+U15AB1Io5YBHA/1hhTgYIvA8yAtMb zbLMGz3M1O9FErdS1kQhPoG23qA+sw9+p6kBgAKQg9vypsyJGRfu3PW79lr5PvpQZgPC Rp5Jrx/10QzoUjYRG6S1rbB+F/CNknY2DONleMSeo5DlZ276yv0yO3yknmqhKTsKqpUY LpGiI3pJJjizFniU+GJRRZ6MocN9sMZOCvNRGSr+QQzVMgPY3tR4HWS8SDb0CQTaM8Jw 4tmaEBUDCQilbCTP1GoJKJHrYkSlrPwKnuJh3mhGp5kKkbYOKRZf9cbL5qO1KbPhhxhN sdNw== MIME-Version: 1.0 X-Received: by 10.112.145.100 with SMTP id st4mr16029934lbb.102.1369734716519; Tue, 28 May 2013 02:51:56 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.181.42 with HTTP; Tue, 28 May 2013 02:51:56 -0700 (PDT) In-Reply-To: References: <20130527233801.GA32042@onelab2.iet.unipi.it> Date: Tue, 28 May 2013 11:51:56 +0200 X-Google-Sender-Auth: HdqJVHzCG-r51kOD1Fn69lpv7R8 Message-ID: Subject: Re: copyin+copyout in one step ? From: Luigi Rizzo To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 09:51:58 -0000 On Tue, May 28, 2013 at 6:56 AM, Zaphod Beeblebrox wrote: > On Mon, May 27, 2013 at 7:38 PM, Luigi Rizzo wrote: > >> >> say a process P1 wants to use the kernel to copy the content of a >> buffer SRC (in its user address space) to a buffer DST (in the >> address space of another process P2), and assume that P1 issues the >> request to the kernel when P2 has already told the kernel where the >> data should go: >> > > Urm... Isn't the use of shared memory the more obvious way to transfer > data between processes? Am I missing some nuance? > see my other message about the use between VMs. I cannot simply share memory because otherwise the sender could alter the message while the receiver is playing with it, so at least one copy is needed (or page flipping, but that would be way more complex/wasteful/ expensive) . But also, in my case the source and destination buffers are chosen arbitrarily by the two VMs, and do not necessarily reside in the mmapped buffers that the kernel module provides. So at the moment I have three copies instead of one. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue May 28 13:23:35 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0ABB34E for ; Tue, 28 May 2013 13:23:35 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 957F2A4A for ; Tue, 28 May 2013 13:23:35 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k13so1591306iea.32 for ; Tue, 28 May 2013 06:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nJMeqnhcTNpp4j2L0y0Gj3uAD1Db0jbEr7d2TiRgqs0=; b=MWtfPUjQ7Ak+oJmGKUW43xIFsXmrJzTtLC21OnETk4BrvR/a1FHsesC/MM+dzJybgp XSBpNdPXMMBNilzQyVCJTD56WCdPhR+eU4MVEPSNcP9Ap+MgBIOP7KTBeTDnUv/K44PD s/tuAkrJFtnjGBrOf+KZ1yOA3S4KvtItDpFgO3M7BuW9bZFhA9VrW8z8kTK/W2eKEH/3 RAEUzsw1tjul2eSXnVjDZSwwBbZpGQ/r9EktDVt7wg5dbUd+k2zyhVGHHytUlEg+mkpi ng+5m355swvIVO2Zg9F1KqOufZfms1HBBR78ymnGeWMQEPywX7KLJ9b6+gH+l5OBDiZU QWfg== X-Received: by 10.50.73.226 with SMTP id o2mr6838612igv.22.1369747414900; Tue, 28 May 2013 06:23:34 -0700 (PDT) Received: from gloom.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPSA id wn10sm18009041igb.2.2013.05.28.06.23.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 06:23:34 -0700 (PDT) Date: Tue, 28 May 2013 09:23:18 -0400 From: Mark Johnston To: Michael Butler Subject: Re: make: "/usr/ports/mail/postfix/Makefile" line 92: warning: Couldn't read shell's output ... Message-ID: <20130528132318.GA4041@gloom.sandvine.com> References: <51A2AB48.6030101@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A2AB48.6030101@protected-networks.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 13:23:35 -0000 On Sun, May 26, 2013 at 08:39:36PM -0400, Michael Butler wrote: > What's up with this? > > imb@toshi:/home/imb> sudo portupgrade -aR > make: "/usr/ports/mail/postfix/Makefile" line 92: warning: Couldn't read > shell's output for "/usr/bin/grep -m 1 '^purgestat' > /etc/mail/mailer.conf || true" I've been seeing this in a few other places. It looks like bmake prints this warning when the shell command in a '!=' assignment doesn't print anything to stdout. For instance, the line below will trigger a warning with bmake: FOO!=/usr/bin/true -Mark From owner-freebsd-current@FreeBSD.ORG Tue May 28 15:15:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0CF18D90 for ; Tue, 28 May 2013 15:15:53 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id E94CA1B3 for ; Tue, 28 May 2013 15:15:52 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,758,1363158000"; d="scan'208";a="58768637" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 28 May 2013 08:15:46 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4SFFkKZ023778; Tue, 28 May 2013 08:15:46 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.208]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Tue, 28 May 2013 08:13:02 -0700 From: "Eggert, Lars" To: Rick Macklem Subject: Re: mounting root from NFS via ROOTDEVNAME Thread-Topic: mounting root from NFS via ROOTDEVNAME Thread-Index: AQHN/WoQ3bLz4fhIpUOOqbDPPwYM3JhhN1MAgADtYYCAAMxdgIAA5iiAgABChICAt8x3gA== Date: Tue, 28 May 2013 15:13:02 +0000 Message-ID: <375AA8A5-E385-4528-A460-D4B8FCB9497B@netapp.com> References: <1435656219.2547176.1359645941027.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1435656219.2547176.1359645941027.JavaMail.root@erie.cs.uoguelph.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <14DA5930BE4AAC4E88CBEFBC3589C8B0@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Craig Rodrigues , "" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:15:53 -0000 Hi, to conclude this thread, the patch below allows one to specify an nfs rootf= s via the ROOTDEVNAME kernel option, which will be mounted when BOOTP does = not return a root-path option. Lars diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c index 2c57a91..972fb12 100644 --- a/sys/nfs/bootp_subr.c +++ b/sys/nfs/bootp_subr.c @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$"); =20 #include "opt_bootp.h" #include "opt_nfs.h" +#include "opt_rootdevname.h" =20 #include #include @@ -870,8 +871,20 @@ bootpc_call(struct bootpc_globalcontext *gctx, struct = thread *td) rtimo =3D time_second + BOOTP_SETTLE_DELAY; printf(" (got root path)"); - } else + } else { printf(" (no root path)"); +#ifdef ROOTDEVNAME + /* + * If we'll mount rootfs from + * ROOTDEVNAME, we can accept + * offers without root paths. + */ + gotrootpath =3D 1; + rtimo =3D time_second + + BOOTP_SETTLE_DELAY; + printf(" (ROOTDEVNAME)"); +#endif + } printf("\n"); } } /* while secs */ @@ -1440,6 +1453,16 @@ bootpc_decode_reply(struct nfsv3_diskless *nd, struc= t bootpc_ifcontext *ifctx, =20 p =3D bootpc_tag(&gctx->tag, &ifctx->reply, ifctx->replylen, TAG_ROOT); +#ifdef ROOTDEVNAME + /* + * If there was no root path in BOOTP, use the one in ROOTDEVNAME. + */ + if (p =3D=3D NULL) { + p =3D strdup(ROOTDEVNAME, M_TEMP); + if (strcmp(strsep(&p, ":"), "nfs") !=3D 0) + panic("ROOTDEVNAME is not an NFS mount point"); + } +#endif if (p !=3D NULL) { if (gctx->setrootfs !=3D NULL) { printf("rootfs %s (ignored) ", p); From owner-freebsd-current@FreeBSD.ORG Tue May 28 18:20:53 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 616EFDDD for ; Tue, 28 May 2013 18:20:53 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 486A8D1F for ; Tue, 28 May 2013 18:20:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4SIKrBt000231 for ; Tue, 28 May 2013 18:20:53 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4SIKrlV000229 for current@freebsd.org; Tue, 28 May 2013 18:20:53 GMT (envelope-from bdrewery) Received: (qmail 6047 invoked from network); 28 May 2013 13:20:51 -0500 Received: from unknown (HELO ?173.160.118.90?) (freebsd@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 28 May 2013 13:20:51 -0500 Message-ID: <51A4F585.60401@FreeBSD.org> Date: Tue, 28 May 2013 13:20:53 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Sergey V. Dyatko" Subject: Re: Supermicro 6027R-N3RF+head, usb trouble References: <20130421223838.6bec3bfb@laptop.minsk.domain> In-Reply-To: <20130421223838.6bec3bfb@laptop.minsk.domain> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2PITNVXIWALCUJQTOLCAE" Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 18:20:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PITNVXIWALCUJQTOLCAE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: > Hi, >=20 > Can anybody explain why USB keyboard (and keyboard from > integrated IPKVM) doesn't work when I boot with 'C606 > chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? > Also I can't boot that box from usb memstick and > FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both > loose(?) device and can't find root If I disable controller in bios > system can't see any sata hdd connected to it:( > booting with hw.usb.ehci.no_hs=3D1, kern.cam.boot_delay=3D"10000" > and debug.acpi.disabled=3D"hostres" without success. I setup dhcpd, tft= p, > nfs on my laptop and finally I install fbsd on that box, but question > with kbd is open - It doesn't work.. > dmesg: > http://svn.freebsd.by/files/dmesg_N3RF.txt > pciconf -lv: > http://svn.freebsd.by/files/pciconf_N3RF.txt >=20 > I would appreciate any hints >=20 I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE (disc1) seems ok though. Did you get this figured out? My startup: > uhub1: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 > usbd_ctrl_transfer_setup: could not setup default USB transfer > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB= _ERR_NOMEM > Root mount waiting for: usbus1 > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_NOMEM, ig= nored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB= _ERR_NOMEM > Root mount waiting for: usbus1 > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_NOMEM, ig= nored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB= _ERR_NOMEM > Root mount waiting for: usbus1 > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_NOMEM, ig= nored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB= _ERR_NOMEM > Root mount waiting for: usbus1 > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_NOMEM, ig= nored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB= _ERR_NOMEM > ugen1.2: at usbus1 (disconnected) > uhub_reattach_port: could not allocate new device --=20 Regards, Bryan Drewery ------enig2PITNVXIWALCUJQTOLCAE 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.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpPWIAAoJEG54KsA8mwz5NuIP/An9wZM0Gekz1xRyjweccCXl huv0TTZ6fEGgDuh6P+nsAchgkalNqJG/NQRS3cX5g2hLS2JCIRmYwgUCa7WOdZWG AWdWh2clqOtaxQTerzKQamCkJa1uWegCgjgySKrX5a0gx7AmRvIdenLg8UD4BmJK nBZEir5g/+pQNS7/AQOUfFZN2M17ya9KvP+C0JItSamZZAn45OYoY0pymkCQtl1N p4RmyhGYv+QiNuDNX9xzijzym6SfzYZpmeAJta6k9tfeTzerw9PkxSy7LPIMgFoq 5Xnf5qJCZeyWz+vOjI91WSsSSzjuX+ZvP0u6Js2B1cV+4fb1PwsQ4lotna53qth6 CiQ2mtaMTUfnBp6lBpgwHVDJpBNyrItpt/HdbVjRL6t5nAbBfTsfWICsEky+rr+e 7Ab+xqhWFA2XaZp4gWsnYcVEUkqKeqGKdn+Unfa430PRXSnRMtv928V57TMiOsHE zKy29XosBluWISNHhpXNmFUptxqQnnKDF7K/LcnLaDWE4Kr4wiRzafq5RQnqLGTl j+VL/HWjkRdYneUxAac5Gp1RJFZeMo99HBB8yBoPrC8VtoZKLHrnUF7w6ulCT1Ms hxbXVXE9wL4w8bdUSpvzqgsNwGKrVjhbg77WpOth4uhz6k31jMkXZRHja7raiwKA 7477YVN5kK2xWq3hC4WS =glty -----END PGP SIGNATURE----- ------enig2PITNVXIWALCUJQTOLCAE-- From owner-freebsd-current@FreeBSD.ORG Tue May 28 21:10:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF6C0823; Tue, 28 May 2013 21:10:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B25BC9A3; Tue, 28 May 2013 21:10:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r4SLA0Mp009589; Tue, 28 May 2013 17:10:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r4SLA0Im009585; Tue, 28 May 2013 21:10:00 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 28 May 2013 21:10:00 GMT Message-Id: <201305282110.r4SLA0Im009585@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:10:08 -0000 TB --- 2013-05-28 14:50:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-28 14:50:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-28 14:50:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-05-28 14:50:20 - cleaning the object tree TB --- 2013-05-28 14:50:20 - /usr/local/bin/svn stat /src TB --- 2013-05-28 14:50:25 - At svn revision 251061 TB --- 2013-05-28 14:50:26 - building world TB --- 2013-05-28 14:50:26 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 14:50:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 14:50:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 14:50:26 - SRCCONF=/dev/null TB --- 2013-05-28 14:50:26 - TARGET=i386 TB --- 2013-05-28 14:50:26 - TARGET_ARCH=i386 TB --- 2013-05-28 14:50:26 - TZ=UTC TB --- 2013-05-28 14:50:26 - __MAKE_CONF=/dev/null TB --- 2013-05-28 14:50:26 - cd /src TB --- 2013-05-28 14:50:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue May 28 14:50:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue May 28 17:56:45 UTC 2013 TB --- 2013-05-28 17:56:45 - generating LINT kernel config TB --- 2013-05-28 17:56:45 - cd /src/sys/i386/conf TB --- 2013-05-28 17:56:45 - /usr/bin/make -B LINT TB --- 2013-05-28 17:56:46 - cd /src/sys/i386/conf TB --- 2013-05-28 17:56:46 - /usr/sbin/config -m LINT TB --- 2013-05-28 17:56:46 - building LINT kernel TB --- 2013-05-28 17:56:46 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 17:56:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 17:56:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 17:56:46 - SRCCONF=/dev/null TB --- 2013-05-28 17:56:46 - TARGET=i386 TB --- 2013-05-28 17:56:46 - TARGET_ARCH=i386 TB --- 2013-05-28 17:56:46 - TZ=UTC TB --- 2013-05-28 17:56:46 - __MAKE_CONF=/dev/null TB --- 2013-05-28 17:56:46 - cd /src TB --- 2013-05-28 17:56:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 28 17:56:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT completed on Tue May 28 18:30:25 UTC 2013 TB --- 2013-05-28 18:30:25 - cd /src/sys/i386/conf TB --- 2013-05-28 18:30:25 - /usr/sbin/config -m LINT-NOINET TB --- 2013-05-28 18:30:25 - building LINT-NOINET kernel TB --- 2013-05-28 18:30:25 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 18:30:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 18:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 18:30:25 - SRCCONF=/dev/null TB --- 2013-05-28 18:30:25 - TARGET=i386 TB --- 2013-05-28 18:30:25 - TARGET_ARCH=i386 TB --- 2013-05-28 18:30:25 - TZ=UTC TB --- 2013-05-28 18:30:25 - __MAKE_CONF=/dev/null TB --- 2013-05-28 18:30:25 - cd /src TB --- 2013-05-28 18:30:25 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue May 28 18:30:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT-NOINET completed on Tue May 28 19:01:17 UTC 2013 TB --- 2013-05-28 19:01:17 - cd /src/sys/i386/conf TB --- 2013-05-28 19:01:17 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-05-28 19:01:17 - building LINT-NOINET6 kernel TB --- 2013-05-28 19:01:17 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 19:01:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 19:01:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 19:01:17 - SRCCONF=/dev/null TB --- 2013-05-28 19:01:17 - TARGET=i386 TB --- 2013-05-28 19:01:17 - TARGET_ARCH=i386 TB --- 2013-05-28 19:01:17 - TZ=UTC TB --- 2013-05-28 19:01:17 - __MAKE_CONF=/dev/null TB --- 2013-05-28 19:01:17 - cd /src TB --- 2013-05-28 19:01:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue May 28 19:01:17 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT-NOINET6 completed on Tue May 28 19:32:56 UTC 2013 TB --- 2013-05-28 19:32:56 - cd /src/sys/i386/conf TB --- 2013-05-28 19:32:56 - /usr/sbin/config -m LINT-NOIP TB --- 2013-05-28 19:32:56 - building LINT-NOIP kernel TB --- 2013-05-28 19:32:56 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 19:32:56 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 19:32:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 19:32:56 - SRCCONF=/dev/null TB --- 2013-05-28 19:32:56 - TARGET=i386 TB --- 2013-05-28 19:32:56 - TARGET_ARCH=i386 TB --- 2013-05-28 19:32:56 - TZ=UTC TB --- 2013-05-28 19:32:56 - __MAKE_CONF=/dev/null TB --- 2013-05-28 19:32:56 - cd /src TB --- 2013-05-28 19:32:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue May 28 19:32:56 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT-NOIP completed on Tue May 28 20:01:12 UTC 2013 TB --- 2013-05-28 20:01:12 - cd /src/sys/i386/conf TB --- 2013-05-28 20:01:12 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-05-28 20:01:12 - building LINT-VIMAGE kernel TB --- 2013-05-28 20:01:12 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 20:01:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 20:01:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 20:01:12 - SRCCONF=/dev/null TB --- 2013-05-28 20:01:12 - TARGET=i386 TB --- 2013-05-28 20:01:12 - TARGET_ARCH=i386 TB --- 2013-05-28 20:01:12 - TZ=UTC TB --- 2013-05-28 20:01:12 - __MAKE_CONF=/dev/null TB --- 2013-05-28 20:01:12 - cd /src TB --- 2013-05-28 20:01:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue May 28 20:01:12 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT-VIMAGE completed on Tue May 28 20:31:46 UTC 2013 TB --- 2013-05-28 20:31:46 - cd /src/sys/i386/conf TB --- 2013-05-28 20:31:46 - /usr/sbin/config -m GENERIC TB --- 2013-05-28 20:31:46 - building GENERIC kernel TB --- 2013-05-28 20:31:46 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 20:31:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 20:31:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 20:31:46 - SRCCONF=/dev/null TB --- 2013-05-28 20:31:46 - TARGET=i386 TB --- 2013-05-28 20:31:46 - TARGET_ARCH=i386 TB --- 2013-05-28 20:31:46 - TZ=UTC TB --- 2013-05-28 20:31:46 - __MAKE_CONF=/dev/null TB --- 2013-05-28 20:31:46 - cd /src TB --- 2013-05-28 20:31:46 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue May 28 20:31:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for GENERIC completed on Tue May 28 21:00:25 UTC 2013 TB --- 2013-05-28 21:00:25 - cd /src/sys/i386/conf TB --- 2013-05-28 21:00:25 - /usr/sbin/config -m PAE TB --- 2013-05-28 21:00:25 - building PAE kernel TB --- 2013-05-28 21:00:25 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 21:00:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 21:00:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 21:00:25 - SRCCONF=/dev/null TB --- 2013-05-28 21:00:25 - TARGET=i386 TB --- 2013-05-28 21:00:25 - TARGET_ARCH=i386 TB --- 2013-05-28 21:00:25 - TZ=UTC TB --- 2013-05-28 21:00:25 - __MAKE_CONF=/dev/null TB --- 2013-05-28 21:00:25 - cd /src TB --- 2013-05-28 21:00:25 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue May 28 21:00:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules -------------------------------------------------------------- cd /obj/i386.i386/src/sys/PAE; MAKEOBJDIRPREFIX=/obj/i386.i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/obj/i386.i386/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/i386.i386/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 8.3-PRERELEASE amd64 803500" INSTALL="sh /src/tools/install.sh" PATH=/obj/i386.i386/src/tmp/legacy/usr/sbin:/obj/i386.i386/src/tmp/legacy/usr/bin:/obj/i386.i386/src/tmp/legacy/usr/games:/obj/i386.i386/src/tmp/legacy/bin:/obj/i386.i386/src/tmp/usr/sbin:/obj/i386.i386/src/tmp/usr/bin:/obj/i386.i386/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=clang /obj/src/make.amd64/make -B -m /src/share/mk KERNEL=kernel modules-all -DNO_MODULES_OBJ make: don't know how to make modules-all. Stop make: stopped in /obj/i386.i386/src/sys/PAE *** Error code 2 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-28 21:10:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-28 21:10:00 - ERROR: failed to build PAE kernel TB --- 2013-05-28 21:10:00 - 18049.16 user 3184.18 system 22779.88 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue May 28 21:29:55 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DCFF4C7; Tue, 28 May 2013 21:29:55 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 68CC6AE2; Tue, 28 May 2013 21:29:55 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UhRSn-0004Cc-7F; Tue, 28 May 2013 21:29:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r4SLTk5U006631; Tue, 28 May 2013 15:29:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/9NfFc/mEmTUj6ii1F/XwJ Subject: Re: Incorrect comparison of ticks in deadlkres From: Ian Lepore To: attilio@FreeBSD.org In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 May 2013 15:29:46 -0600 Message-ID: <1369776586.1258.19.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Ryan Stone , arao@freebsd.og X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:29:55 -0000 On Sun, 2013-05-26 at 02:53 +0200, Attilio Rao wrote: > On Sat, May 25, 2013 at 11:55 PM, Ryan Stone wrote: > > Currently deadlkres performs the following comparison when trying to check > > for threads that have been blocked on a mutex or sleeping on an sx lock: > > > > if (TD_ON_LOCK(td) && ticks < td->td_blktick) { > > /* check for deadlock...*/ > > Yes the check looks indeed inverted. > > > > > > > The test against ticks is incorrect. It results in deadlkres only > > signaling a deadlock after ticks has rolled over; at 1000 hz this will take > > up to 49 days. From looking at the history of the code this test appears > > to be a attempt to deal with ticks rollover. However this is necessary; > > later on the code calculates the amount of time that has passed with: > > tticks = ticks - td->td_blktick; > > > > ticks was designed to exploit integer underflow in the case of rollover to > > guarantee that subtraction produces correct results in all cases (other > > than a double rollover, of course). I am going to remove the two incorrect > > tests unless somebody can point out a overflow/underflow case that I > > haven't considered. > > I'm not sure I follow what are you saying. > Assume that when thread td goes to sleep, ticks is very close to the > 32 bits limit. Then thread td goes to sleep and td->td_blktick is set > to a value very close to 32 bits limits. > After a while deadlkres thread kicks in and in the while "ticks" > counter overflowed, rolling back to a very low value. How are you > supposed to compute a valid value from this situation? > I think that you need to still guard about overflow of ticks for such cases. > ticks is defined as a signed integer but conceptually it is unsigned -- it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If td->td_blktick is captured while ticks = UINT_MAX and later ticks has rolled over and counted back up to 15, then ticks - td->td_blktick gives an elapsed time of 16, as it should be. Whether exploiting this property of signed overflow is elegant or ugly is in the eye of the beholder. :) If the intent of the "ticks < td->td_blktick" is to avoid the deadlock check until "after enough time has passed," then I guess it should probably be something more like "(ticks - td->blktick) > SOME_THRESHOLD" so that it also uses the signed overflow trick. -- Ian From owner-freebsd-current@FreeBSD.ORG Tue May 28 23:18:15 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 531F49C; Tue, 28 May 2013 23:18:15 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 080BC1D1; Tue, 28 May 2013 23:18:14 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id k14so10643556oag.22 for ; Tue, 28 May 2013 16:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mQ776Ghy1vQlQFe2RSHg8xkrIfgG0CJaZ/Fz88+U6Dw=; b=QAUpdmXLksZDHLZanIMc86/3RCNu3Ucc+9f1xdpaKqMvm+68OtZuo/1+1LqiC8MSII 4zxZkUp5oEmgUDbN3caQxdLAo/X5Ul9/Ohh6/l2lpeAiBFpBaUykw9reQp3CWswXYoq3 5uugGz0vaRwgOhJaWBUSEKavnfMybrg0VHzGbH5VAkYOzOAQqZO0lrNpU1JJBy5r54ao +Xxc65SpRjJCh5Mqo51aRiOHguY9w91ce2Ri9P57RiPBnqyJEvPiYnSSfHVd0kzrmwCk LclXTzML1hKJLC4wXFLI4fxDf4Uh5xWyYbHZnRi3xAY66ebSIPYUncRKuuoI9+b9gl7L hTyQ== MIME-Version: 1.0 X-Received: by 10.60.142.67 with SMTP id ru3mr57901oeb.44.1369783088061; Tue, 28 May 2013 16:18:08 -0700 (PDT) Received: by 10.76.91.163 with HTTP; Tue, 28 May 2013 16:18:07 -0700 (PDT) In-Reply-To: <1369776586.1258.19.camel@revolution.hippie.lan> References: <1369776586.1258.19.camel@revolution.hippie.lan> Date: Tue, 28 May 2013 19:18:07 -0400 Message-ID: Subject: Re: Incorrect comparison of ticks in deadlkres From: Ryan Stone To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Attilio Rao , FreeBSD Current , arao@freebsd.og X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 23:18:15 -0000 On Tue, May 28, 2013 at 5:29 PM, Ian Lepore wrote: > ticks is defined as a signed integer but conceptually it is unsigned -- > it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If > td->td_blktick is captured while ticks = UINT_MAX and later ticks has > rolled over and counted back up to 15, then ticks - td->td_blktick gives > an elapsed time of 16, as it should be. Whether exploiting this > property of signed overflow is elegant or ugly is in the eye of the > beholder. :) > > If the intent of the "ticks < td->td_blktick" is to avoid the deadlock > check until "after enough time has passed," then I guess it should > probably be something more like "(ticks - td->blktick) > SOME_THRESHOLD" > so that it also uses the signed overflow trick. > > -- Ian > It already does this later on to actually detect the deadlock. The test is reversed but was intended to bail and not calculate the time elapsed at all if ticks had overflowed after td_blktick was captured, but as you say this is unnecessary. From owner-freebsd-current@FreeBSD.ORG Tue May 28 23:31:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE48A541; Tue, 28 May 2013 23:31:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 8A40D26E; Tue, 28 May 2013 23:31:14 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id s9so5240585iec.16 for ; Tue, 28 May 2013 16:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0mKzfBUkVj+ZPlearUT9WbyQ7pV9M+CbcfIcGihxfRQ=; b=arVMNLsLmbm1eQmaL9d9tjior3FfGAb2HSOp3c1KqSeclduWLT7qNwJte31P7ON7a+ evoNvkPAgQY2Tv+3HrfIolPW58dgpx7Mj81OmhK9soaTrN0WP4Nha9vDyOXG4NStoZNq p6hGBBIYCgQU3ZuwBOEzrB0FDc7gxAnOWC7WC6LXFNmgLMWIUJYwm2qMbB/Gfxwega+V GKY4TJZ7cic0tjn++l3/qcQDDAoQnNc3F6zVfpS2YeKBY4KatmSEjtb1KVhZMEIEEX8K gOEjTKHJnSKTTA/NPBBau9avI7P+ETGWC1+NwoxeitHNa+U5aEUeYQfVRPvpoVQ4V1YC 56fA== MIME-Version: 1.0 X-Received: by 10.50.18.80 with SMTP id u16mr8016376igd.13.1369783873706; Tue, 28 May 2013 16:31:13 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.42.253.129 with HTTP; Tue, 28 May 2013 16:31:13 -0700 (PDT) In-Reply-To: References: <1369776586.1258.19.camel@revolution.hippie.lan> Date: Wed, 29 May 2013 01:31:13 +0200 X-Google-Sender-Auth: OlKjpUAScpjUq4k-XgMSI-JWAgs Message-ID: Subject: Re: Incorrect comparison of ticks in deadlkres From: Attilio Rao To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current , Ian Lepore , arao@freebsd.og X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@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, 28 May 2013 23:31:14 -0000 On Wed, May 29, 2013 at 1:18 AM, Ryan Stone wrote: > On Tue, May 28, 2013 at 5:29 PM, Ian Lepore wrote: >> >> ticks is defined as a signed integer but conceptually it is unsigned -- >> it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If >> td->td_blktick is captured while ticks = UINT_MAX and later ticks has >> rolled over and counted back up to 15, then ticks - td->td_blktick gives >> an elapsed time of 16, as it should be. Whether exploiting this >> property of signed overflow is elegant or ugly is in the eye of the >> beholder. :) >> >> If the intent of the "ticks < td->td_blktick" is to avoid the deadlock >> check until "after enough time has passed," then I guess it should >> probably be something more like "(ticks - td->blktick) > SOME_THRESHOLD" >> so that it also uses the signed overflow trick. >> >> -- Ian > > > It already does this later on to actually detect the deadlock. The test is > reversed but was intended to bail and not calculate the time elapsed at all > if ticks had overflowed after td_blktick was captured, but as you say this > is unnecessary. I'm not sure if there was a comparison between the 2 values (ticks, td_slpticks) somewhere, but if there is not and only add/sub to the relative values then it is good to be removed. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue May 28 23:39:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 580F2BF8 for ; Tue, 28 May 2013 23:39:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D65B5310 for ; Tue, 28 May 2013 23:39:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAO4+pVGDaFvO/2dsb2JhbABZgzmDO75ugR10giMBAQEDAQEBASAEJyALBQcPEQQBAQECAg0FARADAikBCRUDAQUIBggHBAEcBIdmBgypXZFxgSaMNRB+NAcGDAGCLoETA5R3gkSBKZAXgysgMnwHFx8 X-IronPort-AV: E=Sophos;i="4.87,761,1363147200"; d="scan'208";a="30350243" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 28 May 2013 19:39:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 13C8BB3F44; Tue, 28 May 2013 19:39:38 -0400 (EDT) Date: Tue, 28 May 2013 19:39:38 -0400 (EDT) From: Rick Macklem To: Hartmut Brandt Message-ID: <969497820.24821.1369784378065.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: files disappearing from ls on NFS MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 23:39:46 -0000 Hartmut Brandt wrote: > On Wed, 15 May 2013, Rick Macklem wrote: > > RM>Well, getdents() basically just calls kern_getdirentries() and it > calls > RM>VOP_READDIR() { which is called nfs_readdir() in the NFS clients }. > RM>nfs_readdir() calls ncl_bioread() to do the real work of finding > the > RM>buffer cache blocks and copying the data out of them. > RM>One thing you might check via printf()s is whether the buffer cache > RM>has the zero'd data in it before it copies it to userland. > > I now dump the data just before the call to vn_io_fault_iomove in > ncl_bioread(). So what I do: > > 1. reboot > 2. login > 3. ls > -> I see that it is moving 4 blocks 4k each to the user and they look > fine > 4. wait half an hour > 5. ls > -> now there is only one block, which contains zeros starting from > 0x200. > > Note that I don't do anything else on that machine during that time. > > RM>Since you get valid data sometimes and partially zero'd out data > others, > RM>I haven't a clue what is going on. One other person reported a > problem > RM>when they used a small readdirsize, but it is hard to say they saw > the > RM>same thing and no one else seems to be seeing this, so I have no > idea > RM>what it might be. > RM> > RM>I remember you started seeing this after an upgrade of current. Do > you > RM>happen to have dates (or rNNNNNN) for the old working verion vs the > one that broke this? > RM>(All I can think to do is scan the commits that seem to somehow > relate > RM> to the buffer cache or copying to userland or ???) > > It looks like I had copied the old kernel before installing the new > one > and it is from february 5th. There is no SVN revision in it - looks > like > that feature was added only recently. > > harti > Thanks to Hartmut's testing, a patch to fix this problem has just been committed to head as r251079. The problem was caused by vnode_pager_setsize() being called for directories (where the size reported by the server can be smaller than the size of the ufs-like directory created in the client from the RPCs XDR). r251079 will be MFC'd to stable/9 in 1 week if things go smoothly. You might see this problem for head kernels between r248567-r251078 and stable/9 kernels from r249078 (Apr. 4) until a week from now. Sorry for any inconvenience and thanks go to Hartmut for his help isolating this, rick > RM> > RM>rick > RM> > RM>> harti > RM>> > RM>> -----Original Message----- > RM>> From: Rick Macklem [mailto:rmacklem@uoguelph.ca] > RM>> Sent: Tuesday, May 14, 2013 2:50 PM > RM>> To: Brandt, Hartmut > RM>> Cc: current@freebsd.org > RM>> Subject: Re: files disappearing from ls on NFS > RM>> > RM>> Hartmut Brandt wrote: > RM>> > On Mon, 13 May 2013, Rick Macklem wrote: > RM>> > > RM>> > RM>Hartmut Brandt wrote: > RM>> > RM>> On Sun, 12 May 2013, Rick Macklem wrote: > RM>> > RM>> > RM>> > RM>> RM>Hartmut Brandt wrote: > RM>> > RM>> RM>> Hi, > RM>> > RM>> RM>> > RM>> > RM>> RM>> I've updated one of my -current machines this week > RM>> > (previous > RM>> > RM>> update > RM>> > RM>> RM>> was in > RM>> > RM>> RM>> february). Now I see a strange effect (it seems only > on > RM>> > NFS > RM>> > RM>> mounts): > RM>> > RM>> RM>> ls or > RM>> > RM>> RM>> even echo * will list only some files (strange enough > the > RM>> > first > RM>> > RM>> files > RM>> > RM>> RM>> from > RM>> > RM>> RM>> the normal, alphabetically ordered list). If I change > RM>> > something > RM>> > RM>> in the > RM>> > RM>> RM>> directory (delete a file or create a new one) for > some > RM>> > time > RM>> > the > RM>> > RM>> RM>> complete > RM>> > RM>> RM>> listing will appear but after sime time (seconds to a > RM>> > minute > RM>> > or > RM>> > RM>> so) > RM>> > RM>> RM>> again > RM>> > RM>> RM>> only part of the files is listed. > RM>> > RM>> RM>> > RM>> > RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that > RM>> > getdirentries is > RM>> > RM>> RM>> called > RM>> > RM>> RM>> only once (returning 4096). For a full listing > RM>> > getdirentries > RM>> > is > RM>> > RM>> called > RM>> > RM>> RM>> 5 > RM>> > RM>> RM>> times with the last returning 0. > RM>> > RM>> RM>> > RM>> > RM>> RM>> I can still open files that are not listed if I know > their > RM>> > name, > RM>> > RM>> RM>> though. > RM>> > RM>> RM>> > RM>> > RM>> RM>> The NFS server is a Windows 2008 server with an > OpenText > RM>> > NFS > RM>> > RM>> Server > RM>> > RM>> RM>> which > RM>> > RM>> RM>> works without problems to all the other FreeBSD > machines. > RM>> > RM>> RM>> > RM>> > RM>> RM>> So what could that be? > RM>> > RM>> RM>> > RM>> > RM>> RM>I've attached a patch that might be worth trying. It is > a > RM>> > "shot in > RM>> > RM>> the dark", > RM>> > RM>> RM>but brings the new NFS client's readdir closer to the > old > RM>> > one > RM>> > RM>> (which you > RM>> > RM>> RM>mentioned still works ok). > RM>> > RM>> RM> > RM>> > RM>> RM>Please let me know how it goes, if you have a chance to > test > RM>> > it, > RM>> > RM>> rick > RM>> > RM>> > RM>> > RM>> Hi Rick, > RM>> > RM>> > RM>> > RM>> the patch doesn't help. > RM>> > RM>> > RM>> > RM>> I wrote a small test program, which opens a directory, > calls > RM>> > RM>> getdents(2) > RM>> > RM>> in a loop and dumps that. I figured out, that the return > of the > RM>> > system > RM>> > RM>> call depends on the buffer size I pass to it. The > directory has > RM>> > a > RM>> > RM>> block size of 4k according to fstat(2). If I use that, I > get > RM>> > some > RM>> > RM>> 300 > RM>> > of the > RM>> > RM>> almost 500 directory entries. If I use 8k, I get just > around > RM>> > 200 > RM>> > and > RM>> > RM>> if I > RM>> > RM>> use 16k I get a handfull. If I dump the buffer in this > case I > RM>> > see > RM>> > RM>> 0x200 > RM>> > RM>> bytes filled with directory entries, then a lot of zeros > and > RM>> > starting > RM>> > RM>> from > RM>> > RM>> 0x1000 again data. This is of course ignored because of > the > RM>> > zeros > RM>> > RM>> before. > RM>> > RM>> > RM>> > RM>And for this case getdents(2) returned 16K? It is normal for > RM>> > getdents(2) > RM>> > RM>to return less than requested and when end of dir occurs, it > RM>> > should > RM>> > return 0. > RM>> > RM> > RM>> > RM>But if it returns 16K, there shouldn't be zeroed space in > the > RM>> > middle of > RM>> > RM>it. > RM>> > RM> > RM>> > RM>And this always occurs or only after you wait a while? (You > noted > RM>> > in the > RM>> > RM>above description that it would be ok for a little while > after a > RM>> > directory > RM>> > RM>change and then would break, which suggests some kind of > caching > RM>> > problem.) > RM>> > > RM>> > Today in the morning everything was fine. After waiting 5 > minutes, > RM>> > again only partial directories. When I do a read with 8k buffer > RM>> > size, > RM>> > getdents(2) returns 8k, but starting from 0x200 until 0x1000 > the > RM>> > buffer is filled with zeros. The entry just before the zeroes > ends > RM>> > exactly at > RM>> > 0x200 > RM>> > (that would be the first byte of the next entry) and at 0x1000 > a new > RM>> > entry starts. The rest of the buffer is fine. The next read > returns > RM>> > only 4k and seems to be fine - altough it contains some junk > RM>> > non-zero > RM>> > bytes in the padding. > RM>> > > RM>> Directory entries should never cross DIRBLKSIZ boundaries (512 or > RM>> 0x200), so it makes sense that one ends at 0x200 and one starts > at > RM>> 0x1000. What doesn't make sense are the 0 bytes in between. > RM>> > RM>> One difference between the old and new NFS clients, which the > patch I > RM>> sent you changed to the way the old one does it, is filling in > the > RM>> last block. > RM>> The old NFS client just leaves the block short and depends on > RM>> n_direofoffset to recognize it is the last block with b_resid > RM>> indicating where it ends. > RM>> For the new client (unless you've applied the patch I emailed > you), it > RM>> fills the rest of the last block in with "empty directories". > This was > RM>> in the OpenBSD code when I did the original NFSv4 stuff and port. > I > RM>> left it in, because I thought it might avoid problems if > RM>> n_direofoffset was ever bogus. That is why there might be > "different > RM>> junk" at the end of the directory, but it shouldn't matter. > RM>> > RM>> It almost sounds like something else is bzero()ing out part of > the > RM>> buffer cache block. Unless the directory has changed, the > getdents() > RM>> after 5 minutes would just return the same buffer cache block > that was > RM>> read in 5 minutes earlier (unless the buffer fell out of the > cache and > RM>> had to be re-read from the server, which would only happen if > there > RM>> was a lot of other file I/O going on during that 5minutes). > RM>> > RM>> A couple of comments: > RM>> - You can run "nfsstat -m" as root to see what the mount it > actually > RM>> configured to use. This might be worth looking at, to see if any > RM>> of the values are "weird". > RM>> - One other difference between the old and new NFS clients is the > RM>> value of NFS_DIRBLKSIZ. For the new one, it is 8K instead of 4K. > RM>> You could change this in fs/nfs/nfsport.h, where is is defined > RM>> and then rebuild the sources to see if it has any effect. I can't > RM>> see why it should matter, but?? > RM>> - Maybe you could post your system configuration. Someone might > spot > RM>> something that changed in Feb.->Mar. related to your > hardware/setup? > RM>> > RM>> > Ten minutes later again everything is fine. I tries to spy at > the > RM>> > NFS > RM>> > communication with tcpdump, but it seems unwilling to display > RM>> > something useful about the NFS. Is it able to decode the > readdir > RM>> > stuff? > RM>> > > RM>> To look at NFS packets you need wireshark. You can capture the > packets > RM>> with tcpdump using the -w option. Something like: > RM>> # tcpdump -s 0 -w file.pcap host server > RM>> - Then look at file.pcap in wireshark. (Often more convenient > than > RM>> installing wireshark on a particular machine.) If you'd like, you > can > RM>> email me the file.pcap and I can look at it. > RM>> > RM>> rick > RM>> > RM>> > harti > RM>> > > RM>> > _______________________________________________ > RM>> > freebsd-current@freebsd.org mailing list > RM>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > RM>> > To unsubscribe, send any mail to > RM>> > "freebsd-current-unsubscribe@freebsd.org" > RM>> > RM>> _______________________________________________ > RM>> freebsd-current@freebsd.org mailing list > RM>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > RM>> To unsubscribe, send any mail to > RM>> "freebsd-current-unsubscribe@freebsd.org" > RM> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue May 28 23:46:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E77C62C7; Tue, 28 May 2013 23:46:37 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id B39B937F; Tue, 28 May 2013 23:46:37 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id u16so23066309iet.14 for ; Tue, 28 May 2013 16:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oDcbWLNhAVG5ouL5p7OFQ9gCdbRaz0yfvspUxC0MiRk=; b=wAk9X0niVoTO2x3peVzLmhVh5pcZ9NiDqM/Zj3hEzt9gir4ih/BAkek6VuYLxmo5ym 1HZ/Rb1K+H9aL/cxRwFrlWbVxjjc2HAZzvPpO6QQFkTNv1/BdbgLEiRqOdgPCUoRFv3r z+gezucUdjWORF2qpKsVixjjL1M8hiOR51BRQlewV1RXHb/ILpFfCtaDTwiyXwDicrnl f/BOrHRnD1lsJxOyDz220kQj9nGiU2BrKSf5nSPDz5a0TDkfri+0z8sns+jDqkNPsBoG hAKf54K4H06cGElCY7mV2QXF9DW8VF8xSpfoTt5WC+5vi9y6+lhr03jptUqK5QGy7QuH lqnQ== X-Received: by 10.50.20.130 with SMTP id n2mr8329834ige.87.1369784797455; Tue, 28 May 2013 16:46:37 -0700 (PDT) Received: from [192.168.1.34] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPSA id y11sm7046140igy.10.2013.05.28.16.46.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 16:46:36 -0700 (PDT) Message-ID: <51A541B5.3010905@gmail.com> Date: Tue, 28 May 2013 18:45:57 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kenta Suzumoto Subject: Re: BSD sleep References: <20130528230140.A5B396F448@smtp.hushmail.com> In-Reply-To: <20130528230140.A5B396F448@smtp.hushmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 23:46:38 -0000 On 5/28/2013 6:01 PM, Kenta Suzumoto wrote: > Hi. Is there no built-in way of making "sleep" sleep in increments > of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep > 1h" for an hour. The FreeBSD one's manpage leads me to believe we > can only use seconds, which is kind of annoying. Is there an > undocmented or missing feature here? Seems really trivial to > implement. > > ~ $ sleep 1h > usage: sleep seconds > You think it's trivial until you read this: http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time If you sleep one hour, do you sleep one hour from now or one hour from the system clock which may change in the next hour? If it's the system clock, you may sleep for ten minutes or ten hours. If you need to sleep for 3600 seconds, that's simple and understandable. From owner-freebsd-current@FreeBSD.ORG Tue May 28 23:01:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47F49C43 for ; Tue, 28 May 2013 23:01:48 +0000 (UTC) (envelope-from kentas@hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by mx1.freebsd.org (Postfix) with ESMTP id 34D567A for ; Tue, 28 May 2013 23:01:47 +0000 (UTC) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id BC0C41B5326 for ; Tue, 28 May 2013 23:01:40 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp10.hushmail.com (Postfix) with ESMTP; Tue, 28 May 2013 23:01:40 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A5B396F448; Tue, 28 May 2013 23:01:40 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 28 May 2013 19:01:40 -0400 To: freebsd-questions@freebsd.org Subject: BSD sleep From: "Kenta Suzumoto" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130528230140.A5B396F448@smtp.hushmail.com> X-Mailman-Approved-At: Wed, 29 May 2013 01:16:44 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 23:01:48 -0000 Hi. Is there no built-in way of making "sleep" sleep in increments of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep 1h" for an hour. The FreeBSD one's manpage leads me to believe we can only use seconds, which is kind of annoying. Is there an undocmented or missing feature here? Seems really trivial to implement. ~ $ sleep 1h usage: sleep seconds From owner-freebsd-current@FreeBSD.ORG Wed May 29 01:33:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF6FA548; Wed, 29 May 2013 01:33:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C6719AD8; Wed, 29 May 2013 01:33:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r4T1XBMF053503; Tue, 28 May 2013 21:33:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r4T1XB43053483; Wed, 29 May 2013 01:33:11 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 29 May 2013 01:33:11 GMT Message-Id: <201305290133.r4T1XB43053483@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 01:33:13 -0000 TB --- 2013-05-28 22:21:37 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-28 22:21:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-28 22:21:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-05-28 22:21:37 - cleaning the object tree TB --- 2013-05-28 22:21:37 - /usr/local/bin/svn stat /src TB --- 2013-05-28 22:21:40 - At svn revision 251061 TB --- 2013-05-28 22:21:41 - building world TB --- 2013-05-28 22:21:41 - CROSS_BUILD_TESTING=YES TB --- 2013-05-28 22:21:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-28 22:21:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-28 22:21:41 - SRCCONF=/dev/null TB --- 2013-05-28 22:21:41 - TARGET=powerpc TB --- 2013-05-28 22:21:41 - TARGET_ARCH=powerpc TB --- 2013-05-28 22:21:41 - TZ=UTC TB --- 2013-05-28 22:21:41 - __MAKE_CONF=/dev/null TB --- 2013-05-28 22:21:41 - cd /src TB --- 2013-05-28 22:21:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue May 28 22:21:48 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed May 29 00:54:36 UTC 2013 TB --- 2013-05-29 00:54:36 - generating LINT kernel config TB --- 2013-05-29 00:54:36 - cd /src/sys/powerpc/conf TB --- 2013-05-29 00:54:36 - /usr/bin/make -B LINT TB --- 2013-05-29 00:54:36 - cd /src/sys/powerpc/conf TB --- 2013-05-29 00:54:36 - /usr/sbin/config -m LINT TB --- 2013-05-29 00:54:36 - building LINT kernel TB --- 2013-05-29 00:54:36 - CROSS_BUILD_TESTING=YES TB --- 2013-05-29 00:54:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-29 00:54:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-29 00:54:36 - SRCCONF=/dev/null TB --- 2013-05-29 00:54:36 - TARGET=powerpc TB --- 2013-05-29 00:54:36 - TARGET_ARCH=powerpc TB --- 2013-05-29 00:54:36 - TZ=UTC TB --- 2013-05-29 00:54:36 - __MAKE_CONF=/dev/null TB --- 2013-05-29 00:54:36 - cd /src TB --- 2013-05-29 00:54:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed May 29 00:54:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for LINT completed on Wed May 29 01:14:26 UTC 2013 TB --- 2013-05-29 01:14:26 - cd /src/sys/powerpc/conf TB --- 2013-05-29 01:14:26 - /usr/sbin/config -m GENERIC TB --- 2013-05-29 01:14:26 - building GENERIC kernel TB --- 2013-05-29 01:14:26 - CROSS_BUILD_TESTING=YES TB --- 2013-05-29 01:14:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-29 01:14:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-29 01:14:26 - SRCCONF=/dev/null TB --- 2013-05-29 01:14:26 - TARGET=powerpc TB --- 2013-05-29 01:14:26 - TARGET_ARCH=powerpc TB --- 2013-05-29 01:14:26 - TZ=UTC TB --- 2013-05-29 01:14:26 - __MAKE_CONF=/dev/null TB --- 2013-05-29 01:14:26 - cd /src TB --- 2013-05-29 01:14:26 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed May 29 01:14:26 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules >>> Kernel build for GENERIC completed on Wed May 29 01:30:18 UTC 2013 TB --- 2013-05-29 01:30:18 - cd /src/sys/powerpc/conf TB --- 2013-05-29 01:30:18 - /usr/sbin/config -m GENERIC64 TB --- 2013-05-29 01:30:18 - skipping GENERIC64 kernel TB --- 2013-05-29 01:30:18 - cd /src/sys/powerpc/conf TB --- 2013-05-29 01:30:18 - /usr/sbin/config -m MPC85XX TB --- 2013-05-29 01:30:18 - building MPC85XX kernel TB --- 2013-05-29 01:30:18 - CROSS_BUILD_TESTING=YES TB --- 2013-05-29 01:30:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-29 01:30:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-29 01:30:18 - SRCCONF=/dev/null TB --- 2013-05-29 01:30:18 - TARGET=powerpc TB --- 2013-05-29 01:30:18 - TARGET_ARCH=powerpc TB --- 2013-05-29 01:30:18 - TZ=UTC TB --- 2013-05-29 01:30:18 - __MAKE_CONF=/dev/null TB --- 2013-05-29 01:30:18 - cd /src TB --- 2013-05-29 01:30:18 - /usr/bin/make -B buildkernel KERNCONF=MPC85XX >>> Kernel build for MPC85XX started on Wed May 29 01:30:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building the kernel >>> stage 3.3: building the modules -------------------------------------------------------------- cd /obj/powerpc.powerpc/src/sys/MPC85XX; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc MACHINE_ARCH=powerpc MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 8.3-PRERELEASE amd64 803500" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc/src/tmp/legacy/usr/games:/obj/powerpc.powerpc/src/tmp/legacy/bin:/obj/powerpc.powerpc/src/tmp/usr/sbin:/obj/powerpc.powerpc/src/tmp/usr/bin:/obj/powerpc.powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC="cc " CXX="c++ " CPP="cpp " AS="as" AR="ar" LD="ld" NM=nm OBJDUMP= RANLIB=ranlib STRINGS= COMPILER_TYPE=gcc /obj/src/make.amd64/make -B -m /src/share/mk KERNEL=kernel modules-all -DN! O_MODULES_OBJ make: don't know how to make modules-all. Stop make: stopped in /obj/powerpc.powerpc/src/sys/MPC85XX *** Error code 2 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-05-29 01:33:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-29 01:33:11 - ERROR: failed to build MPC85XX kernel TB --- 2013-05-29 01:33:11 - 9953.65 user 1229.51 system 11494.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed May 29 01:38:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5515C6AE; Wed, 29 May 2013 01:38:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADBBB05; Wed, 29 May 2013 01:38:18 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 1E2FD23F804; Tue, 28 May 2013 21:38:16 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us 1E2FD23F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 28 May 2013 21:38:14 -0400 From: Glen Barber To: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on powerpc/powerpc Message-ID: <20130529013814.GB1600@glenbarber.us> References: <201305290133.r4T1XB43053483@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline In-Reply-To: <201305290133.r4T1XB43053483@freebsd-current.sentex.ca> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: powerpc@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 01:38:18 -0000 --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The suspect commit was already reverted. Glen On Wed, May 29, 2013 at 01:33:11AM +0000, FreeBSD Tinderbox wrote: > >>> stage 3.3: building the modules > -------------------------------------------------------------- > cd /obj/powerpc.powerpc/src/sys/MPC85XX; MAKEOBJDIRPREFIX=3D/obj/powerpc.= powerpc MACHINE_ARCH=3Dpowerpc MACHINE=3Dpowerpc CPUTYPE=3D GROFF_BIN_PA= TH=3D/obj/powerpc.powerpc/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/obj/po= werpc.powerpc/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=3D/obj/p= owerpc.powerpc/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=3D/obj/powerp= c.powerpc/src/tmp _LDSCRIPTROOT=3D VERSION=3D"FreeBSD 8.3-PRERELEASE amd6= 4 803500" INSTALL=3D"sh /src/tools/install.sh" PATH=3D/obj/powerpc.powerp= c/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc/src/tmp/legacy/usr/bin:/obj/= powerpc.powerpc/src/tmp/legacy/usr/games:/obj/powerpc.powerpc/src/tmp/legac= y/bin:/obj/powerpc.powerpc/src/tmp/usr/sbin:/obj/powerpc.powerpc/src/tmp/us= r/bin:/obj/powerpc.powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin = CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" NM=3Dn= m OBJDUMP=3D RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dgcc /obj/src/make.= amd64/make -B -m /src/share/mk KERNEL=3Dkernel modules-all -DN! > O_MODULES_OBJ > make: don't know how to make modules-all. Stop >=20 > make: stopped in /obj/powerpc.powerpc/src/sys/MPC85XX > *** Error code 2 >=20 > Stop. > make: stopped in /src > *** Error code 1 >=20 > Stop in /src. > TB --- 2013-05-29 01:33:11 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2013-05-29 01:33:11 - ERROR: failed to build MPC85XX kernel > TB --- 2013-05-29 01:33:11 - 9953.65 user 1229.51 system 11494.62 real >=20 >=20 --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJRpVwFAAoJEFJPDDeguUajR9QH/iNpuPyi2tioNw05kRLURNdP d3KKe/XVXfxXsnAXYnvVigS79hFroVxZu/ORnVF0pXh7RaLs90iILvlmTaZpVGjR gJ0QjhwkQPiYlRkDYI2s+Ky/boqocRV+iqYC3Xsa2KinWEZVWuXBguyz7qIf5AmK eyYAX1cX3fYDe4gCGD2gm4I1lLSFBjpKc5YmKeR6sL88nw28zW+t88eMiK3T7CYT 0rd2TcNqEFolTpcc12al5pt77yUlCeQgYGJBrOB5ROyXIJFrCQol+K20V7QBaOD/ LRIDo3/WCKUju0omGzaH2nn5DByBxCckscmygD6ADQC+/Cykk3gPOn+NaVZZC2w= =EIAJ -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V-- From owner-freebsd-current@FreeBSD.ORG Wed May 29 05:33:42 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9FC7A51A; Wed, 29 May 2013 05:33:42 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 101F5A9A; Wed, 29 May 2013 05:33:41 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id d4so5138220eek.0 for ; Tue, 28 May 2013 22:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=GWEV09R9JmHWC07vnsXq5kEizPBHANw0uNisfXm59nQ=; b=pA/bGTpLGpZRPWm3zlNGRaCJ+75oHfIf53dUZdsp12+AFkAdZpTG6uyxAID0+heQ/+ sJ2AWyh0FDY2kBGgOSu6nINbUCXGb1quPOS8UfZli8cmLNWrbg+5XaXXPvRP7DrLLzHI vUNc69VtszJJmqQEIG3CJKzMuv4pJgwqZHWqympt86rft7iFp2A8NEONWZxt+KRyJdNr a/qtOY8PXPgIIELJf5hGS0ZOaaoKAs6RNuzv3+sOEf81mqY0sNmyxpnfUoPJx4dqtUNh VUifCu5y3f1Jp2goLAna9h3voRJHIfQ027yM0k/f9PwZxvU9arcibBosTUtls87vVBt5 Ez3w== X-Received: by 10.15.76.133 with SMTP id n5mr890362eey.105.1369805620878; Tue, 28 May 2013 22:33:40 -0700 (PDT) Received: from laptop.minsk.domain (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPSA id s43sm51605799eem.13.2013.05.28.22.33.39 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 28 May 2013 22:33:40 -0700 (PDT) Date: Wed, 29 May 2013 08:33:38 +0300 From: "Sergey V. Dyatko" To: Bryan Drewery Subject: Re: Supermicro 6027R-N3RF+head, usb trouble Message-ID: <20130529083338.07a2f54b@laptop.minsk.domain> In-Reply-To: <51A4F585.60401@FreeBSD.org> References: <20130421223838.6bec3bfb@laptop.minsk.domain> <51A4F585.60401@FreeBSD.org> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 05:33:42 -0000 On Tue, 28 May 2013 13:20:53 -0500 Bryan Drewery wrote: > On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: > > Hi, > > > > Can anybody explain why USB keyboard (and keyboard from > > integrated IPKVM) doesn't work when I boot with 'C606 > > chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? > > Also I can't boot that box from usb memstick and > > FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both > > loose(?) device and can't find root If I disable controller in bios > > system can't see any sata hdd connected to it:( > > booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay="10000" > > and debug.acpi.disabled="hostres" without success. I setup dhcpd, > > tftp, nfs on my laptop and finally I install fbsd on that box, but > > question with kbd is open - It doesn't work.. > > dmesg: > > http://svn.freebsd.by/files/dmesg_N3RF.txt > > pciconf -lv: > > http://svn.freebsd.by/files/pciconf_N3RF.txt > > > > I would appreciate any hints > > > > I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE > (disc1) seems ok though. > > Did you get this figured out? > I added to loader.conf kern.maxbcache="128M" vfs.maxbufspace=134217728 also I create /boot.config with '-v' I don't know what exactly help, but now usb kbd (ipkvm) works fine for me. p.s. It is smbios.system.product="X9DRW" > My startup: > > > uhub1: 2 ports with 2 removable, self powered > > uhub0: 2 ports with 2 removable, self powered > > Root mount waiting for: usbus1 > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > > USB_ERR_NOMEM Root mount waiting for: usbus1 > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, > > ignored) usbd_ctrl_transfer_setup: could not setup default USB > > transfer usbd_setup_device_desc: getting device descriptor at addr > > 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, > > ignored) usbd_ctrl_transfer_setup: could not setup default USB > > transfer usbd_setup_device_desc: getting device descriptor at addr > > 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, > > ignored) usbd_ctrl_transfer_setup: could not setup default USB > > transfer usbd_setup_device_desc: getting device descriptor at addr > > 2 failed, USB_ERR_NOMEM Root mount waiting for: usbus1 > > usbd_ctrl_transfer_setup: could not setup default USB transfer > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_NOMEM, > > ignored) usbd_ctrl_transfer_setup: could not setup default USB > > transfer usbd_setup_device_desc: getting device descriptor at addr > > 2 failed, USB_ERR_NOMEM ugen1.2: at usbus1 (disconnected) > > uhub_reattach_port: could not allocate new device > > -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Wed May 29 06:13:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 49FE3ACC; Wed, 29 May 2013 06:13:09 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id EA723CE1; Wed, 29 May 2013 06:13:08 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.7/8.14.7) with ESMTP id r4T6Ctia060259 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 May 2013 07:13:03 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk r4T6Ctia060259 Authentication-Results: smtp.infracaninophile.co.uk/r4T6Ctia060259; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) Message-ID: <51A59C60.3010709@FreeBSD.org> Date: Wed, 29 May 2013 07:12:48 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Sierchio Subject: Re: BSD sleep References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IWTWOFKWKXRMQFOALULR" X-Virus-Scanned: clamav-milter 0.97.8 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Kenta Suzumoto , Joshua Isom , FreeBSD Questions , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 06:13:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IWTWOFKWKXRMQFOALULR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29/05/2013 05:59, Michael Sierchio wrote: > On Tue, May 28, 2013 at 4:45 PM, Joshua Isom wrote: >=20 >=20 >> You think it's trivial until you read this: >> >> http://infiniteundo.com/post/**25326999628/falsehoods-** >> programmers-believe-about-time >> >> > Some days have 86400 seconds, some have 86401. There is a provision fo= r > two leap seconds to be applied at once, but that hasn't ever happened. > Still, a truly correct clock, set to UTC, might someday read >=20 > 23:59:59 > 23:59:60 > 23:59:61 > 00:00:00 >=20 > How many seconds did that hour have? Right. The fact that on very rare occasions a minute may not have 60 seconds in it plus many other corner cases in calculating the current wall-clock time is an amusing irrelevance. First of all, sleep deals in local elapsed time, which is a well defined property even if the displayed wall-clock time would be all over the place due to DST changes or relativistic effects or whatever. In this case, I'd be pretty surprised if GNU sleep's algorithm was anything more complicated than to convert the stated time into seconds and then sleep that number of seconds. And to do that conversion, it wwould just define one minute as 60 seconds, one hour as 60 minutes, one day as 24 hours, one week as 7 days, perhaps one month as 30 days, one year as 365 days[*]. Sure, it's simplistic and unsophisticated, but as an engineering solution it's good enough for the vast majority of purposes. Cheers, Matthew [*] I haven't checked on GNU sleep, but (for example) this is exactly what dnssec-keygen(8) does. --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2IWTWOFKWKXRMQFOALULR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGlnGcACgkQ8Mjk52CukIxjWgCfYsDszXTxMIsq6GSIanZKaBfg VMkAn16VkWFmjQQlfnj6lXizS7EjCiC2 =sH69 -----END PGP SIGNATURE----- ------enig2IWTWOFKWKXRMQFOALULR-- From owner-freebsd-current@FreeBSD.ORG Wed May 29 11:04:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7B3E712; Wed, 29 May 2013 11:04:53 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E508F32; Wed, 29 May 2013 11:04:52 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e50so5329390eek.41 for ; Wed, 29 May 2013 04:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1/Ip5YJCcJei+epzWcI30TKYV+lICnSavghIVUiljDw=; b=g6UDtKEIEQgtlNlaQ3EH9NWlgl6Wdt3HDtB9U9wxlF2QE3FmbhNHe5GXA5AwImCGXC fQx3eIEucogWtbl036EnBzxmCy9iKjNSEY2alvazJg4v+MIGuyeKKSGI/akxZwV1I1Os 0500SBEX5NMOlP1pnzp2EWWrB6tgFVnDsQbkuS9dhteVN+5b7W5yZA3ajIODM86mRBns kvhE+F4dPovlh6cV9dZbxew27NTfH+i/SkF6ARNZAZ4gVoCpyU7yivpNOq8v+hCAZ+jN mqZqVHEUro/yztdIZqdIGbfGihVnCI6tNvaEn9IH68f2/WiQOtmfo0zMgSSrLYX7ZYAk xR+g== MIME-Version: 1.0 X-Received: by 10.15.73.133 with SMTP id h5mr2255533eey.118.1369825487716; Wed, 29 May 2013 04:04:47 -0700 (PDT) Received: by 10.15.23.76 with HTTP; Wed, 29 May 2013 04:04:47 -0700 (PDT) Received: by 10.15.23.76 with HTTP; Wed, 29 May 2013 04:04:47 -0700 (PDT) In-Reply-To: <51A59C60.3010709@FreeBSD.org> References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> <51A59C60.3010709@FreeBSD.org> Date: Wed, 29 May 2013 12:04:47 +0100 Message-ID: Subject: Re: BSD sleep From: Chris Rees To: Matthew Seaman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kenta Suzumoto , Joshua Isom , Michael Sierchio , FreeBSD Questions , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:04:54 -0000 On 29 May 2013 07:13, "Matthew Seaman" wrote: > > On 29/05/2013 05:59, Michael Sierchio wrote: > > On Tue, May 28, 2013 at 4:45 PM, Joshua Isom wrote: > > > > > >> You think it's trivial until you read this: > >> > >> http://infiniteundo.com/post/**25326999628/falsehoods-** > >> programmers-believe-about-time< http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time > > >> > >> > > Some days have 86400 seconds, some have 86401. There is a provision for > > two leap seconds to be applied at once, but that hasn't ever happened. > > Still, a truly correct clock, set to UTC, might someday read > > > > 23:59:59 > > 23:59:60 > > 23:59:61 > > 00:00:00 > > > > How many seconds did that hour have? > > Right. The fact that on very rare occasions a minute may not have 60 > seconds in it plus many other corner cases in calculating the current > wall-clock time is an amusing irrelevance. > > First of all, sleep deals in local elapsed time, which is a well defined > property even if the displayed wall-clock time would be all over the > place due to DST changes or relativistic effects or whatever. > > In this case, I'd be pretty surprised if GNU sleep's algorithm was > anything more complicated than to convert the stated time into seconds > and then sleep that number of seconds. And to do that conversion, it > wwould just define one minute as 60 seconds, one hour as 60 minutes, one > day as 24 hours, one week as 7 days, perhaps one month as 30 days, one > year as 365 days[*]. Sure, it's simplistic and unsophisticated, but as > an engineering solution it's good enough for the vast majority of > purposes. OK, but is this really something the OS should handle? I'm sure sleep `expr 3600 \* 2` will suffice and is perfectly readable, including being more portable. Why should we keep putting these weird "extensions" in? At some point it just becomes fiddling, and yet another source of error when porting.... Chris From owner-freebsd-current@FreeBSD.ORG Wed May 29 04:27:31 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 13471700 for ; Wed, 29 May 2013 04:27:31 +0000 (UTC) (envelope-from unixuser2000-fbsd@yahoo.com) Received: from nm29-vm9.bullet.mail.sg3.yahoo.com (nm29-vm9.bullet.mail.sg3.yahoo.com [106.10.151.168]) by mx1.freebsd.org (Postfix) with ESMTP id 671FA33F for ; Wed, 29 May 2013 04:27:30 +0000 (UTC) Received: from [106.10.166.112] by nm29.bullet.mail.sg3.yahoo.com with NNFMP; 29 May 2013 04:24:40 -0000 Received: from [106.10.150.26] by tm1.bullet.mail.sg3.yahoo.com with NNFMP; 29 May 2013 04:24:40 -0000 Received: from [127.0.0.1] by omp1027.mail.sg3.yahoo.com with NNFMP; 29 May 2013 04:24:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 88193.85014.bm@omp1027.mail.sg3.yahoo.com Received: (qmail 3261 invoked by uid 60001); 29 May 2013 04:24:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1369801480; bh=fYhOEDvZ6Kf4tjlEWgX4sOFK132OUfJ8uhZjIDzs3FI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XFZ0IHbxo+V4s3/cFoBXwR+5q1f7lZc/xDrS6UBVA/p3+zxHtDvGcdcvVPIkx/xkJLAbgVdRCI21UR93LU4KJQCAX1MEijkp7NtMbBQM6JrzLG50V6zMqWolWpzichlxU2HIUXMiWY9kM9a7jL6CwcYpoMYwTNqeLRkucQlfTRA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Z+46qdcmsDTXffU0DJCSCGN/L+r+7LQ6L4PGHlhjEVF2Iuzed2QlUo0YGXXiNhbwKnXgsX7iSP438xAyi6aRiqWw4yA1N/9RyzOIURVa6pt0Kb4dhQhHiYuoisfrhp3mtPuv3JAVbcsuprB3CQQ8t4Bt0cZbvDZBI7ZA9SpB6lA=; X-YMail-OSG: HcW7wzIVM1kGpmz5X2d3HfWEXYUzapxkX.hOMyn.WyTV2Z3 SNU6VDBYNbRnf2uT3WyvYg2Omn9LFheQkZkjEHPDsQyh.kQFolq3zMdcP2nn HFNsI7QlgyWepeyAtjv86A1MCLitPEk6I4OsfK.j1usWpwzDnoseaL4yyvtT k.H.iuNFQo1m4OnzwNIpgJedBioBOl5K8Ji2SjjZfYr3wn791TpfIMDLUiCA ojUrM3nMppNT0mNrOHtj9B7PNXThFYBeb694uKxkhWe1NwgK7ubyMtb7bh7r K16wjIpcywtAw1I43rQg4L0cbW2r1v.0i7rqQTT31DnQpOUD70oRT1UWxuGz U6BO3uEBqsEhyxaEJdSVr5YCsBWvHUn4utqCwxeFwRFvgOBTITq0clD8gcIL W76_dIRaKh8cT4zj4A9Y06QIXJYWvzB8fXIx5lVxrSpaSGI0Hkwi5eJwQMY6 SxrD_QN0MiuhYlM1kGNp5E.EycZSK8C7ozSWj2tKZkE1GH_EPtiA30RMQa4j phR3OfYpwtveloyzQXv4gevsOU7jGKxVcbjoqkKME1hQ3EKhJBhdwbKaLW1c Hr1sfGK2cFW7JEh5wlmEs57KSA1BfZoAkNwJny59Sop2ajCVtyOQv13vkbh8 8zwhLq2ZUSkIkVCcS9brm3Kg1WwMcM_7NKEdKLq.CNN4BRKymkKv9 Received: from [103.245.47.20] by web190706.mail.sg3.yahoo.com via HTTP; Wed, 29 May 2013 12:24:39 SGT X-Rocket-MIMEInfo: 002.001, Cgo.WW91IHRoaW5rIGl0J3MgdHJpdmlhbCB1bnRpbCB5b3UgcmVhZCB0aGlzOgo.Cj5odHRwOi8vaW5maW5pdGV1bmRvLmNvbS9wb3N0LzI1MzI2OTk5NjI4L2ZhbHNlaG9vZHMtcHJvZ3JhbW1lcnMtYmVsaWV2ZS1hYm91dC10aW1lCj4KPklmIHlvdSBzbGVlcCBvbmUgaG91ciwgZG8geW91IHNsZWVwIG9uZSBob3VyIGZyb20gbm93IG9yIG9uZSBob3VyIGZyb20gCj50aGUgc3lzdGVtIGNsb2NrIHdoaWNoIG1heSBjaGFuZ2UgaW4gdGhlIG5leHQgaG91cj_CoCBJZiBpdCdzIHRoZSBzeXN0ZW0gCj5jbG9jaywBMAEBAQE- X-Mailer: YahooMailWebService/0.8.144.546 References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> Message-ID: <1369801479.2670.YahooMailNeo@web190706.mail.sg3.yahoo.com> Date: Wed, 29 May 2013 12:24:39 +0800 (SGT) From: Quark Subject: Re: BSD sleep To: Joshua Isom , Kenta Suzumoto In-Reply-To: <51A541B5.3010905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 29 May 2013 11:19:36 +0000 Cc: "freebsd-current@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Quark List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 04:27:31 -0000 =0A=0A>You think it's trivial until you read this:=0A>=0A>http://infiniteun= do.com/post/25326999628/falsehoods-programmers-believe-about-time=0A>=0A>If= you sleep one hour, do you sleep one hour from now or one hour from =0A>th= e system clock which may change in the next hour?=A0 If it's the system =0A= >clock, you may sleep for ten minutes or ten hours.=A0 If you need to sleep= =0A>for 3600 seconds, that's simple and understandable.=0A=0A=0Awhat is st= opping from interpreting 1h in similar manner to 3600? i.e. from now=0A From owner-freebsd-current@FreeBSD.ORG Wed May 29 11:38:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 063A010E; Wed, 29 May 2013 11:38:38 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id D2CB518A; Wed, 29 May 2013 11:38:37 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id jt11so9067517pbb.38 for ; Wed, 29 May 2013 04:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=52+f6DkQGSiqjofDdzyCkrfq3wsdjttSO2HlyCXpHps=; b=oHU9cqQv5MtyETz9rvXcaRspurVarbY20+yA2DryJBQbsQtJjkupexdbve/P67B89d DcFP3hXoM8MbINwseoaFKNoIBIp1KOmJYPWdmTlhDNpaQb/SSlMniJbV+T9MvkU7xV1X dlbW1XuLK6R5NRsh6YooehBo5amfc8J0ZGizZHYPO7p0HY+7GMWL6RxEIFkn93Ks5x2o /xD2NgM6Bty82EdNeDnZ/y/aAZYSvsU9Kkl3bMj5uIczLd4Fl2X8HBiG4J/zxMdlS4vr fpt1P4ReJJ1ho48yVozcpaPjy9uJlGu8My8erCBJ5IVlOFyWiP0zUjOAQ8Hq5BM1Cgb0 DqTw== MIME-Version: 1.0 X-Received: by 10.68.176.133 with SMTP id ci5mr2483181pbc.21.1369827517605; Wed, 29 May 2013 04:38:37 -0700 (PDT) Received: by 10.68.239.103 with HTTP; Wed, 29 May 2013 04:38:37 -0700 (PDT) In-Reply-To: <1369801479.2670.YahooMailNeo@web190706.mail.sg3.yahoo.com> References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> <1369801479.2670.YahooMailNeo@web190706.mail.sg3.yahoo.com> Date: Wed, 29 May 2013 14:38:37 +0300 Message-ID: Subject: Re: BSD sleep From: Alexander Yerenkow To: Quark Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kenta Suzumoto , Joshua Isom , "freebsd-questions@freebsd.org" , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:38:38 -0000 >what is stopping from interpreting 1h in similar manner to 3600? i.e. from now No, this is user-friendly, and thus can't be done :) But if think a second, sleep is used rarely by average users, mostly by programmers and other scripts, and they should know better what they are doing. Seriously, that explanation about different hours is not enough to prevent at least useful option. like sleep -f 1h (-f means force convert, without it you can see good explanation why sleep for 1 hour will be not sleep for 1 hour, and etc, and not get sleep at all.). Exact units in which sleeps happens (seconds, ticks, minutes, years) can be described in manual page, even without accepting m,h - that info would be useful for one. P.S. There is already non-portable feature in sleep - non-integer, and I'm sure that no one thought about some financists from various countries, who used to specify long numbers with separator, e.g. 3.600, and this means for them one hour and not 3 point 6 seconds. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Wed May 29 04:59:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0E3310B for ; Wed, 29 May 2013 04:59:37 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id AFEB4899 for ; Wed, 29 May 2013 04:59:37 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i10so11128853oag.15 for ; Tue, 28 May 2013 21:59:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+Ht+KMf5JfqvAEaC2oxxKpJZAYPVcaPS9qYLxqAV20Y=; b=cwntsQHsBjJYrZsjo4VRyKGQF2aXEgjq5+eL6LMGFSviQLXV/bfOtHnfcI4R56pM0i topRWnQ9+KlbTysEP2T4zGOFoy9mCLwCLJ9qhDwADqPYu5ugN6npnCj/UqvY+LswaUUt wfUwaUdsMUup2meXLzeEaB6UIH5Z5ScHgP+IVmY0PA2LVtfcX31YWafd4ZH27cMXffX4 DC94rAhYExq17AV0qIhTsbJ9KZvS3Hgd50DcEe10u9tPzZmkn6ikJGJd+RivGu0bBzug YlWnNbyw447luCBbbdmPG/q0tqqbsjrf0Jc5Zc5YHLSxA69G5z371U4qJvQmSzMbNLdf bpLw== MIME-Version: 1.0 X-Received: by 10.60.124.67 with SMTP id mg3mr640917oeb.1.1369803576893; Tue, 28 May 2013 21:59:36 -0700 (PDT) Received: by 10.60.56.198 with HTTP; Tue, 28 May 2013 21:59:36 -0700 (PDT) In-Reply-To: <51A541B5.3010905@gmail.com> References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> Date: Tue, 28 May 2013 21:59:36 -0700 Message-ID: Subject: Re: BSD sleep From: Michael Sierchio To: Joshua Isom X-Gm-Message-State: ALoCoQm3hIZukR5lbjq4GJsg5T8G1DniOQL2yMIdEPOQCjKrWiWwwxwDgkS2Y2BUWfHVw6NnTNCP X-Mailman-Approved-At: Wed, 29 May 2013 11:39:59 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Kenta Suzumoto , freebsd-current@freebsd.org, FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 04:59:37 -0000 On Tue, May 28, 2013 at 4:45 PM, Joshua Isom wrote: > You think it's trivial until you read this: > > http://infiniteundo.com/post/**25326999628/falsehoods-** > programmers-believe-about-time > > Some days have 86400 seconds, some have 86401. There is a provision for two leap seconds to be applied at once, but that hasn't ever happened. Still, a truly correct clock, set to UTC, might someday read 23:59:59 23:59:60 23:59:61 00:00:00 How many seconds did that hour have? From owner-freebsd-current@FreeBSD.ORG Wed May 29 11:58:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4FC293D for ; Wed, 29 May 2013 11:58:16 +0000 (UTC) (envelope-from jbirch@jbirch.net) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id A22362F7 for ; Wed, 29 May 2013 11:58:16 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wo10so281372obc.3 for ; Wed, 29 May 2013 04:58:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=OlWU4juSr49ng8FJNxVAU+6iKoQK0vakyeCXOyYrkZg=; b=jYVC0BAfFC31auQdTNmgrRbfOh3uxDSBv/yiPV6cHRaIm3GF1oA9fxJwmRE/CX6D/5 MW31+letOLR7tQyGiDg3xVdivZe62Npk3wePhuQjkaYoJ35JGK3iQ8wRp6tCBRDew+6Z WeB8P3bK5a7kvAnjZVZBGlLuqgXMQ2ypz0HMAH4ZZa/rT4Mnxj01R+pJvGOLuUXpA2Fq 7hBJ8uh+74nxpeTwjdQf5Hw4Kyn5y4ysCIEQzY7FGyVlKwGv1qBdByx4g0Fa7tP14ieL suM73i2A3FslJLJXrTBAyk1W63IhRpwKmg/a7yHD/HxG1PJcGOieDPXg6SOR7G96WXZG Lcdw== MIME-Version: 1.0 X-Received: by 10.60.37.133 with SMTP id y5mr1329658oej.123.1369828696175; Wed, 29 May 2013 04:58:16 -0700 (PDT) Received: by 10.182.55.35 with HTTP; Wed, 29 May 2013 04:58:16 -0700 (PDT) X-Originating-IP: [49.176.128.84] In-Reply-To: References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> <1369801479.2670.YahooMailNeo@web190706.mail.sg3.yahoo.com> Date: Wed, 29 May 2013 21:58:16 +1000 Message-ID: Subject: Re: BSD sleep From: Jason Birch To: "freebsd-current@freebsd.org" , "freebsd-questions@freebsd.org" X-Gm-Message-State: ALoCoQm7lbIqGZORAMnpT82DEwRGU2DFRQjSew5GDws8NJqZaeZZr9bXGnhOlEWmnFigIUnotR9H Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 11:58:16 -0000 > Seriously, that explanation about different hours is not enough to prevent > at least useful option. > like > sleep -f 1h > (-f means force convert, without it you can see good explanation why sleep > for 1 hour will be not sleep for 1 hour, and etc, and not get sleep at > all.). > Do one thing, and do it well. What you have proposed involves: * an additional force flag * interpolation of what follows the force flag (does m mean minutes, or months?) * expectations around time, time zones, and what an hours is. That fails the litmus test on complexity for me personally - it seems like a lot of complexity for not much gain. > P.S. There is already non-portable feature in sleep - non-integer, and I'm > sure that no one thought about some financists from various countries, who > used to specify long numbers with separator, e.g. 3.600, and this means for > them one hour and not 3 point 6 seconds. > This isn't a good reason for adding another non-portable feature. From owner-freebsd-current@FreeBSD.ORG Wed May 29 12:11:04 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB442F9B; Wed, 29 May 2013 12:11:04 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 94124637; Wed, 29 May 2013 12:11:04 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id mc17so9114834pbc.32 for ; Wed, 29 May 2013 05:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fZhQf8xGG2bCQutx/KvIGvPTHWufCXYB05kHxEWT/nk=; b=zZ2xHn/pbvxebYx7MvyV2bqEQvZFISWOXz2uhd/Y6D0AWdtcIlElY4RgOJq4QCxUNw NCx5SQTTTE7mEE/RheNyV8crc9cRwQev491dvD36fV1Uly078DOKc21c4vUr00whiiSX UHSGKDvW8Gx97ofRynGLC3rx7kgJGqMdftXiS/KESkjxPnUiB+E4AmV9CqJjd4+qUKGY nVM5cn3diRz9mMZmN1D3/sNBwpbNxu9AVaZYbI+HgbtLE+7eh3hI0+0sLE/ZQOg9mmJm ckbGvjlwJOtJYncZarcddlqB9U1Rl3Pr7+Asy+qnS4jiQZ3vcqGBxXZHDKY5OIj00Z8/ KGUQ== MIME-Version: 1.0 X-Received: by 10.67.5.8 with SMTP id ci8mr3101468pad.48.1369829464418; Wed, 29 May 2013 05:11:04 -0700 (PDT) Received: by 10.68.239.103 with HTTP; Wed, 29 May 2013 05:11:04 -0700 (PDT) In-Reply-To: References: <20130528230140.A5B396F448@smtp.hushmail.com> <51A541B5.3010905@gmail.com> <1369801479.2670.YahooMailNeo@web190706.mail.sg3.yahoo.com> Date: Wed, 29 May 2013 15:11:04 +0300 Message-ID: Subject: Re: BSD sleep From: Alexander Yerenkow To: Jason Birch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-current@freebsd.org" , "freebsd-questions@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:11:04 -0000 I'm just saying that there's pretty space for discussion. If someone raised this now, why not discuss it now. > If you sleep one hour, do you sleep one hour from now or one hour from the system clock which may change in the next hour? If it's the system clock, you may sleep for ten minutes or ten hours. If you need to sleep for 3600 seconds, that's simple and understandable. How about rephrase it: > If you sleep 3600 seconds, do you sleep 3600 seconds from now or 3600 seconds from the system clock which may change in the next hour? If it's the system clock, you may sleep for ten minutes or ten hours. How "way of specifying period" changing the fact that "internal minimal unit of sleep" is not clearly specified in manpage? Also, there no info on how DST/ ntp time changes affects of running sleeps. I don't see right now how new flag (which currently if specified makes `sleep` exit with help), could break something, but I see that this is could be useful in some cases. This also raise question what sleep should do if something specified incorrectly, like sleep 2h30m30m , or 1h1h or else. And also if any changes would be accepted, this should be specified in manpage (that one about `m` as month). About non-portable feature with non-integers, it was just side observation. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Wed May 29 12:16:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D4E692CB for ; Wed, 29 May 2013 12:16:55 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B936A6B9 for ; Wed, 29 May 2013 12:16:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4TCGt0N020297 for ; Wed, 29 May 2013 12:16:55 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4TCGtXl020294 for current@freebsd.org; Wed, 29 May 2013 12:16:55 GMT (envelope-from bdrewery) Received: (qmail 16804 invoked from network); 29 May 2013 07:16:53 -0500 Received: from unknown (HELO ?10.10.1.133?) (freebsd@shatow.net@10.10.1.133) by sweb.xzibition.com with ESMTPA; 29 May 2013 07:16:53 -0500 Message-ID: <51A5F1AC.3060606@FreeBSD.org> Date: Wed, 29 May 2013 07:16:44 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 Subject: Re: Supermicro 6027R-N3RF+head, usb trouble References: <20130421223838.6bec3bfb@laptop.minsk.domain> <51A4F585.60401@FreeBSD.org> <20130529083338.07a2f54b@laptop.minsk.domain> In-Reply-To: <20130529083338.07a2f54b@laptop.minsk.domain> X-Enigmail-Version: 1.5.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MVMDPAFWFIIWMKWOACXL" Cc: hps@bitfrost.no, "Sergey V. Dyatko" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:16:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MVMDPAFWFIIWMKWOACXL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: > On Tue, 28 May 2013 13:20:53 -0500 > Bryan Drewery wrote: >=20 >> On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: >>> Hi, >>> >>> Can anybody explain why USB keyboard (and keyboard from >>> integrated IPKVM) doesn't work when I boot with 'C606 >>> chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? >>> Also I can't boot that box from usb memstick and >>> FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both >>> loose(?) device and can't find root If I disable controller in bios >>> system can't see any sata hdd connected to it:( >>> booting with hw.usb.ehci.no_hs=3D1, kern.cam.boot_delay=3D"10000" >>> and debug.acpi.disabled=3D"hostres" without success. I setup dhcpd, >>> tftp, nfs on my laptop and finally I install fbsd on that box, but >>> question with kbd is open - It doesn't work.. >>> dmesg: >>> http://svn.freebsd.by/files/dmesg_N3RF.txt >>> pciconf -lv: >>> http://svn.freebsd.by/files/pciconf_N3RF.txt >>> >>> I would appreciate any hints >>> >> >> I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE >> (disc1) seems ok though. >> >> Did you get this figured out? >> >=20 > I added to loader.conf > kern.maxbcache=3D"128M" > vfs.maxbufspace=3D134217728 > also I create /boot.config with '-v' > I don't know what exactly help, but now usb kbd (ipkvm) works fine > for me. > p.s. It is smbios.system.product=3D"X9DRW" >=20 Yes! This fix of limiting the size worked for me. USB worked on boot, kb works remotely in the IP KVM and locally as well now. For the record, this is a DELL C1100 with 72GB of ram. The symptoms match the previous posts though and the delay settings did not help. This was working on 9.1-R, something must have changed on HEAD. This is not a production system, I'm willing to try any patches or settings to help get this fixed by default. --=20 Regards, Bryan Drewery ------enig2MVMDPAFWFIIWMKWOACXL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpfGsAAoJEG54KsA8mwz578YQAIX9SnV0lW6q6ROmPUv8Sir1 p7cozt6LTy8ZNbd/r9e2EwBw8bE+6UWy5SUJfdqGRBZnmlPetvyqVzFQgHR/ficv 88vBzF+oJxODNgkCiJgPnnAnflobpXSDcfnc0WHliHeEmpYIcfPvdGjcOzcLjHP0 Zv64RbzUiTznlGvSaJyt0jpNkjZH8iTsClz1SVscgmkeJnNQNMUnhL0a+4umyFmc t/BbRyIYZufxIO1SvOGgLHttHpFPh60f1bEU73lMvt+GgI+Wfx3lPG/QgTvmHpmU YaZdno/PVOR15ywlHoH5F4bWOAAQtMC0+f5flxSk0JOI0XdHAAXP8j3yXxFZmff8 inL9cwf9iT/oJe6Zdajciyg5HGiVBROFmmLyaa8jc6ZnoXzl31AonvDFw1mJvZLK XZKVRbvlpjwOTQtDuenhs5HhWg4mjGvKu24Qjn+6Xefy7IrfgPCHhGbJxSSZ6pOi 8fIXASHeAhczjs71HlMxGjq8/tAE0ZOg1tdHk3sz4jU/dmpGKleUKKILx/Tpiuwm qTPSg5U8NAn76b3ohb7ebNwyOmo/+KX9MPYg7PUiMFiXWF2LN0w4cMWfn5QW30Rg Wa109/23IgjD17oM4yicVujZ3awIJE1KA4sY5gy1ZsfS2AbnULxCsWiIrsvzGR+P 3XNPKGNb7xZqpIO4f6sO =mL+O -----END PGP SIGNATURE----- ------enig2MVMDPAFWFIIWMKWOACXL-- From owner-freebsd-current@FreeBSD.ORG Wed May 29 12:45:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7B1FFC for ; Wed, 29 May 2013 12:45:51 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BF8A198B for ; Wed, 29 May 2013 12:45:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4TCjpbX025349 for ; Wed, 29 May 2013 12:45:51 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4TCjpuk025348 for freebsd-current@freebsd.org; Wed, 29 May 2013 12:45:51 GMT (envelope-from bdrewery) Received: (qmail 11257 invoked from network); 29 May 2013 07:45:50 -0500 Received: from unknown (HELO ?10.10.1.133?) (freebsd@shatow.net@10.10.1.133) by sweb.xzibition.com with ESMTPA; 29 May 2013 07:45:50 -0500 Message-ID: <51A5F873.2000103@FreeBSD.org> Date: Wed, 29 May 2013 07:45:39 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Supermicro 6027R-N3RF+head, usb trouble References: <20130421223838.6bec3bfb@laptop.minsk.domain> <51A4F585.60401@FreeBSD.org> <20130529083338.07a2f54b@laptop.minsk.domain> <51A5F1AC.3060606@FreeBSD.org> In-Reply-To: <51A5F1AC.3060606@FreeBSD.org> X-Enigmail-Version: 1.5.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GSBOCELBMDWHFXSVREEG" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:45:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GSBOCELBMDWHFXSVREEG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/29/2013 7:16 AM, Bryan Drewery wrote: > On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: >> On Tue, 28 May 2013 13:20:53 -0500 >> Bryan Drewery wrote: >> >>> On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: >>>> Hi, >>>> >>>> Can anybody explain why USB keyboard (and keyboard from >>>> integrated IPKVM) doesn't work when I boot with 'C606 >>>> chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? >>>> Also I can't boot that box from usb memstick and >>>> FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both >>>> loose(?) device and can't find root If I disable controller in bios >>>> system can't see any sata hdd connected to it:( >>>> booting with hw.usb.ehci.no_hs=3D1, kern.cam.boot_delay=3D"10000" >>>> and debug.acpi.disabled=3D"hostres" without success. I setup dhcpd, >>>> tftp, nfs on my laptop and finally I install fbsd on that box, but >>>> question with kbd is open - It doesn't work.. >>>> dmesg: >>>> http://svn.freebsd.by/files/dmesg_N3RF.txt >>>> pciconf -lv: >>>> http://svn.freebsd.by/files/pciconf_N3RF.txt >>>> >>>> I would appreciate any hints >>>> >>> >>> I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE >>> (disc1) seems ok though. >>> >>> Did you get this figured out? >>> >> >> I added to loader.conf >> kern.maxbcache=3D"128M" ^ This setting is all that was needed. The VFS change was not needed. >> vfs.maxbufspace=3D134217728 >> also I create /boot.config with '-v' >> I don't know what exactly help, but now usb kbd (ipkvm) works fine >> for me. >> p.s. It is smbios.system.product=3D"X9DRW" >> >=20 > Yes! This fix of limiting the size worked for me. USB worked on boot, k= b > works remotely in the IP KVM and locally as well now. >=20 > For the record, this is a DELL C1100 with 72GB of ram. The symptoms > match the previous posts though and the delay settings did not help. >=20 > This was working on 9.1-R, something must have changed on HEAD. >=20 > This is not a production system, I'm willing to try any patches or > settings to help get this fixed by default. >=20 --=20 Regards, Bryan Drewery ------enig2GSBOCELBMDWHFXSVREEG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpfhzAAoJEG54KsA8mwz5Fs8QAIUVC+bheHMK/WiWC1CtdPCQ lFv/WEdIKAV1SkOTc5sbEkl5wl0UIQGhd8EjOdPY75AIztC+8VzzPpnnqljFr7Wd U0VT+izHyVJgyA6Z9CuWxcPZYFEIDQwqa6tMAox0NN10WyUBlDSswLXc+3MeMSPt kgohG0Fx0vp+JXZFGDx1TPxJp1t/rdzqplnU2g8GWCCkAG/OoWyVRGzlvZBTi46s cAUWWxdVUd1wcjG2AOFXsBYDH1bwpfOBkkuAxnvEi/PRz0nTj2g/l/D7xort2DWI Gm705CXyral5ZNYMeRCYpHISX2V+2SXZwFPiFF7mLSxRZHMjjRe9A5re15RuR/vY NJtjhk/RvoFIOexNsFXTi17bI0R/ZdibgUAbs8I/u+6UehR6Xy/RYV3Q6gANS2Ib AHRxKqV84U4WcPOG8cFR3/qHPJCsuM/AC4qVn1jsdyJdZlC2Byoe6XeFNegBpJcs zf5Tv4FIZjtQrsfd8kKQ7hjoiI0q91RR96XcZmIktT0/CLM1bSGtPCr7ci4eeBQT hY+uOY0rBpj0ly9Il+b9mEDohpmS1GBaGsxJvhC7QZPETC4JIw9p4I3Zh6Y9ibiy YD5UARNWYaM6mlv4GCyHowI2zyypGtYhHZfAAZlSXvNHofDLMlXEaSKjyI5wHICL 3flq/vrw0vvSKWLup3I/ =TOYx -----END PGP SIGNATURE----- ------enig2GSBOCELBMDWHFXSVREEG-- From owner-freebsd-current@FreeBSD.ORG Wed May 29 13:19:38 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A91C11CA for ; Wed, 29 May 2013 13:19:38 +0000 (UTC) (envelope-from amon@aelita.org) Received: from aelita.org (unknown [IPv6:2001:7a8:7003::3]) by mx1.freebsd.org (Postfix) with ESMTP id 12F51D82 for ; Wed, 29 May 2013 13:19:37 +0000 (UTC) Received: from ra.aabs (localhost [127.0.0.1]) by aelita.org (8.14.5/8.14.5) with ESMTP id r4TDDDKH074743; Wed, 29 May 2013 15:13:13 +0200 (CEST) (envelope-from amon@ra.aabs) Received: (from amon@localhost) by ra.aabs (8.14.5/8.14.5/Submit) id r4TDDDjI074742; Wed, 29 May 2013 15:13:13 +0200 (CEST) (envelope-from amon) Date: Wed, 29 May 2013 15:13:13 +0200 From: Herve Boulouis To: freebsd-current@freebsd.org Subject: Support of Dell M620 broadcom BCM57810 Message-ID: <20130529131313.GA24559@ra.aabs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: davidch@broadcom.com, zambrano@broadcom.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:19:38 -0000 Hi, I just tried to install 9.1-STABLE on a Dell M620 and it seems its network cards (Broadcom NetXtreme 10G BCM57810) are not yet supported by the bxe driver. I looked into -head but the driver doesn't seem to support it there either. It looks like there are some efforts ongoing : http://freebsd.1045724.n5.nabble.com/panic-at-serial-boot-td5799226.html Is there some test code I could try ? The goal is to run -stable but I can do some testing on -head if necessary. Regards, -- Herve Boulouis From owner-freebsd-current@FreeBSD.ORG Wed May 29 14:31:09 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 60D2B438 for ; Wed, 29 May 2013 14:31:09 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0EFAF860 for ; Wed, 29 May 2013 14:31:08 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=DdQu9JdW c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=x7DcbBAiyEsA:10 a=LjTOzC1lAAAA:8 a=g3k24fdcAAAA:8 a=ieAdtpj_wPgR9xui4aQA:9 a=CjuIK1q_8ugA:10 a=KmloqkfaIt8A:10 a=6k4BJ-aj_1UA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:28572] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 88/47-04294-F8016A15; Wed, 29 May 2013 10:28:32 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <20902.4239.221857.859835@jerusalem.litteratus.org> Date: Wed, 29 May 2013 10:28:31 -0400 To: current@freebsd.org Subject: "make buildworld" fails X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: roberthuff@rcn.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:31:09 -0000 DQoJT24gYSBzeXN0ZW0gcnVubmluZzoNCg0KIEZyZWVCU0QgMTAuMC1DVVJSRU5UICMwIHIy NDg5Mzg6IFN1biBNYXIgMzEgMDY6MjQ6NDIgRURUIDIwMTMgYW1kNjQNCg0KCXdpdGggdGhl IHNvdXJjZSB0cmVlIHVwZGF0ZWQgZXZlcnkgbmlnaHQsICJtYWtlIGJ1aWxkd29ybGQiDQpo YXMgZmFpbGVkIGZvciBhYm91dCB0aGUgcGFzdCB3ZWVrIHdpdGg6DQoNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50 cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0 LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1X bm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAt V25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50 aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAt YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0UHJldi5jDQpjYyAtTyAtcGlw ZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAt RFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lT UEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29u dHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVu dHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1h dC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdt aXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAt V25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQg LVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVu dGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdFJlbW92ZS5jDQpjYyAtTyAt cGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19I ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVG U1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMv Y29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1 bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZv cm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMg LVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXpl ZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1p bnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBh cmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lv biAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdFJlcGxhY2UuYw0KY2Mg LU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtl ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05G SUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRI X0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Iv c3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQt YXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVdu by1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5 cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlh bGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBs dXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVdu by1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZl cnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RTdWNjLmMNCmNj IC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFr ZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09O RklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFU SF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNy L3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2Vk LWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1X bm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90 eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRp YWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1w bHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1X bm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252 ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N0cmVzZXAuYw0KY2MgLU8gLXBp cGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAg LURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZ U1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2Nv bnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1l bnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3Jt YXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1X bWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQg LVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50 IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJl bnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24g ICAtc3RhdGljIC1vIG1ha2UgYXJjaC5vIGJ1Zi5vIGNvbXBhdC5vIGNvbmQubyBkaXIubyBm b3IubyBoYXNoLm8gam9iLm8gbWFpbi5vIG1ha2UubyBtYWtlX21hbGxvYy5vIG1ldGEubyBw YXJzZS5vIHN0ci5vIHN0cmxpc3QubyBzdWZmLm8gdGFyZy5vIHRyYWNlLm8gdXRpbC5vIHZh ci5vIGxzdEFwcGVuZC5vIGxzdEF0RW5kLm8gbHN0QXRGcm9udC5vIGxzdENsb3NlLm8gbHN0 Q29uY2F0Lm8gbHN0RGF0dW0ubyBsc3REZVF1ZXVlLm8gbHN0RGVzdHJveS5vIGxzdER1cGwu byBsc3RFblF1ZXVlLm8gbHN0RmluZC5vIGxzdEZpbmRGcm9tLm8gbHN0Rmlyc3QubyBsc3RG b3JFYWNoLm8gbHN0Rm9yRWFjaEZyb20ubyBsc3RJbml0Lm8gbHN0SW5zZXJ0Lm8gbHN0SXNB dEVuZC5vIGxzdElzRW1wdHkubyBsc3RMYXN0Lm8gbHN0TWVtYmVyLm8gbHN0TmV4dC5vIGxz dE9wZW4ubyBsc3RQcmV2Lm8gbHN0UmVtb3ZlLm8gbHN0UmVwbGFjZS5vIGxzdFN1Y2MubyBz dHJlc2VwLm8gDQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoICAtbyByb290IC1nIHdo ZWVsIC1tIDU1NSAgIG1ha2UgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L21ha2UNCnVz YWdlOiBtYWtlIFstQmVpa05ucXJzdFdYXSANCiAgICAgICAgICAgIFstQyBkaXJlY3Rvcnld IFstRCB2YXJpYWJsZV0gWy1kIGZsYWdzXSBbLWYgbWFrZWZpbGVdDQogICAgICAgICAgICBb LUkgZGlyZWN0b3J5XSBbLUogcHJpdmF0ZV0gWy1qIG1heF9qb2JzXSBbLW0gZGlyZWN0b3J5 XSBbLVQgZmlsZV0NCiAgICAgICAgICAgIFstViB2YXJpYWJsZV0gW3ZhcmlhYmxlPXZhbHVl XSBbdGFyZ2V0IC4uLl0NCioqKiBbYnVpbGR3b3JsZF0gRXJyb3IgY29kZSAyDQoNClN0b3Ag aW4gL3Vzci9zcmMuDQoNCg0KCUkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHNyYy9VUERBVElO RywgYW5kIGRvbid0IHJlbWVtYmVyDQphbnl0aGluZyBvbiB0aGlzIGxpc3Qgb3IgcXVlc3Rp b25zQC4NCgltYWtlLGNvbmYgaXMgYXBwZW5kZWQ7IHRoZXJlIGlzIG5vIHNyYy5jb25mDQoN CglXaGF0IGhhdmUgSSBib3JrZWQ/DQoNCglSZXNwZWN0ZnVsbHksDQoNCg0KCQkJCVJvYmVy dCBIdWZmDQoNCgwgICBtYWtlLmNvbmYNCg0KQ0ZMQUdTPQkJCS1PIC1waXBlIC1nIA0KU1RS SVA9IA0KU1lNVkVSX0VOQUJMRUQ9CXllcw0KWF9XSU5ET1dfU1lTVEVNPQl4b3JnDQpIQVZF X01PVElGPQkJeWVzDQoNCiNGQz0iZ2ZvcnRyYW40MiINCg0KS0VSTkNPTkY9SkVSVVNBTEVN DQoNCiMgVG8gYXZvaWQgYnVpbGRpbmcgdmFyaW91cyBwYXJ0cyBvZiB0aGUgYmFzZSBzeXN0 ZW06DQojCShjb3BpZWQgZnJvbSAvdXNyL3NoYXJlL2V4YW1wbGVzL2V0Yy9tYWtlLmNvbmYN Cg0KTk9fQklORF9FVEM9ICAgICAgIHRydWUgICAgIyBEbyBub3QgaW5zdGFsbCBmaWxlcyB0 byAvZXRjL25hbWVkYg0KTk9fQkxVRVRPT1RIPSAgdHJ1ZSAgICAjIGRvIG5vdCBidWlsZCBC bHVldG9vdGggcmVsYXRlZCBzdHVmZg0KTk9fUFJPRklMRT0gICAgIHRydWUgICAgIyBBdm9p ZCBjb21waWxpbmcgcHJvZmlsZWQgbGlicmFyaWVzDQoNCiMJdG8gZ2V0IGF1dG9tYXRpYyBT QVNMIGluIHNlbmRtYWlsDQoNClNFTkRNQUlMX0NGTEFHUys9CS1JL3Vzci9sb2NhbC9pbmNs dWRlLyAtRFNBU0w9Mg0KU0VORE1BSUxfTERGTEFHUys9CS1ML3Vzci9sb2NhbC9saWINClNF TkRNQUlMX0xEQUREKz0JLWxzYXNsMg0KDQojDQojCXRvIG1ha2UgQ1VQUyBtYWdpY2FsbHkg a2VlcCB3b3JraW5nDQojCVNlZTogaHR0cDovL3d3dy5jc3VhLmJlcmtlbGV5LmVkdS9+cmFu Z2Evbm90ZXMvZnJlZWJzZF9jdXBzLmh0bWwNCiMNCg0KQ1VQU19PVkVSV1JJVEVfQkFTRT0J eWVzDQpOT19MUFI9CQkJCXRydWUNCg0KIwlhZGRlZCBwZXIgL3Vzci9wb3J0cy9VUERBVElO RyBlbnRyeSAyMDA5MDQwMQ0KDQpPVkVSUklERV9MSU5VWF9CQVNFX1BPUlQ9ZjEwDQpPVkVS UklERV9MSU5VWF9OT05CQVNFX1BPUlRTPWYxMA0KDQojDQoNCldJVEhfTU9aSUxMQT0JCQls aWJ4dWwNCldJVEhfR0VDS089CQkJbGlieHVsDQoNCiMNCiMgYWRkZWQgMjAwNy8wMy8wNCBw ZXIgYWR2aWNlIG9mIDxmcmVlYnNkQHRyb2JhY2suY29tPiANCiMJaW4gcmUgc2NpZW5jZS9n cmFtcHMNCiMNCg0KV0lUSF9CRVJLRUxFWURCPWRiNDMNCldJVEhfQkRCX1ZFUj00Mw0KV0FO VF9PUEVOTERBUF9WRVI9MjQNCldBTlRfT1BFTkxEQVBfU0FTTD10cnVlDQoNCiMNCiMgIGFz IHJlcXVpcmVkIGJ5IHBvcnRzL1VQREFUSU5HIG9mIDIwMTIxMDEyDQojDQoNClNBTUJBX0VO QUJMRT1ZRVMNCg0KIw0KIyBQT1JUUzogdXNlIGNsYW5nIHVubGVzcyBnY2MgaXMgZXhwbGlj aXRseSByZXF1aXJlZA0KIw0KDQojDQojIGRlZmF1bHQgdG8gdXNpbmcgY2xhbmcgZm9yIGFs bCBwb3J0IGJ1aWxkcywgd2l0aCB0aGUgZm9sbG93aW5nDQojIGV4Y2VwdGlvbnMNCg0KIyBw b3J0cyB3aGljaCB3aWxsIG9ubHkgYnVpbGQgd2l0aCB0aGUgYmFzZSBzeXN0ZW0gR05VIGNv bXBpbGVyICg0LjIpDQojDQojIHRoZSAibWFrZSBpbmRleCIgdGFyZ2V0IGFsc28gc2VlbXMg dG8gbmVlZCB0aGlzLCBmb3Igc29tZSByZWFzb24NCg0KLmlmIHRhcmdldChpbmRleCkgfCBc DQokey5DVVJESVI6TSovZGV2ZWwvYW50bHIqfSB8IFwNCiR7LkNVUkRJUjpNKi9kZXZlbC9n b29nbGUtcGVyZnRvb2xzKiB9IHwgXA0KJHsuQ1VSRElSOk0qL2dyYXBoaWNzL0ltYWdlTWFn aWNrKiB9IHwgXA0KJHsuQ1VSRElSOk0qL2dyYXBoaWNzL29wZW5jdip9IHwgXA0KJHsuQ1VS RElSOk0qL3gxMS9rZGVsaWJzNCp9IHwgXA0KVVNFX0dDQz89NC4yDQouZW5kaWYNCg0KIyBw b3J0cyB3aGljaCBuZWVkICpzb21lKiB2ZXJzaW9uIG9mIHRoZSBHTlUgY29tcGlsZXIgKHdv bid0IGJ1aWxkIHdpdGgNCiMgY2xhbmcgb3IgaGF2ZSBydW50aW1lIGlzc3VlcyBpZiBidWls dCB3aXRoIGNsYW5nKQ0KIyB1c2UgdGhlIGhpZ2hlc3QgdmVyc2lvbiBvZiBnY2Mgd2UgaGF2 ZSBpbnN0YWxsZWQgZnJvbSBwb3J0cyAoNC42KQ0KDQouaWYgJHsuQ1VSRElSOk0qL2FjY2Vz c2liaWxpdHkvam92aWUqfSB8IFwNCiR7LkNVUkRJUjpNKi9hY2Nlc3NpYmlsaXR5L2tkZWFj Y2Vzc2liaWxpdHk0Kn0gfCBcDQokey5DVVJESVI6TSovYXVkaW8vZ3JpcCp9IHwgXA0KJHsu Q1VSRElSOk0qL2F1ZGlvL21wZzEyMyp9IHwgXA0KJHsuQ1VSRElSOk0qL2F1ZGlvL3Jvc2Vn YXJkZW4qfSB8IFwNCiR7LkNVUkRJUjpNKi9kYXRhYmFzZXMvdmlydHVvc28qfSB8IFwNCiR7 LkNVUkRJUjpNKi9kZXNrdXRpbHMva2RlcGltbGliczQqfSB8IFwNCiR7LkNVUkRJUjpNKi9k ZXZlbC9hcGFjaGUtYW50Kn0gfCBcDQokey5DVVJESVI6TSovZGV2ZWwvaWN1Kn0gfCBcDQok ey5DVVJESVI6TSovZGV2ZWwva2RldmVsb3Ata2RlNCp9IHwgXA0KJHsuQ1VSRElSOk0qL2Rl dmVsL2tkZXZwbGF0Zm9ybSp9IHwgXA0KJHsuQ1VSRElSOk0qL2RldmVsL2xvZzRqKn0gfCBc DQokey5DVVJESVI6TSovZ2FtZXMva2RlZ2FtZXM0Kn0gfCBcDQokey5DVVJESVI6TSovZ3Jh cGhpY3MvdG9uaWNwb2ludC12aWV3ZXIqfSB8IFwNCiR7LkNVUkRJUjpNKi9qYXZhLyogfSB8 IFwNCiR7LkNVUkRJUjpNKi9sYW5nL2djYyogfSB8IFwNCiR7LkNVUkRJUjpNKi9tYXRoL2Zm dHczKn0gfCBcDQokey5DVVJESVI6TSovbXVsdGltZWRpYS9hdmlkZW11eDIqfSB8IFwNCiR7 LkNVUkRJUjpNKi9tdWx0aW1lZGlhL2tkZW11bHRpbWVkaWE0Kn0gfCBcDQokey5DVVJESVI6 TSovbXVsdGltZWRpYS92bGMqfSB8IFwNCiR7LkNVUkRJUjpNKi9tdWx0aW1lZGlhL3hibWMq fSB8IFwNCiR7LkNVUkRJUjpNKi9uZXQva2RlbmV0d29yazQqfSB8IFwNCiR7LkNVUkRJUjpN Ki9uZXQvbXBpY2gyKn0gfCBcDQokey5DVVJESVI6TSovbmV0L29wYWwzKn0gfCBcDQokey5D VVJESVI6TSovbmV0LXAycC9rdG9ycmVudCp9IHwgXA0KJHsuQ1VSRElSOk0qL25ldC1wMnAv dnV6ZSp9IHwgXA0KJHsuQ1VSRElSOk0qL3N5c3V0aWxzL2xzb2YqfSB8IFwNCiR7LkNVUkRJ UjpNKi90ZXh0cHJvYy9kb2Nib29rLXhzbCp9IHwgXA0KJHsuQ1VSRElSOk0qL3RleHRwcm9j L2ZvcCp9IHwgXA0KJHsuQ1VSRElSOk0qL3d3dy9saWJ4dWwqfSB8IFwNCiR7LkNVUkRJUjpN Ki94MTEva2RlNC1iYXNlYXBwcyp9IHwgXA0KJHsuQ1VSRElSOk0qL3gxMS9rZGU0LXdvcmtz cGFjZSp9IHwgXA0KJHsuQ1VSRElSOk0qL3gxMS9seHBhbmVsKn0gfCBcDQpVU0VfR0NDPz00 LjYrDQouZW5kaWYNCg0KLmlmICR7LkNVUkRJUjpNKi91c3IvcG9ydHMvKn0NCi5pZiAhZGVm aW5lZChVU0VfR0NDKQ0KLmlmICFkZWZpbmVkKENDKSB8fCAke0NDfSA9PSAiY2MiDQpDQz1j bGFuZw0KLmVuZGlmDQouaWYgIWRlZmluZWQoQ1hYKSB8fCAke0NYWH0gPT0gImMrKyINCkNY WD1jbGFuZysrDQouZW5kaWYNCi5pZiAhZGVmaW5lZChDUFApIHx8ICR7Q1BQfSA9PSAiY3Bw Ig0KQ1BQPWNsYW5nLWNwcA0KLmVuZGlmDQouZW5kaWYNCi5lbmRpZg0KDQoNCldJVEhfTkVX X1hPUkc9eWVzDQoNCldJVEhfQlNEX1NPUlQ9DQoNCldJVEhfUEtHTkc9eWVzDQoNCiMgYWRk ZWQgYnkgdXNlLnBlcmwgMjAxMy0wNS0yOCAxMDozMjowMg0KUEVSTF9WRVJTSU9OPTUuMTYu Mg== From owner-freebsd-current@FreeBSD.ORG Wed May 29 15:47:27 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1183DC5 for ; Wed, 29 May 2013 15:47:27 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from popeye.kernel32.de (popeye.kernel32.de [46.4.9.204]) by mx1.freebsd.org (Postfix) with ESMTP id B2A3A32B for ; Wed, 29 May 2013 15:47:27 +0000 (UTC) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTP id 675BE289AA for ; Wed, 29 May 2013 17:39:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at popeye.kernel32.de Received: from popeye.kernel32.de ([127.0.0.1]) by popeye.kernel32.de (popeye.kernel32.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFwCzcN3xOC2 for ; Wed, 29 May 2013 17:39:17 +0200 (CEST) Received: from popeye.kernel32.de (localhost [127.0.0.1]) by popeye.kernel32.de (Postfix) with ESMTPA id 5E1A4288FE for ; Wed, 29 May 2013 17:39:17 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 May 2013 17:39:17 +0200 From: mh@kernel32.de To: Subject: Re: Support of Dell M620 broadcom BCM57810 In-Reply-To: <20130529131313.GA24559@ra.aabs> References: <20130529131313.GA24559@ra.aabs> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube WebMail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:47:28 -0000 Hi Ho, sorry for top posting... I contacted the Broadcom developers mentioned in bxe(4). Very friendly guys. They said that they're about to give the driver to FreeBSD someday in May (2013). I guess that didn't happen yet. I'd suspect it has something to do with broadcom's internal procedures... Since they were that open minded and friendly I'll just go and drop them another email and ask them how the driver is doing. Until than... there's not much you can do except waiting, I guess. I'm also waiting for support of this driver. Preferably in 9-STABLE :) BeSD regards, Marian Am 2013-05-29 15:13, schrieb Herve Boulouis: > Hi, > > I just tried to install 9.1-STABLE on a Dell M620 and it seems its > network cards (Broadcom NetXtreme 10G BCM57810) > are not yet supported by the bxe driver. > > I looked into -head but the driver doesn't seem to support it there > either. > > It looks like there are some efforts ongoing : > > > http://freebsd.1045724.n5.nabble.com/panic-at-serial-boot-td5799226.html > > Is there some test code I could try ? The goal is to run -stable but > I can do some testing on -head if necessary. > > Regards, > > -- > Herve Boulouis > _______________________________________________ > 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 May 29 17:31:36 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA36C8AB for ; Wed, 29 May 2013 17:31:36 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 75C40AFF for ; Wed, 29 May 2013 17:31:36 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id eg20so8968644lab.27 for ; Wed, 29 May 2013 10:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZcNFre+8VxZ/+cDyhdnsUt0Lu1TTV6HmdAQu6zxCvxU=; b=RDmTlZoit3S8IcLavt423abKgruyJSuUCBdl7/hteIizOJwxlMIaAMOUi6Q5RadlIh hFN5CljubaJnwZ9tATq4d7zpLbAqBUdi11BqlN8XND24FbRybpxBjCXdibwWW3MJah2c RrR8O+ornBpDEcoC047vRGpsZks4JAK7BiTIK+6hG42WOC+l8WvGVTU/p4tgyGQfbmwX HYsiDl4v8YfhWCnFEhdjTmH1Raw9V/yFj8LaFk0Y5s1EBvY7QubhwR7jiLz2TLqDK/oB QyLVWcdHzlbmydNL1fBa2b8T1WjIyChDvGdXDTrC5jkEG04ysh0AiuIyMGH4m10fbFLl MpRQ== MIME-Version: 1.0 X-Received: by 10.112.162.40 with SMTP id xx8mr2105937lbb.30.1369848380827; Wed, 29 May 2013 10:26:20 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.13.135 with HTTP; Wed, 29 May 2013 10:26:20 -0700 (PDT) In-Reply-To: <20902.4239.221857.859835@jerusalem.litteratus.org> References: <20902.4239.221857.859835@jerusalem.litteratus.org> Date: Wed, 29 May 2013 10:26:20 -0700 X-Google-Sender-Auth: JRnkFTVRAoDjJaWhs6uiLlA250c Message-ID: Subject: Re: "make buildworld" fails From: Craig Rodrigues To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:31:37 -0000 On Wed, May 29, 2013 at 7:28 AM, Robert Huff wrote: > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make > /usr/obj/usr/src/make.amd64/make > usage: make [-BeikNnqrstWX] > [-C directory] [-D variable] [-d flags] [-f makefile] > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T > file] > [-V variable] [variable=value] [target ...] > *** [buildworld] Error code 2 > > Stop in /usr/src. > See this post: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html and see if removing /usr/obj/usr/src/make.amd64/make helps. -- Craig From owner-freebsd-current@FreeBSD.ORG Wed May 29 20:18:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF8C140D for ; Wed, 29 May 2013 20:18:00 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3906BF for ; Wed, 29 May 2013 20:18:00 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=Krx0hwmN c=1 sm=0 tr=0 a=AYs0lCZhWNYcdqRGU1uqFQ==:117 a=xWl05iZal9sA:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=J-SXeeTLAAAA:8 a=2XxJDLx0xmcA:10 a=4svSRLp8KaIAQZoLMZwA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=stuartb@4gh.net; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=stuartb@4gh.net; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=stuartb.4gh@starpower.net; auth=pass (LOGIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 208.58.6.235 is neither permitted nor denied by domain of 4gh.net) Received: from [208.58.6.235] ([208.58.6.235:45035] helo=freeman.4gh.net) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTPA id 1E/1C-06490-77266A15; Wed, 29 May 2013 16:17:59 -0400 Received: by freeman.4gh.net (Postfix, from userid 1001) id 8E4C7130E03; Wed, 29 May 2013 16:17:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by freeman.4gh.net (Postfix) with ESMTP id 864F8130DA7; Wed, 29 May 2013 16:17:58 -0400 (EDT) Date: Wed, 29 May 2013 16:17:58 -0400 (EDT) From: Stuart Barkley To: freebsd-questions@freebsd.org Subject: Re: BSD sleep In-Reply-To: <20130528230140.A5B396F448@smtp.hushmail.com> Message-ID: References: <20130528230140.A5B396F448@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Wed, 29 May 2013 20:29:01 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:18:00 -0000 On Tue, 28 May 2013 at 19:01 -0000, Kenta Suzumoto wrote: > Hi. Is there no built-in way of making "sleep" sleep in increments > of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep > 1h" for an hour. The FreeBSD one's manpage leads me to believe we > can only use seconds, which is kind of annoying. Is there an > undocmented or missing feature here? Seems really trivial to > implement. > > ~ $ sleep 1h > usage: sleep seconds See also /usr/ports/misc/delay. Stuart From owner-freebsd-current@FreeBSD.ORG Thu May 30 00:55:57 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0ACC7FFC for ; Thu, 30 May 2013 00:55:57 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id E5B38777 for ; Thu, 30 May 2013 00:55:56 +0000 (UTC) Received: from [10.9.208.55] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 29 May 2013 17:47:56 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by IRVEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 29 May 2013 17:53:31 -0700 From: "David Christensen" To: "Herve Boulouis" , "freebsd-current@freebsd.org" Subject: RE: Support of Dell M620 broadcom BCM57810 Thread-Topic: Support of Dell M620 broadcom BCM57810 Thread-Index: AQHOXG8wryApyoZbf0uvl6Vj8f1Wo5kc5ibw Date: Thu, 30 May 2013 00:53:31 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A36DE66@IRVEXCHMB11.corp.ad.broadcom.com> References: <20130529131313.GA24559@ra.aabs> In-Reply-To: <20130529131313.GA24559@ra.aabs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7DB87E361R023304237-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Gary Zambrano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 00:55:57 -0000 > Is there some test code I could try ? The goal is to run -stable but I ca= n do > some testing on -head if necessary. I'll have some test code to share in about a week. Please email me directl= y if you're interested and if you're willing to help us work out some of the = bugs. We're not quite ready for a kernel submission yet. Dave From owner-freebsd-current@FreeBSD.ORG Thu May 30 05:07:30 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ADB1B60B; Thu, 30 May 2013 05:07:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 09EBAE90; Thu, 30 May 2013 05:07:29 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4U57NWt060973; Thu, 30 May 2013 08:07:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4U57NWt060973 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4U57Neh060972; Thu, 30 May 2013 08:07:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 May 2013 08:07:23 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: Supermicro 6027R-N3RF+head, usb trouble Message-ID: <20130530050723.GW3047@kib.kiev.ua> References: <20130421223838.6bec3bfb@laptop.minsk.domain> <51A4F585.60401@FreeBSD.org> <20130529083338.07a2f54b@laptop.minsk.domain> <51A5F1AC.3060606@FreeBSD.org> <51A5F873.2000103@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YqfxB+4kvvts0m/u" Content-Disposition: inline In-Reply-To: <51A5F873.2000103@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 05:07:30 -0000 --YqfxB+4kvvts0m/u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2013 at 07:45:39AM -0500, Bryan Drewery wrote: > On 5/29/2013 7:16 AM, Bryan Drewery wrote: > > On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: > >> On Tue, 28 May 2013 13:20:53 -0500 > >> Bryan Drewery wrote: > >> > >>> On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: > >>>> Hi, > >>>> > >>>> Can anybody explain why USB keyboard (and keyboard from > >>>> integrated IPKVM) doesn't work when I boot with 'C606 > >>>> chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? > >>>> Also I can't boot that box from usb memstick and > >>>> FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both > >>>> loose(?) device and can't find root If I disable controller in bios > >>>> system can't see any sata hdd connected to it:( > >>>> booting with hw.usb.ehci.no_hs=3D1, kern.cam.boot_delay=3D"10000" > >>>> and debug.acpi.disabled=3D"hostres" without success. I setup dhcpd, > >>>> tftp, nfs on my laptop and finally I install fbsd on that box, but > >>>> question with kbd is open - It doesn't work.. > >>>> dmesg: > >>>> http://svn.freebsd.by/files/dmesg_N3RF.txt > >>>> pciconf -lv: > >>>> http://svn.freebsd.by/files/pciconf_N3RF.txt > >>>> > >>>> I would appreciate any hints > >>>> > >>> > >>> I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE > >>> (disc1) seems ok though. > >>> > >>> Did you get this figured out? > >>> > >> > >> I added to loader.conf > >> kern.maxbcache=3D"128M" >=20 > ^ This setting is all that was needed. The VFS change was not needed. >=20 >=20 > >> vfs.maxbufspace=3D134217728 > >> also I create /boot.config with '-v' > >> I don't know what exactly help, but now usb kbd (ipkvm) works fine > >> for me. > >> p.s. It is smbios.system.product=3D"X9DRW" > >> > >=20 > > Yes! This fix of limiting the size worked for me. USB worked on boot, kb > > works remotely in the IP KVM and locally as well now. > >=20 > > For the record, this is a DELL C1100 with 72GB of ram. The symptoms > > match the previous posts though and the delay settings did not help. > >=20 > > This was working on 9.1-R, something must have changed on HEAD. > >=20 > > This is not a production system, I'm willing to try any patches or > > settings to help get this fixed by default. > >=20 Could you get the values of sysctl kern.nbuf, kern.bio_transient_maxcnt =66rom the boot without any tuning of the KVA usage ? --YqfxB+4kvvts0m/u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRpt6LAAoJEJDCuSvBvK1BS64P/1V2RGktl9nd9hepRy6kbD+k fOoFdhhiYBB3y1WuKPKZFS31J8FHSVJNbOFyUZPOSFMJnmOpZcCyiExCOGaRS1WG YNwdIYjCww0dbUcsAwSVmbO2CeTnBxe5wbebhd7LnRdam9tm6pdvk4pUPXHEsy+i J7ACEhvt4Hfl1HTtCB+dgQy44BZVYxb2scfihZkDKMg9uOtQwJjS6zWc0Orfknbb Ap6zGihmr/m3CIJN0VZojAJb3kOTdVOTvOdtk+p3ceqVcICxWAhmwgJzff+K2o+r bXTd6GQvBaO0vof76gsRqxIJgVNJCoZiM8uPbiyILl2EtCZUS0WlI9PVXN3PEINo TKc+qmVPTfSmn45MB1Q4u8kfq10bCJQPbdekcc3n9nbt+dwwlrVeoC9FfhmnNaXM yR/txzdMuiSjxCc34WUXtWTUlwU68t9esdA8Ipoq+h5A01B1zO3bBPNDj8W3GknJ fOVAr9eBofvocCZwTfYkmmBW1vCcxru0xLvZd+SHOdkqSHEwHaOmBJsIX6jimWVT Tyl/dph/c56G84MQN5hthqLc9qNLm30OSpmcz3PIp/lPvGG7XC21IceKwRZsO2Cq IlpKVyg0sHz6Md8jxto5B/r/pXFJb57sn8dzSW7YL7Rdc3aDxU5ojsF9st4ORvYy zaQhTLKVQphaTk9/PR5a =/ugs -----END PGP SIGNATURE----- --YqfxB+4kvvts0m/u-- From owner-freebsd-current@FreeBSD.ORG Thu May 30 09:38:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5B8E7A2 for ; Thu, 30 May 2013 09:38:07 +0000 (UTC) (envelope-from amon@aelita.org) Received: from aelita.org (unknown [IPv6:2001:7a8:7003::3]) by mx1.freebsd.org (Postfix) with ESMTP id 85783ECB for ; Thu, 30 May 2013 09:38:07 +0000 (UTC) Received: from ra.aabs (localhost [127.0.0.1]) by aelita.org (8.14.5/8.14.5) with ESMTP id r4U9Ve7G081129; Thu, 30 May 2013 11:31:40 +0200 (CEST) (envelope-from amon@ra.aabs) Received: (from amon@localhost) by ra.aabs (8.14.5/8.14.5/Submit) id r4U9VboA081127; Thu, 30 May 2013 11:31:37 +0200 (CEST) (envelope-from amon) Date: Thu, 30 May 2013 11:31:37 +0200 From: Herve Boulouis To: David Christensen Subject: Re: Support of Dell M620 broadcom BCM57810 Message-ID: <20130530093137.GB24559@ra.aabs> References: <20130529131313.GA24559@ra.aabs> <3A5015FE9E557D448AF7238AF0ACE20A36DE66@IRVEXCHMB11.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A36DE66@IRVEXCHMB11.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: Herve Boulouis , "freebsd-current@freebsd.org" , Gary Zambrano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 09:38:07 -0000 Le 30/05/2013 00:53, David Christensen a écrit: > > Is there some test code I could try ? The goal is to run -stable but I can do > > some testing on -head if necessary. > > I'll have some test code to share in about a week. Please email me directly > if you're interested and if you're willing to help us work out some of the bugs. > We're not quite ready for a kernel submission yet. I'll be glad to test but I'd like to know : - do you require testing on -head or -stable ? - in your opinion in which shape is the current code ? I mean how far are we from something more or less ready to put in production ? That would help me decide how long I can allocate this server for testing before sending it to production (on freebsd or other os). Regards, -- Herve Boulouis From owner-freebsd-current@FreeBSD.ORG Thu May 30 09:48:45 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81F459AA; Thu, 30 May 2013 09:48:45 +0000 (UTC) (envelope-from schweikh@schweikhardt.net) Received: from rs2.shuttle.de (rs2.shuttle.de [IPv6:2001:638:206:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 4544BF59; Thu, 30 May 2013 09:48:45 +0000 (UTC) Received: by rs2.shuttle.de (Postfix, from userid 10) id EACA65804B; Thu, 30 May 2013 11:48:43 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) by hal9000.schweikhardt.net (8.14.7/8.14.7) with ESMTP id r4U9mWQV000737; Thu, 30 May 2013 11:48:32 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.14.7/8.14.7/Submit) id r4U9mWTC000736; Thu, 30 May 2013 11:48:32 +0200 (CEST) (envelope-from schweikh) Date: Thu, 30 May 2013 11:48:32 +0200 From: Jens Schweikhardt To: Kenta Suzumoto Subject: Re: BSD sleep Message-ID: <20130530094832.GB3053@schweikhardt.net> References: <20130528230140.A5B396F448@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130528230140.A5B396F448@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 09:48:45 -0000 On Tue, May 28, 2013 at 07:01:40PM -0400, Kenta Suzumoto wrote: # Hi. Is there no built-in way of making "sleep" sleep in increments # of minutes, hours, etc? The GNU "sleep" can be invoked like "sleep # 1h" for an hour. The FreeBSD one's manpage leads me to believe we # can only use seconds, which is kind of annoying. Is there an # undocmented or missing feature here? Seems really trivial to # implement. # # ~ $ sleep 1h # usage: sleep seconds Perfection is reached when there is nothing left to take away. The GNU format is already an incompatibility. If I want to sleep longer than 3 digit amount in secs, I do the math. The POSIXly *portable* way to do this and document it for the mathematically challenged is sleep $((2*60*60)) # 2h sleep $((7*24*60*60)) # 1w Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Thu May 30 12:15:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB8DC354 for ; Thu, 30 May 2013 12:15:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id AB9E9A33 for ; Thu, 30 May 2013 12:15:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4UCFqkw051658 for ; Thu, 30 May 2013 12:15:52 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4UCFqXC051656 for freebsd-current@freebsd.org; Thu, 30 May 2013 12:15:52 GMT (envelope-from bdrewery) Received: (qmail 80605 invoked from network); 30 May 2013 07:15:51 -0500 Received: from unknown (HELO ?10.10.1.133?) (freebsd@shatow.net@10.10.1.133) by sweb.xzibition.com with ESMTPA; 30 May 2013 07:15:51 -0500 Message-ID: <51A742EB.6070907@FreeBSD.org> Date: Thu, 30 May 2013 07:15:39 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Supermicro 6027R-N3RF+head, usb trouble References: <20130421223838.6bec3bfb@laptop.minsk.domain> <51A4F585.60401@FreeBSD.org> <20130529083338.07a2f54b@laptop.minsk.domain> <51A5F1AC.3060606@FreeBSD.org> <51A5F873.2000103@FreeBSD.org> <20130530050723.GW3047@kib.kiev.ua> In-Reply-To: <20130530050723.GW3047@kib.kiev.ua> X-Enigmail-Version: 1.5.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DVTXSNEEIMNFCKDIXXEJ" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 12:15:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DVTXSNEEIMNFCKDIXXEJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/30/2013 12:07 AM, Konstantin Belousov wrote: > On Wed, May 29, 2013 at 07:45:39AM -0500, Bryan Drewery wrote: >> On 5/29/2013 7:16 AM, Bryan Drewery wrote: >>> On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: >>>> On Tue, 28 May 2013 13:20:53 -0500 >>>> Bryan Drewery wrote: >>>> >>>>> On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: >>>>>> Hi, >>>>>> >>>>>> Can anybody explain why USB keyboard (and keyboard from >>>>>> integrated IPKVM) doesn't work when I boot with 'C606 >>>>>> chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios= ? >>>>>> Also I can't boot that box from usb memstick and >>>>>> FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both >>>>>> loose(?) device and can't find root If I disable controller in bio= s >>>>>> system can't see any sata hdd connected to it:( >>>>>> booting with hw.usb.ehci.no_hs=3D1, kern.cam.boot_delay=3D"10000" >>>>>> and debug.acpi.disabled=3D"hostres" without success. I setup dhcpd= , >>>>>> tftp, nfs on my laptop and finally I install fbsd on that box, but= >>>>>> question with kbd is open - It doesn't work.. >>>>>> dmesg: >>>>>> http://svn.freebsd.by/files/dmesg_N3RF.txt >>>>>> pciconf -lv: >>>>>> http://svn.freebsd.by/files/pciconf_N3RF.txt >>>>>> >>>>>> I would appreciate any hints >>>>>> >>>>> >>>>> I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE >>>>> (disc1) seems ok though. >>>>> >>>>> Did you get this figured out? >>>>> >>>> >>>> I added to loader.conf >>>> kern.maxbcache=3D"128M" >> >> ^ This setting is all that was needed. The VFS change was not needed. >> >> >>>> vfs.maxbufspace=3D134217728 >>>> also I create /boot.config with '-v' >>>> I don't know what exactly help, but now usb kbd (ipkvm) works fine >>>> for me. >>>> p.s. It is smbios.system.product=3D"X9DRW" >>>> >>> >>> Yes! This fix of limiting the size worked for me. USB worked on boot,= kb >>> works remotely in the IP KVM and locally as well now. >>> >>> For the record, this is a DELL C1100 with 72GB of ram. The symptoms >>> match the previous posts though and the delay settings did not help. >>> >>> This was working on 9.1-R, something must have changed on HEAD. >>> >>> This is not a production system, I'm willing to try any patches or >>> settings to help get this fixed by default. >>> >=20 > Could you get the values of sysctl kern.nbuf, kern.bio_transient_maxcnt= > from the boot without any tuning of the KVA usage ? >=20 # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache kern.nbuf: 472300 kern.bio_transient_maxcnt: 1024 kern.maxbcache: 0 For reference, with limiting maxbcache: # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache kern.nbuf: 7372 kern.bio_transient_maxcnt: 102 kern.maxbcache: 134217728 --=20 Regards, Bryan Drewery ------enig2DVTXSNEEIMNFCKDIXXEJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRp0LrAAoJEG54KsA8mwz5C6EP+gJ7q0DDdsWqG1VtN8zvPowH 4HwFcgnu71hkXHZe7NsrrulGfkfAfArMom/zuM6DUhExhW3UvsfvFs5NQHpuNjiG leyZ6ipe8il6kuimL+/4OByUuBqG0HphUsOW/y9DTb4t7mDoikKU1i7P9WKRZ9EK Vz3IkK7OgWKk4qRj4+mox1tvFTqmjEXLIchIV+RZqNdNndzqFjwbZZWHteYtVue+ GD3SPBlEqEesjjmDJC2G45tVdn07JmdPUscq03MQOTK0EG5mPRzQWUc6LplrMvFf b2wTXFBqBHc41+8x+s4XC87mv6anM8JAoUfhR7BDY9Z1ck4ZjnqOusLRKHVvd4Cn fzZEEAPQYrBkKqB/k0zHYpNnU01uABC9lfGwIsHjuQaaot92oVTc75IwXAS3Jf8x mQitqml9T7VY8uk8SZ58H72pS/2pppxcbPNRdhj8MCEwgQRQB+T3qt2ZeyKRLyu5 zqupMmH8ZsXa6JDPxtQLiIxFmW6rFZMqk2j5NOEueVoMGOXDun3F8E1J2v7roXbJ qkg227IOadzbLcQfLTvg50CvFYKbV5N2jtpAf1DWVVvlrwHnh639WQY1AIE50YJM N19ZRfBYHpz3PAYSCJuMwGVTe6yBVV3KbtAxOJiJjsNeN1k4Vs5y0ULFr03RkVNb 6trZl0FJaMK+qtn6nCJJ =hDVl -----END PGP SIGNATURE----- ------enig2DVTXSNEEIMNFCKDIXXEJ-- From owner-freebsd-current@FreeBSD.ORG Thu May 30 15:21:02 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6040A347; Thu, 30 May 2013 15:21:02 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 35B15CFE; Thu, 30 May 2013 15:20:58 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id t60so367370wes.11 for ; Thu, 30 May 2013 08:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=QzdFLneOejklLTB/G9d08zoj6wX8gn7X1PbtyyU1Vg4=; b=RI5Cz6erLdFt4q3qjqMdFHj3GoFzkH/ANphiLNDr3b2byQglpAKgs88S7CUye31OQ4 j/no+9cW/LL5sMb7LS6qIbpu8VSzLAvk6srLfXGt4DOPjkdwqO52Pjgpqh7/JGq6K+3+ jBuuzJUzqvy7lnNv0GhYnno0zswFkwosDAm8FMcsoL+J3Dx54tJLdTJ2woK7MmOwX5ez nGpxOPcW+CKdDDPNnyEl1P0FXbY1dQrv8qvGd1ebw9+5QYqVe6qIvvnYY0FY+oUMKbsy CISTasRBd6Qpr7JpkmfjE89aZghTrv5dGRyCwSWGNu1tBRQFK92mBbzasobTsTcFmVC2 M6Dg== X-Received: by 10.180.211.197 with SMTP id ne5mr5067873wic.54.1369927257350; Thu, 30 May 2013 08:20:57 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id cw8sm38630691wib.7.2013.05.30.08.20.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 30 May 2013 08:20:56 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 30 May 2013 17:20:54 +0200 From: Baptiste Daroussin To: pkg@Freebsd.org Subject: [HEADSUP] New pkg-devel 1.1.0 beta1 Message-ID: <20130530152053.GA19621@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:21:02 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, The pkg developement team is proud to announce the new 1.1.0 beta1 release = of pkg. Here is the list of new features that happened in pkg 1.1: - new simpler and more reliable solver - shared libraries are now always tracked - ssh:// is supported as a protocol to distribute packages (needs pkg 1.1+ = on the server hosting the packages) - multirepository is no longer considered experimental and works by default. - incremental update of the catalog (only if the repository was created by = pkg 1.1+) - simplification of the public API - stabilisation of the public API (we will now try to keep it stable and if change are needed there will be deprecation time before removal of some o= ld functions) - new experimental pkg convert (can convert from and to legacy pkg database) pkg2ng now uses pkg convert (still recommanded to use pkg2ng) - new pkg lock/unlock to prevent any manipulation of a given package (no upgrade,delete,etc) - improved UI (now you can see the progress of an upgrade what is left to be done) - new pkg annotation to allow one to add annotations (free form key/value) = to a package) - pkg audit is now able to directly parse the vuxml native format and not o= nly the compact version - pkg -vv now shows all available options and their current settings - pkg -vvv now shows a description of all the available options - pkg info now automatically considers the query as globbing if * is in the requested pattern - new hook plugin interface (allows users to create hooks that get called at anytime during and upgrade/installation/deletion of a package) - new cmd plugin interface (allows users to create new sub command availabl= e for pkg) - pkg register can now register a port installation in the legacy database format - repository can be defined in simple yaml files Internal: - massive usage of hash tables (uthash), which simplifies a lot of the code, and improves performances - lots of optimisation in plist and manifest parsing - lots of optimisation in loading packages (mmap used when possible) - lots of cleanup in memory usage - regression test framework is now ready (using atf) regression test are sl= owly being added and populated. To use this new version: Ports users (or in building factories: poudriere/tinderbox): Add WITH_PKGNG=3Ddevel to your make.conf pkg set -o ports-mgmt/pkg:ports-mgmt/pkg-devel Binary package users, if the remote repository is providing pkg 1.1: pkg set -o ports-mgmt/pkg:ports-mgmt/pkg-devel pkg upgrade Note that pkg 1.1 can use a repository created for pkg 1.0 and vis versa. Huge thanks to all the people that have contributed to the pkg developement= :=20 - may that be by code - documentation - bug report - feedback - ideas List of people who contributed code: Baptiste Daroussin, Matthew Seaman, Bryan Drewery, Vsevolod Stakhov, Marin Atanasov Nikolov, Alexandre Perrin, Romain Tarti=C3=A8re, Julien Laff= aye, Glen Barber, John Marino, Alex Kozlov, Roman Naumann, Sofian Brabez, Alberto Villa, Will Andrews, Eitan Adler, Dan McGregor, namor, niamtokik, Arthur Gautier, Garrett Cooper, Andrew Turner, Jeremy Chadwick, Hajimu UMEMOTO, Mark Lokowich, Eygene Ryabinkin, Pietro Cerutti, Rolf Grossmann, Ed Schouten, Dimitry Andric, David Forsythe, Stefan Grundma= nn, Craig Rodrigues, Antoine Brodin, Andrey Zonov, Joel Dahl Stats between 1.0 and 1.1: 287 files changed, 63418 insertions(+), 18763 deletions(-) 1198 commits regards, Bapt --J/dobhs11T7y2rNN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlGnblUACgkQ8kTtMUmk6Ey2JQCfWLWmwg/ldAnKn1VVkVGVqFO4 eP8An1FLMPau7L/fchvl+CgxLl2avZUK =KD94 -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Thu May 30 15:21:12 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1683B447; Thu, 30 May 2013 15:21:12 +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 233A9D04; Thu, 30 May 2013 15:21:10 +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 SAA16485; Thu, 30 May 2013 18:21:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <51A76E5E.5050206@FreeBSD.org> Date: Thu, 30 May 2013 18:21:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-hackers Subject: hwpmc with opteron 6128 X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:21:12 -0000 I am trying to do a very basic thing with hwpmc on this CPU: CPU: AMD Opteron(tm) Processor 6128 (1999.05-MHz K8-class CPU) hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 K8/4/48/0x1ff What I am trying is: $ pmcstat -T -S instructions What I am getting is just: PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 0 (0.0%) , 0 unresolved and nothing else on the screen. Has anyone had a success with this class of processors? Should it be supported? Any ideas/suggestions/hints? P.S. pmccontrol -L reports a whole bunch of "K8" counters, just a small random sub-sample: BU_FILL_INTO_L2 IC_FETCH IC_MISS IC_REFILL_FROM_L2 IC_REFILL_FROM_SYSTEM IC_L1_ITLB_MISS_AND_L2_ITLB_HIT IC_L1_ITLB_MISS_AND_L2_ITLB_MISS IC_MICROARCHITECTURAL_RESYNC_BY_SNOOP IC_INSTRUCTION_FETCH_STALL IC_RETURN_STACK_HIT IC_RETURN_STACK_OVERFLOW FR_RETIRED_X86_INSTRUCTIONS FR_RETIRED_UOPS FR_RETIRED_BRANCHES FR_RETIRED_BRANCHES_MISPREDICTED FR_RETIRED_TAKEN_BRANCHES FR_RETIRED_TAKEN_BRANCHES_MISPREDICTED -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 30 13:39:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 542F29F7 for ; Thu, 30 May 2013 13:39:06 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id D8C2D1FA for ; Thu, 30 May 2013 13:39:05 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.7/8.14.7) with ESMTP id r4UDd2n2066980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 May 2013 15:39:02 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.7/8.14.7/Submit) with ESMTP id r4UDd2vD066977 for ; Thu, 30 May 2013 15:39:02 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Thu, 30 May 2013 15:39:02 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: Oversized kernel.txz in FreeBSD-10.0-CURRENT-i386-20130525-r250975-release.iso Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-1781871584-1369921142=:72982" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no X-Mailman-Approved-At: Thu, 30 May 2013 15:24:14 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 13:39:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-1781871584-1369921142=:72982 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Hi, I just tried to install FreeBSD/i386 from the FreeBSD-10.0-CURRENT-i386-20130525-r250975-release.iso snapshot. The installer fails while extracting kernel.txz. kernel.txz file is larger than usual. The file contains virtually everything from /usr/obj/usr/src and not just boot/kernel/* rooted at /usr/obj/usr/src/release/dist/base. Maybe someone would look at the scripts involved when creating kernel.txz. Such a change will certainly make the snapshots more useful. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestřl, | Trond Endrestřl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjřvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-1781871584-1369921142=:72982-- From owner-freebsd-current@FreeBSD.ORG Thu May 30 15:27:32 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE499D39 for ; Thu, 30 May 2013 15:27:32 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9E8E0A for ; Thu, 30 May 2013 15:27:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4UFRW3f089297 for ; Thu, 30 May 2013 15:27:32 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4UFRWgO089291 for current@FreeBSD.org; Thu, 30 May 2013 15:27:32 GMT (envelope-from bdrewery) Received: (qmail 11036 invoked from network); 30 May 2013 10:27:30 -0500 Received: from unknown (HELO ?173.160.118.90?) (freebsd@shatow.net@173.160.118.90) by sweb.xzibition.com with ESMTPA; 30 May 2013 10:27:30 -0500 Message-ID: <51A76FE7.1050900@FreeBSD.org> Date: Thu, 30 May 2013 10:27:35 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 Subject: Re: [HEADSUP] New pkg-devel 1.1.0 beta1 References: <20130530152053.GA19621@ithaqua.etoilebsd.net> In-Reply-To: <20130530152053.GA19621@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AXANWMMHAUFNJHBSDNOF" Cc: pkg@Freebsd.org, ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:27:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AXANWMMHAUFNJHBSDNOF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/30/2013 10:20 AM, Baptiste Daroussin wrote: > Ports users (or in building factories: poudriere/tinderbox): > Add WITH_PKGNG=3Ddevel to your make.conf > pkg set -o ports-mgmt/pkg:ports-mgmt/pkg-devel FYI this will not currently work with portupgrade. I plan to address it soon. --=20 Regards, Bryan Drewery ------enig2AXANWMMHAUFNJHBSDNOF 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.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRp2/nAAoJEG54KsA8mwz5jTIP/0KDzruOJpYqrGSuOVQF3U8n Bx7dFopj2lBjOyn/CAfpfMLwl0N49wzDb7R2FJrI3h1u03p6/mbYEeEpnXwKqKVL cEnBvIuoy3fJg5BBvZqF0tvosQTwq1b6sOS/bnPjdQEtxNyB9zEeBntCva49lGVH sEih9onOOPZU27fKuhWKihvRt4zDH6PpBUORaGgNT/f4iWaA33MPT+mySQcvHvrM BiQJ/rzy8mKKUa+4Hrwjg/zYLbLtMBzb2Ol363rEBXPbpSktIuEEje26MUbS/0+7 nfjjgGW5zq3RdYRaYLIsbphZtiHsboQT4jYaFFwwiCMab7+JwzvHRJvUF30AhI7F QRdtvGOylzHH6thpKRKTwIZzKQrp6V3zAN7s0rCQLosbnAjLWhqy30qxusYvf9Fv VmkreqQawmLgYIPIEsd2TBsdR61D6JE4R4gmF2inFqfvbrEQiPLTu7UiZxkQ+XFo zCZSsUCcXplZ6QWhI5PkDi5SLz/W2xfm0s2E188RJHMbz8RCuNDaDs9tIMK6A0Sh nrNguu7TBoAbPIZSi5VeYElWXWJkkzYJNLxqKIfyerP69kzNMOI/uEbDtNpnZLWN R/mwQ/DeRfYewm5VFZicd/mR4qhpNVDaNvgivHugb7PRRaSQzMWFVH1icvCy1IPK VJLpoCtmSjV03MZhoqQ3 =phJs -----END PGP SIGNATURE----- ------enig2AXANWMMHAUFNJHBSDNOF-- From owner-freebsd-current@FreeBSD.ORG Thu May 30 15:44:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E69AFAAD for ; Thu, 30 May 2013 15:44:04 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id B306497 for ; Thu, 30 May 2013 15:44:04 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=Krx0hwmN c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=6I5d2MoRAAAA:8 a=a_b59eHf_KBM8I9u1TMA:9 a=CjuIK1q_8ugA:10 a=EeD7E4ZpW3AA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:31882] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 7E/89-06490-DB377A15; Thu, 30 May 2013 11:43:57 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20903.29628.653443.909151@jerusalem.litteratus.org> Date: Thu, 30 May 2013 11:43:56 -0400 To: Craig Rodrigues Subject: Re: "make buildworld" fails In-Reply-To: References: <20902.4239.221857.859835@jerusalem.litteratus.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:44:05 -0000 Craig Rodrigues writes: > > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make > > /usr/obj/usr/src/make.amd64/make > > usage: make [-BeikNnqrstWX] > > [-C directory] [-D variable] [-d flags] [-f makefile] > > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T > > file] > > [-V variable] [variable=value] [target ...] > > *** [buildworld] Error code 2 > > > > Stop in /usr/src. > > > > > See this post: > http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html Seen it and all all following. > and see if removing /usr/obj/usr/src/make.amd64/make helps. It does not. Exact same error. Respectfully, Robert Huff From owner-freebsd-current@FreeBSD.ORG Thu May 30 17:19:22 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A62CE19; Thu, 30 May 2013 17:19:22 +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 766AF7D9; Thu, 30 May 2013 17:19:20 +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 UAA18529; Thu, 30 May 2013 20:19:19 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <51A78A16.4050705@FreeBSD.org> Date: Thu, 30 May 2013 20:19:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-hackers Subject: Re: hwpmc with opteron 6128 References: <51A76E5E.5050206@FreeBSD.org> In-Reply-To: <51A76E5E.5050206@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:19:22 -0000 on 30/05/2013 18:21 Andriy Gapon said the following: > > I am trying to do a very basic thing with hwpmc on this CPU: > > CPU: AMD Opteron(tm) Processor 6128 (1999.05-MHz K8-class CPU) > hwpmc: SOFT/16/64/0x67 TSC/1/64/0x20 > K8/4/48/0x1ff I didn't realize that the system was running in a VM. Sorry for the noise. > What I am trying is: > $ pmcstat -T -S instructions > > What I am getting is just: > PMC: [FR_RETIRED_X86_INSTRUCTIONS] Samples: 0 (0.0%) , 0 unresolved > > and nothing else on the screen. > > Has anyone had a success with this class of processors? > Should it be supported? > Any ideas/suggestions/hints? > > P.S. pmccontrol -L reports a whole bunch of "K8" counters, just a small random > sub-sample: > BU_FILL_INTO_L2 > IC_FETCH > IC_MISS > IC_REFILL_FROM_L2 > IC_REFILL_FROM_SYSTEM > IC_L1_ITLB_MISS_AND_L2_ITLB_HIT > IC_L1_ITLB_MISS_AND_L2_ITLB_MISS > IC_MICROARCHITECTURAL_RESYNC_BY_SNOOP > IC_INSTRUCTION_FETCH_STALL > IC_RETURN_STACK_HIT > IC_RETURN_STACK_OVERFLOW > FR_RETIRED_X86_INSTRUCTIONS > FR_RETIRED_UOPS > FR_RETIRED_BRANCHES > FR_RETIRED_BRANCHES_MISPREDICTED > FR_RETIRED_TAKEN_BRANCHES > FR_RETIRED_TAKEN_BRANCHES_MISPREDICTED > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 30 20:48:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44A85B2C for ; Thu, 30 May 2013 20:48:07 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by mx1.freebsd.org (Postfix) with ESMTP id C3873776 for ; Thu, 30 May 2013 20:48:06 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id r11so1022419lbv.38 for ; Thu, 30 May 2013 13:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tIgh4WekbPfBa/qOfnQAdoIPyoyg/0AnOuv3G1ydBi8=; b=y2lCKBXhI9+RC9UUefotGIPtW4JKS28046AszXkhJ80wR9pUs4PG05LHO8H38pew1+ EJazDiiWMA6/5PCHfap4lPlxzu276Q3AREAnWC0Q6ERV8KJfUjISsggZc9KnKyqLLuHA TnedRisB2wF2JKNHve3910gPUiiFnRvuNWjLyOj6MVTPwes80FoiynDlxVWNvlfbI8jb 8VZ1/i9BPhhB561jkNHWZuXAl15oQrPWvjD57CTU6dDBZQ9g+Q1XtDsyfVkLA3Z0nMgD CoVUmWo5q5I0s2XFYOiaj88ln2CZ/F6yVcmVeU1Fkga1ifL+214U6wIa0Fkq0WDdHhTS BzGQ== MIME-Version: 1.0 X-Received: by 10.112.181.130 with SMTP id dw2mr3854153lbc.81.1369946885613; Thu, 30 May 2013 13:48:05 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.13.135 with HTTP; Thu, 30 May 2013 13:48:05 -0700 (PDT) In-Reply-To: <20903.29628.653443.909151@jerusalem.litteratus.org> References: <20902.4239.221857.859835@jerusalem.litteratus.org> <20903.29628.653443.909151@jerusalem.litteratus.org> Date: Thu, 30 May 2013 13:48:05 -0700 X-Google-Sender-Auth: u6zHg2Ezy4Xaxj5t9AJgbgEb9u8 Message-ID: Subject: Re: "make buildworld" fails From: Craig Rodrigues To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:48:07 -0000 On Thu, May 30, 2013 at 8:43 AM, Robert Huff wrote: > > Craig Rodrigues writes: > > > > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make > > > /usr/obj/usr/src/make.amd64/make > > > usage: make [-BeikNnqrstWX] > > > [-C directory] [-D variable] [-d flags] [-f makefile] > > > [-I directory] [-J private] [-j max_jobs] [-m directory] > [-T > > > file] > > > [-V variable] [variable=value] [target ...] > > > *** [buildworld] Error code 2 > > > > > > Stop in /usr/src. > > > > > > > > > See this post: > > http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html > > Seen it and all all following. > > > > and see if removing /usr/obj/usr/src/make.amd64/make helps. > > It does not. > Exact same error. > If you do: make -d l buildworld Does that give more debugging output of the exact command which is failing during the build? -- Craig From owner-freebsd-current@FreeBSD.ORG Thu May 30 23:50:50 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC8AE36B for ; Thu, 30 May 2013 23:50:50 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id CEB5561B for ; Thu, 30 May 2013 23:50:50 +0000 (UTC) Received: from [10.9.208.27] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 30 May 2013 16:39:45 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by irvexchmb05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Thu, 30 May 2013 16:48:33 -0700 From: "David Christensen" To: "Herve Boulouis" Subject: RE: Support of Dell M620 broadcom BCM57810 Thread-Topic: Support of Dell M620 broadcom BCM57810 Thread-Index: AQHOXG8wryApyoZbf0uvl6Vj8f1Wo5kc5ibwgAEHS4CAAHha0A== Date: Thu, 30 May 2013 23:48:32 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A36E8C3@IRVEXCHMB11.corp.ad.broadcom.com> References: <20130529131313.GA24559@ra.aabs> <3A5015FE9E557D448AF7238AF0ACE20A36DE66@IRVEXCHMB11.corp.ad.broadcom.com> <20130530093137.GB24559@ra.aabs> In-Reply-To: <20130530093137.GB24559@ra.aabs> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7DB93CCB2L825162045-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" , Gary Zambrano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 23:50:51 -0000 > I'll be glad to test but I'd like to know : >=20 > - do you require testing on -head or -stable ? Tested with 9.1 and 10.0-Current. Open to patches on earlier kernels for the brave. > - in your opinion in which shape is the current code ? I mean how far are= we > from something more or less ready to put > in production ?=20 It's not extensively tested across all NICs yet (BCM57711E in an HP blade system, BCM57810 w/ 10GBase-T PHY, etc. ) so some hardware specific combinations may not work, but otherwise it's in good shape. Really just needs some wider test before committing to the kernel. Dave From owner-freebsd-current@FreeBSD.ORG Thu May 30 23:57:42 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C09E9599 for ; Thu, 30 May 2013 23:57:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id 86A946A4 for ; Thu, 30 May 2013 23:57:42 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id cr7so161164qab.4 for ; Thu, 30 May 2013 16:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pJy31PeH475YjwLmM0OD7dxxPdwO7byFk7NIJllsHMA=; b=byMAz4ga3ExJyzF4Bjs0mr/NqD+M0GtxdY1uxthmP6ExrFfhfu0Nu8f9bOpTZ9v0k8 xu1sDXl2GHm5hYlyatSAmpQ55+ODlAZCnXQnaCiLBLnL9HhzexX/zjnkmecySbHgaktR aNI62QNvFtGzSVLhcU452NTM2DbB2t/9drkDoF0Ifo/8w9PGTYrNYydeI/PT60RCgfKR A6BDSZdbLkgXGNpprbp8UL9S8ELjsZJVD9oOkFd7561QmK7VrloiPXJ6SDsA8cuS6HDS pljJYcdnm+LHryBrGGHT1fTtUCMwLNXgwe6JAtm61jVYArpPfR9+NYir5zO14xoUkXLI bdKw== MIME-Version: 1.0 X-Received: by 10.49.98.198 with SMTP id ek6mr8958275qeb.23.1369958261444; Thu, 30 May 2013 16:57:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.5.65 with HTTP; Thu, 30 May 2013 16:57:41 -0700 (PDT) In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A36E8C3@IRVEXCHMB11.corp.ad.broadcom.com> References: <20130529131313.GA24559@ra.aabs> <3A5015FE9E557D448AF7238AF0ACE20A36DE66@IRVEXCHMB11.corp.ad.broadcom.com> <20130530093137.GB24559@ra.aabs> <3A5015FE9E557D448AF7238AF0ACE20A36E8C3@IRVEXCHMB11.corp.ad.broadcom.com> Date: Thu, 30 May 2013 16:57:41 -0700 X-Google-Sender-Auth: x3f_Gk29QByOPcdTLMQJW5NXuwo Message-ID: Subject: Re: Support of Dell M620 broadcom BCM57810 From: Adrian Chadd To: David Christensen Content-Type: text/plain; charset=ISO-8859-1 Cc: Herve Boulouis , "freebsd-current@freebsd.org" , Gary Zambrano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 23:57:42 -0000 Would you guys mind dumping it into a github repo or something, so the community can test it out? Adrian On 30 May 2013 16:48, David Christensen wrote: >> I'll be glad to test but I'd like to know : >> >> - do you require testing on -head or -stable ? > > Tested with 9.1 and 10.0-Current. Open to patches on earlier kernels for > the brave. > >> - in your opinion in which shape is the current code ? I mean how far are we >> from something more or less ready to put >> in production ? > > It's not extensively tested across all NICs yet (BCM57711E in an HP blade > system, BCM57810 w/ 10GBase-T PHY, etc. ) so some hardware specific > combinations may not work, but otherwise it's in good shape. > Really just needs some wider test before committing to the kernel. > > > Dave > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri May 31 00:22:56 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0928CA51 for ; Fri, 31 May 2013 00:22:56 +0000 (UTC) (envelope-from amon@aelita.org) Received: from aelita.org (unknown [IPv6:2001:7a8:7003::3]) by mx1.freebsd.org (Postfix) with ESMTP id ADDC07E8 for ; Fri, 31 May 2013 00:22:55 +0000 (UTC) Received: from ra.aabs (localhost [127.0.0.1]) by aelita.org (8.14.5/8.14.5) with ESMTP id r4V0GRor085619; Fri, 31 May 2013 02:16:27 +0200 (CEST) (envelope-from amon@ra.aabs) Received: (from amon@localhost) by ra.aabs (8.14.5/8.14.5/Submit) id r4V0GQAf085618; Fri, 31 May 2013 02:16:26 +0200 (CEST) (envelope-from amon) Date: Fri, 31 May 2013 02:16:26 +0200 From: Herve Boulouis To: David Christensen Subject: Re: Support of Dell M620 broadcom BCM57810 Message-ID: <20130531001626.GC24559@ra.aabs> References: <20130529131313.GA24559@ra.aabs> <3A5015FE9E557D448AF7238AF0ACE20A36DE66@IRVEXCHMB11.corp.ad.broadcom.com> <20130530093137.GB24559@ra.aabs> <3A5015FE9E557D448AF7238AF0ACE20A36E8C3@IRVEXCHMB11.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A36E8C3@IRVEXCHMB11.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: Herve Boulouis , "freebsd-current@freebsd.org" , Gary Zambrano X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 00:22:56 -0000 Le 30/05/2013 23:48, David Christensen a écrit: > > I'll be glad to test but I'd like to know : > > > > - do you require testing on -head or -stable ? > > Tested with 9.1 and 10.0-Current. Open to patches on earlier kernels for > the brave. > > > - in your opinion in which shape is the current code ? I mean how far are we > > from something more or less ready to put > > in production ? > > It's not extensively tested across all NICs yet (BCM57711E in an HP blade > system, BCM57810 w/ 10GBase-T PHY, etc. ) so some hardware specific > combinations may not work, but otherwise it's in good shape. > Really just needs some wider test before committing to the kernel. I guess we are just waiting for the source to give it a run then :) Regards, -- Herve Boulouis From owner-freebsd-current@FreeBSD.ORG Fri May 31 10:13:30 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8BA56268 for ; Fri, 31 May 2013 10:13:30 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9ED240 for ; Fri, 31 May 2013 10:13:29 +0000 (UTC) Received: (qmail 11359 invoked from network); 31 May 2013 11:11:32 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 May 2013 11:11:32 -0000 Message-ID: <51A877C6.9000700@freebsd.org> Date: Fri, 31 May 2013 12:13:26 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: current@freebsd.org Subject: make -jN parallel builds is broken Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:13:30 -0000 Any ideas how to fix this? # make -j8 buildworld --- buildworld --- make: illegal option -- J usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] [-d flags] [-E variable] [-f makefile] [-I directory] [-j max_jobs] [-m directory] [-V variable] [variable=value] [target ...] *** [buildworld] Error code 2 make: stopped in /u/svn/commit/head4 1 error -- Andre From owner-freebsd-current@FreeBSD.ORG Fri May 31 10:16:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91C443B7 for ; Fri, 31 May 2013 10:16:22 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB3D27F for ; Fri, 31 May 2013 10:16:22 +0000 (UTC) Received: from [172.29.180.39] (unknown [194.214.114.46]) by peterschmitt.fr (Postfix) with ESMTPSA id 92AF59C36 for ; Fri, 31 May 2013 12:16:28 +0200 (CEST) Message-ID: <51A878C0.7030600@peterschmitt.fr> Date: Fri, 31 May 2013 12:17:36 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: make -jN parallel builds is broken References: <51A877C6.9000700@freebsd.org> In-Reply-To: <51A877C6.9000700@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2LLGGXPHSOUUIUSEUQIIT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: florent+FreeBSD-current@peterschmitt.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:16:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2LLGGXPHSOUUIUSEUQIIT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 31/05/2013 12:13, Andre Oppermann a =E9crit : > Any ideas how to fix this? >=20 > # make -j8 buildworld > --- buildworld --- > make: illegal option -- J > usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] > [-d flags] [-E variable] [-f makefile] [-I directory] > [-j max_jobs] [-m directory] [-V variable] > [variable=3Dvalue] [target ...] > *** [buildworld] Error code 2 >=20 > make: stopped in /u/svn/commit/head4 > 1 error >=20 See here: http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail +33 (0)6 64 33 97 92 | * PDF for documents http://florent.peterschmitt.fr | Thank you :) ------enig2LLGGXPHSOUUIUSEUQIIT 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.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJRqHjAAAoJEMtO2Sol0IImEOsIAJgSEHXX+/4HQ0LP5/zgMBfT r1zVtYq2w6IaFjB1rq2lNpPvN8QVPoz0vkvtMKpJQFVkqxVGiAXtlVBKsu6sbbx0 A4bwRzBK69FFrQGs//OsFKVJ1PPimTcLagW2ysJAalJrblrODRLexi5UIdigXbsQ tXSrnJQdq/rRRJwl/Z0LvJSvde1Q5PwIqxCW6Hd/Z9bTbJ/nPG9mREXjTzMWmxkr tVRZ0I4ToLSjsQbd7lf+igQPOOu9+Z1bpo5kyZHMdc8XYi/kAxB9zBV7kyaKtd1q ERtUVFWdD6KpRh6fo33LbL17HoY2HWbGB2RUXjZM++KN39gyUQDTpv04pUA+4TI= =7yGR -----END PGP SIGNATURE----- ------enig2LLGGXPHSOUUIUSEUQIIT-- From owner-freebsd-current@FreeBSD.ORG Fri May 31 10:25:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 280D966D for ; Fri, 31 May 2013 10:25:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 900592FF for ; Fri, 31 May 2013 10:25:05 +0000 (UTC) Received: (qmail 11421 invoked from network); 31 May 2013 11:23:08 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 May 2013 11:23:08 -0000 Message-ID: <51A87A7E.3070201@freebsd.org> Date: Fri, 31 May 2013 12:25:02 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: florent+FreeBSD-current@peterschmitt.fr Subject: Re: make -jN parallel builds is broken References: <51A877C6.9000700@freebsd.org> <51A878C0.7030600@peterschmitt.fr> In-Reply-To: <51A878C0.7030600@peterschmitt.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, Florent Peterschmitt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 10:25:06 -0000 On 31.05.2013 12:17, Florent Peterschmitt wrote: > Le 31/05/2013 12:13, Andre Oppermann a écrit : >> Any ideas how to fix this? >> >> # make -j8 buildworld >> --- buildworld --- >> make: illegal option -- J >> usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] >> [-d flags] [-E variable] [-f makefile] [-I directory] >> [-j max_jobs] [-m directory] [-V variable] >> [variable=value] [target ...] >> *** [buildworld] Error code 2 >> >> make: stopped in /u/svn/commit/head4 >> 1 error >> > > See here: > > http://lists.freebsd.org/pipermail/freebsd-current/2013-May/041976.html Blowing away /usr/obj fixed the issue. Apparently "make clean" isn't sufficient. Thanks -- Andre From owner-freebsd-current@FreeBSD.ORG Fri May 31 20:05:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BC6EA46C for ; Fri, 31 May 2013 20:05:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 80C4DA07 for ; Fri, 31 May 2013 20:05:24 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1UiVaj-0000q3-0y for freebsd-current@freebsd.org; Sat, 01 Jun 2013 00:06:25 +0400 Date: Sat, 1 Jun 2013 00:06:25 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Subject: GEOM (GPART) filtered device tree Message-ID: <20130531200624.GA698@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:05:24 -0000 I am try to build SAN with iSCSI access based on FreeBSD+ZFS. LUN emulated by ZFS volume. Because partitioned not contrlled and can be dangerous (even threat host OS) I needed to filtered some /dev subtree from GPART (temporary or permanently). How do i do this? From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 07:54:25 2013 Return-Path: Delivered-To: FreeBSD-CURRENT@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0631882 for ; Sat, 1 Jun 2013 07:54:25 +0000 (UTC) (envelope-from daemon@dx.burplex.com) Received: from dx.burplex.com (dx.burplex.com [50.197.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id B275D37A for ; Sat, 1 Jun 2013 07:54:22 +0000 (UTC) Received: by dx.burplex.com (Postfix, from userid 1) id 4F5D036F49FF; Sat, 1 Jun 2013 00:54:14 -0700 (PDT) To: FreeBSD-CURRENT@FreeBSD.org Subject: issue with libthr? From: Waitman Gobble X-UUID-HOR: C08ECC09-F696-9CCC-AEF2-A5E2374AEDC4 Message-Id: <20130601075414.4F5D036F49FF@dx.burplex.com> Date: Sat, 1 Jun 2013 00:54:14 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 07:54:25 -0000 Hi, I'm getting a ton of core dumps from Python and any software that uses Python, ie has USE_PYTHON_BUILD=yes in Makefile. hundreds of msgs in dmesg: pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped) from gdb it seems to me to be libthr related? I've noticed a couple updates in May.. wonder if it's related? I've only noticed this issue in the past week, after a complete rebuild and updated. > uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r251111: Wed May 29 16:44:31 PDT 2013 root@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 gdb: seamonkey (gdb) bt #0 0x00000008011ee8ca in thr_kill () from /lib/libc.so.7 #1 0x000000080316b585 in XRE_InstallX11ErrorHandler () from /usr/local/lib/seamonkey/libxul.so #2 0x0000000800f73286 in swapcontext () from /lib/libthr.so.3 #3 0x0000000800f72e89 in sigaction () from /lib/libthr.so.3 #4 0x00007ffffffff1d3 in ?? () #5 0x0000000800f72d70 in sigaction () from /lib/libthr.so.3 Previous frame inner to this frame (corrupt stack?) python (gdb) bt #0 0x000000080100d8ca in thr_kill () from /lib/libc.so.7 #1 0x00000008010d2e9c in abort () from /lib/libc.so.7 #2 0x0000000803e4f05b in free () from /usr/local/lib/python2.7/lib-dynload/_ctypes.so #3 0x0000000800d9319f in pthread_mutex_destroy () from /lib/libthr.so.3 #4 0x00000008010269ff in closedir () from /lib/libc.so.7 #5 0x00000000004b545c in initposix () #6 0x000000000047fb75 in PyEval_EvalFrameEx () #7 0x000000000047d824 in PyEval_EvalCodeEx () #8 0x0000000000484256 in _PyEval_SliceIndex () #9 0x00000000004810cd in PyEval_EvalFrameEx () #10 0x000000000047d824 in PyEval_EvalCodeEx () #11 0x00000000004d5f56 in PyFunction_SetClosure () #12 0x000000000041ffeb in PyObject_Call () #13 0x0000000000482085 in PyEval_EvalFrameEx () #14 0x000000000047d824 in PyEval_EvalCodeEx () #15 0x0000000000484256 in _PyEval_SliceIndex () #16 0x00000000004810cd in PyEval_EvalFrameEx () #17 0x000000000047d824 in PyEval_EvalCodeEx () #18 0x0000000000484256 in _PyEval_SliceIndex () #19 0x00000000004810cd in PyEval_EvalFrameEx () #20 0x000000000047d824 in PyEval_EvalCodeEx () #21 0x0000000000484256 in _PyEval_SliceIndex () #22 0x00000000004810cd in PyEval_EvalFrameEx () #23 0x00000000004841f2 in _PyEval_SliceIndex () #24 0x00000000004810cd in PyEval_EvalFrameEx () #25 0x00000000004841f2 in _PyEval_SliceIndex () #26 0x00000000004810cd in PyEval_EvalFrameEx () #27 0x00000000004841f2 in _PyEval_SliceIndex () #28 0x00000000004810cd in PyEval_EvalFrameEx () #29 0x00000000004841f2 in _PyEval_SliceIndex () #30 0x00000000004810cd in PyEval_EvalFrameEx () #31 0x00000000004841f2 in _PyEval_SliceIndex () #32 0x00000000004810cd in PyEval_EvalFrameEx () #33 0x000000000047d824 in PyEval_EvalCodeEx () #34 0x000000000047d156 in PyEval_EvalCode () #35 0x00000000004a1361 in PyRun_FileExFlags () #36 0x00000000004a0eb1 in PyRun_SimpleFileExFlags () #37 0x0000000000417549 in Py_Main () #38 0x000000000041692f in main () Any help/pointers much appreciated. Thank you, -- Waitman Gobble San Jose California USA +1.5108307875 From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 15:06:37 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 696B0D3F for ; Sat, 1 Jun 2013 15:06:37 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id E05AF2CF for ; Sat, 1 Jun 2013 15:06:36 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=MpRrtQqe c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=6I5d2MoRAAAA:8 a=H_MSnKm0d8jQuds88p8A:9 a=CjuIK1q_8ugA:10 a=EeD7E4ZpW3AA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:29279] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 86/38-10053-AFD0AA15; Sat, 01 Jun 2013 11:06:35 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 Message-ID: <20906.3577.581640.887366@jerusalem.litteratus.org> Date: Sat, 1 Jun 2013 11:06:33 -0400 To: Craig Rodrigues Subject: Re: "make buildworld" fails In-Reply-To: References: <20902.4239.221857.859835@jerusalem.litteratus.org> <20903.29628.653443.909151@jerusalem.litteratus.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: Robert Huff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 15:06:37 -0000 DQpDcmFpZyBSb2RyaWd1ZXMgd3JpdGVzOg0KDQo+ICA+ID4gID4gc2ggL3Vzci9zcmMvdG9v bHMvaW5zdGFsbC5zaCAgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBtYWtlDQo+ICA+ID4g ID4gL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L21ha2UNCj4gID4gPiAgPiB1c2FnZTog bWFrZSBbLUJlaWtObnFyc3RXWF0NCj4gID4gPiAgPiAgICAgICAgICAgICBbLUMgZGlyZWN0 b3J5XSBbLUQgdmFyaWFibGVdIFstZCBmbGFnc10gWy1mIG1ha2VmaWxlXQ0KPiAgPiA+ICA+ ICAgICAgICAgICAgIFstSSBkaXJlY3RvcnldIFstSiBwcml2YXRlXSBbLWogbWF4X2pvYnNd IFstbSBkaXJlY3RvcnldDQo+ICA+IFstVA0KPiAgPiA+ICA+IGZpbGVdDQo+ICA+ID4gID4g ICAgICAgICAgICAgWy1WIHZhcmlhYmxlXSBbdmFyaWFibGU9dmFsdWVdIFt0YXJnZXQgLi4u XQ0KPiAgPiA+ICA+ICoqKiBbYnVpbGR3b3JsZF0gRXJyb3IgY29kZSAyDQo+ICA+ID4gID4N Cj4gID4gPiAgPiBTdG9wIGluIC91c3Ivc3JjLg0KPiAgPiA+DQo+ICA+ID4gIFNlZSB0aGlz IHBvc3Q6DQo+ICA+ID4gIGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwvZnJl ZWJzZC1jdXJyZW50LzIwMTMtTWF5LzA0MTk3Ni5odG1sDQo+ICA+DQo+ICA+ICAgICAgICAg U2VlbiBpdCBhbmQgYWxsIGFsbCBmb2xsb3dpbmcuDQo+ICA+DQo+ICA+ID4gIGFuZCBzZWUg aWYgcmVtb3ZpbmcgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L21ha2UgaGVscHMuDQo+ ICA+DQo+ICA+ICAgICAgICAgSXQgZG9lcyBub3QuDQo+ICANCj4gIElmIHlvdSBkbzoNCj4g IA0KPiAgbWFrZSAtZCBsIGJ1aWxkd29ybGQNCj4gIA0KPiAgRG9lcyB0aGF0IGdpdmUgbW9y ZSBkZWJ1Z2dpbmcgb3V0cHV0IG9mIHRoZSBleGFjdCBjb21tYW5kIHdoaWNoDQo+ICBpcyBm YWlsaW5nIGR1cmluZyB0aGUgYnVpbGQ/DQoNCglPdXRwdXQgaXMgYXBwZW5kZWQuDQoNCg0K CQkJCVJvYmVydCBIdWZmDQoNCgwNCihjZCAvdXNyL3NyYyAmJiBtYWtlIGJtYWtlKQ0KZWNo bw0KDQplY2hvICItLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQplY2hvICI+Pj4gQnVpbGRpbmcgYW4g dXAtdG8tZGF0ZSBtYWtlKDEpIg0KPj4+IEJ1aWxkaW5nIGFuIHVwLXRvLWRhdGUgbWFrZSgx KQ0KZWNobyAiLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0iDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KY2QgL3Vzci9zcmMvdXNyLmJpbi9ibWFr ZTsgIE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNU RElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURf VVBHUkFESU5HICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1E Tk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJPUiBvYmogJiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vz ci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0ic2ggL3Vzci9z cmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5PTUFOIC1ETk9f TUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJP UiBkZXBlbmQgJiYgIE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFt ZDY0ICBERVNURElSPSAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIg bWFrZSAgLURfVVBHUkFESU5HICAtRE5PTUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19T SEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAtRE5PX1dFUlJPUiBhbGwgJiYgIE1BS0VPQkpESVJQ UkVGSVg9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0ICBERVNURElSPSAgSU5TVEFMTD0i c2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIgbWFrZSAgLURfVVBHUkFESU5HICAtRE5P TUFOIC1ETk9fTUFOIC1ETk9TSEFSRUQgLUROT19TSEFSRUQgIC1ETk9fQ1BVX0NGTEFHUyAt RE5PX1dFUlJPUiBpbnN0YWxsIERFU1RESVI9L3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0 IEJJTkRJUj0NCmlmICEgdGVzdCAtZCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNy L3NyYy91c3IuYmluL2JtYWtlLzsgdGhlbiAgbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy9t YWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZTsgIGlmICEgdGVzdCAtZCAvdXNyL29i ai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlLzsgdGhlbiAgZWNo byAiVW5hYmxlIHRvIGNyZWF0ZSAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3Ny Yy91c3IuYmluL2JtYWtlLiI7ICBleGl0IDE7ICBmaTsgIGVjaG8gIi91c3Ivb2JqL3Vzci9z cmMvbWFrZS5hbWQ2NC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi9ibWFrZSI7ICBmaQ0KL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L3Vz ci9zcmMvdXNyLmJpbi9ibWFrZSBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL2JtYWtl DQpzZXQgLWU7IGZvciBlbnRyeSBpbiB1bml0LXRlc3RzOyBkbyAgaWYgdGVzdCAtZCAvdXNy L3NyYy91c3IuYmluL2JtYWtlLyR7ZW50cnl9LmFtZDY0OyB0aGVuICBlY2hvICI9PT0+ICR7 ZW50cnl9LmFtZDY0IChvYmopIjsgIGVkaXI9JHtlbnRyeX0uYW1kNjQ7ICBjZCAvdXNyL3Ny Yy91c3IuYmluL2JtYWtlLyR7ZWRpcn07ICBlbHNlICBlY2hvICI9PT0+ICRlbnRyeSAob2Jq KSI7ICBlZGlyPSR7ZW50cnl9OyAgY2QgL3Vzci9zcmMvdXNyLmJpbi9ibWFrZS8ke2VkaXJ9 OyAgZmk7ICBtYWtlIG9iaiAgRElSUFJGWD0kZWRpci87ICBkb25lDQo9PT0+IHVuaXQtdGVz dHMgKG9iaikNCmlmICEgdGVzdCAtZCAvdXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNy L3NyYy91c3IuYmluL2JtYWtlL3VuaXQtdGVzdHMvOyB0aGVuICBta2RpciAtcCAvdXNyL29i ai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlL3VuaXQtdGVzdHM7 ICBpZiAhIHRlc3QgLWQgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L3Vzci9zcmMvdXNy LmJpbi9ibWFrZS91bml0LXRlc3RzLzsgdGhlbiAgZWNobyAiVW5hYmxlIHRvIGNyZWF0ZSAv dXNyL29iai91c3Ivc3JjL21ha2UuYW1kNjQvdXNyL3NyYy91c3IuYmluL2JtYWtlL3VuaXQt dGVzdHMuIjsgIGV4aXQgMTsgIGZpOyAgZWNobyAiL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFt ZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzIGNyZWF0ZWQgZm9yIC91c3Iv c3JjL3Vzci5iaW4vYm1ha2UvdW5pdC10ZXN0cyI7ICBmaQ0KL3Vzci9vYmovdXNyL3NyYy9t YWtlLmFtZDY0L3Vzci9zcmMvdXNyLmJpbi9ibWFrZS91bml0LXRlc3RzIGNyZWF0ZWQgZm9y IC91c3Ivc3JjL3Vzci5iaW4vYm1ha2UvdW5pdC10ZXN0cw0Kcm0gLWYgLmRlcGVuZA0KbWtk ZXAgLWYgLmRlcGVuZCAtYSAgICAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5i aW4vYm1ha2UgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhB VkVfQ09ORklHX0ggLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAt RF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAt SS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgLURNQUtFX05BVElWRSAtc3RkPWdudTk5ICAgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9hcmNoLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9idWYu YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2NvbXBhdC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1h a2UvY29uZC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvZGlyLmMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9mb3IuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2hhc2guYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL2pvYi5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbWFpbi5jIC91c3Iv c3JjL2NvbnRyaWIvYm1ha2UvbWFrZS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbWFrZV9t YWxsb2MuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL21ldGEuYyAvdXNyL3NyYy9jb250cmli L2JtYWtlL3BhcnNlLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9zdHIuYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL3N0cmxpc3QuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N1ZmYuYyAv dXNyL3NyYy9jb250cmliL2JtYWtlL3RhcmcuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3Ry YWNlLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS91dGlsLmMgL3Vzci9zcmMvY29udHJpYi9i bWFrZS92YXIuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0QXBwZW5kLmMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RW5kLmMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RnJvbnQuYyAvdXNyL3NyYy9jb250cmliL2JtYWtl L2xzdC5saWIvbHN0Q2xvc2UuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0 Q29uY2F0LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERhdHVtLmMgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERlUXVldWUuYyAvdXNyL3NyYy9jb250 cmliL2JtYWtlL2xzdC5saWIvbHN0RGVzdHJveS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2Uv bHN0LmxpYi9sc3REdXBsLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEVu UXVldWUuYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RmluZC5jIC91c3Iv c3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RGaW5kRnJvbS5jIC91c3Ivc3JjL2NvbnRy aWIvYm1ha2UvbHN0LmxpYi9sc3RGaXJzdC5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0 LmxpYi9sc3RGb3JFYWNoLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEZv ckVhY2hGcm9tLmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEluaXQuYyAv dXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0SW5zZXJ0LmMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS9sc3QubGliL2xzdElzQXRFbmQuYyAvdXNyL3NyYy9jb250cmliL2JtYWtl L2xzdC5saWIvbHN0SXNFbXB0eS5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9s c3RMYXN0LmMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE1lbWJlci5jIC91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3ROZXh0LmMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9sc3QubGliL2xzdE9wZW4uYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5s aWIvbHN0UHJldi5jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RSZW1vdmUu YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0UmVwbGFjZS5jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RTdWNjLmMgL3Vzci9zcmMvY29udHJpYi9ibWFr ZS9zdHJlc2VwLmMNCmVjaG8gbWFrZTogL3Vzci9saWIvbGliYy5hICA+PiAuZGVwZW5kDQpj YyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1h a2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NP TkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BB VEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vz ci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNl ZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAt V25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3Rv dHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0 aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmct cGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAt V25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29u dmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9hcmNoLmMNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50 cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0 LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1X bm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAt V25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50 aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAt YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2J1Zi5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BX RF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtF X05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1E TUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9z aGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAg LURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1w cm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVdu by11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3Rv dHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXIt c2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xv Z2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFs aXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMv Y29udHJpYi9ibWFrZS9jb21wYXQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJ REUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUg LURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFU SVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6 L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9O QVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9y IC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2Vk LXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVdu by1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNv bXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25v LXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UvY29uZC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Iv c3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09O RklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZF X0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJl L21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0 ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0t aGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVy IC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFy aXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJv ZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25v LXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1 bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9kaXIu Yw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmlu L2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFW RV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAt RF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAt SS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1 bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdh bGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1w cm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVu aW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3Ry aW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFs dWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25v LWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvZm9yLmMNCmNjIC1PIC1w aXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0gg IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZT WVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9j b250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3Vt ZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9y bWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAt V21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVk IC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWlu dCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFy ZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9u ICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2hhc2guYw0KY2MgLU8gLXBpcGUgLWcgLURO T19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1E TUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVU QSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIu Li4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1h a2UgIC1ETUFLRV9OQVRJVkUgLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtc3RkPWdudTk5IC1R dW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1X YWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3Qt cHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11 bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0 cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZh bHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVdu by1jb252ZXJzaW9uIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLWMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9qb2IuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNy L3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NP TkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFW RV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFy ZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1z dGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVt LWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRl ciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1h cml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1i b2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVdu by11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1m dW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIi1ETUFLRV9WRVJTSU9OPVwiMjAxMzA1MjBcIiIg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9tYWluLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9f UFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1B S0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEg LURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4u L3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtl ICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNr LXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAt V25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJv dG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRl ci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRv bG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1 YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3Ny Yy9jb250cmliL2JtYWtlL21ha2UuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJ REUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUg LURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFU SVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6 L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9O QVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9y IC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2Vk LXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVdu by1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNv bXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25v LXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UvbWFrZV9tYWxsb2MuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUg LUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURI QVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZF IC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vz ci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJ VkUgLURIQVZFX0ZJTEVNT05fSCAtSS91c3IvaW5jbHVkZS9kZXYvZmlsZW1vbiAtc3RkPWdu dTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFk ZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdz dHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGgg LVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAt V25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51 c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rp b24gLVduby1jb252ZXJzaW9uIC1ESEFWRV9GSUxFTU9OX0ggLUkvdXNyL2luY2x1ZGUvZGV2 L2ZpbGVtb24gLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9tZXRhLmMNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLXN0ZD1n bnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVh ZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1X c3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRo IC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkg LVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVu dXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0 aW9uIC1Xbm8tY29udmVyc2lvbiAtV25vLWZvcm1hdC1ub25saXRlcmFsIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvcGFyc2UuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJ REUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUg LURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFU SVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6 L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9O QVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9y IC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2Vk LXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVdu by1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNv bXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25v LXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIv Ym1ha2Uvc3RyLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9z cmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05G SUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVf Q09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUv bWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3Rk PWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1o ZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIg LVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJp dGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9k eSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8t dW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVu Y3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N0cmxp c3QuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3Iu YmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1E SEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdf SCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1J LiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkg LVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMg LVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmlj dC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25v LXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8t c3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQt dmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAt V25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2Uvc3VmZi5jDQpjYyAt TyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2Ug IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJ R19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhf REVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9z cmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1h cmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25v LWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlw ZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFs aXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1 cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25v LXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVy c2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS90YXJnLmMNCmNjIC1PIC1waXBlIC1n IC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVU QSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRI PVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmli L2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAt ZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXky ayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3Np bmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8t cG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25v LXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVz ZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAv dXNyL3NyYy9jb250cmliL2JtYWtlL3RyYWNlLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdE X09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0Vf TkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURN QUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3No YXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAt RE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXBy b3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25v LXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90 eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1z aWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9n aWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxp dHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9j b250cmliL2JtYWtlL3V0aWwuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUg LUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURI QVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZF IC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vz ci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJ VkUgLVduby1jYXN0LXF1YWwgLVduby1mb3JtYXQtbm9ubGl0ZXJhbCAtc3RkPWdudTk5IC1R dW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1X YWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3Qt cHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11 bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0 cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZh bHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVdu by1jb252ZXJzaW9uIC1Xbm8tY2FzdC1xdWFsIC1Xbm8tZm9ybWF0LW5vbmxpdGVyYWwgLWMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS92YXIuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0Rf T1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9O QVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1B S0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hh cmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1E TUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJv dGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8t dW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5 cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNp Z24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dp Y2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0 eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2Nv bnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RBcHBlbmQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19Q V0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFL RV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAt RE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4v c2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2Ug IC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2st cHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1X bm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90 b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVy LXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9s b2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVh bGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RBdEVuZC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5P X1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURN QUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRB IC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4u Li9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFr ZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFj ay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcg LVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXBy b3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50 ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0 b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVx dWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9z cmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEF0RnJvbnQuYw0KY2MgLU8gLXBpcGUgLWcg LUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRB IC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9 XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIv Ym1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1m c3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJr IC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1w b2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8t dGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNl cy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RDbG9zZS5jDQpjYyAtTyAtcGlwZSAt ZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01F VEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFU SD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJp Yi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMg LWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15 MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNz aW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25v LXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVdu by10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhl c2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdENvbmNhdC5jDQpjYyAtTyAtcGlw ZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAt RFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lT UEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29u dHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVu dHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1h dC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdt aXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAt V25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQg LVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVu dGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERhdHVtLmMNCmNjIC1PIC1w aXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0gg IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZT WVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9j b250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3Vt ZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9y bWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAt V21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVk IC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWlu dCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFy ZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9u ICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RGVRdWV1ZS5jDQpjYyAt TyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2Ug IC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJ R19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhf REVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9z cmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1h cmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25v LWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlw ZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFs aXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1 cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25v LXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVy c2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdERlc3Ryb3kuYw0K Y2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2Jt YWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9D T05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9Q QVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91 c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVz ZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwg LVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90 b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5p dGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5n LXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUg LVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNv bnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3REdXBsLmMN CmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9i bWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVf Q09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURf UEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkv dXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51 c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxs IC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJv dG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmlu aXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmlu Zy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVl IC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1j b252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0RW5RdWV1 ZS5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5i aW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURI QVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19I IC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUku IC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAt UXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAt V2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0 LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8t dW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1z dHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12 YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1X bm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdEZp bmQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3Iu YmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1E SEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdf SCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1J LiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkg LVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMg LVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmlj dC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25v LXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8t c3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQt dmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAt V25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RG aW5kRnJvbS5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3Jj L3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklH X0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NP TkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21r XCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1n bnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVh ZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1X c3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRo IC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkg LVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVu dXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0 aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGli L2xzdEZpcnN0LmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9z cmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05G SUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVf Q09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUv bWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3Rk PWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1o ZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIg LVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJp dGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9k eSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8t dW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVu Y3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5s aWIvbHN0Rm9yRWFjaC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91 c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVf Q09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURI QVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3No YXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAg LXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0 ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1l dGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVy LWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5 LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAt V25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2Vk LWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9s c3QubGliL2xzdEZvckVhY2hGcm9tLmMNCmNjIC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJS SURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZF IC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05B VElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21r Oi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2JtYWtlICAtRE1BS0Vf TkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3Rv ciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNl ZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAt V3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1X bm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1j b21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVdu by11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmli L2JtYWtlL2xzdC5saWIvbHN0SW5pdC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9PVkVS UklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05BVElW RSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFLRV9O QVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFyZS9t azovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURNQUtF X05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90ZWN0 b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVz ZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMg LVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2lnbiAt V25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2ljYWwt Y29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5IC1X bm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29udHJp Yi9ibWFrZS9sc3QubGliL2xzdEluc2VydC5jDQpjYyAtTyAtcGlwZSAtZyAtRE5PX1BXRF9P VkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEgLURNQUtFX05B VElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9NRVRBIC1ETUFL RV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1cIi4uLi9zaGFy ZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9ibWFrZSAgLURN QUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZzdGFjay1wcm90 ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11 bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlw ZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBvaW50ZXItc2ln biAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10YXV0b2xvZ2lj YWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2VzLWVxdWFsaXR5 IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vzci9zcmMvY29u dHJpYi9ibWFrZS9sc3QubGliL2xzdElzQXRFbmQuYw0KY2MgLU8gLXBpcGUgLWcgLUROT19Q V0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9NRVRBIC1ETUFL RV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURVU0VfTUVUQSAt RE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BBVEg9XCIuLi4v c2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRyaWIvYm1ha2Ug IC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRzIC1mc3RhY2st cHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1X bm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90 b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVduby1wb2ludGVy LXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdGF1dG9s b2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRoZXNlcy1lcXVh bGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1jIC91c3Ivc3Jj L2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RJc0VtcHR5LmMNCmNjIC1PIC1waXBlIC1nIC1E Tk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0VfTUVUQSAt RE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1EVVNFX01F VEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQQVRIPVwi Li4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250cmliL2Jt YWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50cyAtZnN0 YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAt VyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3Npbmct cHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1Xbm8tcG9p bnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXRh dXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50aGVzZXMt ZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAtYyAvdXNy L3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0TGFzdC5jDQpjYyAtTyAtcGlwZSAtZyAt RE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01FVEEg LURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVTRV9N RVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFUSD1c Ii4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJpYi9i bWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMgLWZz dGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15Mmsg LVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5n LXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25vLXBv aW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10 YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhlc2Vz LWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMgL3Vz ci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE1lbWJlci5jDQpjYyAtTyAtcGlwZSAt ZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNFX01F VEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lTUEFU SD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29udHJp Yi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVudHMg LWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1hdC15 MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNz aW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAtV25v LXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQgLVdu by10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVudGhl c2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAgLWMg L3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdE5leHQuYw0KY2MgLU8gLXBpcGUg LWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVTRV9N RVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAgLURV U0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZU1BB VEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2NvbnRy aWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1lbnRz IC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3JtYXQt eTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlz c2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQgLVdu by1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1X bm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJlbnRo ZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24gIC1j IC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RPcGVuLmMNCmNjIC1PIC1waXBl IC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFrZSAgLURVU0Vf TUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09ORklHX0ggIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFUSF9ERUZTWVNQ QVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNyL3NyYy9jb250 cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2VkLWFyZ3VtZW50 cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1Xbm8tZm9ybWF0 LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21p c3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRpYWxpemVkIC1X bm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1wbHVzLWludCAt V25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1Xbm8tcGFyZW50 aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252ZXJzaW9uICAt YyAvdXNyL3NyYy9jb250cmliL2JtYWtlL2xzdC5saWIvbHN0UHJldi5jDQpjYyAtTyAtcGlw ZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1EVVNF X01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19IICAt RFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVGU1lT UEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMvY29u dHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1bWVu dHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZvcm1h dC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdt aXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXplZCAt V25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1pbnQg LVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBhcmVu dGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lvbiAg LWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdFJlbW92ZS5jDQpjYyAtTyAt cGlwZSAtZyAtRE5PX1BXRF9PVkVSUklERSAtSS91c3Ivc3JjL3Vzci5iaW4vYm1ha2UgIC1E VVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURIQVZFX0NPTkZJR19I ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1EX1BBVEhfREVG U1lTUEFUSD1cIi4uLi9zaGFyZS9tazovdXNyL3NoYXJlL21rXCIgLUkuIC1JL3Vzci9zcmMv Y29udHJpYi9ibWFrZSAgLURNQUtFX05BVElWRSAgLXN0ZD1nbnU5OSAtUXVudXNlZC1hcmd1 bWVudHMgLWZzdGFjay1wcm90ZWN0b3IgLVdzeXN0ZW0taGVhZGVycyAtV2FsbCAtV25vLWZv cm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1ldGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMg LVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1Xbm8tdW5pbml0aWFsaXpl ZCAtV25vLXBvaW50ZXItc2lnbiAtV25vLWVtcHR5LWJvZHkgLVduby1zdHJpbmctcGx1cy1p bnQgLVduby10YXV0b2xvZ2ljYWwtY29tcGFyZSAtV25vLXVudXNlZC12YWx1ZSAtV25vLXBh cmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tdW51c2VkLWZ1bmN0aW9uIC1Xbm8tY29udmVyc2lv biAgLWMgL3Vzci9zcmMvY29udHJpYi9ibWFrZS9sc3QubGliL2xzdFJlcGxhY2UuYw0KY2Mg LU8gLXBpcGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtl ICAtRFVTRV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05G SUdfSCAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRI X0RFRlNZU1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Iv c3JjL2NvbnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQt YXJndW1lbnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVdu by1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5 cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlh bGl6ZWQgLVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBs dXMtaW50IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVdu by1wYXJlbnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZl cnNpb24gIC1jIC91c3Ivc3JjL2NvbnRyaWIvYm1ha2UvbHN0LmxpYi9sc3RTdWNjLmMNCmNj IC1PIC1waXBlIC1nIC1ETk9fUFdEX09WRVJSSURFIC1JL3Vzci9zcmMvdXNyLmJpbi9ibWFr ZSAgLURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtREhBVkVfQ09O RklHX0ggIC1EVVNFX01FVEEgLURNQUtFX05BVElWRSAtREhBVkVfQ09ORklHX0ggLURfUEFU SF9ERUZTWVNQQVRIPVwiLi4uL3NoYXJlL21rOi91c3Ivc2hhcmUvbWtcIiAtSS4gLUkvdXNy L3NyYy9jb250cmliL2JtYWtlICAtRE1BS0VfTkFUSVZFICAtc3RkPWdudTk5IC1RdW51c2Vk LWFyZ3VtZW50cyAtZnN0YWNrLXByb3RlY3RvciAtV3N5c3RlbS1oZWFkZXJzIC1XYWxsIC1X bm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90 eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVduby11bmluaXRp YWxpemVkIC1Xbm8tcG9pbnRlci1zaWduIC1Xbm8tZW1wdHktYm9keSAtV25vLXN0cmluZy1w bHVzLWludCAtV25vLXRhdXRvbG9naWNhbC1jb21wYXJlIC1Xbm8tdW51c2VkLXZhbHVlIC1X bm8tcGFyZW50aGVzZXMtZXF1YWxpdHkgLVduby11bnVzZWQtZnVuY3Rpb24gLVduby1jb252 ZXJzaW9uICAtYyAvdXNyL3NyYy9jb250cmliL2JtYWtlL3N0cmVzZXAuYw0KY2MgLU8gLXBp cGUgLWcgLUROT19QV0RfT1ZFUlJJREUgLUkvdXNyL3NyYy91c3IuYmluL2JtYWtlICAtRFVT RV9NRVRBIC1ETUFLRV9OQVRJVkUgLURIQVZFX0NPTkZJR19IIC1ESEFWRV9DT05GSUdfSCAg LURVU0VfTUVUQSAtRE1BS0VfTkFUSVZFIC1ESEFWRV9DT05GSUdfSCAtRF9QQVRIX0RFRlNZ U1BBVEg9XCIuLi4vc2hhcmUvbWs6L3Vzci9zaGFyZS9ta1wiIC1JLiAtSS91c3Ivc3JjL2Nv bnRyaWIvYm1ha2UgIC1ETUFLRV9OQVRJVkUgIC1zdGQ9Z251OTkgLVF1bnVzZWQtYXJndW1l bnRzIC1mc3RhY2stcHJvdGVjdG9yIC1Xc3lzdGVtLWhlYWRlcnMgLVdhbGwgLVduby1mb3Jt YXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1X bWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV25vLXVuaW5pdGlhbGl6ZWQg LVduby1wb2ludGVyLXNpZ24gLVduby1lbXB0eS1ib2R5IC1Xbm8tc3RyaW5nLXBsdXMtaW50 IC1Xbm8tdGF1dG9sb2dpY2FsLWNvbXBhcmUgLVduby11bnVzZWQtdmFsdWUgLVduby1wYXJl bnRoZXNlcy1lcXVhbGl0eSAtV25vLXVudXNlZC1mdW5jdGlvbiAtV25vLWNvbnZlcnNpb24g ICAtc3RhdGljIC1vIG1ha2UgYXJjaC5vIGJ1Zi5vIGNvbXBhdC5vIGNvbmQubyBkaXIubyBm b3IubyBoYXNoLm8gam9iLm8gbWFpbi5vIG1ha2UubyBtYWtlX21hbGxvYy5vIG1ldGEubyBw YXJzZS5vIHN0ci5vIHN0cmxpc3QubyBzdWZmLm8gdGFyZy5vIHRyYWNlLm8gdXRpbC5vIHZh ci5vIGxzdEFwcGVuZC5vIGxzdEF0RW5kLm8gbHN0QXRGcm9udC5vIGxzdENsb3NlLm8gbHN0 Q29uY2F0Lm8gbHN0RGF0dW0ubyBsc3REZVF1ZXVlLm8gbHN0RGVzdHJveS5vIGxzdER1cGwu byBsc3RFblF1ZXVlLm8gbHN0RmluZC5vIGxzdEZpbmRGcm9tLm8gbHN0Rmlyc3QubyBsc3RG b3JFYWNoLm8gbHN0Rm9yRWFjaEZyb20ubyBsc3RJbml0Lm8gbHN0SW5zZXJ0Lm8gbHN0SXNB dEVuZC5vIGxzdElzRW1wdHkubyBsc3RMYXN0Lm8gbHN0TWVtYmVyLm8gbHN0TmV4dC5vIGxz dE9wZW4ubyBsc3RQcmV2Lm8gbHN0UmVtb3ZlLm8gbHN0UmVwbGFjZS5vIGxzdFN1Y2MubyBz dHJlc2VwLm8gDQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoICAtbyByb290IC1nIHdo ZWVsIC1tIDU1NSAgIG1ha2UgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmFtZDY0L21ha2UNCmNk IC91c3Ivc3JjOyBQQVRIPS9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluIGBpZiBbIC14 IC91c3Ivb2JqL3Vzci9zcmMvbWFrZS5hbWQ2NC9tYWtlIF07IHRoZW4gZWNobyAvdXNyL29i ai91c3Ivc3JjL21ha2UuYW1kNjQvbWFrZTsgZWxzZSBlY2hvIG1ha2U7IGZpYCAgLW0gL3Vz ci9zcmMvc2hhcmUvbWsgLWYgTWFrZWZpbGUuaW5jMSBUQVJHRVQ9YW1kNjQgVEFSR0VUX0FS Q0g9YW1kNjQgYnVpbGR3b3JsZA0KdXNhZ2U6IG1ha2UgWy1CZWlrTm5xcnN0V1hdIA0KICAg ICAgICAgICAgWy1DIGRpcmVjdG9yeV0gWy1EIHZhcmlhYmxlXSBbLWQgZmxhZ3NdIFstZiBt YWtlZmlsZV0NCiAgICAgICAgICAgIFstSSBkaXJlY3RvcnldIFstSiBwcml2YXRlXSBbLWog bWF4X2pvYnNdIFstbSBkaXJlY3RvcnldIFstVCBmaWxlXQ0KICAgICAgICAgICAgWy1WIHZh cmlhYmxlXSBbdmFyaWFibGU9dmFsdWVdIFt0YXJnZXQgLi4uXQ0KKioqIFtidWlsZHdvcmxk XSBFcnJvciBjb2RlIDINCg0KU3RvcCBpbiAvdXNyL3NyYy4= From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 17:00:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84263DB7; Sat, 1 Jun 2013 17:00:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E7AF67C4; Sat, 1 Jun 2013 17:00:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r51H0GBo082293; Sat, 1 Jun 2013 20:00:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r51H0GBo082293 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r51H0GOG082292; Sat, 1 Jun 2013 20:00:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 1 Jun 2013 20:00:16 +0300 From: Konstantin Belousov To: Bryan Drewery Subject: Re: Supermicro 6027R-N3RF+head, usb trouble Message-ID: <20130601170016.GU3047@kib.kiev.ua> References: <20130421223838.6bec3bfb@laptop.minsk.domain> <51A4F585.60401@FreeBSD.org> <20130529083338.07a2f54b@laptop.minsk.domain> <51A5F1AC.3060606@FreeBSD.org> <51A5F873.2000103@FreeBSD.org> <20130530050723.GW3047@kib.kiev.ua> <51A742EB.6070907@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ycbhuq+KTgWRWYKC" Content-Disposition: inline In-Reply-To: <51A742EB.6070907@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:00:21 -0000 --ycbhuq+KTgWRWYKC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 30, 2013 at 07:15:39AM -0500, Bryan Drewery wrote: > On 5/30/2013 12:07 AM, Konstantin Belousov wrote: > > On Wed, May 29, 2013 at 07:45:39AM -0500, Bryan Drewery wrote: > >> On 5/29/2013 7:16 AM, Bryan Drewery wrote: > >>> On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: > >>>> On Tue, 28 May 2013 13:20:53 -0500 > >>>> Bryan Drewery wrote: > >>>> > >>>>> On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Can anybody explain why USB keyboard (and keyboard from > >>>>>> integrated IPKVM) doesn't work when I boot with 'C606 > >>>>>> chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? > >>>>>> Also I can't boot that box from usb memstick and > >>>>>> FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both > >>>>>> loose(?) device and can't find root If I disable controller in bios > >>>>>> system can't see any sata hdd connected to it:( > >>>>>> booting with hw.usb.ehci.no_hs=3D1, kern.cam.boot_delay=3D"10000" > >>>>>> and debug.acpi.disabled=3D"hostres" without success. I setup dhcpd, > >>>>>> tftp, nfs on my laptop and finally I install fbsd on that box, but > >>>>>> question with kbd is open - It doesn't work.. > >>>>>> dmesg: > >>>>>> http://svn.freebsd.by/files/dmesg_N3RF.txt > >>>>>> pciconf -lv: > >>>>>> http://svn.freebsd.by/files/pciconf_N3RF.txt > >>>>>> > >>>>>> I would appreciate any hints > >>>>>> > >>>>> > >>>>> I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE > >>>>> (disc1) seems ok though. > >>>>> > >>>>> Did you get this figured out? > >>>>> > >>>> > >>>> I added to loader.conf > >>>> kern.maxbcache=3D"128M" > >> > >> ^ This setting is all that was needed. The VFS change was not needed. > >> > >> > >>>> vfs.maxbufspace=3D134217728 > >>>> also I create /boot.config with '-v' > >>>> I don't know what exactly help, but now usb kbd (ipkvm) works fine > >>>> for me. > >>>> p.s. It is smbios.system.product=3D"X9DRW" > >>>> > >>> > >>> Yes! This fix of limiting the size worked for me. USB worked on boot,= kb > >>> works remotely in the IP KVM and locally as well now. > >>> > >>> For the record, this is a DELL C1100 with 72GB of ram. The symptoms > >>> match the previous posts though and the delay settings did not help. > >>> > >>> This was working on 9.1-R, something must have changed on HEAD. > >>> > >>> This is not a production system, I'm willing to try any patches or > >>> settings to help get this fixed by default. > >>> > >=20 > > Could you get the values of sysctl kern.nbuf, kern.bio_transient_maxcnt > > from the boot without any tuning of the KVA usage ? > >=20 >=20 > # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache > kern.nbuf: 472300 > kern.bio_transient_maxcnt: 1024 > kern.maxbcache: 0 >=20 > For reference, with limiting maxbcache: >=20 > # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache > kern.nbuf: 7372 > kern.bio_transient_maxcnt: 102 > kern.maxbcache: 134217728 You did not tuned BKVASIZE nor MAXPHYS ? This is somewhat unexpected, but indeed reasonable. The buffer cache dutifully tried to allocate 1/10 of the RAM size for the buffer KVA. Please try the following tweak. diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 7bd8d7e..2f92cde 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -560,7 +560,8 @@ kern_vfs_bio_buffer_alloc(caddr_t v, long physmem_est) nbuf +=3D min((physmem_est - 4096) / factor, 65536 / factor); if (physmem_est > 65536) - nbuf +=3D (physmem_est - 65536) * 2 / (factor * 5); + nbuf +=3D min((physmem_est - 65536) * 2 / (factor * 5), + 32 * 1024 * 1024 / (factor * 5)); =20 if (maxbcache && nbuf > maxbcache / BKVASIZE) nbuf =3D maxbcache / BKVASIZE; --ycbhuq+KTgWRWYKC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRqiifAAoJEJDCuSvBvK1BDMsQAJ2iNDZJgHjlKi2y2x54RPVg aOvQzGe0pMOM/sh4MkDz0HQZ/dCPEux4XjoS5t7pOMWfSfNdeyScXofBZ+y61+N0 894EA0OkUAsQHCUZ60TCeOuUYfKDUSjhmnZxdWtBrGoaM7JlJkH/h5rMUnwcLPit i/hG+P8EmgZ+q5TLjZBi/LKwlbGFiimMggGboBDSW4mVRvZEQo9rSRwZPTSn7EmN 4Z9UuAFH9m2tzQHRRDMot4NGWo4Um/g/R7za7In/unfNO5Bn/zhiv5YHKBReDifv wX1xWdlJ0WWCkVRAojOmUfmgPHsE8JHyNZa+Imu7bDv6SDlj95myfRPbEX/2uBz4 NY17kwBuPcsws8CGJOU2f0zt3vBPzHmq8/H10pldoULzo1f7bB/VQ7ej+uYxSTVh pN+we8xOrvJ7/JsMurFcHO/rzBMEa5W0/E/pv2cIbP/i+H5P6F7l4Y4u8CiOMJes Q5QqgPyU1pJFi8flyzJs/vAjXA74jSwerNlvwNG35sWi9RSfMJ6NuCtPzBC+vC4P NfmjNUOajq0cusBBWAnAno+ZKQDBWWeThT98WQHnk17Wflxt2USFax64Z4WTeAmH ZP8yUqDChH1uNEgFo37GYLZM/yu35KGMeG8Z1Pka0XZmECFDA5bDqYtU4MTmVgQW kt+h4HQFtgcE8v+XEP76 =JsTE -----END PGP SIGNATURE----- --ycbhuq+KTgWRWYKC-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 17:21:46 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16C417F9 for ; Sat, 1 Jun 2013 17:21:46 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 93CF184C for ; Sat, 1 Jun 2013 17:21:45 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id fe20so815831lab.2 for ; Sat, 01 Jun 2013 10:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kmBcZnmjWBNT6PWlWgk/oox4GTWa4IVMDcfDPYjqKI8=; b=lRCEghpgyea+UwswFhAx57Wv7wOAdUTNcz0Yij67pVOLALfMq7EClrhUtKJX/8QjgO iGw02y8uzgeMd73oh6Kp8Uha8hviOGQMLt0E066ROfztKkPfjwSqTvXb01m66pRjh3/Y 6+9tttn7eWY4csLZfQenPl5n+1OnNZOqGz2Namju3XRj92HJVbJjNVvuijiUCc30PC5E HuUmtWjTg3Kd/R4paAvIptU39hzcXZWf908SdB1hJlailD6ODaAkkqa8vXuZ/8KdIn1V 5DR9x9m+q1IZCxfq759F/Yi+yKm99AHleCL3BD1MVeTtGUVq5JvzTIZpv/suy2tiJ2sv MawA== MIME-Version: 1.0 X-Received: by 10.112.218.6 with SMTP id pc6mr7961790lbc.62.1370107304524; Sat, 01 Jun 2013 10:21:44 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.13.135 with HTTP; Sat, 1 Jun 2013 10:21:44 -0700 (PDT) In-Reply-To: <20906.3577.581640.887366@jerusalem.litteratus.org> References: <20902.4239.221857.859835@jerusalem.litteratus.org> <20903.29628.653443.909151@jerusalem.litteratus.org> <20906.3577.581640.887366@jerusalem.litteratus.org> Date: Sat, 1 Jun 2013 10:21:44 -0700 X-Google-Sender-Auth: XY509Fjk_STljZZa1wzdje7bKtQ Message-ID: Subject: Re: "make buildworld" fails From: Craig Rodrigues To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:21:46 -0000 On Sat, Jun 1, 2013 at 8:06 AM, Robert Huff wrote: > > > (cd /usr/src && make bmake) > echo > > echo "--------------------------------------------------------------" > -------------------------------------------------------------- > echo ">>> Building an up-to-date make(1)" > >>> Building an up-to-date make(1) > echo "--------------------------------------------------------------" > -------------------------------------------------------------- > > sh /usr/src/tools/install.sh -o root -g wheel -m 555 make > /usr/obj/usr/src/make.amd64/make > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x > /usr/obj/usr/src/make.amd64/make ]; then echo > /usr/obj/usr/src/make.amd64/make; else echo make; fi` -m /usr/src/share/mk > -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 buildworld > usage: make [-BeikNnqrstWX] > [-C directory] [-D variable] [-d flags] [-f makefile] > [-I directory] [-J private] [-j max_jobs] [-m directory] [-T > file] > [-V variable] [variable=value] [target ...] > *** [buildworld] Error code 2 > > Stop in /usr/src. > Thank you for providing the output of make -d l buildworld. Without touching anything in your tree, can you provide some more information: (1) What is the output of /usr/bin/make -V MAKE_VERSION (2) What is the output of /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION (3) How did you update your source tree (svn, svnup, cvs, csup,....?) (4) What is the GRN version of your tree? If you updated with svn directly, you can find out with "svn info /usr/src" -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 17:44:13 2013 Return-Path: Delivered-To: FreeBSD-CURRENT@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA747FDD for ; Sat, 1 Jun 2013 17:44:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3BDA48E2 for ; Sat, 1 Jun 2013 17:44:13 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r51Hi0Be091353; Sat, 1 Jun 2013 20:44:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r51Hi0Be091353 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r51Hi0tk091341; Sat, 1 Jun 2013 20:44:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 1 Jun 2013 20:44:00 +0300 From: Konstantin Belousov To: Waitman Gobble Subject: Re: issue with libthr? Message-ID: <20130601174400.GV3047@kib.kiev.ua> References: <20130601075414.4F5D036F49FF@dx.burplex.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDw7img9kF1itdgu" Content-Disposition: inline In-Reply-To: <20130601075414.4F5D036F49FF@dx.burplex.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: FreeBSD-CURRENT@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:44:13 -0000 --KDw7img9kF1itdgu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote: >=20 > Hi, >=20 > I'm getting a ton of core dumps from Python and any software that uses Py= thon, > ie has USE_PYTHON_BUILD=3Dyes in Makefile. >=20 > hundreds of msgs in dmesg: > pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped) > pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped) >=20 > from gdb it seems to me to be libthr related? I've noticed a couple updat= es in > May.. wonder if it's related? I've only noticed this issue in the past we= ek, > after a complete rebuild and updated. >=20 > > uname -a > FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r251111: Wed = May > 29 16:44:31 PDT 2013 root@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA= =20 > amd64 >=20 > gdb: >=20 > seamonkey >=20 > (gdb) bt > #0 0x00000008011ee8ca in thr_kill () from /lib/libc.so.7 > #1 0x000000080316b585 in XRE_InstallX11ErrorHandler () > from /usr/local/lib/seamonkey/libxul.so > #2 0x0000000800f73286 in swapcontext () from /lib/libthr.so.3 > #3 0x0000000800f72e89 in sigaction () from /lib/libthr.so.3 > #4 0x00007ffffffff1d3 in ?? () > #5 0x0000000800f72d70 in sigaction () from /lib/libthr.so.3 > Previous frame inner to this frame (corrupt stack?) >=20 >=20 > python >=20 > (gdb) bt > #0 0x000000080100d8ca in thr_kill () from /lib/libc.so.7 > #1 0x00000008010d2e9c in abort () from /lib/libc.so.7 > #2 0x0000000803e4f05b in free () > from /usr/local/lib/python2.7/lib-dynload/_ctypes.so > #3 0x0000000800d9319f in pthread_mutex_destroy () from /lib/libthr.so.3 > #4 0x00000008010269ff in closedir () from /lib/libc.so.7 > #5 0x00000000004b545c in initposix () > #6 0x000000000047fb75 in PyEval_EvalFrameEx () > #7 0x000000000047d824 in PyEval_EvalCodeEx () > #8 0x0000000000484256 in _PyEval_SliceIndex () > #9 0x00000000004810cd in PyEval_EvalFrameEx () > #10 0x000000000047d824 in PyEval_EvalCodeEx () > #11 0x00000000004d5f56 in PyFunction_SetClosure () > #12 0x000000000041ffeb in PyObject_Call () > #13 0x0000000000482085 in PyEval_EvalFrameEx () > #14 0x000000000047d824 in PyEval_EvalCodeEx () > #15 0x0000000000484256 in _PyEval_SliceIndex () > #16 0x00000000004810cd in PyEval_EvalFrameEx () > #17 0x000000000047d824 in PyEval_EvalCodeEx () > #18 0x0000000000484256 in _PyEval_SliceIndex () > #19 0x00000000004810cd in PyEval_EvalFrameEx () > #20 0x000000000047d824 in PyEval_EvalCodeEx () > #21 0x0000000000484256 in _PyEval_SliceIndex () > #22 0x00000000004810cd in PyEval_EvalFrameEx () > #23 0x00000000004841f2 in _PyEval_SliceIndex () > #24 0x00000000004810cd in PyEval_EvalFrameEx () > #25 0x00000000004841f2 in _PyEval_SliceIndex () > #26 0x00000000004810cd in PyEval_EvalFrameEx () > #27 0x00000000004841f2 in _PyEval_SliceIndex () > #28 0x00000000004810cd in PyEval_EvalFrameEx () > #29 0x00000000004841f2 in _PyEval_SliceIndex () > #30 0x00000000004810cd in PyEval_EvalFrameEx () > #31 0x00000000004841f2 in _PyEval_SliceIndex () > #32 0x00000000004810cd in PyEval_EvalFrameEx () > #33 0x000000000047d824 in PyEval_EvalCodeEx () > #34 0x000000000047d156 in PyEval_EvalCode () > #35 0x00000000004a1361 in PyRun_FileExFlags () > #36 0x00000000004a0eb1 in PyRun_SimpleFileExFlags () > #37 0x0000000000417549 in Py_Main () > #38 0x000000000041692f in main () >=20 >=20 > Any help/pointers much appreciated. You cannot even guess what is going on without a proper debug information. Recompile and reinstall the libc/libthr/rtld with the debugging symbols to get proper backtraces. Anyway, two backtraces you demostrated, although not giving much useful data, look very different. More, the second backtrace suggests that there is either a bug in python interposing of malloc or memory corruption. --KDw7img9kF1itdgu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRqjLfAAoJEJDCuSvBvK1B2LAP/1RbwXlP0tFqd3L6lSjP8s9k IY5HGfvpLk08S5rtk3QIziEiBMuDXgDZkGKm4emGrmwyRaC61hiR+8qUcIUe0pF6 doyeitRjuaYDlRvxlhfPgET1/2BG3+LsHL1LM7gXMl6WUxQr17vN/6YC6NVx1rvU 0o22bHFOf6VDJh8aUVwtDmxkFdiCcgNhINWnraJk7uu5WKskKdYLCVXB737IBBNT pjYZCFF1OIjXHZG+bRXx2RLij+JOHD1te65TPr9zYCqTJUirMzsaHw4WQT9xBHFi 9z3HCLqkr0AeFdBfCe1GAwNC+VIH2i8iz/vwBoiAf4LXUoAWVYeKwYz14F5boNNh Sqfcpl1W5d8ZiTarUdqSIs3y5LVlFlT00o5H+HhTh26GEITDE5bakfSUkJPz7930 0bmzmlLOtn4NOrQKDYR6nE5Za7/gpJc7ur1tIy9xV1rE8RXgW9D47VBI2KR9dyZH sKmA7WM2jgAYlcF3c5FD1apRgk4VP9DbZIN1YjHJ6rpx5Pzf5VG1sr1hc+YWxNJZ qZX01Q/MoMyGAbCCMMiZnpvqNtVD+sPoAQrKcvAUlDpaEFjvpV+iOvcAnfCglZGi klORBwAnR8+atpG+glBOUJCzwh9Jeu1bdT8hgS1p672QlXjIchf6vZLZv78e0UkT 5xUJ2Hy7Picjg45MyRkO =juUW -----END PGP SIGNATURE----- --KDw7img9kF1itdgu-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 17:47:07 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DF30390 for ; Sat, 1 Jun 2013 17:47:07 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id DBE3F90A for ; Sat, 1 Jun 2013 17:47:06 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.1 cv=N7UQSQNB c=1 sm=0 tr=0 a=nVny9ETX7T5uMhI2oTVyRA==:117 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=S2kPtTsVP8EA:10 a=6I5d2MoRAAAA:8 a=8IZXt7FvfZkZxexA2osA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.193.164 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.193.164] ([209.6.193.164:15052] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 07/3F-02280-8933AA15; Sat, 01 Jun 2013 13:47:05 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20906.13208.152438.765867@jerusalem.litteratus.org> Date: Sat, 1 Jun 2013 13:47:04 -0400 To: Craig Rodrigues Subject: Re: "make buildworld" fails In-Reply-To: References: <20902.4239.221857.859835@jerusalem.litteratus.org> <20903.29628.653443.909151@jerusalem.litteratus.org> <20906.3577.581640.887366@jerusalem.litteratus.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: Robert Huff , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 17:47:07 -0000 Craig Rodrigues writes: > Without touching anything in your tree, can you provide some more > information: > > (1) What is the output of /usr/bin/make -V MAKE_VERSION 10201205300 > (2) What is the output of /usr/obj/usr/src/make.amd64/make -V MAKE_VERSION 20130520 > (4) What is the GRN version of your tree? If you updated with svn > directly, > you can find out with "svn info /usr/src" Working Copy Root Path: /usr/src URL: svn://svn0.us-east.freebsd.org/base/head Repository Root: svn://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 251213 Node Kind: directory Schedule: normal Last Changed Author: np Last Changed Rev: 251213 Last Changed Date: 2013-05-31 22:07:37 -0400 (Fri, 31 May 2013) Robert Huff From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 18:14:47 2013 Return-Path: Delivered-To: FreeBSD-CURRENT@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 570EF3D0 for ; Sat, 1 Jun 2013 18:14:47 +0000 (UTC) (envelope-from daemon@dx.burplex.com) Received: from dx.burplex.com (dx.burplex.com [50.197.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 474F7A03 for ; Sat, 1 Jun 2013 18:14:47 +0000 (UTC) Received: by dx.burplex.com (Postfix, from userid 1) id 75A1736F489C; Sat, 1 Jun 2013 11:14:46 -0700 (PDT) To: Konstantin Belousov Subject: Re: issue with libthr? From: Waitman Gobble X-UUID-HOR: dee89fc1-cae2-11e2-a1b3-902b34a86bc3 Message-Id: <20130601181446.75A1736F489C@dx.burplex.com> Date: Sat, 1 Jun 2013 11:14:46 -0700 (PDT) Cc: FreeBSD-CURRENT@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 18:14:47 -0000 On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov wrote: > > > >You cannot even guess what is going on without a proper debug information. >Recompile and reinstall the libc/libthr/rtld with the debugging symbols >to get proper backtraces. > >Anyway, two backtraces you demostrated, although not giving much useful >data, look very different. More, the second backtrace suggests that >there is either a bug in python interposing of malloc or memory corruption. Thanks so much for your help, I'll rebuild with debug on next. One thing I can get an instant crash is building midori, so I've been experimenting to see where it's breaking. It seems two things in the build script cause it wreck python: the midori build reconstitutes a binary coded file within the script, it's a file t.bz, which is uncompressed to become wafadmin, inside that is a file Tools/config_c.py there's p.Utils.pproc.Popen in 'cmd_and_log' function it returns: p: {'_child_created': True, 'returncode': 1, 'stdout': ', mode 'rb' at 0x8037e92e0>, 'stdin': None, 'pid': 62571, 'stderr': ', mode 'rb' at 0x8037e8b60>, 'universal_newlines': False} the '1' returncode causes build to fail.. Also, function def validate_c(self,kw) *always* causes python to crash for example, when it calls conf.check (header_name='unistd.h') ..core dump... Maybe this isn't useful information.. Next I'll rebuild with debug and see about getting more info from gdb. Thanks, -- Waitman Gobble San Jose California USA +1.5108307875 From owner-freebsd-current@FreeBSD.ORG Sat Jun 1 19:11:55 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3EE53D51 for ; Sat, 1 Jun 2013 19:11:55 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id BC266BD6 for ; Sat, 1 Jun 2013 19:11:54 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id t13so2673944lbd.29 for ; Sat, 01 Jun 2013 12:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bV/KB8nDPnsZMu8Hrgzib/qt9B64A7yiKddwEtL+6WI=; b=RUpXzNW2UrEIM5af8ucUdWWh1q2vGqvha+JKr5GkseJwxdlg5aGjf1eUNJUDcty/NN U6y9FYnF+WaXQIrDiDEQJsxmb2rwugqHyv5kS+AisaXGUNFNwudDzUlz6EodPk0Ny72x 9EvBnGXQlEjDIjgL5e+bC54o8CsOHYy5CuD7LKIswEBJcSqIRPMXkkBbS9wVXz7gpCqK SAb1hksTKsCKsaBOloRPF6oXsRXVUyAh7zmX53hfMzHAYVnWqOlV50rkHcnTGX9rprak ROl5op2KebIdnJ1wMMCNywpkxi31EYI+Us+r5lnRYEbaoPC0LgYQC2DPG31fteg64sU0 yqGw== MIME-Version: 1.0 X-Received: by 10.152.29.227 with SMTP id n3mr8139029lah.3.1370113908135; Sat, 01 Jun 2013 12:11:48 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.13.135 with HTTP; Sat, 1 Jun 2013 12:11:48 -0700 (PDT) In-Reply-To: <20906.13208.152438.765867@jerusalem.litteratus.org> References: <20902.4239.221857.859835@jerusalem.litteratus.org> <20903.29628.653443.909151@jerusalem.litteratus.org> <20906.3577.581640.887366@jerusalem.litteratus.org> <20906.13208.152438.765867@jerusalem.litteratus.org> Date: Sat, 1 Jun 2013 12:11:48 -0700 X-Google-Sender-Auth: Yh7bSvwNQzG9EuGb9vGmUg348ss Message-ID: Subject: Re: "make buildworld" fails From: Craig Rodrigues To: Robert Huff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 19:11:55 -0000 On Sat, Jun 1, 2013 at 10:47 AM, Robert Huff wrote: > > Craig Rodrigues writes: > > Without touching anything in your tree, can you provide some more > > information: > > > > (1) What is the output of /usr/bin/make -V MAKE_VERSION > > 10201205300 > > > (2) What is the output of /usr/obj/usr/src/make.amd64/make -V > MAKE_VERSION > > 20130520 > > > (4) What is the GRN version of your tree? If you updated with svn > > directly, > > you can find out with "svn info /usr/src" > > Working Copy Root Path: /usr/src > URL: svn://svn0.us-east.freebsd.org/base/head > Repository Root: svn://svn0.us-east.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 251213 > Node Kind: directory > Schedule: normal > Last Changed Author: np > Last Changed Rev: 251213 > Last Changed Date: 2013-05-31 22:07:37 -0400 (Fri, 31 May 2013) > Thanks for providing the information. This looks related to the latest change to switch to bmake. I don't understand how all the pieces of the puzzle fit together to 100% diagnose the problem, but an you try the following: (1) Completely blow away the obj tree with: rm -fr /usr/obj (2) Update the source tree under /usr/src to the latest revision with "svn update" (3) Try again: make -d l buildworld -- Craig