From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 10:12:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 675211F9 for ; Sun, 16 Feb 2014 10:12:18 +0000 (UTC) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [IPv6:2a02:6b8:0:1819::a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 206001099 for ; Sun, 16 Feb 2014 10:12:18 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward10l.mail.yandex.net (Yandex) with ESMTP id A388BBA0BA3 for ; Sun, 16 Feb 2014 14:12:14 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 628BDE40113 for ; Sun, 16 Feb 2014 14:12:14 +0400 (MSK) Received: from unknown (unknown [178.76.234.16]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id C7K9FLgRLC-CEMaNq3a; Sun, 16 Feb 2014 14:12:14 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 1b42eb1a-55d0-4d4b-bfb5-8714b39b1db0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392545534; bh=mGJWhvlB7LdbM9sUfpYgbEbB6Ah/ijYB32/xejJuDkQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=mksA+J6LKbR2QatZ0EeDTTubb3U29xg+v3tq3ZZTKfFeVbFQf70bBnhjtl22NUAuS BfBQiwXruQt0XQcFQaQ3jAKN9ZuPBEXGm1kZ27Wl9k2e9gwoDmyB7+vcaaCNWp502k 2ORe0dFl+KN0o9djWOLaiXecBOyM/VuLqjLEl5RM= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53008ECD.2070004@yandex.ru> Date: Sun, 16 Feb 2014 14:11:25 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: FreeBSD Current Subject: ssh-keygen -Z 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.17 Precedence: 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, 16 Feb 2014 10:12:18 -0000 Hello, there is -Z parameter in ssh-keygen --help output, but no mention of it in ssh-keygen's man-page. Any clue what values this parameter accept? -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 10:20:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C456652E; Sun, 16 Feb 2014 10:20:47 +0000 (UTC) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6935610D5; Sun, 16 Feb 2014 10:20:47 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id pa12so11080030veb.16 for ; Sun, 16 Feb 2014 02:20:46 -0800 (PST) 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:message-id :subject:from:to:cc:content-type; bh=UWOMNdSUzVcvJzrShH40VrAkfigi7ItW6SxBonYib4o=; b=RtcrB4HK3ZwkBUYnKEU+TQ9XbxL1sZdAgdVH0lXc5NBjFu9B88InPadielvSfvOcs7 T2sg9hkRA3yh/egrajpzJ/Y47I5kWATvyvqQKzp4cnfbAiQSkkEv+mpJ7b/3HpzCW9zx 0xD5EGnYV8gBuJRRl8nSikPOC8hD+YMTbubegJA/vteWVU8XGy1Sdi3pEKnH3IvhWlL0 88bs05h4UHCu29uvcG8cGxgw3zSZBPmMuDp9k3GeKPU/Sk8L/mA5O+6UzbfAMz5dafJM D4Z9U+OsaGM1mQFtH0d4pXuxfX8JUoPFaDmHX+1Wy228YJgZe0DoFBLzbuPg0dFRh7G5 GLYA== MIME-Version: 1.0 X-Received: by 10.52.181.199 with SMTP id dy7mr546760vdc.43.1392546046501; Sun, 16 Feb 2014 02:20:46 -0800 (PST) Sender: hiroo.ono@gmail.com Received: by 10.58.210.66 with HTTP; Sun, 16 Feb 2014 02:20:46 -0800 (PST) In-Reply-To: References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> <20130813.125709.1168850046133874829.shigeru@iij.ad.jp> Date: Sun, 16 Feb 2014 19:20:46 +0900 X-Google-Sender-Auth: jsm_KLhgj7fEtKP_2Sc1dxQzcX4 Message-ID: Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet From: =?ISO-2022-JP?B?SGlyb28gT25vICgbJEI+LkxuNDJAOBsoQik=?= To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: hiroo.ono+freebsd@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 10:20:47 -0000 Hello, The problem of USB ethernet device with VIMAGE kernel still remains with 10.0-RELEASE and I think I have found the reason and a fix. I have filed a patch and backtrace as a followup to the PR http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/183835 I will repeat the explanation here. The problem occur when ue_attach_post_task() (in sys/dev/usb/net/usb_ethernet.c) is called. ue_attach_post_task() calls if_alloc() (in sys/net/if.c) and ether_attach() (in sys/net/if_ethersubr.c), which finally refer V_if_index. The problem is that curvnet is NULL when ue_attach_post_task() is invoked, and with VIMAGE, V_if_index is defined to VNET(if_index) => VNET_VNET(curvnet, if_index) => (*VNET_VNET_PTR((curvnet), if_index)) => (*_VNET_PTR((curvnet)->vnet_data_base, if_index)) and so on. For device attach, the following code in device_probe_and_attach() (in kern/subr_bus.c) CURVNET_SET_QUIET(vnet0); error = device_attach(dev); CURVNET_RESTORE(); should assign curvnet to vnet0, but it is not the case for ue device. As an example of USB ethernet device, with if_axe, device_attach(dev) is axe_attach() (in sys/dev/usb/net/if_axe.c). axe_attach() calls uether_ifattach() (in sys/dev/usb/net/usb_ethernet.c) (other USB ethernet devices' *_attach() also call this function), which *queues* (not calls) ue_attach_post_task(). As ue_attach_post_task is called from usb_process (not from uther_ifattach), it is not assured that curvnet is properly assigned. 2013-08-14 4:08 GMT+09:00 Craig Rodrigues : > On Mon, Aug 12, 2013 at 8:57 PM, YAMAMOTO Shigeru wrote: > >> >> My try is, >> 1) I try to enable "option VIMAGE" at r254236@HEAD. >> It causes panic at accessing V_if_index in ifindex_alloc_locked(). >> > > Can you provide the kernel backtrace for this panic? > It would be interesting to see where we need to initialize currvnet for USB > Ethernet. > I thought we already handled that case in subr_bus.c > > -- > Craig > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 10:29:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0578F794 for ; Sun, 16 Feb 2014 10:29:30 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CECA11154 for ; Sun, 16 Feb 2014 10:29:29 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id y10so13572027pdj.26 for ; Sun, 16 Feb 2014 02:29:29 -0800 (PST) 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=OsxJZ42V1YH4ZDN3xT04K14/I5teAU66Mb+9vDhf0Rs=; b=U6C2PJCZjsbqw82bwQaFT56MMEOn0UoNTdKKhH4+zB6qKaBCNn9/qGq8JeGnChY/bc pXtqy56zoYJPno2V0hYTwGqAKHiNIO0qOa59vQHNQJM5Az47cLIzhlu/AXvOlGj/5wlS SgiL+zqE2/DYePCr3Os2KoWHu9IWDmA9rLRQbXY+xWMEBxOwlm0bRbp+QfuipR2dneSx FzpAAPqtEp7WVJoDLNdfCMZsTcv9VspR4MHLhyIlET0U8BVWP080MxoXm4qNa+aVyISV 8ZKTYa1yDTdAEHqi4/V+7PRpUZDlxaOrYfMoULXbeQOJk3hN+oqslcca0btgdW0ntKz2 z5Rg== MIME-Version: 1.0 X-Received: by 10.66.16.131 with SMTP id g3mr1996335pad.138.1392546569287; Sun, 16 Feb 2014 02:29:29 -0800 (PST) Received: by 10.68.155.38 with HTTP; Sun, 16 Feb 2014 02:29:29 -0800 (PST) In-Reply-To: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> Date: Sun, 16 Feb 2014 05:29:29 -0500 Message-ID: Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet From: Aryeh Friedman To: YAMAMOTO Shigeru Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 10:29:30 -0000 Take a look at petitecloud.org it might solve your issue we have a working cloud on a stick for stuff like the above (using bhyve running off a usb drive) On Sun, Aug 11, 2013 at 11:48 PM, YAMAMOTO Shigeru wrote: > > Hi all, > > I hope to use "option VIMAGE" on RaspberryPi. > > So, I try to make a patch. > > http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/raspberry-pi/patch-vimage-r254236.diff > #There is a SD image for RaspberryPi at same place. > > But, I only test it for if_smsc driver on RaspberryPi. > I don't test other architectures/devices. > > Please test my patch and suggest the way to support "option VIMAGE" on USB > devices, if you are interested in. > > Thanks, > ------- > YAMAMOTO Shigeru > _______________________________________________ > 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" > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 10:32:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72A8F8D0 for ; Sun, 16 Feb 2014 10:32:40 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4529811D7 for ; Sun, 16 Feb 2014 10:32:40 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id p10so13780431pdj.3 for ; Sun, 16 Feb 2014 02:32:39 -0800 (PST) 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=tjQxqbIDad4Wf/ALoHtnLk7w2PVVYzXF3bUy4OS3GnM=; b=ZoQAi4thAFzed7FLNhPUKc4CyAQ/Iyc7+EHj0igPkPRRv5fv3yBDLMTWDTglqNuVUQ kHPx7IUqkwSHBuNeH6MUkutpIuoLHi+u3BvYckDDhVeWBLBSNXdMccOi6j9l0NzBti9q w9CUica2qsGTnZ4QNPr1dJUfX8BC8639byhadfOJqL38hAzzHfEnnSWtkdNo2bC3fLPO tBuYdoPm+wefiMHJhSuG2W/kuk8+4v5tIraj792RQwzzkh8qgQHboZYdcQ5a+6k1OAl9 W+NtL2GnCP2DuJr0bZ/0kCLpBy3ahfNhSkMQhHmlGkCNK3FGUWZXSfi6J+jWB43xPkmr 96Mg== MIME-Version: 1.0 X-Received: by 10.68.172.37 with SMTP id az5mr1959734pbc.139.1392546759808; Sun, 16 Feb 2014 02:32:39 -0800 (PST) Received: by 10.68.155.38 with HTTP; Sun, 16 Feb 2014 02:32:39 -0800 (PST) In-Reply-To: References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> Date: Sun, 16 Feb 2014 05:32:39 -0500 Message-ID: Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet From: Aryeh Friedman To: YAMAMOTO Shigeru Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 10:32:40 -0000 Forgot to mention that the actual solution is only in our mailing list archives but should in the next few days be on the site On Sun, Feb 16, 2014 at 5:29 AM, Aryeh Friedman wrote: > Take a look at petitecloud.org it might solve your issue we have a > working cloud on a stick for stuff like the above (using bhyve running off > a usb drive) > > > On Sun, Aug 11, 2013 at 11:48 PM, YAMAMOTO Shigeru wrote: > >> >> Hi all, >> >> I hope to use "option VIMAGE" on RaspberryPi. >> >> So, I try to make a patch. >> >> http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/raspberry-pi/patch-vimage-r254236.diff >> #Thereis a SD image for RaspberryPi at same place. >> >> But, I only test it for if_smsc driver on RaspberryPi. >> I don't test other architectures/devices. >> >> Please test my patch and suggest the way to support "option VIMAGE" on USB >> devices, if you are interested in. >> >> Thanks, >> ------- >> YAMAMOTO Shigeru >> _______________________________________________ >> 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 >> " >> > > > > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 11:25:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB114D93 for ; Sun, 16 Feb 2014 11:25:51 +0000 (UTC) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 655331566 for ; Sun, 16 Feb 2014 11:25:51 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward7l.mail.yandex.net (Yandex) with ESMTP id EC3D1BC004F for ; Sun, 16 Feb 2014 15:25:48 +0400 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id AA3B5E40068 for ; Sun, 16 Feb 2014 15:25:48 +0400 (MSK) Received: from 78.108.206.159.tel.ru (78.108.206.159.tel.ru [78.108.206.159]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ZlJ1wijF1G-PmMmGDPP; Sun, 16 Feb 2014 15:25:48 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 21670f74-9ef7-488e-8073-a1fbedbb088e Message-ID: <5300A03C.3040901@passap.ru> Date: Sun, 16 Feb 2014 15:25:48 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 11:25:51 -0000 16.02.2014 14:29, Aryeh Friedman пишет: > Take a look at petitecloud.org it might solve your issue we have a working > cloud on a stick for stuff like the above (using bhyve running off a usb > drive) Is it only me who thinks that it's a pure SPAM? > On Sun, Aug 11, 2013 at 11:48 PM, YAMAMOTO Shigeru wrote: >> >> I hope to use "option VIMAGE" on RaspberryPi. >> >> So, I try to make a patch. >> >> http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/raspberry-pi/patch-vimage-r254236.diff >> #There is a SD image for RaspberryPi at same place. >> >> But, I only test it for if_smsc driver on RaspberryPi. >> I don't test other architectures/devices. >> >> Please test my patch and suggest the way to support "option VIMAGE" on USB >> devices, if you are interested in. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 11:28:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECC04F36 for ; Sun, 16 Feb 2014 11:28:34 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C05481584 for ; Sun, 16 Feb 2014 11:28:34 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so13995154pad.8 for ; Sun, 16 Feb 2014 03:28:33 -0800 (PST) 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=97eRnRdmpxu4OXzHz/4BluXUYwlV8w3HavgdsITskKw=; b=QN+JgGru5/EG8j+gbWCrMRm+a1SUw48ZptnE5n/FIIpvfLEaXjhrCJk89cv4CtTBVR P5kNwBB7AyHDVlmDwYmPTIh+wW3ojkXnV4zFSorwxpeCq1TddVprKaCsvKtdgJZMIjoZ UOnvmD7W+L+slXqP7ijK0vM8kyW64vGymvsKiqAHWvqhgHxUQWwA+IK2iQ3ARgKWU+TA jW7P/7rDdtKyKIyjB7jYodetZGagtGoj71W466AhM73pOHxUFlhR3pVbF7jsHkmUkxRM HqUWMN0qokt5fw5r9HwqGiO1zwJxsy2UcDtKAJb8gu0VvCIo1qM2t6XjmBAAM9sgBLZ9 vEJA== MIME-Version: 1.0 X-Received: by 10.68.171.229 with SMTP id ax5mr20049604pbc.125.1392550113836; Sun, 16 Feb 2014 03:28:33 -0800 (PST) Received: by 10.68.155.38 with HTTP; Sun, 16 Feb 2014 03:28:33 -0800 (PST) In-Reply-To: <5300A03C.3040901@passap.ru> References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> <5300A03C.3040901@passap.ru> Date: Sun, 16 Feb 2014 06:28:33 -0500 Message-ID: Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet From: Aryeh Friedman To: Boris Samorodov Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 11:28:35 -0000 He was asking how to run a VM on ARM something that one of our core team members has already demostrated and I was just giving a pointer to it (the archives are a little screw right now so no direct link) On Sun, Feb 16, 2014 at 6:25 AM, Boris Samorodov wrote: > 16.02.2014 14:29, Aryeh Friedman =D0=C9=DB=C5=D4: > > > Take a look at petitecloud.org it might solve your issue we have a > working > > cloud on a stick for stuff like the above (using bhyve running off a us= b > > drive) > > Is it only me who thinks that it's a pure SPAM? > > > On Sun, Aug 11, 2013 at 11:48 PM, YAMAMOTO Shigeru >wrote: > >> > >> I hope to use "option VIMAGE" on RaspberryPi. > >> > >> So, I try to make a patch. > >> > >> > http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/raspb= erry-pi/patch-vimage-r254236.diff > >> #There is a SD image for RaspberryPi at same place. > >> > >> But, I only test it for if_smsc driver on RaspberryPi. > >> I don't test other architectures/devices. > >> > >> Please test my patch and suggest the way to support "option VIMAGE" on > USB > >> devices, if you are interested in. > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > _______________________________________________ > 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 Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 12:13:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14C11DD6 for ; Sun, 16 Feb 2014 12:13:54 +0000 (UTC) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [IPv6:2a02:6b8:0:1819::a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3ABC1850 for ; Sun, 16 Feb 2014 12:13:53 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward10l.mail.yandex.net (Yandex) with ESMTP id BB964BA0C78 for ; Sun, 16 Feb 2014 16:13:51 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 797D11B608B7 for ; Sun, 16 Feb 2014 16:13:51 +0400 (MSK) Received: from 78.108.206.159.tel.ru (78.108.206.159.tel.ru [78.108.206.159]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id ao9nGMbjKw-Dp5Wf0JF; Sun, 16 Feb 2014 16:13:51 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) To: undisclosed-recipients:; X-Yandex-Uniq: 67667de6-a997-4c0e-869e-d028d5086497 Message-ID: <5300AB7E.5040300@passap.ru> Date: Sun, 16 Feb 2014 16:13:50 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 CC: FreeBSD Current Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> <5300A03C.3040901@passap.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 12:13:54 -0000 16.02.2014 15:28, Aryeh Friedman пишет: > He was asking how to run a VM on ARM something that one of our core team > members has already demostrated and I was just giving a pointer to it (the > archives are a little screw right now so no direct link) 1. Top quoting. 2. Unneeded over quoting. 3. Bogus quoting (my words were removed but name remained). 4. No technical answer at your first answer (only site link). 5. The aforementioned site does not have the word "VIMAGE". This _is_ SPAM. PS. You claim to be a "Lead Developer", so, please, try to write technical answers and to respect all others time (do appropriate quoting). > On Sun, Feb 16, 2014 at 6:25 AM, Boris Samorodov wrote: > >> 16.02.2014 14:29, Aryeh Friedman пишет: >> >>> Take a look at petitecloud.org it might solve your issue we have a >> working >>> cloud on a stick for stuff like the above (using bhyve running off a usb >>> drive) >> >> Is it only me who thinks that it's a pure SPAM? >> >>> On Sun, Aug 11, 2013 at 11:48 PM, YAMAMOTO Shigeru >> wrote: >>>> >>>> I hope to use "option VIMAGE" on RaspberryPi. >>>> >>>> So, I try to make a patch. >>>> >>>> >> http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/raspberry-pi/patch-vimage-r254236.diff >>>> #There is a SD image for RaspberryPi at same place. >>>> >>>> But, I only test it for if_smsc driver on RaspberryPi. >>>> I don't test other architectures/devices. >>>> >>>> Please test my patch and suggest the way to support "option VIMAGE" on >> USB >>>> devices, if you are interested in. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 14:21:16 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30E08308 for ; Sun, 16 Feb 2014 14:21:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0082C11A3 for ; Sun, 16 Feb 2014 14:21:15 +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 1WF2aj-00055m-Gq; Sun, 16 Feb 2014 14:21:09 +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 s1GEL6qU001662; Sun, 16 Feb 2014 07:21:06 -0700 (MST) (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+393glysoDdyz30NhJv3oz Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet From: Ian Lepore To: Aryeh Friedman In-Reply-To: References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> <5300A03C.3040901@passap.ru> Content-Type: text/plain; charset="koi8-r" Date: Sun, 16 Feb 2014 07:21:06 -0700 Message-ID: <1392560466.1145.132.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1GEL6qU001662 Cc: FreeBSD Current , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 14:21:16 -0000 On Sun, 2014-02-16 at 06:28 -0500, Aryeh Friedman wrote: > He was asking how to run a VM on ARM something that one of our core tea= m > members has already demostrated and I was just giving a pointer to it (= the > archives are a little screw right now so no direct link) >=20 What he was asking had nothing to do with running a VM on ARM. If you were actually a developer as you claim, you'd know that. Everything posted by this person so far is indeed off-topic spam. -- Ian >=20 > On Sun, Feb 16, 2014 at 6:25 AM, Boris Samorodov wrote= : >=20 > > 16.02.2014 14:29, Aryeh Friedman =D0=C9=DB=C5=D4: > > > > > Take a look at petitecloud.org it might solve your issue we have a > > working > > > cloud on a stick for stuff like the above (using bhyve running off = a usb > > > drive) > > > > Is it only me who thinks that it's a pure SPAM? > > > > > On Sun, Aug 11, 2013 at 11:48 PM, YAMAMOTO Shigeru > >wrote: > > >> > > >> I hope to use "option VIMAGE" on RaspberryPi. > > >> > > >> So, I try to make a patch. > > >> > > >> > > http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20130812/r= aspberry-pi/patch-vimage-r254236.diff > > >> #There is a SD image for RaspberryPi at same place. > > >> > > >> But, I only test it for if_smsc driver on RaspberryPi. > > >> I don't test other architectures/devices. > > >> > > >> Please test my patch and suggest the way to support "option VIMAGE= " on > > USB > > >> devices, if you are interested in. > > > > -- > > WBR, Boris Samorodov (bsam) > > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" > > >=20 >=20 >=20 > --=20 > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 18:35:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5230221 for ; Sun, 16 Feb 2014 18:35:55 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C6F613C7 for ; Sun, 16 Feb 2014 18:35: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 s1GIZtMU081309 for ; Sun, 16 Feb 2014 18:35:55 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1GIZtFS081308 for freebsd-current@freebsd.org; Sun, 16 Feb 2014 18:35:55 GMT (envelope-from bdrewery) Received: (qmail 53976 invoked from network); 16 Feb 2014 12:35:52 -0600 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 16 Feb 2014 12:35:52 -0600 Message-ID: <53010507.3080601@FreeBSD.org> Date: Sun, 16 Feb 2014 12:35:51 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: M_FILEDESC leak References: <52FEE944.2050406@FreeBSD.org> In-Reply-To: <52FEE944.2050406@FreeBSD.org> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxggnEkIfE7k60n0cPfIcxBvrRIGWFilT" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 18:35:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mxggnEkIfE7k60n0cPfIcxBvrRIGWFilT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/14/2014 10:12 PM, Bryan Drewery wrote: > There's some leak of M_FILEDESC. Most head servers I look on have high > filedesc usage in vmstat -m. Older (stable/9,8) do not. >=20 > vmstat -m|grep filedesc usage on various servers: >=20 > r259961 133350 (freefall) > r261350 829256 (my dev server) > r261411 67 (pointyhat) > r263068 288122 (beefy1) > r260368 1193324 (beefy2) >=20 I have figured this out and am preparing a patch for review/commit. This goes back at least to Jan 2013 in head, thus is in 10.0-R as well. --=20 Regards, Bryan Drewery --mxggnEkIfE7k60n0cPfIcxBvrRIGWFilT 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/ iQEcBAEBAgAGBQJTAQUIAAoJEDXXcbtuRpfP8EAIAL4M6sGmXOjf08J28IhmRpc2 H3nqPoYt5+MRa3hh25X3qCgo3y7q6rkXb+QNcjEDGQ5X7q8ZojFfoEpxMTkpDLAQ M95xKBN3WW/BdyqWEj/hFf4OHgpJlvqcQejKBOyZtVBoKyaPsJx3+mC4i5FRoUyA fXnQF7izTGe0meLghU7vSwV1BQy0QyitD+xSJDuisgaLXpYnizskMFcFFk4QpTFn 39CBEE9VUDcEeS0OU+m9NVyWRCxrgiawZ03olwBXCkzxJ5WDAinqeKAL5P+2hxL6 BS01H10mHppprchxfr88phwmOYmcWZurNjZ5QCWxnF+5lOQZhMoigvjSZsC0AF8= =GJs0 -----END PGP SIGNATURE----- --mxggnEkIfE7k60n0cPfIcxBvrRIGWFilT-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 20:07:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35B774D4 for ; Sun, 16 Feb 2014 20:07:22 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0E771A24 for ; Sun, 16 Feb 2014 20:07:21 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::21c3:44c8:db38:e11b] (unknown [IPv6:2001:7b8:3a7:0:21c3:44c8:db38:e11b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C36165C45 for ; Sun, 16 Feb 2014 21:07:13 +0100 (CET) From: Dimitry Andric Content-Type: multipart/signed; boundary="Apple-Mail=_A64F6D5F-88DC-4AA3-9F89-04E832341CB0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: HEADS UP: Updated llvm/clang to 3.4 in r261991 Message-Id: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> Date: Sun, 16 Feb 2014 21:06:58 +0100 To: FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 20:07:22 -0000 --Apple-Mail=_A64F6D5F-88DC-4AA3-9F89-04E832341CB0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I have just upgraded our copy of llvm/clang to 3.4 release, in r261991. This version supports all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y. The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work. Release notes for llvm and clang can be found here: Note that building lldb (using WITH_LLDB) will not work at this point, since our lldb snapshot was locally modified to be able to work with the old llvm 3.3 API. Ed Maste will most likely fix this very soon (and maybe import a new snapshot, I hope :-). Another important aspect for end-users and ports maintainers is the new compiler flag handling in clang 3.4. It has become more strict, in the sense that it will now error out on flags it does not recognize, in particular most gcc-specific optimization fine-tuning flags. Some ports which blindly use such gcc-specific flags will therefore be broken, but these are usually very easy to fix. During the exp-run which was done with this new version of clang, several ports with the highest number of dependent ports (open-motif, libtheora, boost-libs, etc) have already been handled, but more work still needs to be done. Last but not least, I hope we can now start using clang for more of our existing architectures, like powerpc, mips, and possibly even new ones like arm64. Enjoy! -Dimitry --Apple-Mail=_A64F6D5F-88DC-4AA3-9F89-04E832341CB0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMBGmYACgkQsF6jCi4glqPLBQCcD6vHZTgqcrtekSJhhEp/+yC0 nPEAoNa0lQ/GlIGSrQib2WerZVEvzsxV =njzp -----END PGP SIGNATURE----- --Apple-Mail=_A64F6D5F-88DC-4AA3-9F89-04E832341CB0-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 20:16:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AF38881; Sun, 16 Feb 2014 20:16:34 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E7D51AD1; Sun, 16 Feb 2014 20:16:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.8/8.14.8) with ESMTP id s1GKGNNC045981; Sun, 16 Feb 2014 12:16:23 -0800 (PST) (envelope-from freebsd@penx.com) Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 From: Dennis Glatting To: Dimitry Andric In-Reply-To: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Feb 2014 12:16:22 -0800 Message-ID: <1392581782.45152.6.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1GKGNNC045981 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 20:16:34 -0000 On Sun, 2014-02-16 at 21:06 +0100, Dimitry Andric wrote: > Hi, > > I have just upgraded our copy of llvm/clang to 3.4 release, in r261991. > This version supports all of the features in the current working draft > of the upcoming C++ standard, provisionally named C++1y. > > The code generator's performance is greatly increased, and the loop > auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The > PowerPC backend has made several major improvements to code generation > quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ > backends have all seen major feature work. > > Release notes for llvm and clang can be found here: > > > > Note that building lldb (using WITH_LLDB) will not work at this point, > since our lldb snapshot was locally modified to be able to work with the > old llvm 3.3 API. Ed Maste will most likely fix this very soon (and > maybe import a new snapshot, I hope :-). > > Another important aspect for end-users and ports maintainers is the new > compiler flag handling in clang 3.4. It has become more strict, in the > sense that it will now error out on flags it does not recognize, in > particular most gcc-specific optimization fine-tuning flags. > > Some ports which blindly use such gcc-specific flags will therefore be > broken, but these are usually very easy to fix. During the exp-run > which was done with this new version of clang, several ports with the > highest number of dependent ports (open-motif, libtheora, boost-libs, > etc) have already been handled, but more work still needs to be done. > > Last but not least, I hope we can now start using clang for more of our > existing architectures, like powerpc, mips, and possibly even new ones > like arm64. Enjoy! > Is OpenMP supported in this version? Clang 3.4 from ports barfs: btw> /usr/local/bin/clang34 -fopenmp /tmp/foo.c clang: warning: argument unused during compilation: '-fopenmp' Ditto the installed version of 3.3 under 10: btw> clang -fopenmp /tmp/foo.c clang: warning: argument unused during compilation: '-fopenmp' > -Dimitry > From owner-freebsd-current@FreeBSD.ORG Sun Feb 16 20:38:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E1702A5 for ; Sun, 16 Feb 2014 20:38:24 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18D1A1C70 for ; Sun, 16 Feb 2014 20:38:23 +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 307AF5C45; Sun, 16 Feb 2014 21:38:22 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_FB270B0E-936B-434A-BC0A-F7405FB7914F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 From: Dimitry Andric In-Reply-To: <1392581782.45152.6.camel@btw.pki2.com> Date: Sun, 16 Feb 2014 21:38:07 +0100 Message-Id: <4702D3BA-E020-4787-86E9-2AB13E4562E3@FreeBSD.org> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> <1392581782.45152.6.camel@btw.pki2.com> To: Dennis Glatting X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 16 Feb 2014 20:38:24 -0000 --Apple-Mail=_FB270B0E-936B-434A-BC0A-F7405FB7914F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 16 Feb 2014, at 21:16, Dennis Glatting wrote: > On Sun, 2014-02-16 at 21:06 +0100, Dimitry Andric wrote: >> I have just upgraded our copy of llvm/clang to 3.4 release, in r261991. >> This version supports all of the features in the current working draft >> of the upcoming C++ standard, provisionally named C++1y. ... > Is OpenMP supported in this version? Clang 3.4 from ports barfs: No, this is still being worked on in trunk. Support from Intel was announced last August, here: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031595.html I hope it will be ready to appear in 3.5 release. There is currently an experimental version, based on clang 3.3, published here: http://clang-omp.github.io/ -Dimitry --Apple-Mail=_FB270B0E-936B-434A-BC0A-F7405FB7914F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMBIbYACgkQsF6jCi4glqMTNgCfYgO5K0IGgw3DaYywOyrZiKCT lo8AoIo2P+a+xzk1qfZxCyTekrsTG4Z6 =iocL -----END PGP SIGNATURE----- --Apple-Mail=_FB270B0E-936B-434A-BC0A-F7405FB7914F-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 00:01:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7519E52 for ; Mon, 17 Feb 2014 00:01:19 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DD591B40 for ; Mon, 17 Feb 2014 00:01:19 +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 s1H01JLK088769 for ; Mon, 17 Feb 2014 00:01:19 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1H01JW7088767 for freebsd-current@freebsd.org; Mon, 17 Feb 2014 00:01:19 GMT (envelope-from bdrewery) Received: (qmail 50959 invoked from network); 16 Feb 2014 18:01:16 -0600 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 16 Feb 2014 18:01:16 -0600 Message-ID: <53015149.8020404@FreeBSD.org> Date: Sun, 16 Feb 2014 18:01:13 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: M_FILEDESC leak References: <52FEE944.2050406@FreeBSD.org> <53010507.3080601@FreeBSD.org> In-Reply-To: <53010507.3080601@FreeBSD.org> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v14eSF0emXCBlsrWpueINke6Rexr2BSjL" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 00:01:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v14eSF0emXCBlsrWpueINke6Rexr2BSjL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/16/2014 12:35 PM, Bryan Drewery wrote: > On 2/14/2014 10:12 PM, Bryan Drewery wrote: >> There's some leak of M_FILEDESC. Most head servers I look on have high= >> filedesc usage in vmstat -m. Older (stable/9,8) do not. >> >> vmstat -m|grep filedesc usage on various servers: >> >> r259961 133350 (freefall) >> r261350 829256 (my dev server) >> r261411 67 (pointyhat) >> r263068 288122 (beefy1) >> r260368 1193324 (beefy2) >> >=20 > I have figured this out and am preparing a patch for review/commit. Thi= s > goes back at least to Jan 2013 in head, thus is in 10.0-R as well. >=20 Fixed in r262006. --=20 Regards, Bryan Drewery --v14eSF0emXCBlsrWpueINke6Rexr2BSjL 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/ iQEcBAEBAgAGBQJTAVFJAAoJEDXXcbtuRpfPp5cIAIYXAPiRPyuTS4Pt8HOivM5N KARVteD2m4EnHH9uXwvbT/v/7Yr6MioHrjtjZcXQ4O0lfsgbCOxkJg8bpY97QaRP ZpjFYw3qjMz/Qb/Ka7E9Hm5D59jqFQNQMosRfigE9ltp8b46MIMwzgPbmR5rrXEx VYiW2Do0wuLQf9YMKSA/vpsXKlQYr1MIELHTj8NUKIKgHKL9TOXmCbYuIQhPKjxe N10OlNGWC0Id3UMd6eLJmCMyguQAr/iDDC1zm7kRHCfH8CV+k+cMY0ehy4Can13+ h8hjiVCrfoLop42CAPEDAg6ItqrbVSKpKwl0MUrX9NLyf/YknhXsclZ5dTUFBVQ= =LAJ6 -----END PGP SIGNATURE----- --v14eSF0emXCBlsrWpueINke6Rexr2BSjL-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 01:13:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BCEB5A9; Mon, 17 Feb 2014 01:13:11 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A70C10BB; Mon, 17 Feb 2014 01:13:10 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.8/8.14.8) with ESMTP id s1H1CxnQ072618; Sun, 16 Feb 2014 17:12:59 -0800 (PST) (envelope-from freebsd@penx.com) Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 From: Dennis Glatting To: Dimitry Andric In-Reply-To: <4702D3BA-E020-4787-86E9-2AB13E4562E3@FreeBSD.org> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> <1392581782.45152.6.camel@btw.pki2.com> <4702D3BA-E020-4787-86E9-2AB13E4562E3@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 16 Feb 2014 17:12:59 -0800 Message-ID: <1392599579.45152.9.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1H1CxnQ072618 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 01:13:11 -0000 On Sun, 2014-02-16 at 21:38 +0100, Dimitry Andric wrote: > On 16 Feb 2014, at 21:16, Dennis Glatting wrote: > > On Sun, 2014-02-16 at 21:06 +0100, Dimitry Andric wrote: > >> I have just upgraded our copy of llvm/clang to 3.4 release, in r261991. > >> This version supports all of the features in the current working draft > >> of the upcoming C++ standard, provisionally named C++1y. > ... > > Is OpenMP supported in this version? Clang 3.4 from ports barfs: > > No, this is still being worked on in trunk. Support from Intel was > announced last August, here: > > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031595.html > > I hope it will be ready to appear in 3.5 release. There is currently an > experimental version, based on clang 3.3, published here: > > http://clang-omp.github.io/ > Thanks. I was confused between Phronix, the clang web site content, and trying to compile. > -Dimitry > From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 05:01:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20B5DD63 for ; Mon, 17 Feb 2014 05:01:15 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B979B1436 for ; Mon, 17 Feb 2014 05:01:14 +0000 (UTC) X-AuditID: 12074425-f79906d000000cf9-f4-53019665b879 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 87.42.03321.56691035; Sun, 16 Feb 2014 23:56:05 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s1H4u5Zu010174; Sun, 16 Feb 2014 23:56:05 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1H4u2nt015320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Feb 2014 23:56:04 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1H4u2oa000344; Sun, 16 Feb 2014 23:56:02 -0500 (EST) Date: Sun, 16 Feb 2014 23:56:02 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Ruslan Makhmatkhanov Subject: Re: ssh-keygen -Z In-Reply-To: <53008ECD.2070004@yandex.ru> Message-ID: References: <53008ECD.2070004@yandex.ru> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nops6jTHYoOGDucWbTa9ZLOa8+cDk wOQx49N8Fo/DDf0sAUxRXDYpqTmZZalF+nYJXBntRy6wFLxgrfh8+B9jA+N5li5GTg4JAROJ h7N7mSBsMYkL99azdTFycQgJzGaSmNF/gB3C2cgocerCUWYI5xCTxKbmBqiyBkaJzWf2MoL0 swhoS7w79gPMZhNQk3i8t5kVYq6ixOZTk5hBbBEBHYkXm7vAbGYBQ4nuw4fA6oUFpCS+zLoA dhOngKbErs07wG7iFXCQ2LBjH1CcA2iZhsTDe5IgYVGgMav3T2GBKBGUODnzCQvESEuJc3+u s01gFJqFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXQu93MwSvdSU0k2M4BB2Ud3B OOGQ0iFGAQ5GJR5eg2rGYCHWxLLiytxDjJIcTEqivNkTgEJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeN3jgHK8KYmVValF+TApaQ4WJXHeWotfQUIC6YklqdmpqQWpRTBZGQ4OJQles6lAjYJF qempFWmZOSUIaSYOTpDhPEDD+UFqeIsLEnOLM9Mh8qcYFaXEeaeCJARAEhmleXC9sBTzilEc 6BVh3hCQKh5geoLrfgU0mAlo8KrTf4OABpckIqSkGhgF+ITvnn7i8M9nuwjDWTFJnzyl7stH /23cteCAcM2+d0V9yTL8XfmXb6yZfM1g+qc5rdxHtjPznwoRv/KPa6WQnX6i3+79vBUnlRwO zd11bttvFZ0JAfMWSrxdcs6w7/CPEEvljapTmz/8+31iJ+/s38o3/q7+pFHOMOtCZ7YEb/q5 j6+ndx48ocRSnJFoqMVcVJwIAAdQnEIMAwAA Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 05:01:15 -0000 On Sun, 16 Feb 2014, Ruslan Makhmatkhanov wrote: > Hello, > > there is -Z parameter in ssh-keygen --help output, but no mention of it in > ssh-keygen's man-page. Any clue what values this parameter accept? It is the "new-format ciphername", which can be used for RSA keys if the new format file is being used, and is used for the elliptic curve keys, if I'm reading things correctly. I guess that would mean that it accepts things like "chacha20-poly1305@openssh.com" and "aes256-ctr" (see the table ciphers[] in cipher.c), though I don't know which ones make sense to pass in there. I guess we should ask the OpenBSD folks to document it, the -Z argument was added to ssh-keygen.c in r1.237 back in December. -Ben From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 08:05:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59ABD89B; Mon, 17 Feb 2014 08:05:32 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1447F11A0; Mon, 17 Feb 2014 08:05:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1WFJCe-0047gh-07>; Mon, 17 Feb 2014 09:05:24 +0100 Received: from g225191063.adsl.alicedsl.de ([92.225.191.63] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1WFJCd-000pZ9-Re>; Mon, 17 Feb 2014 09:05:23 +0100 Date: Mon, 17 Feb 2014 09:05:23 +0100 From: "O. Hartmann" To: Dimitry Andric Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 Message-ID: <20140217090523.51cf962e.ohartman@zedat.fu-berlin.de> In-Reply-To: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/4Dy1tgqgvuif8aW0zwHgzCX"; protocol="application/pgp-signature" X-Originating-IP: 92.225.191.63 X-ZEDAT-Hint: A Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 08:05:32 -0000 --Sig_/4Dy1tgqgvuif8aW0zwHgzCX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 16 Feb 2014 21:06:58 +0100 Dimitry Andric wrote: > Hi, >=20 > I have just upgraded our copy of llvm/clang to 3.4 release, in r261991. > This version supports all of the features in the current working draft > of the upcoming C++ standard, provisionally named C++1y. >=20 > The code generator's performance is greatly increased, and the loop > auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The > PowerPC backend has made several major improvements to code generation > quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ > backends have all seen major feature work. >=20 > Release notes for llvm and clang can be found here: > > >=20 > Note that building lldb (using WITH_LLDB) will not work at this point, > since our lldb snapshot was locally modified to be able to work with the > old llvm 3.3 API. Ed Maste will most likely fix this very soon (and > maybe import a new snapshot, I hope :-). >=20 > Another important aspect for end-users and ports maintainers is the new > compiler flag handling in clang 3.4. It has become more strict, in the > sense that it will now error out on flags it does not recognize, in > particular most gcc-specific optimization fine-tuning flags. >=20 > Some ports which blindly use such gcc-specific flags will therefore be > broken, but these are usually very easy to fix. During the exp-run > which was done with this new version of clang, several ports with the > highest number of dependent ports (open-motif, libtheora, boost-libs, > etc) have already been handled, but more work still needs to be done. >=20 > Last but not least, I hope we can now start using clang for more of our > existing architectures, like powerpc, mips, and possibly even new ones > like arm64. Enjoy! >=20 > -Dimitry >=20 Dimitry, I want to say thank you and the Mannschaft for the work you've done.=20 Regards, Oliver --Sig_/4Dy1tgqgvuif8aW0zwHgzCX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTAcLDAAoJEOgBcD7A/5N8cV0H/2pKzgNuMEYa2YmXs4d4xZI4 dgtzcIEi7Nto6CPv9EKFnURIWO0vCvdYfvMz4UVu2i27bNQwJa0TUMhUVoKXb4HK 1JWibiKXatPhS05vyEVxwKL7IPNx+h80BHEr8h7sqgU7mmJ0A9aDYRMrtnpNBoWi GwzulNI+vj3pp3v1G4TXf/8nAzvATHH81/MGcCbI0LO8TYgvr3ox15A5Y2nXzym/ KSYUk1ldOOYof2AIvDp6ou07n740mCxlLp/vLuS1MeWLvl2wPJ99LLZCVSnuczx8 7azzCPNQay2KSU870ye+Y6l0bxCb8pYQCymkCU/rquE2vzuJCSe1TmzwYOdUiKE= =oght -----END PGP SIGNATURE----- --Sig_/4Dy1tgqgvuif8aW0zwHgzCX-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 08:16:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FE19D7A; Mon, 17 Feb 2014 08:16:28 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29EE5124B; Mon, 17 Feb 2014 08:16:27 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1H8GHX6087134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 08:16:19 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 From: David Chisnall In-Reply-To: <4702D3BA-E020-4787-86E9-2AB13E4562E3@FreeBSD.org> Date: Mon, 17 Feb 2014 08:16:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <03306636-8B7F-4601-9B1B-51210A69E7CB@FreeBSD.org> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> <1392581782.45152.6.camel@btw.pki2.com> <4702D3BA-E020-4787-86E9-2AB13E4562E3@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Current , Dennis Glatting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 08:16:28 -0000 On 16 Feb 2014, at 20:38, Dimitry Andric wrote: > I hope it will be ready to appear in 3.5 release. There is currently = an > experimental version, based on clang 3.3, published here: >=20 > http://clang-omp.github.io/ I'd like to see this version in ports so that we could build ports with = an OpenMP-enabled clang if they needed clang, but unfortunately the = Intel OpenMP runtime needs some porting. I spent a while trying to get = it to build, but their build system is a horrible mess of Makefiles and = Perl and I couldn't even get it to try to compile to see what actually = needed changing. I expect that it will be fairly minimal, given that it = supports OS X and Linux already. David From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 10:09:34 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE490B1A; Mon, 17 Feb 2014 10:09:34 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD231BBA; Mon, 17 Feb 2014 10:09:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA27704; Mon, 17 Feb 2014 12:09:30 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WFL8k-000BEh-IY; Mon, 17 Feb 2014 12:09:30 +0200 Message-ID: <5301DF89.5030707@FreeBSD.org> Date: Mon, 17 Feb 2014 12:08:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: FreeBSD Current , Aleksandr Rybalko Subject: vt(9): couple of small issues X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 10:09:34 -0000 I used to have mousechar_start="3" in my r.conf. To be honest I can not even recall why. But this worked fine with syscons without any glitches. With vt I get the following during boot up: vidcontrol: setting mouse character: Inappropriate ioctl for device And mouse cursor is never drawn, apparently vidcontrol -m on -M just fails. Looks like with syscons MOUSE_MOUSECHAR ioctl is handled by a terminal device and consolectl device while with vt it is handled only by sysmouse device. Another issue is that I see the following messages appearing during boot and from time to time afterwards in the system log: kernel: sysmouse: unknown ioctl: t:40007413 kernel: sysmouse: unknown ioctl: t:80007410 The ioctls seem to be TIOCFLUSH and TIOCGETA, so I am not sure why sysmouse gets involved. Maybe the same issue exists with syscons's sysmouse as well, but it is just silent about it. Seems like ioctls are called by X server. For example: sysmouse_ioctl:entry kernel`devfs_ioctl_f+0x11c kernel`kern_ioctl+0x1db kernel`sys_ioctl+0x142 kernel`amd64_syscall+0x3c9 kernel`0xffffffff8080e6db libc.so.7`ioctl+0xa Xorg`xf86OpenSerial+0x221 mouse_drv.so`MouseProc+0x2f3 Xorg`EnableDevice+0x214 Xorg`xf86Wakeup+0x57b Xorg`WakeupHandler+0x42 Xorg`WaitForSomething+0x317 Xorg`Dispatch+0x92 Xorg`main+0x475 Xorg`_start+0x14f sysmouse_ioctl:entry kernel`devfs_ioctl_f+0x11c kernel`kern_ioctl+0x1db kernel`sys_ioctl+0x142 kernel`amd64_syscall+0x3c9 kernel`0xffffffff8080e6db libc.so.7`ioctl+0xa Xorg`xf86FlushInput+0x21 mouse_drv.so`MouseProc+0x376 Xorg`EnableDevice+0x214 Xorg`xf86Wakeup+0x57b Xorg`WakeupHandler+0x42 Xorg`WaitForSomething+0x317 Xorg`Dispatch+0x92 Xorg`main+0x475 Xorg`_start+0x14f ld-elf.so.1`0x8007d5000 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 11:16:45 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDCE6851 for ; Mon, 17 Feb 2014 11:16:45 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E3E213CF for ; Mon, 17 Feb 2014 11:16:44 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s1HBGafL059373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Feb 2014 15:16:36 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s1HBGau4059372 for current@FreeBSD.org; Mon, 17 Feb 2014 15:16:36 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 17 Feb 2014 15:16:35 +0400 From: Gleb Smirnoff To: current@FreeBSD.org Subject: [CFT] new sendfile(2) Message-ID: <20140217111635.GL26785@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 11:16:45 -0000 Hello! At Netflix and Nginx we are experimenting with improving FreeBSD wrt sending large amounts of static data via HTTP. One of the approaches we are experimenting with is new sendfile(2) implementation, that doesn't block on the I/O done from the file descriptor. The problem with classic sendfile(2) is that if the the request length is large enough, and file data is not cached in VM, then sendfile(2) syscall would not return until it fills socket buffer with data. With modern internet socket buffers can be up to 1 Mb, thus time taken by the syscall raises by order of magnitude. All the time, the nginx worker is blocked in syscall and doesn't process data from other clients. The best current practice to mitigate that is known as "sendfile(2) + aio_read(2)". This is special mode of nginx operation on FreeBSD. The sendfile(2) call is issued with SF_NODISKIO flag, that forbids the syscall to perform disk I/O, and send only data that is cached by VM. If sendfile(2) reports that I/O needs to be done (but forbidden), then nginx would do aio_read() of a chunk of the file. The data read is cached by VM, as side affect. Then sendfile() is called again. Now for the new sendfile. The core idea is that sendfile() schedules the I/O, but doesn't wait for it to complete. It returns immediately to the process, and I/O completion is processed in kernel context. Unlike aio(4), no additional threads in kernel are created. The new sendfile is a drop-in replacement for the old one. Applications (like nginx) doesn't need recompile, neither configuration change. The SF_NODISKIO is ignored. At Netflix, we already see improvements with new sendfile(2). We can send more data utilizing same amount of CPU, and we can push closer to 0% idle, without experiencing short lags. However, we have somewhat modified VM subsystem, that behaves optimal for our task, but suboptimal for average FreeBSD system. I'd like someone from community to try the new sendfile(2) at other setup and see how does it serve for you. To be the early tester you need to checkout projects/sendfile branch and build kernel from it. The world from head/ would run fine with it. svn co http://svn.freebsd.org/base/projects/sendfile cd sendfile ... build kernel ... Limitations: - Some subsystems that use socket buffers are not compilable, namely SCTP. - No testing were done on serving files on NFS. - No testing were done on serving files on ZFS. - There is mbuf leak. The leak is very slow. It takes 3 days serving up to 20 Gbit/s to deplete the cluster zone. I'm working on finding the leak. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 11:24:33 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7BFDD98; Mon, 17 Feb 2014 11:24:33 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B64A214E5; Mon, 17 Feb 2014 11:24:33 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1HBOSMo087792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 11:24:31 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [CFT] new sendfile(2) From: David Chisnall In-Reply-To: <20140217111635.GL26785@glebius.int.ru> Date: Mon, 17 Feb 2014 11:24:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140217111635.GL26785@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1827) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 11:24:34 -0000 On 17 Feb 2014, at 11:16, Gleb Smirnoff wrote: > Now for the new sendfile. The core idea is that sendfile() > schedules the I/O, but doesn't wait for it to complete. It > returns immediately to the process, and I/O completion is > processed in kernel context. Unlike aio(4), no additional > threads in kernel are created. The new sendfile is a drop-in > replacement for the old one. Applications (like nginx) doesn't > need recompile, neither configuration change. The SF_NODISKIO is > ignored. Doesn't this introduce a race? If I do a sendfile now, then I am at = liberty to modify the underlying file as soon as it returns. With this = version, I not only am not free to modify the file, I have no = notification that it is finished so I can't ever safely use this call on = a file that I might eventually modify. Wouldn't it be better to provide an aio_sendfile() that would deliver = completion notifications via the normal aio mechanism? =20 David P.S. If aio() is creating a new thread per request, rather than = scheduling them from a pool, then that is also likely a bug. The aio = APIs were designed so that systems with DMA controllers could issue DMA = requests in the syscall and return immediately, then trigger the = notification in response to the DMA-finished interrupt. There shouldn't = need to be any kernel threads created to do this...= From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 11:32:55 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9041456F; Mon, 17 Feb 2014 11:32:55 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16A7115F7; Mon, 17 Feb 2014 11:32:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s1HBWrMB059506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Feb 2014 15:32:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s1HBWrNN059505; Mon, 17 Feb 2014 15:32:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 17 Feb 2014 15:32:53 +0400 From: Gleb Smirnoff To: David Chisnall Subject: Re: [CFT] new sendfile(2) Message-ID: <20140217113253.GM26785@glebius.int.ru> References: <20140217111635.GL26785@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 11:32:55 -0000 On Mon, Feb 17, 2014 at 11:24:21AM +0000, David Chisnall wrote: D> > Now for the new sendfile. The core idea is that sendfile() D> > schedules the I/O, but doesn't wait for it to complete. It D> > returns immediately to the process, and I/O completion is D> > processed in kernel context. Unlike aio(4), no additional D> > threads in kernel are created. The new sendfile is a drop-in D> > replacement for the old one. Applications (like nginx) doesn't D> > need recompile, neither configuration change. The SF_NODISKIO is D> > ignored. D> D> Doesn't this introduce a race? If I do a sendfile now, then I am at liberty to modify the underlying file as soon as it returns. With this version, I not only am not free to modify the file, I have no notification that it is finished so I can't ever safely use this call on a file that I might eventually modify. D> D> Wouldn't it be better to provide an aio_sendfile() that would deliver completion notifications via the normal aio mechanism? This race actually exists with the classical sendfile and existed ever since. While pages are in socket buffer, and not yet sent out wire, any modification to them would affect data sent. To know when you can modify data you need to use SF_SYNC flag. The flag should work with new sendfile as well, effectively making it blocking on socket. I haven't tested this, but should work. Adrian have also committed the kqueue notification of SF_SYNC event. This should work in combination with new sendfile, but that hasn't been tested yet. This is going to be tested soon, since we need this functionality. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 13:07:59 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99A0E562; Mon, 17 Feb 2014 13:07:59 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 320C91E25; Mon, 17 Feb 2014 13:07:59 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id i8so23396189qcq.22 for ; Mon, 17 Feb 2014 05:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=jkEKxMsz1JDaKEBV0I+VwQWk3eZMeyl1dYoT9Tdu4YU=; b=Gws4HnpyteVhycdKk1ZVowa04jLT4Cnrcf/yXkfMx5wkOBSWrveCMcs2lfQ3AR8+Wg h/S5WdAcw0rlGAG1oFHy31m0FA/u5z/RdRS9qpIZIdKjJ4JCJy7SY/+L62Ot8xVv4Mqe rDnjHGJfzXNC0tTvF3HOmcMfOYrUCuO02aDxzuElY7WMogHwJ239sw6st8/JmabvC0yH tFVdh9ZD2w1UvzhkP0GF1n6LH2A4OQa1u/HDgBuQ72ebhzxXYqsrKhCyxLQeBxe8aJ26 SxuCDLroAid1TWoKP2duHvtUS8O2nhoZwFh20jIQPgYAQS+GG9h8Q5PMpFEWSxxThfTw KFkw== MIME-Version: 1.0 X-Received: by 10.224.16.72 with SMTP id n8mr2296563qaa.76.1392642478420; Mon, 17 Feb 2014 05:07:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Mon, 17 Feb 2014 05:07:58 -0800 (PST) In-Reply-To: <20140217113253.GM26785@glebius.int.ru> References: <20140217111635.GL26785@glebius.int.ru> <20140217113253.GM26785@glebius.int.ru> Date: Mon, 17 Feb 2014 05:07:58 -0800 X-Google-Sender-Auth: jQFXHYxv-oXS1Zec9tnh3fS_1uc Message-ID: Subject: Re: [CFT] new sendfile(2) From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Chisnall , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 13:07:59 -0000 On 17 February 2014 03:32, Gleb Smirnoff wrote: > On Mon, Feb 17, 2014 at 11:24:21AM +0000, David Chisnall wrote: > D> > Now for the new sendfile. The core idea is that sendfile() > D> > schedules the I/O, but doesn't wait for it to complete. It > D> > returns immediately to the process, and I/O completion is > D> > processed in kernel context. Unlike aio(4), no additional > D> > threads in kernel are created. The new sendfile is a drop-in > D> > replacement for the old one. Applications (like nginx) doesn't > D> > need recompile, neither configuration change. The SF_NODISKIO is > D> > ignored. > D> > D> Doesn't this introduce a race? If I do a sendfile now, then I am at l= iberty to modify the underlying file as soon as it returns. With this versi= on, I not only am not free to modify the file, I have no notification that = it is finished so I can't ever safely use this call on a file that I might = eventually modify. > D> > D> Wouldn't it be better to provide an aio_sendfile() that would deliver = completion notifications via the normal aio mechanism? > > This race actually exists with the classical sendfile and existed > ever since. While pages are in socket buffer, and not yet sent > out wire, any modification to them would affect data sent. > > To know when you can modify data you need to use SF_SYNC flag. > The flag should work with new sendfile as well, effectively > making it blocking on socket. I haven't tested this, but > should work. > > Adrian have also committed the kqueue notification of SF_SYNC > event. This should work in combination with new sendfile, but > that hasn't been tested yet. This is going to be tested soon, > since we need this functionality. Yup, that's exactly why I committed the sendfile kqueue completion notification stuff. It's main caveat is that it requires that the ethernet driver immediately free the mbuf upon TX completion - which the chelsio driver doesn't yet do. That has to be fixed for the notification completion stuff to behave well under lower traffic loads. -a From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 16:01:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E0C9454; Mon, 17 Feb 2014 16:01:48 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E316111EA; Mon, 17 Feb 2014 16:01:45 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208";a="101466418" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 17 Feb 2014 16:01:38 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Mon, 17 Feb 2014 11:01:37 -0500 Message-ID: <53023260.1070109@citrix.com> Date: Mon, 17 Feb 2014 17:01:36 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John Baldwin , Andrew Cooper Subject: Re: [Xen-devel] [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> <1980951.95r2q2cca3@ralph.baldwin.cx> <52FD7624.90202@citrix.com> <201402141251.10278.jhb@freebsd.org> In-Reply-To: <201402141251.10278.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, xen-devel@lists.xenproject.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 16:01:48 -0000 On 14/02/14 18:51, John Baldwin wrote: > On Thursday, February 13, 2014 8:49:24 pm Andrew Cooper wrote: >> On 08/02/2014 21:42, John Baldwin wrote: >>> On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote: >>>> Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can >>>> force the usage of the Xen mptable enumerator even when ACPI is >>>> detected. >>> Hmm, so I think one question is why does the existing MADT parser >>> not work with the MADT table provided by Xen? This may very well >>> be correct, but if it's only a small change to make the existing >>> MADT parser work with Xen's MADT table, that route might be >>> preferable. >>> >> >> For dom0, the MADT seen is the system MADT, which does not bear any >> reality to dom0's topology. For PV domU, no MADT will be found. For >> HVM domU, the MADT seen ought to represent (virtual) reality. > > Hmm, the other changes suggested that you do want to use the I/O APIC > entries and interrupt overrides from the system MADT for dom0? Just > not the CPU entries. Is that correct? Yes, we need the interrupt entries in order to interact with the underlying hardware, but not the CPU entries/topology. Roger. From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 16:41:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAF36FE5 for ; Mon, 17 Feb 2014 16:41:38 +0000 (UTC) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CCCD15F1 for ; Mon, 17 Feb 2014 16:41:38 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id n15so11290280lbi.39 for ; Mon, 17 Feb 2014 08:41:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:subject:from:date:to:cc :message-id; bh=nlNlwVltYMWtBYaX4JCo0SZ98Q6R3bDoAQHDA5vZgy0=; b=GO8Pzf5IDQpXtE7jvL3Pvt+uTUtnwKCzievoeMKdBt2i4zwQR/CMLRECtVSnNZIpKO 6yKNIWHisWuTbgSIhIMG5+UElNxHohEsc9qnsjQGSw0XkrqI34uTThmvOWXAltA1ovc7 jqh+FHeTBIB8NOqQ3srIxgCUceR+Ccl7aXml63WNNAScRhqYwvby3jmr3hzPynvYQjKO m/qMlr5vbJnlwd9ug48gJHvzFyCNlL+8UnXKE0OaGKeUs76JBcXoFmlb9miPohZE+6CM BbPqn61i1UZlGFjk8FoEdjcgp8Ks8K6AwvSHe92SGTtV4fepgGGgfmCUM3pBW7AFeMqB QENA== X-Gm-Message-State: ALoCoQmoAYOGuxvNxRZHte8SobATNYSTANsQXEnc+klO7Hfaz6IZkJQ1gCyOpChrUHIO77qzasHF X-Received: by 10.112.164.5 with SMTP id ym5mr2220178lbb.48.1392655290106; Mon, 17 Feb 2014 08:41:30 -0800 (PST) Received: from [88.154.170.47] ([88.154.170.47]) by mx.google.com with ESMTPSA id g8sm26610987lae.1.2014.02.17.08.41.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 17 Feb 2014 08:41:28 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <5301DF89.5030707@FreeBSD.org> References: <5301DF89.5030707@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: vt(9): couple of small issues From: Aleksandr Rybalko Date: Mon, 17 Feb 2014 18:41:13 +0200 To: Andriy Gapon , FreeBSD Current , Aleksandr Rybalko Message-ID: <78196899-7922-4fd0-937c-7b4a69714dbc@email.android.com> Cc: freebsd-x11@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 16:41:39 -0000 On 17 лютого 2014 р. 12:08:09 GMT+02:00, Andriy Gapon wrote: > >I used to have mousechar_start="3" in my r.conf. To be honest I can >not even >recall why. But this worked fine with syscons without any glitches. >With vt I get the following during boot up: >vidcontrol: setting mouse character: Inappropriate ioctl for device >And mouse cursor is never drawn, apparently vidcontrol -m on -M >just fails. > >Looks like with syscons MOUSE_MOUSECHAR ioctl is handled by a terminal >device >and consolectl device while with vt it is handled only by sysmouse >device. > > >Another issue is that I see the following messages appearing during >boot and >from time to time afterwards in the system log: >kernel: sysmouse: unknown ioctl: t:40007413 >kernel: sysmouse: unknown ioctl: t:80007410 > >The ioctls seem to be TIOCFLUSH and TIOCGETA, so I am not sure why >sysmouse gets >involved. Maybe the same issue exists with syscons's sysmouse as well, >but it >is just silent about it. > >Seems like ioctls are called by X server. For example: >sysmouse_ioctl:entry > kernel`devfs_ioctl_f+0x11c > kernel`kern_ioctl+0x1db > kernel`sys_ioctl+0x142 > kernel`amd64_syscall+0x3c9 > kernel`0xffffffff8080e6db > > libc.so.7`ioctl+0xa > Xorg`xf86OpenSerial+0x221 > mouse_drv.so`MouseProc+0x2f3 > Xorg`EnableDevice+0x214 > Xorg`xf86Wakeup+0x57b > Xorg`WakeupHandler+0x42 > Xorg`WaitForSomething+0x317 > Xorg`Dispatch+0x92 > Xorg`main+0x475 > Xorg`_start+0x14f > >sysmouse_ioctl:entry > kernel`devfs_ioctl_f+0x11c > kernel`kern_ioctl+0x1db > kernel`sys_ioctl+0x142 > kernel`amd64_syscall+0x3c9 > kernel`0xffffffff8080e6db > > libc.so.7`ioctl+0xa > Xorg`xf86FlushInput+0x21 > mouse_drv.so`MouseProc+0x376 > Xorg`EnableDevice+0x214 > Xorg`xf86Wakeup+0x57b > Xorg`WakeupHandler+0x42 > Xorg`WaitForSomething+0x317 > Xorg`Dispatch+0x92 > Xorg`main+0x475 > Xorg`_start+0x14f > ld-elf.so.1`0x8007d5000 Hello Andriy! I remember we were discussed that problem before, can you please check if moused enabled (in rc.conf or by devd for USB mouse) and do you use Kern.vt.textmode (IIRC its name)? Mousecharstart is a first char of 4 to replace its bitmap with parts of mouse pointer. You can see its job by defining it to some of frequently used chars, then mouse pointer will be moved over many chars on the screen :-) About second question - there is no problem to just remove that warning, but think better to left it to make an idea for developers about what term ioctls doing with sysmuse devfs node. Thanks for testing! WBW ------ Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 17:21:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8DEC98F for ; Mon, 17 Feb 2014 17:21:34 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 806281985 for ; Mon, 17 Feb 2014 17:21:34 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id lh14so11798132vcb.24 for ; Mon, 17 Feb 2014 09:21:33 -0800 (PST) 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=MR+j5qlBW+2pqvV2EXz7ovc0RJjrrMF2efWjDF4wtYc=; b=KwN1qxmCI6AOvACySEN0mPFDBK07hCOfZ5mO5uN7DL5N8SmFz42R2qUXlP424pEh5R VJk/uGGcIfb5EkQ4mA2yF0wGEIncMAo2KAdf2NamTPhxDk/o6a3zXlRJjwAieOuU54qk hy9stbArxJXRavXBYOw6a1aeyeyEc7VIT8/NmBRU8b9ltIU+0hHMw13489Sl0nDcEpm8 A9XQtqWoUMYWZVBWxc2S+7VyIdCJ+4QnGSYp3ROmh3AGfGmbbqH0jJ0G2bSpvDlrWtnb Yc2FS2V1fUlfUOfDfsjNzZbi9pHEWqZtROldreaqJL4PlfCNCNybNxKcOW8Qaw0dc2g/ olUw== MIME-Version: 1.0 X-Received: by 10.52.27.132 with SMTP id t4mr5286444vdg.11.1392657693509; Mon, 17 Feb 2014 09:21:33 -0800 (PST) Received: by 10.220.11.130 with HTTP; Mon, 17 Feb 2014 09:21:33 -0800 (PST) In-Reply-To: <52FD297E.6040502@allanjude.com> References: <52FD297E.6040502@allanjude.com> Date: Mon, 17 Feb 2014 11:21:33 -0600 Message-ID: Subject: Re: ezjails, systat -ifstat, and multiple network cards From: Preston Hagar To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 17:21:34 -0000 On Thu, Feb 13, 2014 at 2:22 PM, Allan Jude wrote: > On 2014-02-13 13:59, Preston Hagar wrote: > > I have a server setup with FreeBSD-10.0-RELEASE. It has 3 Intel gigabit > > network cards in it, em0, em1, and em2. I have multiple ezjails setup > that > > run various things. > > > > One jail, called db, runs a postgresql database. It was my intention to > > give it em0 all to itself. The other jails and host machine should be > > going through em2. em1 currently isn't being used. > > > > If I do an ifconfig, I see that em0 has the alias IP for my db jail and > em2 > > has the alias IP for all other jails. All the jails respond to network > > traffic as expected and seemingly work fine. > > > > The weird thing is when I do a systat -ifstat from the host, it should > > essentially all traffic going through em0. Some of the jails that run > off > > of em2 (as defined in their jail config files and seen in ifconfig) have > > large data transfers and/or are web servers with lots of photos. I have > > even tried to manually scp a large file out of a jail setup through em2 > and > > the numbers don't seem to budge. > > > > If I do netstat -i -b -n -I and check em0 and em2, it seems to support > the > > numbers shown by systat -ifstat. However, if I use trafshow or iftop > (both > > of which require choosing one interface at a time), they both seem to > > indicate the traffic flowing through the interfaces as I would expect. > > > > So I was curious if anyone had seen something like this before or had any > > ideas of what is going on. I have net.fibs=2 set in /boot/loader.conf, > but > > in all the jails I current have jail_name_fib="" as I haven't got around > to > > fullying setting up fibs. Is that perhaps the issue? Is there any way > to > > determine with certainty which jail is using which interface short of > > physically pulling a network cable and seeing what stops working? > > > > Here are the relevant lines from my db (the one that should be on em0) > > config: > > > > export jail_db_hostname="db" > > export jail_db_ip="em0|10.1.10.2" > > > > From another jail on em2 called www: > > > > export jail_www_hostname="www" > > export jail_www_ip="em2|10.1.10.7" > > > > from ifconfig > > > > em0: flags=8843 metric 0 mtu 1500 > > > options=4219b > > ether 08:60:6e:13:94:06 > > inet 10.1.1.4 netmask 0xffff0000 broadcast 10.1.255.255 > > inet6 fe80::a60:6eff:fe13:9406%em0 prefixlen 64 scopeid 0x1 > > inet 10.1.10.2 netmask 0xffffffff broadcast 10.1.10.2 > > nd6 options=29 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > em2: flags=8843 metric 0 mtu 1500 > > > options=4219b > > ether 68:05:ca:13:74:2a > > inet 10.1.1.2 netmask 0xffff0000 broadcast 10.1.255.255 > > inet6 fe80::6a05:caff:fe13:742a%em2 prefixlen 64 scopeid 0x3 > > inet 10.1.10.3 netmask 0xffffffff broadcast 10.1.10.3 > > inet 10.1.10.1 netmask 0xffffffff broadcast 10.1.10.1 > > inet 10.1.10.8 netmask 0xffffffff broadcast 10.1.10.8 > > inet 10.1.10.10 netmask 0xffffffff broadcast 10.1.10.10 > > inet 10.1.10.4 netmask 0xffffffff broadcast 10.1.10.4 > > inet 10.1.10.9 netmask 0xffffffff broadcast 10.1.10.9 > > inet 10.1.10.7 netmask 0xffffffff broadcast 10.1.10.7 > > nd6 options=29 > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > > > Let me know if any more detail would be helpful or if you have any ideas > of > > things to check. > > > > Thanks, > > > > Preston > > _______________________________________________ > > 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" > > > > All traffic going out from the jails will using the routing table from > the host system. The routing table will use the network card that is in > the same subnet as your default gateway to route the traffic to the > internet. > > In your case, I would imagine this is 10.1.1.4/16 (and 10.1.1.2/16). > > 'netstat -rn' will tell the tale, but I imagine it is whichever was > added first. > > If you want to have separate routing tables per jail, you'd have to > either use FIBs, and set the jails to use the different FIBs, or use > VNET jails and have a routing table in each jail. > > -- > Allan Jude > > Makes sense, thank you. I'll setup the FIBs. Preston From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 22:23:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 567E77BE; Mon, 17 Feb 2014 22:23:45 +0000 (UTC) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 0F10017E2; Mon, 17 Feb 2014 22:23:44 +0000 (UTC) Received: from rnote.ddteam.net (131-4-133-95.pool.ukrtel.net [95.133.4.131]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id AEED6C4936; Tue, 18 Feb 2014 00:23:36 +0200 (EET) Date: Tue, 18 Feb 2014 00:23:26 +0200 From: Aleksandr Rybalko To: Lev Serebryakov Subject: Re: vt(9) r261654 with preloaded i915kms -- hangs 9 times out of 10 on boot Message-Id: <20140218002326.39045f60.ray@freebsd.org> In-Reply-To: <1994922749.20140215195633@serebryakov.spb.ru> References: <1994922749.20140215195633@serebryakov.spb.ru> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-x11@FreeBSD.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 22:23:45 -0000 On Sat, 15 Feb 2014 19:56:33 +0400 Lev Serebryakov wrote: > Hello, Freebsd-x11. > > $subj. Loading modules via X.org works. > > It is not Lenovo X, it is old Sony Vaio (VGN-SZ340P) and video is > i945GM... > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" Hi Lev, can you please test same setup but w/o vt(9). I understand you will not see kernel output, but Xorg should show up if problem related to vt(9). Or at least you can do ping test. But way with connected serial cable is best :) Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 22:32:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96353DCD for ; Mon, 17 Feb 2014 22:32:57 +0000 (UTC) Received: from btw.pki2.com (btw.pki2.com [IPv6:2001:470:a:6fd::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B9BD190C for ; Mon, 17 Feb 2014 22:32:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by btw.pki2.com (8.14.8/8.14.8) with ESMTP id s1HMWiD1089892 for ; Mon, 17 Feb 2014 14:32:45 -0800 (PST) (envelope-from freebsd@penx.com) Subject: LOR r262009 From: Dennis Glatting To: freebsd-current@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Feb 2014 14:32:44 -0800 Message-ID: <1392676364.45152.12.camel@btw.pki2.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-SoftwareMunitions-MailScanner-Information: Dennis Glatting X-SoftwareMunitions-MailScanner-ID: s1HMWiD1089892 X-SoftwareMunitions-MailScanner: Found to be clean X-MailScanner-From: freebsd@penx.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 17 Feb 2014 22:32:57 -0000 Decided to try clang 3.4 under CURRENT and got a LOR under ESXi: Feb 17 14:13:10 Head kernel: lock order reversal: Feb 17 14:13:10 Head kernel: 1st 0xfffffe00f6868548 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3081 Feb 17 14:13:10 Head kernel: 2nd 0xfffff800035d3c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 Feb 17 14:13:10 Head kernel: KDB: stack backtrace: Feb 17 14:13:10 Head kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f67ea2d0 Feb 17 14:13:10 Head kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00f67ea380 Feb 17 14:13:10 Head kernel: witness_checkorder() at witness_checkorder +0xdc2/frame 0xfffffe00f67ea410 Feb 17 14:13:10 Head kernel: _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe00f67ea450 Feb 17 14:13:10 Head kernel: ufsdirhash_add() at ufsdirhash_add +0x3a/frame 0xfffffe00f67ea490 Feb 17 14:13:10 Head kernel: ufs_direnter() at ufs_direnter+0x5e8/frame 0xfffffe00f67ea550 Feb 17 14:13:10 Head kernel: ufs_mkdir() at ufs_mkdir+0x89c/frame 0xfffffe00f67ea740 Feb 17 14:13:10 Head kernel: VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf7/frame 0xfffffe00f67ea770 Feb 17 14:13:10 Head kernel: kern_mkdirat() at kern_mkdirat+0x209/frame 0xfffffe00f67ea9a0 Feb 17 14:13:10 Head kernel: amd64_syscall() at amd64_syscall +0x25a/frame 0xfffffe00f67eaab0 Feb 17 14:13:10 Head kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00f67eaab0 Feb 17 14:13:10 Head kernel: --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x801d3220a, rsp = 0x7fffffffce08, rbp = 0x7fffffffce20 --- root@Head:/usr/share/sendmail/cf # uname -a FreeBSD Head 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r262009: Mon Feb 17 12:53:11 PST 2014 root@Head:/usr/obj/usr/src/sys/GENERIC amd64 Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r262009: Mon Feb 17 12:53:11 PST 2014 root@Head:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD FX(tm)-8150 Eight-Core Processor (3616.16-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x600f12 Family=0x15 Model=0x1 Stepping=2 Features=0x1783fbff Features2=0x9e982203 AMD Features=0x2a500800 AMD Features2=0x10be9 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4100911104 (3910 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 4 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x10c0-0x10cf at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 7.3 (no driver attached) pci0: at device 7.7 (no driver attached) vgapci0: port 0x10d0-0x10df mem 0xd8000000-0xdbffffff,0xd0800000-0xd0ffffff irq 16 at device 15.0 on pci0 vgapci0: Boot video device pcib2: at device 17.0 on pci0 pci2: on pcib2 pcib3: at device 21.0 on pci0 pci3: on pcib3 mpt0: port 0x4000-0x40ff mem 0xd2410000-0xd2413fff,0xd2400000-0xd240ffff irq 18 at device 0.0 on pci3 mpt0: MPI Version=1.5.0.0 pcib4: at device 21.1 on pci0 pci4: on pcib4 pcib5: at device 21.2 on pci0 pci5: on pcib5 pcib6: at device 21.3 on pci0 pci6: on pcib6 pcib7: at device 21.4 on pci0 pci7: on pcib7 pcib8: at device 21.5 on pci0 pci8: on pcib8 pcib9: at device 21.6 on pci0 pci9: on pcib9 pcib10: at device 21.7 on pci0 pci10: on pcib10 pcib11: at device 22.0 on pci0 pci11: on pcib11 vmx0: port 0x5000-0x500f mem 0xd2504000-0xd2504fff,0xd2503000-0xd2503fff,0xd2500000-0xd2501fff irq 19 at device 0.0 on pci11 vmx0: Ethernet address: 00:0c:29:b1:e6:22 pcib12: at device 22.1 on pci0 pci12: on pcib12 pcib13: at device 22.2 on pci0 pci13: on pcib13 pcib14: at device 22.3 on pci0 pci14: on pcib14 pcib15: at device 22.4 on pci0 pci15: on pcib15 pcib16: at device 22.5 on pci0 pci16: on pcib16 pcib17: at device 22.6 on pci0 pci17: on pcib17 pcib18: at device 22.7 on pci0 pci18: on pcib18 pcib19: at device 23.0 on pci0 pci19: on pcib19 pcib20: at device 23.1 on pci0 pci20: on pcib20 pcib21: at device 23.2 on pci0 pci21: on pcib21 pcib22: at device 23.3 on pci0 pci22: on pcib22 pcib23: at device 23.4 on pci0 pci23: on pcib23 pcib24: at device 23.5 on pci0 pci24: on pcib24 pcib25: at device 23.6 on pci0 pci25: on pcib25 pcib26: at device 23.7 on pci0 pci26: on pcib26 pcib27: at device 24.0 on pci0 pci27: on pcib27 pcib28: at device 24.1 on pci0 pci28: on pcib28 pcib29: at device 24.2 on pci0 pci29: on pcib29 pcib30: at device 24.3 on pci0 pci30: on pcib30 pcib31: at device 24.4 on pci0 pci31: on pcib31 pcib32: at device 24.5 on pci0 pci32: on pcib32 pcib33: at device 24.6 on pci0 pci33: on pcib33 pcib34: at device 24.7 on pci0 pci34: on pcib34 acpi_acad0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xc0000-0xc7fff,0xca000-0xcafff,0xdc000-0xdffff,0xe0000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 Timecounters tick every 10.000 msec random: unblocking device. da0 at mpt0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 16384MB (33554432 512 byte sectors: 255H 63S/T 2088C) da1 at mpt0 bus 0 scbus2 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 8192MB (16777216 512 byte sectors: 255H 63S/T 1044C) cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number 10000000000000000001 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Netvsc initializing... done! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0p2 [rw]... lock order reversal: 1st 0xfffffe00f6868548 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3081 2nd 0xfffff800035d3c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f67ea2d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00f67ea380 witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe00f67ea410 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe00f67ea450 ufsdirhash_add() at ufsdirhash_add+0x3a/frame 0xfffffe00f67ea490 ufs_direnter() at ufs_direnter+0x5e8/frame 0xfffffe00f67ea550 ufs_mkdir() at ufs_mkdir+0x89c/frame 0xfffffe00f67ea740 VOP_MKDIR_APV() at VOP_MKDIR_APV+0xf7/frame 0xfffffe00f67ea770 kern_mkdirat() at kern_mkdirat+0x209/frame 0xfffffe00f67ea9a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe00f67eaab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00f67eaab0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip = 0x801d3220a, rsp = 0x7fffffffce08, rbp = 0x7fffffffce20 --- From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 01:28:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7E2720F for ; Tue, 18 Feb 2014 01:28:28 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B9A716A9 for ; Tue, 18 Feb 2014 01:28:28 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id hr13so11970664lab.29 for ; Mon, 17 Feb 2014 17:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6H0I114bNvlKw7zK/TUrIpbe0fp+znCglw12KhFTXvE=; b=F1NWwYLPGL8hEx3dJgyXuUXTcO3ofQtsIVGmZDpdzwdJNo+i5OxPaPVnxHFBdbW7cs KC1ctjETJ7Tuo1LPnIWHB/ZkRct1lxOjFbxpq9H8Xjo8YGtQ0PTbfldJVe8LHb4R0DHN ZuUyeIYqdsHsgYBi34JcVkgBwW21RBVX5tKSKEl9NZCo/JCweGbjiSQMX8fH6tmCg6GV 7ct88jB2fBTjT/v6lGqKv5GNToYWPoKjzgLtjXgIFr412RycqzX66xr6so3P8G+59Tu5 9AXTuILTtNsMYx9suuTwGiQ4hnV7Y/PKq70ROzSa1PRgSKJWF8K599FJTzJydUzn53vh YlMQ== MIME-Version: 1.0 X-Received: by 10.112.132.131 with SMTP id ou3mr18566144lbb.29.1392686906325; Mon, 17 Feb 2014 17:28:26 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.30.211 with HTTP; Mon, 17 Feb 2014 17:28:26 -0800 (PST) In-Reply-To: References: <20130812.124834.1287983109881683567.shigeru@iij.ad.jp> <20130813.125709.1168850046133874829.shigeru@iij.ad.jp> Date: Mon, 17 Feb 2014 17:28:26 -0800 X-Google-Sender-Auth: LE8ubSvlYjlD77WVm5N6ZPTaRQQ Message-ID: Subject: Re: quick hack to support "option VIMAGE" on USB Ethernet From: Craig Rodrigues To: hiroo.ono+freebsd@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 01:28:28 -0000 On Sun, Feb 16, 2014 at 2:20 AM, Hiroo Ono (=E5=B0=8F=E9=87=8E=E5=AF=9B=E7= =94=9F) < hiroo.ono+freebsd@gmail.com> wrote: > Hello, > > The problem of USB ethernet device with VIMAGE kernel still remains > with 10.0-RELEASE and I think I have found the reason and a fix. > > I have filed a patch and backtrace as a followup to the PR > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/183835 > > I will repeat the explanation here. > The problem occur when ue_attach_post_task() (in > sys/dev/usb/net/usb_ethernet.c) is called. > > ue_attach_post_task() calls if_alloc() (in sys/net/if.c) > and ether_attach() (in sys/net/if_ethersubr.c), which finally refer > V_if_index. > > The problem is that curvnet is NULL when ue_attach_post_task() > is invoked, and with VIMAGE, V_if_index is defined to > VNET(if_index) =3D> VNET_VNET(curvnet, if_index) > =3D> (*VNET_VNET_PTR((curvnet), if_index)) > =3D> (*_VNET_PTR((curvnet)->vnet_data_base, > if_index)) > and so on. > > For device attach, the following code in device_probe_and_attach() > (in kern/subr_bus.c) > > CURVNET_SET_QUIET(vnet0); > error =3D device_attach(dev); > CURVNET_RESTORE(); > > should assign curvnet to vnet0, but it is not the case for ue device. > > As an example of USB ethernet device, with if_axe, device_attach(dev) > is axe_attach() (in sys/dev/usb/net/if_axe.c). > axe_attach() calls uether_ifattach() (in sys/dev/usb/net/usb_ethernet.c) > (other USB ethernet devices' *_attach() also call this function), > which *queues* (not calls) ue_attach_post_task(). > As ue_attach_post_task is called from usb_process (not from > uther_ifattach), > it is not assured that curvnet is properly assigned. > Well done! Your analysis of the problem was very good! I committed the patch, and will MFC in about a week. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 05:27:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95AD74A3 for ; Tue, 18 Feb 2014 05:27:29 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22BCB1CC7 for ; Tue, 18 Feb 2014 05:27:28 +0000 (UTC) X-AuditID: 12074425-f79906d000000cf9-3e-5302ef39ee3d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.84.03321.93FE2035; Tue, 18 Feb 2014 00:27:21 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s1I5RKbM025729; Tue, 18 Feb 2014 00:27:21 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1I5RIaV009757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Feb 2014 00:27:19 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1I5RIHS018182; Tue, 18 Feb 2014 00:27:18 -0500 (EST) Date: Tue, 18 Feb 2014 00:27:18 -0500 (EST) From: Benjamin Kaduk To: Dennis Glatting Subject: Re: LOR r262009 In-Reply-To: <1392676364.45152.12.camel@btw.pki2.com> Message-ID: References: <1392676364.45152.12.camel@btw.pki2.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrWv5ninY4NJzGYs5bz4wWXzb9IfV gcljxqf5LB4Tdm1mCmCK4rJJSc3JLEst0rdL4MqY/+4ac0ELS8XSKSdZGhhXM3cxcnJICJhI fF+2gxXCFpO4cG89WxcjF4eQwGwmiS0be1kgnI2MEuenr4bKHGKS6GjtZYVwGhglNr3vYAHp ZxHQluj5Oh9sLpuAisTMNxvZQGwRATWJ+5M2g9nMAvIS/69cZgKxhQUkJFb9vgzWyylgKrHn bhtYnFfAQeLW4tdgNwkB3bekZQVYXFRAR2L1/iksEDWCEidnPmGBmGkpce7PdbYJjIKzkKRm IUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERSs7C6qOxgnHFI6xCjA wajEw/tDiylYiDWxrLgy9xCjJAeTkihv0iugEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeO/eB crwpiZVVqUX5MClpDhYlcd5ai19BQgLpiSWp2ampBalFMFkZDg4lCV7Vd0CNgkWp6akVaZk5 JQhpJg5OkOE8QMNtQGp4iwsSc4sz0yHypxgVpcR5Xd4CJQRAEhmleXC9sGTyilEc6BVhXmeQ dh5gIoLrfgU0mAlosNdeRpDBJYkIKakGxuSQw/+Z4nUalycq8aqIGEyYMet9cf8Fe5X0Aw7N 71eoyDOy35DPvVPAyjzbT/hq+9fbL2rYm8zWmHsVf/Kp6+BXrPea+9PE/+W+pZbvlVzLTwvM Yaz6sCxT5t8R/37eSZs+XH/4a7WivmCe0Hu3SV5SS3bM2hfX9XPiztBf/icUXDzjpq2rVGIp zkg01GIuKk4EABEvzaUBAwAA Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 05:27:29 -0000 On Mon, 17 Feb 2014, Dennis Glatting wrote: > Decided to try clang 3.4 under CURRENT and got a LOR under ESXi: > > > Feb 17 14:13:10 Head kernel: lock order reversal: > Feb 17 14:13:10 Head kernel: 1st 0xfffffe00f6868548 bufwait (bufwait) > @ /usr/src/sys/kern/vfs_bio.c:3081 > Feb 17 14:13:10 Head kernel: 2nd 0xfffff800035d3c00 dirhash (dirhash) > @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 That looks like a well-known false positive, http://sources.zabbadoz.net/freebsd/lor.html numbr 261. -Ben From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 07:29:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCF3779E; Tue, 18 Feb 2014 07:29:22 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29E7015F5; Tue, 18 Feb 2014 07:29:21 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s1I7SLFO087426; Tue, 18 Feb 2014 07:28:21 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s1I7SLBK087425; Tue, 18 Feb 2014 07:28:21 GMT (envelope-from wkoszek) Date: Tue, 18 Feb 2014 07:28:21 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: BSD XXI Manifesto Message-ID: <20140218072821.GF34282@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 18 Feb 2014 07:28:25 +0000 (UTC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 07:29:23 -0000 (cross-posted message: eventual discussion let's keep on hackers@) Hello, After being disappointed with the list of submitted FreeBSD ideas, I created my own Machiavellist vision of XXI-century FreeBSD. I paste it below. If you want to add something, it's here: https://wiki.freebsd.org/BSD_XXI_Manifesto GSOC students could use this as an inspiration for their projects. The idea is to invite non-C, non-OS, non-kernel developers to help out with FreeBSD stuff. ============ BSDXXI manifesto For people seeking for inspiration here are some ideas of how FreeBSD of 21st century could operate... - FreeBSD boots from simple USB-stick image or SD card. Image would contain nothing more than HTTP-enabled installer, so that as OS updates are rolled out, the installer doesn't change. It means I can keep the same USB-stick for years, since all packages/installation procedure would actually be fetched from the Internet. - installer is in high-resolution mode with graphical environment started, and my bluetooth/remote-USB mouse/keyboard working OK. Additionally I have an access to the filesystem on USB-stick. I have Wi-Fi access and/or Ethernet access and a browser to do the installation. This all is in case I want to bother to use a keyboard. - installer starts HTTP server in the background. It serves responsive 'FreeBSD installer' website. You can enter this website with your smartphone and perform the whole installation procedure from your mobile device. This HTTP server is getting left of "service partition", so that in case of problems, you can always boot FreeBSD in emergency mode and recover from problems. - installer asks me whether I'd like to use my FreeBSD account or to setup one. FreeBSD is similar to Apple ID or Amazon ID and remembers my preferences, so that in case of installation/backup/recovery I don't have to be asked same questions 10 times. This data is stored in an encrypted form on my disk, and gets imported by all programs that may ever want to ask me about my name/surname etc. This account is used to submit data about hardware which I use too, so that developers see which hardware is popular among users. This account is used for encrypted crashdump reports, bug reporting and others. This is the key to the contact with the FreeBSD developers community. Also as a part of the account users get easy access to 'BSDDEV' environment, which lets them clone, change and contribute back changes by themselves, without asking any commiters/developers for anything. They may later request this change to be pushed back to the FreeBSD. - installer asks me whether I'd like to pick certain profile of installation and install everything in 1 step. This is similar to "1 click buy" on Amazon, and is similar to node.js "npm" manager -- dozens of users contribute their installation profiles to the FreeBSD portal, and FreeBSD accounts have access to these profiles. Everybody sees which installation profile has most "Likes", and based on that users can choose whether to struggle with 100 parameters for the installation, or pick something that expert picked for them. Also desktop users willing to use Flash can pick "freebsd_superflash" installation profile, which will give them Flash working out of the box etc... - Among installation profiles, installer presents me: * mobile installation (cell phone) FreeBSD of XXI century runs on most of mobile devices, and this is one of the types of installation which I can pick for my tablet/smartphone. FreeBSD found great adoption in mobile environments, since BSD license attracted more people than GPLv4 code. FreeBSD has drivers for all sensors, GPSes and GSM/UMTS modules from phones. * laptop This profile installs me all possible optimizations for maximal power and maximal battery life, and minimal noise for any leftover laptops that still have a fan. * desktop This profile installs me everything for a desktop user. * VM (cloud solution: EC2, Rackspace etc) This installation may pick optimized I/O schedulers, so that environments which charge for I/O access, network access etc.. end up being cheap thanks to smart algorithms in FreeBSD. * hosted cloud This is a profile for enterprise users. Hosted installation is something which lets you designate a master, and slaves which connect to the master. Once slaves are connected, from 1 installer you can choose what all nodes will get installed and how they'll work. So e.g.: if you want to have a storage-cloud with 4 servers, you can make them be a redundant storage with 2 servers each, for improved efficiency. If servers are plugged in the same switch, I'd like to see them all in the menu and be able to toggle the ones which I want to be added to the cluster. - FreeBSD is getting setup in less than 5 minutes. All stages are marked with barcodes/URLs, so that in case of problems, user can take a photo of a screen and get immediate helps from FreeBSD community portal. - FreeBSD on 1st boot establishes connection via your FreeBSD ID and submits stuff necessary for improved FreeBSD development. You may choose not to submit stuff, but you'll not get an access to interactive bug database, easy contribution capability etc.. - FreeBSD ID offers to sync my disk with the BSDCloud, and offers me options for storage providers and their prices. - FreeBSD once installed, just works. It includes only the most necessary ports installed as a part of chosen profile. If necessary, users can share their configurations, e.g.: if there's somebody who got Jail/MAC/Capability-enabled environment for Node.Js installed in /jail/nodejs/, I don't really want to keep retyping his commands like a monkey. I just want to get his configuration and 20s is max I can wait for this to happen. This includes things which are popular, but boring, e.g.: HTTP server, SQL server, Mail server etc.. configuration. I'd like to add my 3 domains: koszek.com freebsd.czest.pl something.com to FreeBSD system, pick my HTTP solution, my Mail solution, my SQL solution and have them installed in the most security-hardened way possible with 0 effort. - I keep all of important system actions versioned/logged, so that if I happen to have some problems with ports/packages, I can send the journal of what happened to my system, so that somebody can reproduce it. - in cases of problems with programs, I screen share my terminal with other FreeBSD IDs. I'd like to say: "I want FreeBSD ID 'cognet' to have access to this computer but only for watching", so that I can show the problem to the 2nd FreeBSD developer. It should also be possible to give full-access to the machine to the developer, so that in case of critical problems developer can reproduce exactly what's going on. - FreeBSD rarely asks me to compile anything. FreeBSD.org has powerful BSDCloud configuration which compiles everything for me. So if I want custom kernel configuration, I can mark checkboxes online and BSDCloud will compile the kernel quickly for me, so that I don't have to bother with it. - In case of problems, it's very easily to submit a record. FreeBSD loader, FreeBSD kernel and FreeBSD user-space utilities are all equiped with OCR-enabled/scannable mechanism, which lets me to use my phone to submit a bug report. It should be possible to e.g.: take a photo of a screen, have your phone recognize what the photo is all about and act accordingly via your FreeBSD ID (submit benchmark result, submit bug report, submit security problem etc..) - FreeBSD developers check in stuff to the repository. Upon check-in FreeBSD gets compiled and automatically booted on all possible platforms -- where possible in the BSDCloud, and where it's not possible, it gets booted on real hardware. Developer has access to the BSDCloud, so should the problem happen, the VM is frozen and dev. can login to it and see what's wrong. - Upon each commit FreeBSD regression test suite is run. Test suite tries to make sure FreeBSD is still runnable, and whether any regressions got introduced. Each unit test lets you to start, stop and modify existing VM by typing commands in it and comparing the result the expected one. Users can easily contribute to regression tests by recording their actions and contributing the recorded sessions back: their FreeBSD IDs can submit regression sets to the repository and their tests will be included in the next regression run. - FreeBSD documentation is always up-to-date. Regression suite is basically a specialized Domain Specific Language, that is especially annotated with comments which are an integral part of the code. This code is used to generate the documentation -- upon each action the screenshot is taken and explanation gets inserted. Once regression test is run, and screenshots are obtained, they get glued together for a slide-show (HTML page) or screencast and are being exported to YouTube. - Check-in process gets modified, so that only when all accepted regression sets are run, the check-in is accepted. - Documentation is available in easy-to-modify form for all FreeBSD IDs. Internal format for the documentation doesn't matter, since everything gets edited in the WWW browser anyway. - Once the document is submitted, it gets reviewed and accepted by the FreeBSD developer. Upon commit, all FreeBSD IDs whose users marked 'want to contribute to documentation' get the notification on document change. The ones which speak other languages get a chance to translate the changes right away and earn credits. - submission of regression test/patch/doc change earns FreeBSD ID certain reputation. FreeBSD ID could get tied to FreeBSD forums, so that people who help others a lot also get credits. There's a simple 'acceptance' formula: above X credits you get privileges A, B, C within FreeBSD.org. - FreeBSD development can happen entirely online, via BSDCould. Users and developers can edit files via WWW browser and do it the same way. They compile the system and boot it in VM and later, on the real hardware. - Upon making a change, I select 'users who have device X' and users who marked the checkbox 'Willing to test'. They get the VM which I used for testing available and can clone the VM's configuration to their system with 1 click, boot on their hardware and report the results. - Donation process gets modified so that users who care about certain devices a lot can send their hardware to BSDCloud. Hardware would get plugged in the physical hardware and since then regression tests testing this piece of hardware would be run on each commit. Expensive hardware can get linked with BSDCloud so that the machine stays on the owners side. This box is available via VPN just like any other BSDCloud box, and as long as it's available, regression suite is run on it as well. VPN works across firewall and proxies, so specialized platforms behind the corporate walls can also get tested. - On each commit set of benchmarks is run and visualized in the browser. The configuration can include the VM configurations, but can also involve hardware. So before performing a change, developer can see the impact of the change on the system performance. - On each commit set of power benchmarks is run. Couple of real hardware setups have power measurement attached to them and are able to export power profiling information upon commit. This is crucial for cell phones, which FreeBSD can run. ============ -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 08:50:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E835A6D; Tue, 18 Feb 2014 08:50:08 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A9F01B7C; Tue, 18 Feb 2014 08:50:07 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,500,1389772800"; d="asc'?scan'208";a="102894499" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 18 Feb 2014 00:50:06 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 00:50:06 -0800 From: "Eggert, Lars" To: Dimitry Andric Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 Thread-Topic: HEADS UP: Updated llvm/clang to 3.4 in r261991 Thread-Index: AQHPK1K5Jz0zkdozhUqrFehnhJ8B/5q7PEyA Date: Tue, 18 Feb 2014 08:50:05 +0000 Message-ID: <3B45555E-04C0-4C89-AA63-C053C174945C@netapp.com> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> In-Reply-To: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.18] Content-Type: multipart/signed; boundary="Apple-Mail=_C6773F57-E92D-49C3-9E84-9C49FF6087D6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 08:50:08 -0000 --Apple-Mail=_C6773F57-E92D-49C3-9E84-9C49FF6087D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-2-16, at 21:06, Dimitry Andric wrote: > I have just upgraded our copy of llvm/clang to 3.4 release, in = r261991. I just done a "git pull" followed by a buildworld. Shouldn't I be having = version 3.4? root@six:~ # dmesg | grep clang FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 root@six:~ # clang -v FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: x86_64-unknown-freebsd11.0 Thread model: posix root@six:~ # uname -a FreeBSD six 11.0-CURRENT FreeBSD 11.0-CURRENT #14 df7b691(fas3270): Tue = Feb 4 13:28:37 CET 2014 = elars@stanley.muccbc.hq.netapp.com:/usr/home/elars/obj/usr/home/elars/src/= sys/FAS3270 amd64 Lars --Apple-Mail=_C6773F57-E92D-49C3-9E84-9C49FF6087D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwMevdZcnpRveo1xAQL8dgP9Fki/ACyHS5jASybt+ZR3U5eDKVoLkTF1 t/cXcwVLw1ZKHn6LRZ5dH4bFvk8hk21lKVx8MMi+EwJtQ8aJGYV0kUk6PylvRxRl VOtqBwucmZjx32MfG0RIqJ45jCKfrOCYrg+mf1cThe9c86FzJV3UC55pku9iaLOu HeWKNvOG7CE= =+vM8 -----END PGP SIGNATURE----- --Apple-Mail=_C6773F57-E92D-49C3-9E84-9C49FF6087D6-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 08:57:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E452F8A; Tue, 18 Feb 2014 08:57:40 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CBCC1C47; Tue, 18 Feb 2014 08:57:40 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.97,500,1389772800"; d="asc'?scan'208";a="143563080" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 18 Feb 2014 00:57:35 -0800 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.211]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 00:57:35 -0800 From: "Eggert, Lars" To: Dimitry Andric Subject: Re: HEADS UP: Updated llvm/clang to 3.4 in r261991 Thread-Topic: HEADS UP: Updated llvm/clang to 3.4 in r261991 Thread-Index: AQHPK1K5Jz0zkdozhUqrFehnhJ8B/5q7PEyAgAACFoA= Date: Tue, 18 Feb 2014 08:57:34 +0000 Message-ID: <02B2D103-F029-4826-90E1-1CA555E9E99E@netapp.com> References: <6FA0FC8C-ABAA-433A-94AF-43AF84AD2AE4@FreeBSD.org> <3B45555E-04C0-4C89-AA63-C053C174945C@netapp.com> In-Reply-To: <3B45555E-04C0-4C89-AA63-C053C174945C@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/signed; boundary="Apple-Mail=_50CC42A6-FD72-4942-9622-844B9543459E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 08:57:40 -0000 --Apple-Mail=_50CC42A6-FD72-4942-9622-844B9543459E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Disregard - pilot error. (It's not Feb 4...) Lars On 2014-2-18, at 9:50, Eggert, Lars wrote: > Hi, >=20 > On 2014-2-16, at 21:06, Dimitry Andric wrote: >> I have just upgraded our copy of llvm/clang to 3.4 release, in = r261991. >=20 > I just done a "git pull" followed by a buildworld. Shouldn't I be = having version 3.4? >=20 > root@six:~ # dmesg | grep clang > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >=20 > root@six:~ # clang -v > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > Target: x86_64-unknown-freebsd11.0 > Thread model: posix >=20 > root@six:~ # uname -a > FreeBSD six 11.0-CURRENT FreeBSD 11.0-CURRENT #14 df7b691(fas3270): = Tue Feb 4 13:28:37 CET 2014 = elars@stanley.muccbc.hq.netapp.com:/usr/home/elars/obj/usr/home/elars/src/= sys/FAS3270 amd64 >=20 > Lars --Apple-Mail=_50CC42A6-FD72-4942-9622-844B9543459E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUwMgfdZcnpRveo1xAQJxfAP/fY0L0eJEVdbkSVDKBdAY9iGrVJ0AfcqU jaCWWwyioh74H43MUZOgAr3ypDucYl1MPnCtUITAPj8fKiPxmDpjoKHx6SoOYF3P qlQwZPAYNbn0Yev5uBnBG/0LMPAQdbYOtVhoURxo69K5vfCgPbbKePeAu9O/e3cA usiYZ6aDU+A= =lFsA -----END PGP SIGNATURE----- --Apple-Mail=_50CC42A6-FD72-4942-9622-844B9543459E-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:14:34 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53F164B0; Tue, 18 Feb 2014 13:14:34 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17FDF135B; Tue, 18 Feb 2014 13:14:33 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 9D4A01023F6; Tue, 18 Feb 2014 13:14:26 +0000 (UTC) Date: Tue, 18 Feb 2014 14:14:26 +0100 From: Jeremie Le Hen To: Konstantin Belousov Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) Message-ID: <20140218131426.GE3783@caravan.chchile.org> Mail-Followup-To: Konstantin Belousov , Andriy Gapon , freebsd-current@FreeBSD.org References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> <20140215200259.GZ24664@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140215200259.GZ24664@kib.kiev.ua> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:14:34 -0000 On Sat, Feb 15, 2014 at 10:02:59PM +0200, Konstantin Belousov wrote: > On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote: > > on 14/02/2014 21:18 Jeremie Le Hen said the following: > > > I've just got another occurence of the exact same panic. Any clue how > > > to debug this? > > > > Could you please obtain *vp from frame 12 ? > > > > The problem seems to be happening in this piece of ZFS code: > > if (cnp->cn_flags & ISDOTDOT) { > > ltype = VOP_ISLOCKED(dvp); > > VOP_UNLOCK(dvp, 0); > > } > > ZFS_EXIT(zfsvfs); > > error = vn_lock(*vpp, cnp->cn_lkflags); > > if (cnp->cn_flags & ISDOTDOT) > > vn_lock(dvp, ltype | LK_RETRY); > > > > ltype is apparently LK_SHARED and the assertion is apparently triggered by > > EDEADLK error. The error can occur only if a thread tries to obtain a lock in a > > shared mode when it already has the lock exclusively. > > My only explanation of how this could happen is that dvp == *vpp and cn_lkflags > > is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results in the > > same vnode. I think that this is only possible if dvp is the root vnode. > > I am not sure if my theory is correct though. > > Also, I am not sure if zfs_lookup() should be prepared to handle such a lookup > > or if this kind of lookup should be handled by upper/other layers. In this case > > these would be VFS lookup code and nullfs code. > > > > So, is VV_ROOT flag set on the corresponding ZFS vnode ? > > Just in case, you could try the following change, but I doubt that it > would have any effect. Nullfs root vnode is cached so its VV_ROOT flag > should not be lost. Also, I never seen similar issue with UFS. > > diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c > index fa6c4af..3f74579 100644 > --- a/sys/fs/nullfs/null_subr.c > +++ b/sys/fs/nullfs/null_subr.c > @@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, vpp) > vp->v_type = lowervp->v_type; > vp->v_data = xp; > vp->v_vnlock = lowervp->v_vnlock; > + vp->v_vflag = lowervp->v_vflag & VV_ROOT; > error = insmntque1(vp, mp, null_insmntque_dtr, xp); > if (error != 0) > return (error); I've applied it and recompiling my kernel right now. I cannot really reproduce the problem for sure: it sometimes happens when I'm performing file manipulations on command-line on my nullfs-mounted zfs dataset; right after the reboot, I try again and it works. Well, now I'm writing this, this could well be the problem you describe: right after the boot I guess the root vnode is cached and still here. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:18:18 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0CEA62F; Tue, 18 Feb 2014 13:18:17 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86485138F; Tue, 18 Feb 2014 13:18:17 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 066A81024CB; Tue, 18 Feb 2014 13:18:15 +0000 (UTC) Date: Tue, 18 Feb 2014 14:18:15 +0100 From: Jeremie Le Hen To: Andriy Gapon Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) Message-ID: <20140218131815.GF3783@caravan.chchile.org> Mail-Followup-To: Andriy Gapon , freebsd-current@FreeBSD.org References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FF59B8.1080206@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:18:18 -0000 On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote: > on 14/02/2014 21:18 Jeremie Le Hen said the following: > > I've just got another occurence of the exact same panic. Any clue how > > to debug this? > > Could you please obtain *vp from frame 12 ? Sure: $1 = {v_tag = 0xffffffff815019a5 "zfs", v_op = 0xffffffff815164a0, v_data = 0xfffff80010dcb2e0, v_mount = 0xfffff80010dcd660, v_nmntvnodes = {tqe_next = 0xfffff80010dc7ce8, tqe_prev = 0xfffff80010dcd6c0}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = { lh_first = 0xfffff8005aeefcb0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfffff80010dc8050}, v_cache_dd = 0x0, v_lock = { lock_object = {lo_name = 0xffffffff815019a5 "zfs", lo_flags = 117112832, lo_data = 0, lo_witness = 0x0}, lk_lock = 18446735277920538624, lk_exslpfail = 0, lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = { lo_name = 0xffffffff80b46085 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock = 0xfffff80010dc8068, v_actfreelist = { tqe_next = 0x0, tqe_prev = 0xfffff80010dc7da8}, v_bufobj = { bo_lock = {lock_object = { lo_name = 0xffffffff80b4e613 "bufobj interlock", lo_flags = 86179840, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, bo_ops = 0xffffffff80e2d440, bo_object = 0xfffff800a30bbd00, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xfffff80010dc8000, __bo_vnode = 0xfffff80010dc8000, bo_clean = {bv_hd = { tqh_first = 0x0, tqh_last = 0xfffff80010dc8120}, bv_root = { pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = { tqh_first = 0x0, tqh_last = 0xfffff80010dc8140}, bv_root = { pt_root = 0}, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, tqh_last = 0xfffff80010dc8188}, rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 7, v_usecount = 6, v_iflag = 512, v_vflag = 1, v_writecount = 0, v_hash = 3, v_type = VDIR} > The problem seems to be happening in this piece of ZFS code: > if (cnp->cn_flags & ISDOTDOT) { > ltype = VOP_ISLOCKED(dvp); > VOP_UNLOCK(dvp, 0); > } > ZFS_EXIT(zfsvfs); > error = vn_lock(*vpp, cnp->cn_lkflags); > if (cnp->cn_flags & ISDOTDOT) > vn_lock(dvp, ltype | LK_RETRY); > > ltype is apparently LK_SHARED and the assertion is apparently triggered by > EDEADLK error. The error can occur only if a thread tries to obtain a lock in a > shared mode when it already has the lock exclusively. > My only explanation of how this could happen is that dvp == *vpp and cn_lkflags > is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results in the > same vnode. I think that this is only possible if dvp is the root vnode. > I am not sure if my theory is correct though. > Also, I am not sure if zfs_lookup() should be prepared to handle such a lookup > or if this kind of lookup should be handled by upper/other layers. In this case > these would be VFS lookup code and nullfs code. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:32:54 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18D71C05 for ; Tue, 18 Feb 2014 13:32:54 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 458981576 for ; Tue, 18 Feb 2014 13:32:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27989 for ; Tue, 18 Feb 2014 15:32:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WFkn3-000G9y-RR for freebsd-current@FreeBSD.org; Tue, 18 Feb 2014 15:32:49 +0200 Message-ID: <530360C9.9080609@FreeBSD.org> Date: Tue, 18 Feb 2014 15:31:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> <20140218131815.GF3783@caravan.chchile.org> In-Reply-To: <20140218131815.GF3783@caravan.chchile.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:32:54 -0000 on 18/02/2014 15:18 Jeremie Le Hen said the following: > On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote: >> on 14/02/2014 21:18 Jeremie Le Hen said the following: >>> I've just got another occurence of the exact same panic. Any clue how >>> to debug this? >> >> Could you please obtain *vp from frame 12 ? > > Sure: > > $1 = {v_tag = 0xffffffff815019a5 "zfs", v_op = 0xffffffff815164a0, > v_data = 0xfffff80010dcb2e0, v_mount = 0xfffff80010dcd660, > v_nmntvnodes = {tqe_next = 0xfffff80010dc7ce8, > tqe_prev = 0xfffff80010dcd6c0}, v_un = {vu_mount = 0x0, > vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, > v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = { > lh_first = 0xfffff8005aeefcb0}, v_cache_dst = {tqh_first = 0x0, > tqh_last = 0xfffff80010dc8050}, v_cache_dd = 0x0, v_lock = { > lock_object = {lo_name = 0xffffffff815019a5 "zfs", > lo_flags = 117112832, lo_data = 0, lo_witness = 0x0}, > lk_lock = 18446735277920538624, lk_exslpfail = 0, lk_timo = 51, > lk_pri = 96}, v_interlock = {lock_object = { > lo_name = 0xffffffff80b46085 "vnode interlock", > lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, > mtx_lock = 4}, v_vnlock = 0xfffff80010dc8068, v_actfreelist = { > tqe_next = 0x0, tqe_prev = 0xfffff80010dc7da8}, v_bufobj = { > bo_lock = {lock_object = { > lo_name = 0xffffffff80b4e613 "bufobj interlock", > lo_flags = 86179840, lo_data = 0, lo_witness = 0x0}, > rw_lock = 1}, bo_ops = 0xffffffff80e2d440, > bo_object = 0xfffff800a30bbd00, bo_synclist = {le_next = 0x0, > le_prev = 0x0}, bo_private = 0xfffff80010dc8000, > __bo_vnode = 0xfffff80010dc8000, bo_clean = {bv_hd = { > tqh_first = 0x0, tqh_last = 0xfffff80010dc8120}, bv_root = { > pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = { > tqh_first = 0x0, tqh_last = 0xfffff80010dc8140}, bv_root = { > pt_root = 0}, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, > bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0, > v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0, > tqh_last = 0xfffff80010dc8188}, rl_currdep = 0x0}, > v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 7, > v_usecount = 6, v_iflag = 512, v_vflag = 1, v_writecount = 0, > v_hash = 3, v_type = VDIR} So, VV_ROOT is indeed set in v_vflag. Thank you. >> The problem seems to be happening in this piece of ZFS code: >> if (cnp->cn_flags & ISDOTDOT) { >> ltype = VOP_ISLOCKED(dvp); >> VOP_UNLOCK(dvp, 0); >> } >> ZFS_EXIT(zfsvfs); >> error = vn_lock(*vpp, cnp->cn_lkflags); >> if (cnp->cn_flags & ISDOTDOT) >> vn_lock(dvp, ltype | LK_RETRY); >> >> ltype is apparently LK_SHARED and the assertion is apparently triggered by >> EDEADLK error. The error can occur only if a thread tries to obtain a lock in a >> shared mode when it already has the lock exclusively. >> My only explanation of how this could happen is that dvp == *vpp and cn_lkflags >> is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results in the >> same vnode. I think that this is only possible if dvp is the root vnode. >> I am not sure if my theory is correct though. >> Also, I am not sure if zfs_lookup() should be prepared to handle such a lookup >> or if this kind of lookup should be handled by upper/other layers. In this case >> these would be VFS lookup code and nullfs code. > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:38:51 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 946E8E1D; Tue, 18 Feb 2014 13:38:51 +0000 (UTC) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3A815C8; Tue, 18 Feb 2014 13:38:51 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1WFksj-000FKh-Az ; Tue, 18 Feb 2014 15:38:41 +0200 Date: Tue, 18 Feb 2014 15:38:41 +0200 From: Vitalij Satanivskij To: Andriy Gapon Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain) Message-ID: <20140218133841.GA58764@hell.ukr.net> References: <1391083826.948700370.cmzf8475@frv45.ukr.net> <20140131182637.GA82526@hell.ukr.net> <20140204100823.GA95709@hell.ukr.net> <52F0F687.6050307@FreeBSD.org> <20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org> <20140205090449.GA9341@hell.ukr.net> <20140205122241.GA38114@hell.ukr.net> <52F4A35E.1080902@FreeBSD.org> <52FA2CA2.5000508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52FA2CA2.5000508@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Vitalij Satanivskij , Current FreeBSD , Vladimir Sharun X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:38:51 -0000 Dear Andriy and FreeBSD community, I'm testing you patch for sometime and looks like everything is ok. At last for 5 day of working any notisible memory leak wos not found. AG> AG> I've been able to spend some time on this issue. AG> Could you please try the following patch? AG> http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch AG> It obsoletes all previous patches from me. AG> AG> -- AG> Andriy Gapon AG> _______________________________________________ AG> freebsd-current@freebsd.org mailing list AG> http://lists.freebsd.org/mailman/listinfo/freebsd-current AG> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:39:54 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F443FC1; Tue, 18 Feb 2014 13:39:54 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C730215DC; Tue, 18 Feb 2014 13:39:53 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 21DB4102771; Tue, 18 Feb 2014 13:39:52 +0000 (UTC) Date: Tue, 18 Feb 2014 14:39:52 +0100 From: Jeremie Le Hen To: Andriy Gapon Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) Message-ID: <20140218133951.GG3783@caravan.chchile.org> Mail-Followup-To: Andriy Gapon , freebsd-current@FreeBSD.org References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> <20140218131815.GF3783@caravan.chchile.org> <530360C9.9080609@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530360C9.9080609@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:39:54 -0000 On Tue, Feb 18, 2014 at 03:31:53PM +0200, Andriy Gapon wrote: > > So, VV_ROOT is indeed set in v_vflag. > Thank you. So there's no need for me to reboot with kib's patch, right? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:41:50 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2715015E for ; Tue, 18 Feb 2014 13:41:50 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 762A7164E for ; Tue, 18 Feb 2014 13:41:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA28116; Tue, 18 Feb 2014 15:41:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WFkvi-000GAd-T3; Tue, 18 Feb 2014 15:41:46 +0200 Message-ID: <530362F7.5060403@FreeBSD.org> Date: Tue, 18 Feb 2014 15:41:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> <20140215200259.GZ24664@kib.kiev.ua> In-Reply-To: <20140215200259.GZ24664@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:41:50 -0000 on 15/02/2014 22:02 Konstantin Belousov said the following: > On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote: >> on 14/02/2014 21:18 Jeremie Le Hen said the following: >>> I've just got another occurence of the exact same panic. Any clue how >>> to debug this? >> >> Could you please obtain *vp from frame 12 ? >> >> The problem seems to be happening in this piece of ZFS code: if >> (cnp->cn_flags & ISDOTDOT) { ltype = VOP_ISLOCKED(dvp); VOP_UNLOCK(dvp, >> 0); } ZFS_EXIT(zfsvfs); error = vn_lock(*vpp, cnp->cn_lkflags); if >> (cnp->cn_flags & ISDOTDOT) vn_lock(dvp, ltype | LK_RETRY); >> >> ltype is apparently LK_SHARED and the assertion is apparently triggered >> by EDEADLK error. The error can occur only if a thread tries to obtain a >> lock in a shared mode when it already has the lock exclusively. My only >> explanation of how this could happen is that dvp == *vpp and cn_lkflags >> is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results >> in the same vnode. I think that this is only possible if dvp is the root >> vnode. I am not sure if my theory is correct though. Also, I am not sure >> if zfs_lookup() should be prepared to handle such a lookup or if this >> kind of lookup should be handled by upper/other layers. In this case >> these would be VFS lookup code and nullfs code. >> > > So, is VV_ROOT flag set on the corresponding ZFS vnode ? As Jeremy has just reported, yes, it is set. > Just in case, you could try the following change, but I doubt that it would > have any effect. Nullfs root vnode is cached so its VV_ROOT flag should > not be lost. Also, I never seen similar issue with UFS. I have never seen this issue with ZFS... before. > diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c index > fa6c4af..3f74579 100644 --- a/sys/fs/nullfs/null_subr.c +++ > b/sys/fs/nullfs/null_subr.c @@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, > vpp) vp->v_type = lowervp->v_type; vp->v_data = xp; vp->v_vnlock = > lowervp->v_vnlock; + vp->v_vflag = lowervp->v_vflag & VV_ROOT; error = > insmntque1(vp, mp, null_insmntque_dtr, xp); if (error != 0) return > (error); > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:44:26 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70B8C3ED for ; Tue, 18 Feb 2014 13:44:26 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BE3A91672 for ; Tue, 18 Feb 2014 13:44:25 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA28140 for ; Tue, 18 Feb 2014 15:44:24 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WFkyG-000GAm-6N for freebsd-current@FreeBSD.org; Tue, 18 Feb 2014 15:44:24 +0200 Message-ID: <53036380.4010002@FreeBSD.org> Date: Tue, 18 Feb 2014 15:43:28 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org> <52FF59B8.1080206@FreeBSD.org> <20140218131815.GF3783@caravan.chchile.org> <530360C9.9080609@FreeBSD.org> <20140218133951.GG3783@caravan.chchile.org> In-Reply-To: <20140218133951.GG3783@caravan.chchile.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:44:26 -0000 on 18/02/2014 15:39 Jeremie Le Hen said the following: > On Tue, Feb 18, 2014 at 03:31:53PM +0200, Andriy Gapon wrote: >> >> So, VV_ROOT is indeed set in v_vflag. >> Thank you. > > So there's no need for me to reboot with kib's patch, right? You better ask kib. I do not see any misbehavior in ZFS code so far. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:45:42 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DC9C526 for ; Tue, 18 Feb 2014 13:45:42 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 603C71689 for ; Tue, 18 Feb 2014 13:45:40 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA28178; Tue, 18 Feb 2014 15:45:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WFkzS-000GAt-IT; Tue, 18 Feb 2014 15:45:38 +0200 Message-ID: <530363CA.4060507@FreeBSD.org> Date: Tue, 18 Feb 2014 15:44:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Vitalij Satanivskij Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain) References: <1391083826.948700370.cmzf8475@frv45.ukr.net> <20140131182637.GA82526@hell.ukr.net> <20140204100823.GA95709@hell.ukr.net> <52F0F687.6050307@FreeBSD.org> <20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org> <20140205090449.GA9341@hell.ukr.net> <20140205122241.GA38114@hell.ukr.net> <52F4A35E.1080902@FreeBSD.org> <52FA2CA2.5000508@FreeBSD.org> <20140218133841.GA58764@hell.ukr.net> In-Reply-To: <20140218133841.GA58764@hell.ukr.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Vladimir Sharun , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:45:42 -0000 on 18/02/2014 15:38 Vitalij Satanivskij said the following: > Dear Andriy and FreeBSD community, > > I'm testing you patch for sometime and looks like everything is ok. > > At last for 5 day of working any notisible memory leak wos not found. Vitalij, thank you very much for testing! What about those checksum errors? Do you see them now? > AG> > AG> I've been able to spend some time on this issue. > AG> Could you please try the following patch? > AG> http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch > AG> It obsoletes all previous patches from me. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:47:12 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6C3E63E; Tue, 18 Feb 2014 13:47:12 +0000 (UTC) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 820BE169D; Tue, 18 Feb 2014 13:47:12 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1WFl0w-000FQG-Fr ; Tue, 18 Feb 2014 15:47:10 +0200 Date: Tue, 18 Feb 2014 15:47:10 +0200 From: Vitalij Satanivskij To: Andriy Gapon Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain) Message-ID: <20140218134710.GA58844@hell.ukr.net> References: <20140204100823.GA95709@hell.ukr.net> <52F0F687.6050307@FreeBSD.org> <20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org> <20140205090449.GA9341@hell.ukr.net> <20140205122241.GA38114@hell.ukr.net> <52F4A35E.1080902@FreeBSD.org> <52FA2CA2.5000508@FreeBSD.org> <20140218133841.GA58764@hell.ukr.net> <530363CA.4060507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530363CA.4060507@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Vitalij Satanivskij , Current FreeBSD , Vladimir Sharun X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 13:47:12 -0000 Dear Andriy and FreeBSD community, No checksume errors or any other errors found for now. Andriy Gapon wrote: AG> on 18/02/2014 15:38 Vitalij Satanivskij said the following: AG> > Dear Andriy and FreeBSD community, AG> > AG> > I'm testing you patch for sometime and looks like everything is ok. AG> > AG> > At last for 5 day of working any notisible memory leak wos not found. AG> AG> Vitalij, AG> AG> thank you very much for testing! AG> What about those checksum errors? Do you see them now? AG> AG> > AG> AG> > AG> I've been able to spend some time on this issue. AG> > AG> Could you please try the following patch? AG> > AG> http://people.freebsd.org/~avg/l2arc-b_tmp_cdata-diag.2.patch AG> > AG> It obsoletes all previous patches from me. AG> AG> -- AG> Andriy Gapon AG> _______________________________________________ AG> freebsd-current@freebsd.org mailing list AG> http://lists.freebsd.org/mailman/listinfo/freebsd-current AG> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 13:47:40 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B93B754; Tue, 18 Feb 2014 13:47:40 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED8C16AD; Tue, 18 Feb 2014 13:47:40 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c896:bb5c:9b2b:52b0]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 950D54AC2D; Tue, 18 Feb 2014 17:47:29 +0400 (MSK) Date: Tue, 18 Feb 2014 17:47:25 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <4010409659.20140218174725@serebryakov.spb.ru> To: Aleksandr Rybalko Subject: Re: vt(9) r261654 with preloaded i915kms -- hangs 9 times out of 10 on boot In-Reply-To: <20140218002326.39045f60.ray@freebsd.org> References: <1994922749.20140215195633@serebryakov.spb.ru> <20140218002326.39045f60.ray@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@FreeBSD.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:47:40 -0000 Hello, Aleksandr. You wrote 18 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2014 =D0=B3., 2:23:= 26: AR> can you please test same setup but w/o vt(9). I understand you will not Ok, I'll do it tonight. AR> see kernel output, but Xorg should show up if problem related to vt(9). AR> Or at least you can do ping test. AR> But way with connected serial cable is best :) It doesn't have serial port. Only FireWire. Hmm! I could try to buy FireWire cable, as I have FireWire adapter in my desktop, but, I afraid, it could take some time, as is is not very popular format now (and notebook has very rare now "miniature" connector). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 17:10:29 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F15CB8A for ; Tue, 18 Feb 2014 17:10:29 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E16201C6E for ; Tue, 18 Feb 2014 17:10:28 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 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 A2C526184 for ; Tue, 18 Feb 2014 12:10:27 -0500 (EST) 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=nVg/D88IGWhayKnBf4AgTG4kIPiA29vXYBQGxExD9ODVQv+ULogQ1/FOX1WpJhiQZ putcna2XWosoBPMw+VZJqA1JtuIGNxW/ZlIWHKvnSMEZcAKlVtsQSaB2tdyhV1V Message-ID: <53039401.7050701@protected-networks.net> Date: Tue, 18 Feb 2014 12:10:25 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: FreeBSD Current Subject: firebox build fails post clang-3.4 merge X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 17:10:29 -0000 Is anyone else seeing firefox failing to install after the clang-3.4 merge? As in xpcshell dumping core .. ===> firefox-27.0.1,1 depends on shared library: startup-notification-1.0 - found ===> firefox-27.0.1,1 depends on shared library: pulse.0 - found gmake[3]: Entering directory `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0' gmake[4]: Entering directory `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/browser/installer' /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/_virtualenv/bin/python ../../../config/Preprocessor.py -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_S OMNIJAR_NAME=omni.ja \ /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/_virtualenv/bin/python ../../../toolkit/mozapps/installer/packager.py -DMOZ_GLUE_IN_PROGRAM --format omni \ --removals ../../../browser/installer/removed-files.in \ \ \ \ --optimizejars \ \ package-manifest ../../dist ../../dist/firefox \ Executing /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/dist/bin/xpcshell -g /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld Traceback (most recent call last): File "../../../toolkit/mozapps/installer/packager.py", line 375, in main() File "../../../toolkit/mozapps/installer/packager.py", line 367, in main args.source, gre_path, base) File "../../../toolkit/mozapps/installer/packager.py", line 148, in precompile_cache errors.fatal('Error while running startup cache precompilation') File "/usr/ports/www/firefox/work/mozilla-release/python/mozbuild/mozpack/errors.py", line 101, in fatal self._handle(self.FATAL, msg) File "/usr/ports/www/firefox/work/mozilla-release/python/mozbuild/mozpack/errors.py", line 96, in _handle raise ErrorMessage(msg) mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation gmake[4]: *** [stage-package] Error 1 gmake[4]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/browser/installer' gmake[3]: *** [install] Error 2 gmake[3]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0' *** Error code 2 From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 17:28:24 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C770220 for ; Tue, 18 Feb 2014 17:28:24 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A6841DB5 for ; Tue, 18 Feb 2014 17:28:24 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s1IHSHkY072847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Feb 2014 09:28:17 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s1IHSH66072846; Tue, 18 Feb 2014 09:28:17 -0800 (PST) (envelope-from sgk) Date: Tue, 18 Feb 2014 09:28:16 -0800 From: Steve Kargl To: Michael Butler Subject: Re: firebox build fails post clang-3.4 merge Message-ID: <20140218172816.GA72839@troutmask.apl.washington.edu> References: <53039401.7050701@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53039401.7050701@protected-networks.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 17:28:24 -0000 On Tue, Feb 18, 2014 at 12:10:25PM -0500, Michael Butler wrote: > Is anyone else seeing firefox failing to install after the clang-3.4 > merge? As in xpcshell dumping core .. Yes. Exact same error. > Executing > /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/dist/bin/xpcshell > -g /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld > Traceback (most recent call last): > File "../../../toolkit/mozapps/installer/packager.py", line 375, in > > main() > File "../../../toolkit/mozapps/installer/packager.py", line 367, in main > args.source, gre_path, base) > File "../../../toolkit/mozapps/installer/packager.py", line 148, in > precompile_cache > errors.fatal('Error while running startup cache precompilation') > File > "/usr/ports/www/firefox/work/mozilla-release/python/mozbuild/mozpack/errors.py", > line 101, in fatal > self._handle(self.FATAL, msg) > File > "/usr/ports/www/firefox/work/mozilla-release/python/mozbuild/mozpack/errors.py", > line 96, in _handle > raise ErrorMessage(msg) > mozpack.errors.ErrorMessage: Error: Error while running startup cache > precompilation > gmake[4]: *** [stage-package] Error 1 > gmake[4]: Leaving directory > `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0/browser/installer' > gmake[3]: *** [install] Error 2 > gmake[3]: Leaving directory > `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.0' > *** Error code 2 -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 17:31:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 321B9376 for ; Tue, 18 Feb 2014 17:31:18 +0000 (UTC) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F33731DEB for ; Tue, 18 Feb 2014 17:31:17 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 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 EF04260E4 for ; Tue, 18 Feb 2014 12:31:16 -0500 (EST) 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=Q/QGNx8wMS5/5wnklcL/VfLWaWU5gzQBYIMEOKvBIfVIJZVRGNjfeZuzgKFHz8S6G wnbk5ltROXvfqH9JL//JGgJbadjief8UKxpwB3vYqbdPO6hYiibBl/LA2TnjmMj Message-ID: <530398E3.4010009@protected-networks.net> Date: Tue, 18 Feb 2014 12:31:15 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current Subject: docbook and old package management X-Enigmail-Version: 1.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 17:31:18 -0000 Seems the old package management went EOL *way* before September .. none of the docbook ports install now :-( [Updating the pkgdb in /var/db/pkg ... - 183 packages found (-1 +0) (...) done] ---> Installing the new version via the port ===> Staging for docbook241-2.4.1_2,1 ===> docbook241-2.4.1_2,1 depends on file: /usr/local/share/sgml/iso8879/catalog - found ===> docbook241-2.4.1_2,1 depends on file: /usr/local/bin/xmlcatmgr - found ===> Generating temporary packing list cd /usr/ports/textproc/docbook-241/work/docbk241 && /bin/sh -c '(/usr/bin/find -d $0 $2 | /usr/bin/cpio -dumpl $1 >/dev/null 2>&1) && /usr/sbin/chown -Rh root:wheel $1 && /usr/bin/find -d $0 $2 -type d -exec chmod 755 $1/{} \; && /usr/bin/find -d $0 $2 -type f -exec chmod 444 $1/{} \;' -- . /usr/ports/textproc/docbook-241/work/stage/usr/local/share/sgml/docbook/2.4.1/dtd install -o root -g wheel -m 444 /usr/ports/textproc/docbook-241/work/catalog /usr/ports/textproc/docbook-241/work/stage/usr/local/share/sgml/docbook/2.4.1/dtd /bin/mv /usr/ports/textproc/docbook-241/work/stage/usr/local/share/sgml/docbook/2.4.1/dtd/*.txt /usr/ports/textproc/docbook-241/work/stage/usr/local/share/doc/docbook/2.4.1 ====> Compressing man pages (compress-man) ===> Building package for docbook241-2.4.1_2,1 Creating package /usr/ports/textproc/docbook-241/work/docbook241-2.4.1_2,1.tbz Registering depends: iso8879-1986_3 xmlcatmgr-2.2. pkg_create: read_plist: unknown command '@dirrmtry share/sgml/docbook' (package tools out of date?) pkg_create: read_plist: unknown command '@dirrmtry share/doc/docbook' (package tools out of date?) pkg_create: write_plist: unknown command type -1 (share/sgml/docbook) *** Error code 1 Stop in /usr/ports/textproc/docbook-241. *** Error code 1 Stop in /usr/ports/textproc/docbook-241. *** Error code 1 Stop in /usr/ports/textproc/docbook-241. ** Command failed [exit code 1]: /usr/local/libexec/pkgtools/script -qa /tmp/portupgrade20140218-69013-1yygj31 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=docbook-2.4.1_1,1 UPGRADE_PORT_VER=2.4.1_1,1 make reinstall ---> Restoring the old version From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 17:41:36 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A0B477D for ; Tue, 18 Feb 2014 17:41:36 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C329F107C for ; Tue, 18 Feb 2014 17:41:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1WFofc-002Aaa-F6>; Tue, 18 Feb 2014 18:41:24 +0100 Received: from g225038039.adsl.alicedsl.de ([92.225.38.39] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1WFofc-003grp-AB>; Tue, 18 Feb 2014 18:41:24 +0100 Date: Tue, 18 Feb 2014 18:41:16 +0100 From: "O. Hartmann" To: Steve Kargl Subject: Re: firebox build fails post clang-3.4 merge Message-ID: <20140218184116.555d064b.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140218172816.GA72839@troutmask.apl.washington.edu> References: <53039401.7050701@protected-networks.net> <20140218172816.GA72839@troutmask.apl.washington.edu> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Nr5OX9a9k.Jhzp0ZD6EG5nz"; protocol="application/pgp-signature" X-Originating-IP: 92.225.38.39 X-ZEDAT-Hint: A Cc: Michael Butler , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 17:41:36 -0000 --Sig_/Nr5OX9a9k.Jhzp0ZD6EG5nz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 18 Feb 2014 09:28:16 -0800 Steve Kargl wrote: > On Tue, Feb 18, 2014 at 12:10:25PM -0500, Michael Butler wrote: > > Is anyone else seeing firefox failing to install after the clang-3.4 > > merge? As in xpcshell dumping core .. >=20 > Yes. Exact same error. >=20 > > Executing > > /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11.= 0/dist/bin/xpcshell > > -g /usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld > > Traceback (most recent call last): > > File "../../../toolkit/mozapps/installer/packager.py", line 375, in > > > > main() > > File "../../../toolkit/mozapps/installer/packager.py", line 367, in m= ain > > args.source, gre_path, base) > > File "../../../toolkit/mozapps/installer/packager.py", line 148, in > > precompile_cache > > errors.fatal('Error while running startup cache precompilation') > > File > > "/usr/ports/www/firefox/work/mozilla-release/python/mozbuild/mozpack/er= rors.py", > > line 101, in fatal > > self._handle(self.FATAL, msg) > > File > > "/usr/ports/www/firefox/work/mozilla-release/python/mozbuild/mozpack/er= rors.py", > > line 96, in _handle > > raise ErrorMessage(msg) > > mozpack.errors.ErrorMessage: Error: Error while running startup cache > > precompilation > > gmake[4]: *** [stage-package] Error 1 > > gmake[4]: Leaving directory > > `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11= .0/browser/installer' > > gmake[3]: *** [install] Error 2 > > gmake[3]: Leaving directory > > `/usr/ports/www/firefox/work/mozilla-release/obj-i386-portbld-freebsd11= .0' > > *** Error code 2 >=20 I have built firefox-27.0.1,1 on 11.0-CURRENT #0 r262153: Tue Feb 18 09:52:= 59 CET 2014 amd64 for two times after the LLVM/CLANG 3.4 merge without problems. I gues= s it is a i386 problem, since I can only report for amd64. Oliver --Sig_/Nr5OX9a9k.Jhzp0ZD6EG5nz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTA5tDAAoJEOgBcD7A/5N8BEIH/03glsZdgufftSL0vn2suO+v rUv0N5jsncJ54d/piD3BP3Gqw/nW9jGdStpP1co01TWQiw87bpPqSMmwgzQaTnwk sWVuQxBgwMtINMf0Ofl8EvcRL4ehxRb8yhGCd/Mq0UiZFQHuKC9DK34DZdEBTxAa okjicf04+oGmmZLlJsvqalC3sxZk3ltbzhPvVNVhnQXexRVF6kxoIVWPwr8gzEFh uOq3gmk30f1ExT+wnjlTngTST5/ocrtFWqVQ6S8FjjYZ4IlmUcXjlJl+tOevUe1I UypTgppX8R8+8pZLZvRqTJBHqYDkBerpUhY5cOcVJb/n2dxwinITtZgruj1Mu54= =XFtq -----END PGP SIGNATURE----- --Sig_/Nr5OX9a9k.Jhzp0ZD6EG5nz-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 19:15:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F19A8DE for ; Tue, 18 Feb 2014 19:15:43 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14B6C18E7 for ; Tue, 18 Feb 2014 19:15:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED725B988; Tue, 18 Feb 2014 14:15:41 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: docbook and old package management Date: Tue, 18 Feb 2014 13:16:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <530398E3.4010009@protected-networks.net> In-Reply-To: <530398E3.4010009@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402181316.45791.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:15:42 -0500 (EST) Cc: Michael Butler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 19:15:43 -0000 On Tuesday, February 18, 2014 12:31:15 pm Michael Butler wrote: > Seems the old package management went EOL *way* before September .. none > of the docbook ports install now :-( > > [Updating the pkgdb in /var/db/pkg ... - 183 packages > found (-1 +0) (...) done] Hmm, does this mean you are using pkg(8) and pkg_add? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 19:15:47 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75B689DE; Tue, 18 Feb 2014 19:15:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B01318EB; Tue, 18 Feb 2014 19:15:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 40956B9AB; Tue, 18 Feb 2014 14:15:46 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: HEAD buildkernel error (aic7xxx_seq.h is missing. Run 'make ahcfirmware') Date: Tue, 18 Feb 2014 13:24:09 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140214173553.GA90364@onelab2.iet.unipi.it> <1392402215.1145.103.camel@revolution.hippie.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402181324.09582.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:15:46 -0500 (EST) Cc: Luigi Rizzo , FreeBSD Current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 19:15:47 -0000 On Friday, February 14, 2014 1:42:05 pm Luigi Rizzo wrote: > On Fri, Feb 14, 2014 at 10:23 AM, Ian Lepore wrote: > > > On Fri, 2014-02-14 at 18:35 +0100, Luigi Rizzo wrote: > > > on a freshly checked out HEAD, > > > "make toolchain" followed by "make buildkernel" fails at this stage: > > > > > > ... > > > @ -> /usr/home/luigi/FreeBSD/head/sys > > > machine -> /usr/home/luigi/FreeBSD/head/sys/amd64/include > > > x86 -> /usr/home/luigi/FreeBSD/head/sys/x86/include > > > Error: aic7xxx_reg_print.c is missing. Run 'make ahcfirmware' > > > Error: aic7xxx_seq.h is missing. Run 'make ahcfirmware' > > > Error: aic7xxx_reg.h is missing. Run 'make ahcfirmware' > > > > > > (don't think it matters, but i am cross compiling amd64 > > > from a stable/9 amd64 system, using clang). > > > I am not sure which commit triggered the problem, > > > but this used to work in the past -- toolchain was enough > > > to build a kernel. > > > > > > cheers > > > luigi > > > > That should be 'make kernel-toolchain', shouldn't it? > > > > thanks, i will learn the difference and retry. > i just used toolchain in the past for both and since it worked > i thought it was enough. You are correct, kernel-toolchain is a subset of toolchain. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 19:15:51 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77E17B12; Tue, 18 Feb 2014 19:15:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4CEB618F0; Tue, 18 Feb 2014 19:15:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 41ED7B988; Tue, 18 Feb 2014 14:15:50 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [CFT] new sendfile(2) Date: Tue, 18 Feb 2014 13:28:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140217111635.GL26785@glebius.int.ru> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402181328.26553.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:15:50 -0500 (EST) Cc: Gleb Smirnoff , David Chisnall , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 19:15:51 -0000 On Monday, February 17, 2014 6:24:21 am David Chisnall wrote: > P.S. If aio() is creating a new thread per request, rather than scheduling them from a pool, then that is also likely a bug. The aio APIs were designed so that systems with DMA controllers could issue DMA requests in the syscall and return immediately, then trigger the notification in response to the DMA- finished interrupt. There shouldn't need to be any kernel threads created to do this... AIO uses a pool, but the requests are all done synchronously from that pool. While our low-level disk routines are async (e.g. GEOM etc.), the filesystem code above that generally is not. The aio code does have some special gunk in place for sockets (and I believe raw disk I/O) to make it truly async, but aio for files uses sychronous I/O from a pool of worker threads. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 19:20:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E569E90 for ; Tue, 18 Feb 2014 19:20:31 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 75FAD1946 for ; Tue, 18 Feb 2014 19:20:30 +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.8/8.14.8) with ESMTP id s1IJKHuq007556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 18 Feb 2014 19:20:25 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s1IJKHuq007556 Authentication-Results: smtp.infracaninophile.co.uk/s1IJKHuq007556; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <5303B269.7000604@FreeBSD.org> Date: Tue, 18 Feb 2014 19:20:09 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: docbook and old package management References: <530398E3.4010009@protected-networks.net> <201402181316.45791.jhb@freebsd.org> In-Reply-To: <201402181316.45791.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x8rMr9BoGgq3epeI4p94tgS0RjvhLJcgt" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 19:20:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x8rMr9BoGgq3epeI4p94tgS0RjvhLJcgt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18/02/2014 18:16, John Baldwin wrote: > On Tuesday, February 18, 2014 12:31:15 pm Michael Butler wrote: >> Seems the old package management went EOL *way* before September .. no= ne >> of the docbook ports install now :-( >> >> [Updating the pkgdb in /var/db/pkg ... - 183 packag= es >> found (-1 +0) (...) done] >=20 > Hmm, does this mean you are using pkg(8) and pkg_add? >=20 That's portupgrade(8) and pkg_add. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --x8rMr9BoGgq3epeI4p94tgS0RjvhLJcgt 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.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTA7JwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATxHIQAKH7waugFDQgowJsNmujzATF A8CBlw/Eu0hE0kKxyN9ZsatGn9UqSzOHddXf6i4RsYiT5lxOLxNHyudcKLnoXgBR y8rrysdRuJuwa/3aY0C9n1ZqmuDmwptm5SxEOhRo9Df89qz1awDMgFJwF4T9ZV2j rDRXuHwiZhW3iT7Su2ZrbJnJBBNmjpzgW0dtxC53SESxCNo+4g92AZbi8URyCEdk VATXxRK/UHYJmjzizKtDc+SGO1YWUlDcn3DSA42twBUalU/k+bWSYAnP3d2DWXHY 3nnQLTwcqN2yHpd7Lj7BPXd2H2jKV32KJKtuQJyxsJfC35UUI/OX/y1O3yGynfNa iNu9zWprIP2Y59A6Qz6pBDuS2WMQEn9RbSUF+ItEq47WED+5Babb54G1DyImnzrX UtBGlNaihPE9N0+ipqUGQbzFqRZQdeWbQaT5IFTAJNYAnj0JWPP1VWnJqrC3QTwU /k1B7DanQE6keegew43YJY9MMcXvtGW62cfZTNirwfg8jPcq5uNob4eJNtWCUwms VhgzSw7HaPr63dY2dlzkszBA8/SzsUKEsa25u/VOrYLRkg2RiHo8m4TfQ3jr6vlD FxvmTh6M/+L2kjmjVLsyDEk6HBDKA72F2pDBAVYDVEVxK9RTadrMyTW0HU9ncet5 AcYbYEm2aSW7uLxduuEU =yu1V -----END PGP SIGNATURE----- --x8rMr9BoGgq3epeI4p94tgS0RjvhLJcgt-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 19:24:41 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 791E7277 for ; Tue, 18 Feb 2014 19:24:41 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47DEB19ED for ; Tue, 18 Feb 2014 19:24:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WFqHS-0009KI-Fa; Tue, 18 Feb 2014 19:24:34 +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 s1IJOT4D028918; Tue, 18 Feb 2014 12:24:29 -0700 (MST) (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: U2FsdGVkX193JxrCdd+elZPaq5QZEFWv Subject: Re: HEAD buildkernel error (aic7xxx_seq.h is missing. Run 'make ahcfirmware') From: Ian Lepore To: Luigi Rizzo In-Reply-To: References: <20140214173553.GA90364@onelab2.iet.unipi.it> <1392402215.1145.103.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Feb 2014 12:24:29 -0700 Message-ID: <1392751469.1145.24.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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 19:24:41 -0000 On Fri, 2014-02-14 at 13:46 -0800, Luigi Rizzo wrote: > On Fri, Feb 14, 2014 at 10:23 AM, Ian Lepore wrote: > > > On Fri, 2014-02-14 at 18:35 +0100, Luigi Rizzo wrote: > > > on a freshly checked out HEAD, > > > "make toolchain" followed by "make buildkernel" fails at this stage: > > > > > > ... > > > @ -> /usr/home/luigi/FreeBSD/head/sys > > > machine -> /usr/home/luigi/FreeBSD/head/sys/amd64/include > > > x86 -> /usr/home/luigi/FreeBSD/head/sys/x86/include > > > Error: aic7xxx_reg_print.c is missing. Run 'make ahcfirmware' > > > Error: aic7xxx_seq.h is missing. Run 'make ahcfirmware' > > > Error: aic7xxx_reg.h is missing. Run 'make ahcfirmware' > > > > > > (don't think it matters, but i am cross compiling amd64 > > > from a stable/9 amd64 system, using clang). > > > I am not sure which commit triggered the problem, > > > but this used to work in the past -- toolchain was enough > > > to build a kernel. > > > > > > cheers > > > luigi > > > > That should be 'make kernel-toolchain', shouldn't it? > > > > nope, fails with kernel-toolchain as well. > I need to do a full buildworld to avoid this problem. > > cheers > luigi > This all used to work when cross-building from older systems, but there were some changes recently to get rid of the whole process of compiling the aicasm tool. There's supposed to be some sort of binary firmware blob involved now. Did you try what the error message recommended (make ahcfirmware)? -- Ian From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 20:03:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 029BAB3A for ; Tue, 18 Feb 2014 20:03:23 +0000 (UTC) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by mx1.freebsd.org (Postfix) with ESMTP id C1C7D1E08 for ; Tue, 18 Feb 2014 20:03:22 +0000 (UTC) Received: from BLU179-W85 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Feb 2014 12:02:16 -0800 X-TMN: [A751CYAsJJ1Bz1ceHdbagxrlg1X2E4/Z] X-Originating-Email: [brunolauze@msn.com] Message-ID: From: =?iso-8859-1?B?QnJ1bm8gTGF1euk=?= To: "freebsd-current@freebsd.org" Subject: Device File Creation Time Date: Tue, 18 Feb 2014 15:02:16 -0500 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Feb 2014 20:02:16.0385 (UTC) FILETIME=[52699310:01CF2CE4] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 20:03:23 -0000 root@pcbsd:/dev # stat /dev/ada0=0A= 1895890688 97 crw-rw-rw- 1 root operator 97 0 "Feb 18 10:52:11 2014" "Feb 1= 7 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0 /de= v/ada0=0A= =0A= root@pcbsd:/dev # stat /dev/ada0p2=0A= 1895890688 103 crw-rw-rw- 1 root operator 103 0 "Feb 18 10:52:05 2014" "Feb= 17 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0 /= dev/ada0p2=0A= =0A= root@pcbsd:/dev # stat /dev/ada0p3=0A= 1895890688 105 crw-rw-rw- 1 root operator 105 0 "Feb 18 10:52:21 2014" "Feb= 17 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0 /= dev/ada0p3=0A= =0A= As we can see all files in devfs reports Dec 31 1969 as creation time.=0A= =0A= Can we look to manage this value to know when a certain device was installe= d?=0A= =0A= It would be really great to know when a disk was replaced.=0A= =0A= Would there be any other mechanism to accomplish this? = From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 20:19:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2742861E; Tue, 18 Feb 2014 20:19:06 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92F291030; Tue, 18 Feb 2014 20:19:05 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i8so26483569qcq.32 for ; Tue, 18 Feb 2014 12:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lIWY8+fCOvqJBKGQlWezG2F4dDEG3XqyHVYMwqZv84s=; b=lcMTHjRZMAwtC9HZO28Nso4tNcf00V2dSU8/rjDxV0m+5Xp+cGj7r4I76hCrKu82SB 30cLzL/+qAh4ufTCocNNx1rkykSLBw1C/Tid9UVXEzybHCV7lcsXMeG505npfwA9Et2a JPkbksjdGGHfKI6usA2Aeh6Swcz1GnRxu+nWCPP5ratcQONacgrD1v42BG+ehJIW6Rhh QJpFQoLC8ZfeW+mHPMAd+RTGNAvIgdhZyC8njEDKKN0DRSgYLq6oaTCf4D0tVigg781A hLyjQp10EHo/6susaY22DRrm+EZr7jkFaDGXrPNOXBO+ypcTysp/hYlNebVGE5EkwbxV obPA== MIME-Version: 1.0 X-Received: by 10.229.188.69 with SMTP id cz5mr45669100qcb.7.1392754744070; Tue, 18 Feb 2014 12:19:04 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 12:19:04 -0800 (PST) In-Reply-To: <201402181328.26553.jhb@freebsd.org> References: <20140217111635.GL26785@glebius.int.ru> <201402181328.26553.jhb@freebsd.org> Date: Tue, 18 Feb 2014 12:19:04 -0800 X-Google-Sender-Auth: Tm0w7yFjojxbnu96GCMopG8X97c Message-ID: Subject: Re: [CFT] new sendfile(2) From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , David Chisnall , Gleb Smirnoff , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 20:19:06 -0000 On 18 February 2014 10:28, John Baldwin wrote: > On Monday, February 17, 2014 6:24:21 am David Chisnall wrote: >> P.S. If aio() is creating a new thread per request, rather than scheduling > them from a pool, then that is also likely a bug. The aio APIs were designed > so that systems with DMA controllers could issue DMA requests in the syscall > and return immediately, then trigger the notification in response to the DMA- > finished interrupt. There shouldn't need to be any kernel threads created to > do this... > > AIO uses a pool, but the requests are all done synchronously from that > pool. While our low-level disk routines are async (e.g. GEOM etc.), > the filesystem code above that generally is not. The aio code does have > some special gunk in place for sockets (and I believe raw disk I/O) to > make it truly async, but aio for files uses sychronous I/O from a pool > of worker threads. Just to expand on John's response - which is absolutely correct: * the IO strategy routines these days do indeed do things via callbacks, so no AIO worker threads required * However any blocking that goes on in the completion path ends up making the disk IO rate drop dramatically - so there's still a single AIO completion thread involved in posting the kqueue notifications (ie, doing kqueue notifications from the strategy completion callback doesn't work well because of (kqueue, etc) lock contention) * The disk code is all blocking - especially trying to do metadata reads for things like directory traversal. I don't know if Scott is working on the async directory stuff or not, but nailing a fully async path for filesystem strategy() calls on an arbitrary file would really aid high throughput AIO based systems. We'd be able to do zero copy disk IO for both read and write. -a From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 20:20:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59F0D741; Tue, 18 Feb 2014 20:20:17 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C41841067; Tue, 18 Feb 2014 20:20:16 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id f11so23835351qae.38 for ; Tue, 18 Feb 2014 12:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DNuudeZmeE0cUDs1UOhfhkZzsBMAwB3M/Bj56Sj3eAU=; b=ZwRIkdjYx8gcZdhpiuQqSJXS2WIZAmDcQ4YMUvQl/Swzwb20vLiuwRrRVt07dW36Fg MYNRcfYw5tdimvkTxCruTWpGCVarsID/nOT25NEmyP40FWnEd1KRR7NUN/oDTXu6E335 LDpLz3AKHiUdxojbA7kqklDd19xRWc0YdYDrhmgZkMdndfbUPTzju+3rmMX8vyt7di1k D35onE9SImjxWxd+boUZrzz6l+ih+GFj4e4gVynULpWglPZVf8HZ22o56ZAPOWm8NkRn maPiul08IPKwU2g+WdKrClueX3q+X2vFTPbR1LH9HWmg/fASjHfOA9zr2KCjGfSJjnzV xZng== MIME-Version: 1.0 X-Received: by 10.140.98.203 with SMTP id o69mr4870660qge.102.1392754815934; Tue, 18 Feb 2014 12:20:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 12:20:15 -0800 (PST) In-Reply-To: References: <20140217111635.GL26785@glebius.int.ru> <201402181328.26553.jhb@freebsd.org> Date: Tue, 18 Feb 2014 12:20:15 -0800 X-Google-Sender-Auth: PaCg42Pw-ZiyX5gc-JVzlfqRfeA Message-ID: Subject: Re: [CFT] new sendfile(2) From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , David Chisnall , Gleb Smirnoff , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 20:20:17 -0000 ..blah, the "filesystem code is all blocking.." -a From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 21:17:12 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AFF4AE6; Tue, 18 Feb 2014 21:17:12 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C47A15F9; Tue, 18 Feb 2014 21:17:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:c896:bb5c:9b2b:52b0]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2959E4AC2D; Wed, 19 Feb 2014 01:17:10 +0400 (MSK) Date: Wed, 19 Feb 2014 01:17:06 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1318211869.20140219011706@serebryakov.spb.ru> To: Aleksandr Rybalko Subject: Re: vt(9) r261654 with preloaded i915kms -- hangs 9 times out of 10 on boot In-Reply-To: <20140218002326.39045f60.ray@freebsd.org> References: <1994922749.20140215195633@serebryakov.spb.ru> <20140218002326.39045f60.ray@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-x11@FreeBSD.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:17:12 -0000 Hello, Aleksandr. You wrote 18 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2014 =D0=B3., 2:23:= 26: AR> can you please test same setup but w/o vt(9). I understand you will not AR> see kernel output, but Xorg should show up if problem related to vt(9). AR> Or at least you can do ping test. AR> But way with connected serial cable is best :) It is hard to be 100% sure without FireWire debugging, as I have geom_eli-based full-disk encryption, but looks like it hangs without vt (with GENERIC kernel and preloaded i915kms.ko) too. Maybe, I've mistyped password 3 times, but it is not very plausible :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 23:47:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03B273C5 for ; Tue, 18 Feb 2014 23:47:26 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF86A14E2 for ; Tue, 18 Feb 2014 23:47:25 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1WFSmk-00075A-J7 for freebsd-current@freebsd.org; Mon, 17 Feb 2014 10:19:18 -0800 Date: Mon, 17 Feb 2014 10:19:18 -0800 (PST) From: Robert_Burmeister To: freebsd-current@freebsd.org Message-ID: <1392661158563-5886786.post@n5.nabble.com> Subject: Base iconv (sort of) replaces libiconv in FreeBSD 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Feb 2014 00:16:22 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 18 Feb 2014 23:47:26 -0000 While base iconv replaces libiconv in FreeBSD 10, base iconv doesn't do utf-8 -> wchar_t, which is required by glib20, thus impacts thousands of ports. An entry in the FreeBSD 10 Errata stating that iconv is now in the base system, however, that it does not include all the functionality of libiconv from ports, would help make port maintainers aware of iconv issues. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Base-iconv-sort-of-replaces-libiconv-in-FreeBSD-10-tp5886786.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 00:28:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 458F0A0F; Wed, 19 Feb 2014 00:28:19 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6B4017FB; Wed, 19 Feb 2014 00:28:18 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id o15so24393269qap.2 for ; Tue, 18 Feb 2014 16:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=86PlWIGv2Q3HVdOUfhOJMWPOi6e60AbiMQ7Pg3k8ZAY=; b=P4I9B9gWB0J2AnA9h8HGSdA7QDgvPMV+Ps4zlIuN9Cbel96CyOFvcK5xWwnrRhqaHb HcOmIUVABa9l6k1qa3kTkYPpiwoNRNC0cNChyqdi2L2ZqZJgbphK0PqkOZdOmXaqkcKK PdczxEMtvPzC7RI3vekD7bX0FNPbDU5SVhqbkXDMFowQftYWwMWZHey/jWWXuUDoE42u XmS517O6uFOa3anYRfhCJjyaZOKoPj0mRg4bVJSziQqTE74+7VaQi+K+IgSD6kz+fy5Q v8bCuPcykb7jgpVehqKXUQ45W1i5Zd5AlwpoZIGP48L0d53HbZ1QtpebQkZmB+L6ULFt Ct3Q== MIME-Version: 1.0 X-Received: by 10.140.44.119 with SMTP id f110mr45202963qga.31.1392769698073; Tue, 18 Feb 2014 16:28:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 16:28:18 -0800 (PST) Date: Tue, 18 Feb 2014 16:28:18 -0800 X-Google-Sender-Auth: Jyth5QnZ-sb0Y0Ok-iUW5LUUVPQ Message-ID: Subject: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , Jeffrey Faden , John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 00:28:19 -0000 Hi, This patch binds the per-CPU timeout swi threads to the CPU they're on. The scheduler may decide that a preempted kernel thread that's still runnable and this can happen during things like per-CPU TCP timers firing. Thanks, Index: sys/kern/kern_timeout.c =================================================================== --- sys/kern/kern_timeout.c (revision 261910) +++ sys/kern/kern_timeout.c (working copy) @@ -355,6 +355,7 @@ char name[MAXCOMLEN]; #ifdef SMP int cpu; + struct intr_event *ie; #endif cc = CC_CPU(timeout_cpu); @@ -362,6 +363,11 @@ if (swi_add(&clk_intr_event, name, softclock, cc, SWI_CLOCK, INTR_MPSAFE, &cc->cc_cookie)) panic("died while creating standard software ithreads"); + if (intr_event_bind(clk_intr_event, timeout_cpu) != 0) { + printf("%s: timeout clock couldn't be pinned to cpu %d\n", + __func__, + timeout_cpu); + } #ifdef SMP CPU_FOREACH(cpu) { if (cpu == timeout_cpu) @@ -370,9 +376,15 @@ cc->cc_callout = NULL; /* Only cpu0 handles timeout(9). */ callout_cpu_init(cc); snprintf(name, sizeof(name), "clock (%d)", cpu); - if (swi_add(NULL, name, softclock, cc, SWI_CLOCK, + ie = NULL; + if (swi_add(&ie, name, softclock, cc, SWI_CLOCK, INTR_MPSAFE, &cc->cc_cookie)) panic("died while creating standard software ithreads"); + if (intr_event_bind(ie, cpu) != 0) { + printf("%s: per-cpu clock couldn't be pinned to cpu %d\n", + __func__, + cpu); + } } #endif } -a From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 00:32:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C565C8A; Wed, 19 Feb 2014 00:32:33 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF44718A1; Wed, 19 Feb 2014 00:32:32 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id j5so24134043qaq.6 for ; Tue, 18 Feb 2014 16:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=hWdgO78LqGdWyDPtpK3tohGE9sr642FLCGSM3sP1ynQ=; b=gqYRwofj2B+yw60Qpeiqogb72VnusKBCuAje7FtGOvzpN7PdREsfXg8eVEpPWIi2dR nFVFlEuRET7hbnu7Pieg7Xrmt60SNGUAadT6lDvv+KsLDqkB9JJrtFEJ8FEthYf/OzJ+ 1Zl3LYqQKGFS8OxNSjJHdvDSmBfJHCFh26m01L8DrHRGq+VGNOkthgNhkttNdqAQN+Dz FQ3aqjmJZ7WPjx8hCBIZ3a9lUJYy8iCZpuzzGHyu0wVNl7yrc9PFWrOZuHa8dKyKV1tt rG6Uki6SOGX6UsMFfRCSxDNKJXmD0J3U9qmYOlXJ+hZqcARuIpKLC6QHcgnQPiEJ35hz sWPA== MIME-Version: 1.0 X-Received: by 10.224.125.4 with SMTP id w4mr15512371qar.68.1392769952037; Tue, 18 Feb 2014 16:32:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 16:32:32 -0800 (PST) Date: Tue, 18 Feb 2014 16:32:32 -0800 X-Google-Sender-Auth: intH1abbjtVTQYc-V8ubSaTK7o8 Message-ID: Subject: [rfc] add callgraph PC annotation to pmcstat From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 00:32:33 -0000 Hi, This patch adds callgraph annotation to pmcstat via -a. It doesn't (yet) add line numbers; I'll see if I can easily add that without too much effort. This is like (and based on) the -m option but the -m option only prints the first entry in the callgraph. It isn't very useful if you want to see what actually called it and where it called it from, in order to trace things like "where's that memcpy actually coming from?" http://people.freebsd.org/~adrian/netflix/20140218-pmcstat-callgraph-annotate.diff Thanks! -a From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 00:46:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 019461E8; Wed, 19 Feb 2014 00:46:02 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6E8197C; Wed, 19 Feb 2014 00:46:01 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id j107so8193084qga.8 for ; Tue, 18 Feb 2014 16:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HLN2VtLhpX6ANeRJNTIdtERhNAOSAyXpo7Hpeo3afqs=; b=SRILzV8NgG1gVv0LAMFdElkvY8VKYVa1zR13Ffcq+SWyS6XHJOUJeCOPQ2Xa1zQewK qZ4wXledKsf0cmCJTz2FzNOTSXIcohz85mNBp/jNWb0yG6MHbAOC63//3P9iYnLs+o/5 xKRl534tqDvxxlw4cuazPyx/6UJFc/RpsQ1ZuzZol7Y68z38nQJ2pzja6/0SSDtf7lOM moJRih51bhrN53KMfch2/ZBi1gQzb2YtY128eJ2xHKFGOofMD6htthUnZ7ebEVMBHt8t BG4pLFmHg1Ytnp7SubOkqQDgUBnz6zCD2W2467Ettvw50sUZI8jDSdjext4r+plPPFNV WitA== MIME-Version: 1.0 X-Received: by 10.140.22.145 with SMTP id 17mr45127973qgn.0.1392770760430; Tue, 18 Feb 2014 16:46:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Tue, 18 Feb 2014 16:46:00 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Feb 2014 16:46:00 -0800 X-Google-Sender-Auth: QjHyLFxXwCanUaSFqCV0OEmioZ4 Message-ID: Subject: Re: [rfc] add callgraph PC annotation to pmcstat From: Adrian Chadd To: "freebsd-arch@freebsd.org" , freebsd-current , George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 00:46:02 -0000 .. and now with file:line information: http://people.freebsd.org/~adrian/netflix/20140218-pmcstat-callgraph-annotate-2.diff It doesn't yet correctly handle klds - the address calculation stuff isn't taking the load addr into account. -a From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 04:38:18 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A08E483F; Wed, 19 Feb 2014 04:38:18 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAE0B16A1; Wed, 19 Feb 2014 04:38:17 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id p9so12777505lbv.6 for ; Tue, 18 Feb 2014 20:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pbxdnOz84mPs6i91vQ8OpAKdf9FMAlnka0KWQQUansg=; b=Y1LXvkcWuyM75DicQuhVXDfUkElbB3ZDnL0m1GJayhuZXciZbVSlc44wjyVidS2+tI V3c1WaFi4PXzpMI1SRWC6a2+VkFrpvbzLelDdZ4NvEml0j6R+G+iVupMohqqieSA1qd7 lDZ/qNKXe3k+syG+Ho7+fnh/scjwbmMEroOhq1T0tRVGxzsTNfgNYx23nMe5JVJQwpEc FvkjLWzvCMULadtNn5ZAEPBwVo0Wg3itgQ/lFDgbBIbdTiX62GvJvZA4gj/Hoj26NXmt wRvR4EOCEIs8qvWw6R1SwhBGfzfP4eFzsfl56AkE69enDN84Qarj3W5aPpLzzxZP3xyR isBA== MIME-Version: 1.0 X-Received: by 10.152.21.4 with SMTP id r4mr2087lae.51.1392784695841; Tue, 18 Feb 2014 20:38:15 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Tue, 18 Feb 2014 20:38:15 -0800 (PST) In-Reply-To: <1392751469.1145.24.camel@revolution.hippie.lan> References: <20140214173553.GA90364@onelab2.iet.unipi.it> <1392402215.1145.103.camel@revolution.hippie.lan> <1392751469.1145.24.camel@revolution.hippie.lan> Date: Tue, 18 Feb 2014 20:38:15 -0800 X-Google-Sender-Auth: 8mcYTedJfYAEhTSyQVs9ZUsueFg Message-ID: Subject: Re: HEAD buildkernel error (aic7xxx_seq.h is missing. Run 'make ahcfirmware') From: Luigi Rizzo To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 04:38:18 -0000 On Tue, Feb 18, 2014 at 11:24 AM, Ian Lepore wrote: > On Fri, 2014-02-14 at 13:46 -0800, Luigi Rizzo wrote: > > On Fri, Feb 14, 2014 at 10:23 AM, Ian Lepore wrote: > > > > > On Fri, 2014-02-14 at 18:35 +0100, Luigi Rizzo wrote: > > > > on a freshly checked out HEAD, > > > > "make toolchain" followed by "make buildkernel" fails at this stage: > > > > > > > > ... > > > > @ -> /usr/home/luigi/FreeBSD/head/sys > > > > machine -> /usr/home/luigi/FreeBSD/head/sys/amd64/include > > > > x86 -> /usr/home/luigi/FreeBSD/head/sys/x86/include > > > > Error: aic7xxx_reg_print.c is missing. Run 'make ahcfirmware' > > > > Error: aic7xxx_seq.h is missing. Run 'make ahcfirmware' > > > > Error: aic7xxx_reg.h is missing. Run 'make ahcfirmware' > > > > > > > > (don't think it matters, but i am cross compiling amd64 > > > > from a stable/9 amd64 system, using clang). > > > > I am not sure which commit triggered the problem, > > > > but this used to work in the past -- toolchain was enough > > > > to build a kernel. > > > > > > > > cheers > > > > luigi > > > > > > That should be 'make kernel-toolchain', shouldn't it? > > > > > > > nope, fails with kernel-toolchain as well. > > I need to do a full buildworld to avoid this problem. > > > > cheers > > luigi > > > > This all used to work when cross-building from older systems, but there > were some changes recently to get rid of the whole process of compiling > the aicasm tool. There's supposed to be some sort of binary firmware > blob involved now. > > Did you try what the error message recommended (make ahcfirmware)? > i have not tried partly for laziness partly because usually these suggestions require the command to run in the cross-building environment. But i guess my point is that building aicasm should be part of kernel-toolchain (or whatever the target is for "all the tools we need to build a kernel"). Now, if aicasm is not changing we can perhaps try to reuse the one in the host environment, in which case i'd first try to support the same feature to avoid rebuilding clang or gcc. thanks luigi From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 07:57:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31B1311D for ; Wed, 19 Feb 2014 07:57:45 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 068911663 for ; Wed, 19 Feb 2014 07:57:45 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id v10so44486pde.28 for ; Tue, 18 Feb 2014 23:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OAUlMsbHWUpY2BYUZndldnPwItbKlCZ/bxoghUGpWdQ=; b=PbOs5ofO4jC9rhnWEyIeivqw2xV70/j0fwT/HC13P2ok6/OvxWs1PM8POUDt7dTguR /7Py/j28FjUMUUTGb/lWt4ai3u105dpnQATvhm1Im1FTfjKHDblMu34mqLTvtaGdNhHz kiNxldhyYLPh+RPZsEn3WRH3g7pamClHQdcl4YvICKhv4kol0sZ6JyCW+Lv7qTZVYhIL emGWzWhxBUacy+1NtlJqBeiyUz/TYIjXnMRj+WzjoDQYCIgSQhUa8VY3jp3h7cy+R5PB ZibXjumprw0wG7z9yPMBaiSptIcRC5RdRfQze4+x6aK5+2Sug8MoOrE0qFN7KL4Iv8l5 AYDQ== MIME-Version: 1.0 X-Received: by 10.68.218.65 with SMTP id pe1mr37922311pbc.1.1392796664497; Tue, 18 Feb 2014 23:57:44 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.30.1 with HTTP; Tue, 18 Feb 2014 23:57:44 -0800 (PST) In-Reply-To: <1392661158563-5886786.post@n5.nabble.com> References: <1392661158563-5886786.post@n5.nabble.com> Date: Tue, 18 Feb 2014 23:57:44 -0800 X-Google-Sender-Auth: 6JhtGmUtbUL016GJVEQeVRAwmlk Message-ID: Subject: Re: Base iconv (sort of) replaces libiconv in FreeBSD 10 From: Kevin Oberman To: Robert_Burmeister Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 07:57:45 -0000 On Mon, Feb 17, 2014 at 10:19 AM, Robert_Burmeister < robert.burmeister@utoledo.edu> wrote: > While base iconv replaces libiconv in FreeBSD 10, > base iconv doesn't do utf-8 -> wchar_t, > which is required by glib20, thus impacts thousands of ports. > > An entry in the FreeBSD 10 Errata stating that iconv is now in the base > system, > however, that it does not include all the functionality of libiconv from > ports, > would help make port maintainers aware of iconv issues. > Support for wchar_t is only one of the differences. The base iconv is fully posix compliant, but the port (GNU) library has several extra capabilities including wchat_t. Since the base iconv is in the kernel, not a shared library, it is not clear (to me) that that it is necessary to re-build ports that depend on ports that need libiconv. E.g. It does not appear that building glib20 with libiconv forces a rebuild of glibmm even though the wchar_t calls are triggered by rawtherapee to glibmm which actually makes the call to glib that tries to do the wchar_t operation. This is very different from a libtrary that had been in ports being moved to base such as openssl. This does force lots of rebuilds to prevent library version collisions that will cause load failures. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 08:53:32 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E1B0DA8; Wed, 19 Feb 2014 08:53:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 470031B11; Wed, 19 Feb 2014 08:53:31 +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 s1J8rOYa062671; Wed, 19 Feb 2014 03:53:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1J8rOaE062667; Wed, 19 Feb 2014 08:53:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Feb 2014 08:53:24 GMT Message-Id: <201402190853.s1J8rOaE062667@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 08:53:32 -0000 TB --- 2014-02-19 07:57:41 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-19 07:57:41 - 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 --- 2014-02-19 07:57:41 - starting HEAD tinderbox run for mips/mips TB --- 2014-02-19 07:57:41 - cleaning the object tree TB --- 2014-02-19 07:57:41 - /usr/local/bin/svn stat /src TB --- 2014-02-19 07:57:44 - At svn revision 262200 TB --- 2014-02-19 07:57:45 - building world TB --- 2014-02-19 07:57:45 - CROSS_BUILD_TESTING=YES TB --- 2014-02-19 07:57:45 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-19 07:57:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-19 07:57:45 - SRCCONF=/dev/null TB --- 2014-02-19 07:57:45 - TARGET=mips TB --- 2014-02-19 07:57:45 - TARGET_ARCH=mips TB --- 2014-02-19 07:57:45 - TZ=UTC TB --- 2014-02-19 07:57:45 - __MAKE_CONF=/dev/null TB --- 2014-02-19 07:57:45 - cd /src TB --- 2014-02-19 07:57:45 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Feb 19 07:57:52 UTC 2014 >>> 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 [...] /src/sys/boot/mips/beri/boot2/boot2.c:432: warning: cast to pointer from integer of different size /src/sys/boot/mips/beri/boot2/boot2.c: In function 'load': /src/sys/boot/mips/beri/boot2/boot2.c:440: error: 'BOOTINFO_DEV_TYPE_DRAM' undeclared (first use in this function) /src/sys/boot/mips/beri/boot2/boot2.c: In function 'parse': /src/sys/boot/mips/beri/boot2/boot2.c:544: warning: too many arguments for format /src/sys/boot/mips/beri/boot2/boot2.c: In function 'drvread': /src/sys/boot/mips/beri/boot2/boot2.c:583: error: 'BOOTINFO_DEV_TYPE_CFI' undeclared (first use in this function) /src/sys/boot/mips/beri/boot2/boot2.c:586: error: 'BOOTINFO_DEV_TYPE_SDCARD' undeclared (first use in this function) *** Error code 1 Stop. bmake[6]: stopped in /src/sys/boot/mips/beri/boot2 *** Error code 1 Stop. bmake[5]: stopped in /src/sys/boot/mips/beri *** Error code 1 Stop. bmake[4]: stopped in /src/sys/boot/mips *** Error code 1 Stop. bmake[3]: stopped in /src/sys/boot *** Error code 1 Stop. bmake[2]: stopped in /src/sys *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-19 08:53:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-19 08:53:24 - ERROR: failed to build world TB --- 2014-02-19 08:53:24 - 2343.84 user 604.73 system 3343.45 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 09:31:38 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37A59A15; Wed, 19 Feb 2014 09:31:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8D581FEA; Wed, 19 Feb 2014 09:31:37 +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 s1J9Vb6D020785; Wed, 19 Feb 2014 04:31:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1J9VaPU020784; Wed, 19 Feb 2014 09:31:36 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Feb 2014 09:31:36 GMT Message-Id: <201402190931.s1J9VaPU020784@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 09:31:38 -0000 TB --- 2014-02-19 08:35:44 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-19 08:35:44 - 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 --- 2014-02-19 08:35:44 - starting HEAD tinderbox run for mips64/mips TB --- 2014-02-19 08:35:44 - cleaning the object tree TB --- 2014-02-19 08:35:44 - /usr/local/bin/svn stat /src TB --- 2014-02-19 08:35:51 - At svn revision 262200 TB --- 2014-02-19 08:35:52 - building world TB --- 2014-02-19 08:35:52 - CROSS_BUILD_TESTING=YES TB --- 2014-02-19 08:35:52 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-19 08:35:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-19 08:35:52 - SRCCONF=/dev/null TB --- 2014-02-19 08:35:52 - TARGET=mips TB --- 2014-02-19 08:35:52 - TARGET_ARCH=mips64 TB --- 2014-02-19 08:35:52 - TZ=UTC TB --- 2014-02-19 08:35:52 - __MAKE_CONF=/dev/null TB --- 2014-02-19 08:35:52 - cd /src TB --- 2014-02-19 08:35:52 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Feb 19 08:35:59 UTC 2014 >>> 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 [...] /src/sys/boot/mips/beri/boot2/boot2.c:336: error: 'struct bootinfo' has no member named 'bi_memsize' /src/sys/boot/mips/beri/boot2/boot2.c: In function 'load': /src/sys/boot/mips/beri/boot2/boot2.c:440: error: 'BOOTINFO_DEV_TYPE_DRAM' undeclared (first use in this function) /src/sys/boot/mips/beri/boot2/boot2.c: In function 'parse': /src/sys/boot/mips/beri/boot2/boot2.c:544: warning: too many arguments for format /src/sys/boot/mips/beri/boot2/boot2.c: In function 'drvread': /src/sys/boot/mips/beri/boot2/boot2.c:583: error: 'BOOTINFO_DEV_TYPE_CFI' undeclared (first use in this function) /src/sys/boot/mips/beri/boot2/boot2.c:586: error: 'BOOTINFO_DEV_TYPE_SDCARD' undeclared (first use in this function) *** Error code 1 Stop. bmake[6]: stopped in /src/sys/boot/mips/beri/boot2 *** Error code 1 Stop. bmake[5]: stopped in /src/sys/boot/mips/beri *** Error code 1 Stop. bmake[4]: stopped in /src/sys/boot/mips *** Error code 1 Stop. bmake[3]: stopped in /src/sys/boot *** Error code 1 Stop. bmake[2]: stopped in /src/sys *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-19 09:31:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-19 09:31:36 - ERROR: failed to build world TB --- 2014-02-19 09:31:36 - 2336.84 user 590.12 system 3352.91 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 05:16:25 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C0CD121 for ; Wed, 19 Feb 2014 05:16:25 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCDE6191E for ; Wed, 19 Feb 2014 05:16:24 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wp4so19556718obc.39 for ; Tue, 18 Feb 2014 21:16:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=iZ0KmOrDNnMh1OGfUKDF2qSFBjjpv9jdZK9KmkKn1vs=; b=RO6FDjE0t5ZolFn2eX0Tn1Whnxg6tjCphCFOfOH2bCyHsyKt3yCVFePYHE6sQIO+sV txinPp2HCpKoxmV94PdR4WDUe0lGtT4zkT1ROBy5P2IoYXxEMpehpXctNKX5m6V5iEJt 26BbeTNyAkFIY4fNNHoFaWutO9Zd3wkCvClgLAD42OtWNGJTegvqBkhefzK4Y5fGG8No QU+uFVTtwbWo7sRXRjpCE7pPAh74vQp4t+BMrfTrXWklx8M64xJpQD8ZscEVxD53nyGa dtLfufdg/S6VElSXUezyP+cFySBkqy9oKFa3U90U9Hlhx6/mcSQdxbPGIbvkeemFyFXO yyGA== X-Gm-Message-State: ALoCoQmGHSEUvlKrDboRzSRbKSw9+0xVS6O8NqwBJSkYAASILGHmoE/WEXaA6z04M53dz5bap2GA X-Received: by 10.60.94.231 with SMTP id df7mr121450oeb.69.1392786977762; Tue, 18 Feb 2014 21:16:17 -0800 (PST) Received: from [10.0.0.90] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id z5sm66335490obg.13.2014.02.18.21.16.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 21:16:17 -0800 (PST) References: <20140214173553.GA90364@onelab2.iet.unipi.it> <1392402215.1145.103.camel@revolution.hippie.lan> <1392751469.1145.24.camel@revolution.hippie.lan> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: Warner Losh Subject: Re: HEAD buildkernel error (aic7xxx_seq.h is missing. Run 'make ahcfirmware') Date: Tue, 18 Feb 2014 22:16:15 -0700 To: Luigi Rizzo X-Mailman-Approved-At: Wed, 19 Feb 2014 12:39:07 +0000 Cc: FreeBSD Current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 05:16:25 -0000 Sent from my iPad > On Feb 18, 2014, at 9:38 PM, Luigi Rizzo wrote: >=20 >> On Tue, Feb 18, 2014 at 11:24 AM, Ian Lepore wrote: >>=20 >>> On Fri, 2014-02-14 at 13:46 -0800, Luigi Rizzo wrote: >>>> On Fri, Feb 14, 2014 at 10:23 AM, Ian Lepore wrote: >>>>=20 >>>>> On Fri, 2014-02-14 at 18:35 +0100, Luigi Rizzo wrote: >>>>> on a freshly checked out HEAD, >>>>> "make toolchain" followed by "make buildkernel" fails at this stage: >>>>>=20 >>>>> ... >>>>> @ -> /usr/home/luigi/FreeBSD/head/sys >>>>> machine -> /usr/home/luigi/FreeBSD/head/sys/amd64/include >>>>> x86 -> /usr/home/luigi/FreeBSD/head/sys/x86/include >>>>> Error: aic7xxx_reg_print.c is missing. Run 'make ahcfirmware' >>>>> Error: aic7xxx_seq.h is missing. Run 'make ahcfirmware' >>>>> Error: aic7xxx_reg.h is missing. Run 'make ahcfirmware' >>>>>=20 >>>>> (don't think it matters, but i am cross compiling amd64 >>>>> from a stable/9 amd64 system, using clang). >>>>> I am not sure which commit triggered the problem, >>>>> but this used to work in the past -- toolchain was enough >>>>> to build a kernel. >>>>>=20 >>>>> cheers >>>>> luigi >>>>=20 >>>> That should be 'make kernel-toolchain', shouldn't it? >>>=20 >>> nope, fails with kernel-toolchain as well. >>> I need to do a full buildworld to avoid this problem. >>>=20 >>> cheers >>> luigi >>=20 >> This all used to work when cross-building from older systems, but there >> were some changes recently to get rid of the whole process of compiling >> the aicasm tool. There's supposed to be some sort of binary firmware >> blob involved now. >>=20 >> Did you try what the error message recommended (make ahcfirmware)? >=20 > i have not tried partly for laziness partly because usually > these suggestions require the command to run in the > cross-building environment. >=20 > But i guess my point is that building aicasm should be > part of kernel-toolchain (or whatever the target is for > "all the tools we need to build a kernel"). >=20 > Now, if aicasm is not changing we can perhaps try to > reuse the one in the host environment, in which > case i'd first try to support the same feature to > avoid rebuilding clang or gcc. The actual problem is old make. Old make doesn't parse this construct right,= but new make does. That's why some people hit it and others don't. The righ= t answer isn't to make aicasm a tool (which I tried and it failed the same w= ay). It would be better to disable these targets for old make. Warner > thanks > luigi > _______________________________________________ > 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 Feb 19 14:32:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FE8F877 for ; Wed, 19 Feb 2014 14:32:08 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 604E71C36 for ; Wed, 19 Feb 2014 14:32:08 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1WG8Bz-0000zS-4Q for freebsd-current@freebsd.org; Wed, 19 Feb 2014 06:32:07 -0800 Date: Wed, 19 Feb 2014 06:32:07 -0800 (PST) From: Robert_Burmeister To: freebsd-current@freebsd.org Message-ID: <1392820327124-5887307.post@n5.nabble.com> In-Reply-To: References: <1392661158563-5886786.post@n5.nabble.com> Subject: Re: Base iconv (sort of) replaces libiconv in FreeBSD 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Feb 2014 15:01:48 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 14:32:08 -0000 As I use the Gnome2 desktop, I am unclear as to the recommended best practice. Base iconv and ports libiconv conflict, so one or the other should be used. FreeBSD 10 has been updated so that either base iconv or ports libiconv can be used. For me to switch between the two requires a two day recompile. I removed converters/libiconv for FreeBSD 10, as use of base iconv is now more correct. Since, glib20 has added dependancy libiconv back in, which affects many ports. (I was at first elated that iconv was finally in the base system, as updating libiconv causes much havok.) I am also working on the problem of USB drives no longer mounting from user space like they did on FreeBSD 9. An increasing number of people are noting this issue, and like descriptions of the issue were being related to iconv issues. http://www.freebsd.org/cgi/query-pr.cgi?pr=109024 I don't know whether I should continue to trouble shoot base iconv issues, or try to stick with ports' converters/libiconv until FreeBSD 11? Will use of both be somehow supported??? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Base-iconv-sort-of-replaces-libiconv-in-FreeBSD-10-tp5886786p5887307.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 15:34:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F22E1A52 for ; Wed, 19 Feb 2014 15:34:43 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE5C81330 for ; Wed, 19 Feb 2014 15:34:43 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s1JFYhJc046520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Feb 2014 07:34:43 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s1JFYCtc046502; Wed, 19 Feb 2014 07:34:12 -0800 (PST) (envelope-from sgk) Date: Wed, 19 Feb 2014 07:34:12 -0800 From: Steve Kargl To: Robert_Burmeister Subject: Re: Base iconv (sort of) replaces libiconv in FreeBSD 10 Message-ID: <20140219153412.GA46474@troutmask.apl.washington.edu> References: <1392661158563-5886786.post@n5.nabble.com> <1392820327124-5887307.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1392820327124-5887307.post@n5.nabble.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 15:34:44 -0000 On Wed, Feb 19, 2014 at 06:32:07AM -0800, Robert_Burmeister wrote: > As I use the Gnome2 desktop, I am unclear as to the recommended best > practice. > > Base iconv and ports libiconv conflict, so one or the other should be used. See the commit made 3 days ago to glib20 port. Of particular interest to you are these 3 lines from devel/glib20/Makefile: # iconv:wchar_t - our iconv in base doesn't support utf-8 -> wchar_t (boooo) # (wchar_t is used by glibmm, rawtherapee triggered this) USES= gettext gmake iconv:wchar_t pathfix pkgconfig shebangfix perl5 -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 16:49:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD07FB68 for ; Wed, 19 Feb 2014 16:49:16 +0000 (UTC) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id 783F91AD6 for ; Wed, 19 Feb 2014 16:49:16 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGAGbfBFNbsI2W/2dsb2JhbABZDoJ4rGaRHIMGgRcXdIIlAQEEATocIwULCxgJJQ8qHgaIEAwBzXAXjmQHhDgBA5gvkiWCbkA7 Received: from 150.141-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.141.150]) by relay.skynet.be with ESMTP; 19 Feb 2014 17:49:14 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s1JGnCGH098280; Wed, 19 Feb 2014 17:49:13 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Wed, 19 Feb 2014 17:49:12 +0100 From: Tijl Coosemans To: Robert_Burmeister Subject: Re: Base iconv (sort of) replaces libiconv in FreeBSD 10 Message-ID: <20140219174912.41832465@kalimero.tijl.coosemans.org> In-Reply-To: <1392820327124-5887307.post@n5.nabble.com> References: <1392661158563-5886786.post@n5.nabble.com> <1392820327124-5887307.post@n5.nabble.com> 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.17 Precedence: 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, 19 Feb 2014 16:49:16 -0000 On Wed, 19 Feb 2014 06:32:07 -0800 (PST) Robert_Burmeister wrote: > As I use the Gnome2 desktop, I am unclear as to the recommended best > practice. > > Base iconv and ports libiconv conflict, so one or the other should be used. > FreeBSD 10 has been updated so that either base iconv or ports libiconv can > be used. > For me to switch between the two requires a two day recompile. > > I removed converters/libiconv for FreeBSD 10, as use of base iconv is now > more correct. This conflict has been resolved so both can be installed at the same time now. The intention is that only ports that need libiconv will use it. The large majority continues to use base iconv. > (I was at first elated that iconv was finally in the base system, as > updating libiconv causes much havok.) This is actually an issue with libtool which propagates dependencies on libraries. Now that glib depends on libiconv everything that depends on glib will also register a dependency on libiconv even if they don't use it directly. This is something we are also trying to solve and then updates to libiconv will become fairly painless. > Is there a time frame for adding GNU iconv extensions to the base system > iconv? i.e. FreeBSD 10 or Freebsd 11? Nobody is working on that as far as I know. From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 17:02:04 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D1C537B; Wed, 19 Feb 2014 17:02:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E89A1C62; Wed, 19 Feb 2014 17:02:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s1JH22WU094283; Wed, 19 Feb 2014 12:02:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1JH22SM094279; Wed, 19 Feb 2014 17:02:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Feb 2014 17:02:02 GMT Message-Id: <201402191702.s1JH22SM094279@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:02:04 -0000 TB --- 2014-02-19 16:07:40 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-19 16:07:40 - 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 --- 2014-02-19 16:07:40 - starting HEAD tinderbox run for mips/mips TB --- 2014-02-19 16:07:40 - cleaning the object tree TB --- 2014-02-19 16:08:37 - /usr/local/bin/svn stat /src TB --- 2014-02-19 16:08:40 - At svn revision 262219 TB --- 2014-02-19 16:08:41 - building world TB --- 2014-02-19 16:08:41 - CROSS_BUILD_TESTING=YES TB --- 2014-02-19 16:08:41 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-19 16:08:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-19 16:08:41 - SRCCONF=/dev/null TB --- 2014-02-19 16:08:41 - TARGET=mips TB --- 2014-02-19 16:08:41 - TARGET_ARCH=mips TB --- 2014-02-19 16:08:41 - TZ=UTC TB --- 2014-02-19 16:08:41 - __MAKE_CONF=/dev/null TB --- 2014-02-19 16:08:41 - cd /src TB --- 2014-02-19 16:08:41 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Feb 19 16:08:48 UTC 2014 >>> 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 [...] ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(printf.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(printf.o) ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(strlen.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(strlen.o) ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(qdivrem.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(qdivrem.o) ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(bcd.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(bcd.o) *** Error code 1 Stop. bmake[6]: stopped in /src/sys/boot/mips/beri/boot2 *** Error code 1 Stop. bmake[5]: stopped in /src/sys/boot/mips/beri *** Error code 1 Stop. bmake[4]: stopped in /src/sys/boot/mips *** Error code 1 Stop. bmake[3]: stopped in /src/sys/boot *** Error code 1 Stop. bmake[2]: stopped in /src/sys *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-19 17:02:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-19 17:02:02 - ERROR: failed to build world TB --- 2014-02-19 17:02:02 - 2343.76 user 611.09 system 3262.54 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 17:40:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C9E031C; Wed, 19 Feb 2014 17:40:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46E291094; Wed, 19 Feb 2014 17:40:27 +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 s1JHeOES053700; Wed, 19 Feb 2014 12:40:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1JHeO8C053699; Wed, 19 Feb 2014 17:40:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 19 Feb 2014 17:40:24 GMT Message-Id: <201402191740.s1JHeO8C053699@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:40:28 -0000 TB --- 2014-02-19 16:44:50 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-19 16:44:50 - 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 --- 2014-02-19 16:44:50 - starting HEAD tinderbox run for mips64/mips TB --- 2014-02-19 16:44:50 - cleaning the object tree TB --- 2014-02-19 16:45:38 - /usr/local/bin/svn stat /src TB --- 2014-02-19 16:45:41 - At svn revision 262219 TB --- 2014-02-19 16:45:42 - building world TB --- 2014-02-19 16:45:42 - CROSS_BUILD_TESTING=YES TB --- 2014-02-19 16:45:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-19 16:45:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-19 16:45:42 - SRCCONF=/dev/null TB --- 2014-02-19 16:45:42 - TARGET=mips TB --- 2014-02-19 16:45:42 - TARGET_ARCH=mips64 TB --- 2014-02-19 16:45:42 - TZ=UTC TB --- 2014-02-19 16:45:42 - __MAKE_CONF=/dev/null TB --- 2014-02-19 16:45:42 - cd /src TB --- 2014-02-19 16:45:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Feb 19 16:45:50 UTC 2014 >>> 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 [...] vm.c:(.text+0x404): relocation truncated to fit: R_MIPS_GOT_DISP against `no symbol' vm.c:(.text+0x408): relocation truncated to fit: R_MIPS_GOT_DISP against `no symbol' vm.c:(.text+0x40c): relocation truncated to fit: R_MIPS_CALL16 against `__assert' /obj/mips.mips64/src/sys/boot/mips/beri/loader/../../../ficl/libficl.a(vm.o): In function `vmGetWord0': vm.c:(.text+0x490): relocation truncated to fit: R_MIPS_CALL16 against `skipSpace' /obj/mips.mips64/src/sys/boot/mips/beri/loader/../../../ficl/libficl.a(vm.o): In function `vmTextOut': vm.c:(.text+0x590): relocation truncated to fit: R_MIPS_GOT_DISP against `no symbol' vm.c:(.text+0x594): additional relocation overflows omitted from the output *** Error code 1 Stop. bmake[6]: stopped in /src/sys/boot/mips/beri/loader *** Error code 1 Stop. bmake[5]: stopped in /src/sys/boot/mips/beri *** Error code 1 Stop. bmake[4]: stopped in /src/sys/boot/mips *** Error code 1 Stop. bmake[3]: stopped in /src/sys/boot *** Error code 1 Stop. bmake[2]: stopped in /src/sys *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-19 17:40:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-19 17:40:24 - ERROR: failed to build world TB --- 2014-02-19 17:40:24 - 2339.21 user 595.64 system 3333.31 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 18:58:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE5802FC for ; Wed, 19 Feb 2014 18:58:36 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5A421771 for ; Wed, 19 Feb 2014 18:58:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B4F38B95B; Wed, 19 Feb 2014 13:58:35 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Device File Creation Time Date: Wed, 19 Feb 2014 13:44:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201402191344.21738.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Feb 2014 13:58:35 -0500 (EST) Cc: Bruno =?iso-8859-1?q?Lauz=E9?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 18:58:37 -0000 On Tuesday, February 18, 2014 3:02:16 pm Bruno Lauz=E9 wrote: > root@pcbsd:/dev # stat /dev/ada0 > 1895890688 97 crw-rw-rw- 1 root operator 97 0 "Feb 18 10:52:11 2014" "Feb= 17=20 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0=20 /dev/ada0 >=20 > root@pcbsd:/dev # stat /dev/ada0p2 > 1895890688 103 crw-rw-rw- 1 root operator 103 0 "Feb 18 10:52:05 2014" "F= eb=20 17 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0=20 /dev/ada0p2 >=20 > root@pcbsd:/dev # stat /dev/ada0p3 > 1895890688 105 crw-rw-rw- 1 root operator 105 0 "Feb 18 10:52:21 2014" "F= eb=20 17 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0=20 /dev/ada0p3 >=20 > As we can see all files in devfs reports Dec 31 1969 as creation time. >=20 > Can we look to manage this value to know when a certain device was=20 installed? >=20 > It would be really great to know when a disk was replaced. >=20 > Would there be any other mechanism to accomplish this? I think if you hot attach a device post-boot it will have the time it was=20 attached as the birth time. I think it is only devices created during boot= =20 that use time 0. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 19:20:58 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0020EDB2; Wed, 19 Feb 2014 19:20:57 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C10A01939; Wed, 19 Feb 2014 19:20:57 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WGChU-000Fqr-Gj; Wed, 19 Feb 2014 19:20:56 +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 s1JJKrX8030231; Wed, 19 Feb 2014 12:20:53 -0700 (MST) (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+L9rBGvHcOIp1L8dk5Wdf9 Subject: Re: Device File Creation Time From: Ian Lepore To: John Baldwin In-Reply-To: <201402191344.21738.jhb@freebsd.org> References: <201402191344.21738.jhb@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 19 Feb 2014 12:20:53 -0700 Message-ID: <1392837653.1145.41.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s1JJKrX8030231 Cc: Bruno =?ISO-8859-1?Q?Lauz=E9?= , freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 19:20:58 -0000 On Wed, 2014-02-19 at 13:44 -0500, John Baldwin wrote: > On Tuesday, February 18, 2014 3:02:16 pm Bruno Lauz=E9 wrote: > > root@pcbsd:/dev # stat /dev/ada0 > > 1895890688 97 crw-rw-rw- 1 root operator 97 0 "Feb 18 10:52:11 2014" = "Feb 17=20 > 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 0=20 > /dev/ada0 > >=20 > > root@pcbsd:/dev # stat /dev/ada0p2 > > 1895890688 103 crw-rw-rw- 1 root operator 103 0 "Feb 18 10:52:05 2014= " "Feb=20 > 17 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 = 0=20 > /dev/ada0p2 > >=20 > > root@pcbsd:/dev # stat /dev/ada0p3 > > 1895890688 105 crw-rw-rw- 1 root operator 105 0 "Feb 18 10:52:21 2014= " "Feb=20 > 17 09:36:43 2014" "Feb 17 09:36:43 2014" "Dec 31 17:59:59 1969" 4096 0 = 0=20 > /dev/ada0p3 > >=20 > > As we can see all files in devfs reports Dec 31 1969 as creation time. > >=20 > > Can we look to manage this value to know when a certain device was=20 > installed? > >=20 > > It would be really great to know when a disk was replaced. > >=20 > > Would there be any other mechanism to accomplish this? >=20 > I think if you hot attach a device post-boot it will have the time it w= as=20 > attached as the birth time. I think it is only devices created during = boot=20 > that use time 0. >=20 That's actually a time of -1 converted to some local timezone. I'm not sure that's germane, just thought I'd mention it. revolution > date -jur -1 Wed Dec 31 23:59:59 UTC 1969 -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 19:40:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B5C2C28; Wed, 19 Feb 2014 19:40:45 +0000 (UTC) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 96B881BE6; Wed, 19 Feb 2014 19:40:44 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id e51so340686eek.30 for ; Wed, 19 Feb 2014 11:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=AJWRW5BvtIktqLdiSbIGQr6fS9n54lzMsUVK+6xN5Zc=; b=J2Aj/ogk3gD7gbHvR8ldQBLA6TVvbaVn+d9LyCcbIu3FVL+auq2f6/FVA5dwx2GqgR m+vodjW8gsxFTwOm+zKNlPmuNQkBUrD/1RMNRgm1ZvT27o+muX763UgD7SHw6oEVZ/TS azGZMjDPz8Icn5Vk17OHuwbId3nmObpcnqm5d284aEYzd4cjNZ7WpfmUVrG4hiIXxkwa 43RXHmUDxd0tFGP/ffrspP6fZGLE+mwI7GPOlUgiCTsD2FyrJIxSyReMZsger19Tp4id S8SB4l/T4YpdNYiKiNy0xuEEM53QmJD2DruwSpo4SvqymkhXteMXZtbKC0s52pDXlFM2 vA3g== X-Received: by 10.14.149.131 with SMTP id x3mr41808707eej.7.1392838842978; Wed, 19 Feb 2014 11:40:42 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id f45sm4375551eeg.5.2014.02.19.11.40.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 11:40:41 -0800 (PST) Sender: Alexander Motin Message-ID: <530508B7.7060102@FreeBSD.org> Date: Wed, 19 Feb 2014 21:40:39 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 19:40:45 -0000 Hi. Clock interrupt threads, same as other ones are only softly bound to specific CPUs by scheduler preferring to run them on CPUs where they are scheduled. So far that was enough to balance load, but allowed threads to migrate, if needed. Is it too flexible for some use case? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 19:51:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E9F055F; Wed, 19 Feb 2014 19:51:24 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDC181CE4; Wed, 19 Feb 2014 19:51:23 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id w8so1344476qac.14 for ; Wed, 19 Feb 2014 11:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=X6kNn5lN+MC2b63xQb/SfNCqkKNbURa6SF3LWah8+hM=; b=IUOmYzcb7wLTInvCC1V1jalVn7UgVmahUDExLmX+ixc3pht1YXyAk7Nb983zbylxUl GqzhoEwPiiuVO1d+fc0Pr/jE+Okv/9SJhiozFpHoc2kk9KASrSgLJm/5kov7rFkjlnh+ /JH9GuZ8EP69a90BltAh1Vv18iaqsOVjU9W7lZ0eWCRYEnYBkBnUBJUXt7PxvYiThsct OYfk1XUeQyJc1B7cOOLmD37QbI9wpQaiYLpctDetIWGXIn2S0bcWxrOpULRTXOe+iy5B rTC3PgKD0G+fBFH4UMMwOzyDZLKHgrK2MgDzWh/vMRdHz4rloBvlRKpx58nrsT+Bu8qh 7j6g== MIME-Version: 1.0 X-Received: by 10.224.121.137 with SMTP id h9mr53542985qar.55.1392839483145; Wed, 19 Feb 2014 11:51:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 11:51:23 -0800 (PST) In-Reply-To: <530508B7.7060102@FreeBSD.org> References: <530508B7.7060102@FreeBSD.org> Date: Wed, 19 Feb 2014 11:51:23 -0800 X-Google-Sender-Auth: GGQpyPjUteZDH3ufNKQq0jlXsgk Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 19:51:24 -0000 On 19 February 2014 11:40, Alexander Motin wrote: > Hi. > > Clock interrupt threads, same as other ones are only softly bound to > specific CPUs by scheduler preferring to run them on CPUs where they are > scheduled. So far that was enough to balance load, but allowed threads to > migrate, if needed. Is it too flexible for some use case? I saw it migrate under enough CPU load / pressure, right smack bang in the middle of doing TCP processing. So if we're moving towards supporting (among others) a pcbgroup / RSS hash style work load distribution across CPUs to minimise per-connection lock contention, we really don't want the scheduler to decide it can schedule things on other CPUs under enough pressure. That'll just make things worse. -a From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 19:59:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EEAD7ED; Wed, 19 Feb 2014 19:59:39 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3511D43; Wed, 19 Feb 2014 19:59:38 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id t61so712668wes.8 for ; Wed, 19 Feb 2014 11:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lFoxSb/Qa7RlBFsdnMBYmMBxHLL22X+hS5e7yNG2j40=; b=mAnh1BdvWm5m2B7ENLrsS+IdrlpgyG6b6sLvdX+Tp0hWOZJK3ML9UsFAoL5Pl+JRGo zggZmv2L3iHeHIah7ikI8dmDGGBK2NtOCyWOEQjkUt52ztfbHoz9EeHTCmqmiXZIq36t q6KP3vMJNeNFxoA7yMtNDVIoob1WPMBbIv1kzRrspKSmdCWcMSO9/SJkSNML4/fNpFUy LkrB5dE1zvqrNXWoiFzQ78rzqWYe+B3j5c61MR1/VdZr2vPAfZiIMSmRSZufiu3O7Tk/ bhjk/p3eK07wvcA+ozUYJJYAvrcHXCJofRjeftwhSqY3CZRjSvRdOho2Q67Dfa4CxoFw ydbA== X-Received: by 10.15.81.196 with SMTP id x44mr41590044eey.31.1392839976375; Wed, 19 Feb 2014 11:59:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id o45sm4513341eeb.18.2014.02.19.11.59.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 11:59:35 -0800 (PST) Sender: Alexander Motin Message-ID: <53050D24.3020505@FreeBSD.org> Date: Wed, 19 Feb 2014 21:59:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 19:59:39 -0000 On 19.02.2014 21:51, Adrian Chadd wrote: > On 19 February 2014 11:40, Alexander Motin wrote: >> Clock interrupt threads, same as other ones are only softly bound to >> specific CPUs by scheduler preferring to run them on CPUs where they are >> scheduled. So far that was enough to balance load, but allowed threads to >> migrate, if needed. Is it too flexible for some use case? > > I saw it migrate under enough CPU load / pressure, right smack bang in > the middle of doing TCP processing. > > So if we're moving towards supporting (among others) a pcbgroup / RSS > hash style work load distribution across CPUs to minimise > per-connection lock contention, we really don't want the scheduler to > decide it can schedule things on other CPUs under enough pressure. > That'll just make things worse. True, though it is also not obvious that putting second thread on CPU run queue is better then executing it right now on another core. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 20:04:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C54B0CA8; Wed, 19 Feb 2014 20:04:52 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0F71E01; Wed, 19 Feb 2014 20:04:52 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id x13so1487713qcv.34 for ; Wed, 19 Feb 2014 12:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IqvWeHcGadUnOsbPLAtj5kksQ0xjEHFOAFLbQiR/TM8=; b=TXPLYIGrVzR0xx+m67xsrwLglssbQzNe8wLHxJNZ3CyuNj95JHgxcRuQV3Ugp/I+f7 UJQRytl0uUKY6LygLQydJmUs0/2A01+4LL+yqofksit5hoeVUAl6I1zcRi44DAeQEgzB XXD0PARwjac8GKAoGfv+XqPd86FT+OOy0lcZg4+v4KQQ6FOyb6hS6rrt57nhoJa/7jl4 BMXyHuo6vbYRuKF3SXHYo+g3YImZ14L2gqttsLDnYUm56972+QfaBBUDsQUhGr3KAR8z tQtrD+2K31vR7G5aipAk8iKLlz7gJy5soetOEFvww/q450aqbEWPwVVIt6uHVOWRXRvt Y7CA== MIME-Version: 1.0 X-Received: by 10.224.121.137 with SMTP id h9mr53658877qar.55.1392840291480; Wed, 19 Feb 2014 12:04:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 12:04:51 -0800 (PST) In-Reply-To: <53050D24.3020505@FreeBSD.org> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> Date: Wed, 19 Feb 2014 12:04:51 -0800 X-Google-Sender-Auth: 726LKOLQ3R1buKQFdHLdOFFrTKQ Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 20:04:52 -0000 On 19 February 2014 11:59, Alexander Motin wrote: >> So if we're moving towards supporting (among others) a pcbgroup / RSS >> hash style work load distribution across CPUs to minimise >> per-connection lock contention, we really don't want the scheduler to >> decide it can schedule things on other CPUs under enough pressure. >> That'll just make things worse. > True, though it is also not obvious that putting second thread on CPU run > queue is better then executing it right now on another core. Well, it depends if you're trying to optimise for "run all runnable tasks as quickly as possible" or "run all runnable tasks in contexts that minimise lock contention." The former sounds great as long as there's no real lock contention going on. But as you add more chances for contention (something like "100,000 concurrent TCP flows") then you may end up having your TCP timer firing stuff interfere with more TXing or RXing on the same connection. Chasing this stuff down is a pain, because it only really shows up when you're doing lots of concurrency. I'm happy to make this a boot-time option and leave it off for the time being. How's that? -a From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 20:32:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C56EE579 for ; Wed, 19 Feb 2014 20:32:17 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id AF333117A for ; Wed, 19 Feb 2014 20:32:17 +0000 (UTC) Received: from Alfreds-MacBook-Pro.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id F30C21A3C38 for ; Wed, 19 Feb 2014 12:32:16 -0800 (PST) Message-ID: <530514F0.2000609@mu.org> Date: Wed, 19 Feb 2014 12:32:48 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 20:32:17 -0000 On 2/19/14, 12:04 PM, Adrian Chadd wrote: > On 19 February 2014 11:59, Alexander Motin wrote: > >>> So if we're moving towards supporting (among others) a pcbgroup / RSS >>> hash style work load distribution across CPUs to minimise >>> per-connection lock contention, we really don't want the scheduler to >>> decide it can schedule things on other CPUs under enough pressure. >>> That'll just make things worse. >> True, though it is also not obvious that putting second thread on CPU run >> queue is better then executing it right now on another core. > Well, it depends if you're trying to optimise for "run all runnable > tasks as quickly as possible" or "run all runnable tasks in contexts > that minimise lock contention." > > The former sounds great as long as there's no real lock contention > going on. But as you add more chances for contention (something like > "100,000 concurrent TCP flows") then you may end up having your TCP > timer firing stuff interfere with more TXing or RXing on the same > connection. > > Chasing this stuff down is a pain, because it only really shows up > when you're doing lots of concurrency. > > I'm happy to make this a boot-time option and leave it off for the > time being. How's that? options THROUGHPUT Yes, looks like a latency vs throughput issue. One giant switch might be a starting point so that it doesn't become death of 1000 switches to get throughput or latency sensitive work done. > > > > -a > _______________________________________________ > 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 Feb 19 21:04:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CE9231B; Wed, 19 Feb 2014 21:04:55 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5115E1445; Wed, 19 Feb 2014 21:04:54 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id e49so477480eek.0 for ; Wed, 19 Feb 2014 13:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FB0GMNpZOBmSHQf7WepADuZcQqRlVrLrhRN+FxFJx1k=; b=x2w2ZW/RrLTiaquWqQ88uFyAedhD67Vn2LjpOFtZRb0/DRuRT3Bbzsm1P41C4EYKQr ZJRwLSJ5fsbRiOcpNfX9cbHObyfHiVC9ZW9vbgFymU94pfsLTUaRzkKjjHJ2N+/CPROA XF/UMha5q6vlQN0k9ctW6qBvAeS2LhHGN3qtvYwmDuYzNf48ltq6sKZ+7shNoFX86yhW nw/+9aY7oxmjiTTTMxk2KehuUpdkEK0c1e1XOXoApD/A0ChwsWSyyhALLmPOBz+9hsMC Jg3sFyUI2XtCr7in2wH+PmfPd2bRmVRhaW3K9uYc2TrXN9aiDlT3vJRFwgJkf3Cc9vwW u4kw== X-Received: by 10.15.98.68 with SMTP id bi44mr16976364eeb.67.1392843892638; Wed, 19 Feb 2014 13:04:52 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id u6sm5116099eep.11.2014.02.19.13.04.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 13:04:51 -0800 (PST) Sender: Alexander Motin Message-ID: <53051C71.3050705@FreeBSD.org> Date: Wed, 19 Feb 2014 23:04:49 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeffrey Faden , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 21:04:55 -0000 On 19.02.2014 22:04, Adrian Chadd wrote: > On 19 February 2014 11:59, Alexander Motin wrote: > >>> So if we're moving towards supporting (among others) a pcbgroup / RSS >>> hash style work load distribution across CPUs to minimise >>> per-connection lock contention, we really don't want the scheduler to >>> decide it can schedule things on other CPUs under enough pressure. >>> That'll just make things worse. > >> True, though it is also not obvious that putting second thread on CPU run >> queue is better then executing it right now on another core. > > Well, it depends if you're trying to optimise for "run all runnable > tasks as quickly as possible" or "run all runnable tasks in contexts > that minimise lock contention." > > The former sounds great as long as there's no real lock contention > going on. But as you add more chances for contention (something like > "100,000 concurrent TCP flows") then you may end up having your TCP > timer firing stuff interfere with more TXing or RXing on the same > connection. 100K TCP flows probably means 100K locks. That means that chance of lock collision on each of them is effectively zero. More realistic it could be to speak about cache coherency traffic, etc, but I still think that number of expired timeouts should be much lower then number of other flow data accesses. > Chasing this stuff down is a pain, because it only really shows up > when you're doing lots of concurrency. > > I'm happy to make this a boot-time option and leave it off for the > time being. How's that? I generally hate tunables like that. There are too few people who may even try to make grounded decision in that question. If you think it right -- just do it, otherwise -- don't do it. I am not really objecting, more like sounding concerns. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 21:04:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F5C8417; Wed, 19 Feb 2014 21:04:59 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 452531447; Wed, 19 Feb 2014 21:04:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5DE0BB972; Wed, 19 Feb 2014 16:04:58 -0500 (EST) From: John Baldwin To: Adrian Chadd Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Date: Wed, 19 Feb 2014 16:02:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201402191602.54465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 19 Feb 2014 16:04:58 -0500 (EST) Cc: Alexander Motin , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 21:04:59 -0000 On Wednesday, February 19, 2014 3:04:51 pm Adrian Chadd wrote: > On 19 February 2014 11:59, Alexander Motin wrote: > > >> So if we're moving towards supporting (among others) a pcbgroup / RSS > >> hash style work load distribution across CPUs to minimise > >> per-connection lock contention, we really don't want the scheduler to > >> decide it can schedule things on other CPUs under enough pressure. > >> That'll just make things worse. > > > True, though it is also not obvious that putting second thread on CPU run > > queue is better then executing it right now on another core. > > Well, it depends if you're trying to optimise for "run all runnable > tasks as quickly as possible" or "run all runnable tasks in contexts > that minimise lock contention." > > The former sounds great as long as there's no real lock contention > going on. But as you add more chances for contention (something like > "100,000 concurrent TCP flows") then you may end up having your TCP > timer firing stuff interfere with more TXing or RXing on the same > connection. > > Chasing this stuff down is a pain, because it only really shows up > when you're doing lots of concurrency. > > I'm happy to make this a boot-time option and leave it off for the > time being. How's that? I think having it be a tunable would be good. OTOH, I could also see another option which would be to pin all clock threads except for the "default" one by default and only have the option control whether or not the default thread is pinned to CPU 0 as callers who use callout_on() are explicitly asking to run the callout on a specific CPU. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 21:28:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CC9DCB5; Wed, 19 Feb 2014 21:28:16 +0000 (UTC) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45CC21655; Wed, 19 Feb 2014 21:28:16 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward9l.mail.yandex.net (Yandex) with ESMTP id 02F37E61027; Thu, 20 Feb 2014 01:28:04 +0400 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id 9B2BC1B435E9; Thu, 20 Feb 2014 01:28:04 +0400 (MSK) Received: from unknown (unknown [178.76.234.16]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Cu3oRduXWN-S4buRccR; Thu, 20 Feb 2014 01:28:04 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5a73752b-3cea-44c0-bc34-e586c3d78d5a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1392845284; bh=RX280lHkt1WwPyIC2BDOgApJn1AJSqvAd/4dBvCcXMM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fkwv97CQdpLhLX2I/DDir4XEXGnboC1o9DoKHCAumNQNyjm6V2iXJhWtBHvZivo8G 4uYvwV2XIM7xvEItSILGQ4ce8//IjCk1TsiOPmviOA5xAm/MeFxuta3rSAyisvSucx c3U+BVcTqBfZ01wXuUBF3/VBadnXDuToWrhF8CoQ= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <530521DF.4010205@yandex.ru> Date: Thu, 20 Feb 2014 01:27:59 +0400 From: Ruslan Makhmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: ssh-keygen -Z References: <53008ECD.2070004@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 21:28:16 -0000 Benjamin Kaduk wrote on 17.02.2014 08:56: > On Sun, 16 Feb 2014, Ruslan Makhmatkhanov wrote: > >> Hello, >> >> there is -Z parameter in ssh-keygen --help output, but no mention of >> it in ssh-keygen's man-page. Any clue what values this parameter accept? > > It is the "new-format ciphername", which can be used for RSA keys if the > new format file is being used, and is used for the elliptic curve keys, > if I'm reading things correctly. I guess that would mean that it accepts > things like "chacha20-poly1305@openssh.com" and "aes256-ctr" (see the > table ciphers[] in cipher.c), though I don't know which ones make sense > to pass in there. > > I guess we should ask the OpenBSD folks to document it, the -Z argument > was added to ssh-keygen.c in r1.237 back in December. > > -Ben Thank you for description! -- Regards, Ruslan T.O.S. Of Reality From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 21:44:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D74B5287; Wed, 19 Feb 2014 21:44:29 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6395317C2; Wed, 19 Feb 2014 21:44:29 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1WGEwO-000ERU-3P; Thu, 20 Feb 2014 01:44:28 +0400 Date: Thu, 20 Feb 2014 01:44:28 +0400 From: Slawa Olhovchenkov To: Alexander Motin Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Message-ID: <20140219214428.GA53864@zxy.spb.ru> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53051C71.3050705@FreeBSD.org> 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 Cc: Adrian Chadd , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 21:44:29 -0000 On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: > On 19.02.2014 22:04, Adrian Chadd wrote: > > On 19 February 2014 11:59, Alexander Motin wrote: > > > >>> So if we're moving towards supporting (among others) a pcbgroup / RSS > >>> hash style work load distribution across CPUs to minimise > >>> per-connection lock contention, we really don't want the scheduler to > >>> decide it can schedule things on other CPUs under enough pressure. > >>> That'll just make things worse. > > > >> True, though it is also not obvious that putting second thread on CPU run > >> queue is better then executing it right now on another core. > > > > Well, it depends if you're trying to optimise for "run all runnable > > tasks as quickly as possible" or "run all runnable tasks in contexts > > that minimise lock contention." > > > > The former sounds great as long as there's no real lock contention > > going on. But as you add more chances for contention (something like > > "100,000 concurrent TCP flows") then you may end up having your TCP > > timer firing stuff interfere with more TXing or RXing on the same > > connection. > > 100K TCP flows probably means 100K locks. That means that chance of lock > collision on each of them is effectively zero. More realistic it could What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP timeouts callbacks? From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 22:09:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAAE7BC3; Wed, 19 Feb 2014 22:09:11 +0000 (UTC) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 016EE1960; Wed, 19 Feb 2014 22:09:10 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e53so528383eek.27 for ; Wed, 19 Feb 2014 14:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VuqIlI8+Gqs2IbN7BUiL11bTjatcrP2K8ne1jPqP2ok=; b=mZOSlh7QeZknQcNQQpBuzI5jYEnqrE+szjAtyVUHexZp3dGM40Wrk5U8CsWqz6s6Eg haW9QrRGFXPRzAPyAme8MDmhNTK7RTuzpA0RJOMbDY+RuQrYMnU1gm+bYMwdLtTflEKv 419/7GIW8dSiNpO8lUYJ7WVZBUTGH9x6rpHN0eUysHcOc7FYbxZ0SX+tAZGGC9kQ0pzc irIJsLBcTnGqfMYC2bUotyxaceELQQsR7HY84KyaaRbXUUMDVGhSBvHAgat6rcjoCK/h Dnn/H0Zaa6X68JHMGhrtrZkBKX2jHc1F9uO+hZFjq5ptNZwTuULIKLicMD8euL+c1qUZ +xtg== X-Received: by 10.14.176.66 with SMTP id a42mr4533470eem.101.1392847748155; Wed, 19 Feb 2014 14:09:08 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id 43sm3949365eeh.13.2014.02.19.14.09.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 14:09:07 -0800 (PST) Sender: Alexander Motin Message-ID: <53052B80.3010505@FreeBSD.org> Date: Thu, 20 Feb 2014 00:09:04 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: [rfc] bind per-cpu timeout threads to each CPU References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> In-Reply-To: <20140219214428.GA53864@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 22:09:11 -0000 On 19.02.2014 23:44, Slawa Olhovchenkov wrote: > On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: > >> On 19.02.2014 22:04, Adrian Chadd wrote: >>> On 19 February 2014 11:59, Alexander Motin wrote: >>> >>>>> So if we're moving towards supporting (among others) a pcbgroup / RSS >>>>> hash style work load distribution across CPUs to minimise >>>>> per-connection lock contention, we really don't want the scheduler to >>>>> decide it can schedule things on other CPUs under enough pressure. >>>>> That'll just make things worse. >>> >>>> True, though it is also not obvious that putting second thread on CPU run >>>> queue is better then executing it right now on another core. >>> >>> Well, it depends if you're trying to optimise for "run all runnable >>> tasks as quickly as possible" or "run all runnable tasks in contexts >>> that minimise lock contention." >>> >>> The former sounds great as long as there's no real lock contention >>> going on. But as you add more chances for contention (something like >>> "100,000 concurrent TCP flows") then you may end up having your TCP >>> timer firing stuff interfere with more TXing or RXing on the same >>> connection. >> >> 100K TCP flows probably means 100K locks. That means that chance of lock >> collision on each of them is effectively zero. More realistic it could > > What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP > timeouts callbacks? I am not sure what this formula means, but yes, per-CPU callout locks can much more likely be congested. They are only per-CPU, not per-flow. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 22:55:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ACA39D5; Wed, 19 Feb 2014 22:55:04 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 108DB1D33; Wed, 19 Feb 2014 22:55:03 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id m5so1733696qaj.4 for ; Wed, 19 Feb 2014 14:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FzkE4mtRngfT55+6aMNHO5UuDsMi7jpIukJp2bb7x9U=; b=NfkaCwM8t//W5gcYCbjD6MZZXn5Y3Xb0Ul8YYIjkGTW7lArjwmUssEvApO7DcdFhxv DTfa51gQTNYD7fPmUdqnBeIRZjPVm7V5FEaaQVTWXOKW2PtCyj/lDyOJ3SmXLCSQsYE2 nzvwqGJpFY52cJhWchShmIGfw0qln/2LPeU3vi3iziqh4KKHVTSCsalN4nyDhqQG+b4p foSWxNmWPZZiGZc3Y9QRxDmbsorlS2oXeLpjNn0KF17FTUlQEhN+H/79xurqnujfOuvX vw1AxOd7f+wk+ATcVMwOXC/u5IL/9OiKOcswr4NcQ8epd2s0mEeYwOqxab+lESp2nFtA +/YA== MIME-Version: 1.0 X-Received: by 10.224.160.195 with SMTP id o3mr5218609qax.98.1392850503157; Wed, 19 Feb 2014 14:55:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 19 Feb 2014 14:55:03 -0800 (PST) In-Reply-To: <53052B80.3010505@FreeBSD.org> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> <53052B80.3010505@FreeBSD.org> Date: Wed, 19 Feb 2014 14:55:03 -0800 X-Google-Sender-Auth: PTeu-O3MZj0oEYNAg5JUlt3SFkQ Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arch@freebsd.org" , freebsd-current , Slawa Olhovchenkov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 22:55:04 -0000 On 19 February 2014 14:09, Alexander Motin wrote: > On 19.02.2014 23:44, Slawa Olhovchenkov wrote: >> >> On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: >> >>> On 19.02.2014 22:04, Adrian Chadd wrote: >>>> >>>> On 19 February 2014 11:59, Alexander Motin wrote: >>>> >>>>>> So if we're moving towards supporting (among others) a pcbgroup / RSS >>>>>> hash style work load distribution across CPUs to minimise >>>>>> per-connection lock contention, we really don't want the scheduler to >>>>>> decide it can schedule things on other CPUs under enough pressure. >>>>>> That'll just make things worse. >>>> >>>> >>>>> True, though it is also not obvious that putting second thread on CPU >>>>> run >>>>> queue is better then executing it right now on another core. >>>> >>>> >>>> Well, it depends if you're trying to optimise for "run all runnable >>>> tasks as quickly as possible" or "run all runnable tasks in contexts >>>> that minimise lock contention." >>>> >>>> The former sounds great as long as there's no real lock contention >>>> going on. But as you add more chances for contention (something like >>>> "100,000 concurrent TCP flows") then you may end up having your TCP >>>> timer firing stuff interfere with more TXing or RXing on the same >>>> connection. >>> >>> >>> 100K TCP flows probably means 100K locks. That means that chance of lock >>> collision on each of them is effectively zero. More realistic it could >> >> >> What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP >> timeouts callbacks? > > > I am not sure what this formula means, but yes, per-CPU callout locks can > much more likely be congested. They are only per-CPU, not per-flow. It's not just that, but also TX versus RX ACK processing and further TX being done on different threads. -a From owner-freebsd-current@FreeBSD.ORG Wed Feb 19 23:07:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A26CCD34; Wed, 19 Feb 2014 23:07:21 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1621E1E; Wed, 19 Feb 2014 23:07:21 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1WGGEZ-000Fl4-Uw; Thu, 20 Feb 2014 03:07:19 +0400 Date: Thu, 20 Feb 2014 03:07:19 +0400 From: Slawa Olhovchenkov To: Alexander Motin Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Message-ID: <20140219230719.GM83358@zxy.spb.ru> References: <530508B7.7060102@FreeBSD.org> <53050D24.3020505@FreeBSD.org> <53051C71.3050705@FreeBSD.org> <20140219214428.GA53864@zxy.spb.ru> <53052B80.3010505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53052B80.3010505@FreeBSD.org> 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 Cc: Adrian Chadd , freebsd-current , Jeffrey Faden , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 19 Feb 2014 23:07:21 -0000 On Thu, Feb 20, 2014 at 12:09:04AM +0200, Alexander Motin wrote: > On 19.02.2014 23:44, Slawa Olhovchenkov wrote: > > On Wed, Feb 19, 2014 at 11:04:49PM +0200, Alexander Motin wrote: > > > >> On 19.02.2014 22:04, Adrian Chadd wrote: > >>> On 19 February 2014 11:59, Alexander Motin wrote: > >>> > >>>>> So if we're moving towards supporting (among others) a pcbgroup / RSS > >>>>> hash style work load distribution across CPUs to minimise > >>>>> per-connection lock contention, we really don't want the scheduler to > >>>>> decide it can schedule things on other CPUs under enough pressure. > >>>>> That'll just make things worse. > >>> > >>>> True, though it is also not obvious that putting second thread on CPU run > >>>> queue is better then executing it right now on another core. > >>> > >>> Well, it depends if you're trying to optimise for "run all runnable > >>> tasks as quickly as possible" or "run all runnable tasks in contexts > >>> that minimise lock contention." > >>> > >>> The former sounds great as long as there's no real lock contention > >>> going on. But as you add more chances for contention (something like > >>> "100,000 concurrent TCP flows") then you may end up having your TCP > >>> timer firing stuff interfere with more TXing or RXing on the same > >>> connection. > >> > >> 100K TCP flows probably means 100K locks. That means that chance of lock > >> collision on each of them is effectively zero. More realistic it could > > > > What about 100K/N_cpu*PPS timer's queue locks for remove/insert TCP > > timeouts callbacks? > > I am not sure what this formula means, but yes, per-CPU callout locks > can much more likely be congested. They are only per-CPU, not per-flow. 100K TCP flows distributed between CPU (100K/N_cpu). every TCP flow several times per seconds touch his callout (*PPS) From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 01:02:16 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C47612F7; Thu, 20 Feb 2014 01:02:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 990791825; Thu, 20 Feb 2014 01:02:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s1K12F1N028061; Wed, 19 Feb 2014 20:02:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1K12Fm5028057; Thu, 20 Feb 2014 01:02:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 20 Feb 2014 01:02:15 GMT Message-Id: <201402200102.s1K12Fm5028057@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:02:16 -0000 TB --- 2014-02-20 00:07:46 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-20 00:07:46 - 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 --- 2014-02-20 00:07:46 - starting HEAD tinderbox run for mips/mips TB --- 2014-02-20 00:07:47 - cleaning the object tree TB --- 2014-02-20 00:08:49 - /usr/local/bin/svn stat /src TB --- 2014-02-20 00:08:53 - At svn revision 262232 TB --- 2014-02-20 00:08:54 - building world TB --- 2014-02-20 00:08:54 - CROSS_BUILD_TESTING=YES TB --- 2014-02-20 00:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-20 00:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-20 00:08:54 - SRCCONF=/dev/null TB --- 2014-02-20 00:08:54 - TARGET=mips TB --- 2014-02-20 00:08:54 - TARGET_ARCH=mips TB --- 2014-02-20 00:08:54 - TZ=UTC TB --- 2014-02-20 00:08:54 - __MAKE_CONF=/dev/null TB --- 2014-02-20 00:08:54 - cd /src TB --- 2014-02-20 00:08:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 20 00:09:01 UTC 2014 >>> 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 [...] ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(printf.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(printf.o) ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(strlen.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(strlen.o) ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(qdivrem.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(qdivrem.o) ld: /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(bcd.o): ABI is incompatible with that of the selected emulation ld: failed to merge target specific data of file /obj/mips.mips/src/sys/boot/mips/beri/boot2/../../../../../lib/libstand/libstand.a(bcd.o) *** Error code 1 Stop. bmake[6]: stopped in /src/sys/boot/mips/beri/boot2 *** Error code 1 Stop. bmake[5]: stopped in /src/sys/boot/mips/beri *** Error code 1 Stop. bmake[4]: stopped in /src/sys/boot/mips *** Error code 1 Stop. bmake[3]: stopped in /src/sys/boot *** Error code 1 Stop. bmake[2]: stopped in /src/sys *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-20 01:02:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-20 01:02:15 - ERROR: failed to build world TB --- 2014-02-20 01:02:15 - 2342.71 user 610.41 system 3268.16 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 01:19:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBEC1518 for ; Thu, 20 Feb 2014 01:19:45 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A75981903 for ; Thu, 20 Feb 2014 01:19:45 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s1K1Jdfp049516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 19 Feb 2014 17:19:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s1K1Jdlq049515 for freebsd-current@freebsd.org; Wed, 19 Feb 2014 17:19:39 -0800 (PST) (envelope-from sgk) Date: Wed, 19 Feb 2014 17:19:39 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Help fixing clang 3.4 Message-ID: <20140220011939.GA49492@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 01:19:45 -0000 Can someone point to where I disable clang from issuing an error and aborting on an unknown option? % cd /usr/ports/databases/py-sqlite3 % make cc -shared -O2 -pipe -march=opteron -fno-strict-aliasing build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cache.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/connection.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/cursor.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/microprotocols.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/module.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/prepare_protocol.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/row.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/statement.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/util.o -L/usr/local/lib -R/usr/local/lib -lsqlite3 -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_sqlite3.so cc: error: unknown argument: '-R/usr/local/lib' error: command 'cc' failed with exit status 1 *** Error code 1 -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 01:40:34 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07A49A14; Thu, 20 Feb 2014 01:40:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8CB31AEB; Thu, 20 Feb 2014 01:40:33 +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 s1K1eWqo086228; Wed, 19 Feb 2014 20:40:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1K1eW89086227; Thu, 20 Feb 2014 01:40:32 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 20 Feb 2014 01:40:32 GMT Message-Id: <201402200140.s1K1eW89086227@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:40:34 -0000 TB --- 2014-02-20 00:44:53 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-20 00:44:53 - 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 --- 2014-02-20 00:44:53 - starting HEAD tinderbox run for mips64/mips TB --- 2014-02-20 00:44:53 - cleaning the object tree TB --- 2014-02-20 00:45:37 - /usr/local/bin/svn stat /src TB --- 2014-02-20 00:45:41 - At svn revision 262232 TB --- 2014-02-20 00:45:42 - building world TB --- 2014-02-20 00:45:42 - CROSS_BUILD_TESTING=YES TB --- 2014-02-20 00:45:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-20 00:45:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-20 00:45:42 - SRCCONF=/dev/null TB --- 2014-02-20 00:45:42 - TARGET=mips TB --- 2014-02-20 00:45:42 - TARGET_ARCH=mips64 TB --- 2014-02-20 00:45:42 - TZ=UTC TB --- 2014-02-20 00:45:42 - __MAKE_CONF=/dev/null TB --- 2014-02-20 00:45:42 - cd /src TB --- 2014-02-20 00:45:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Feb 20 00:45:49 UTC 2014 >>> 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 [...] vm.c:(.text+0x404): relocation truncated to fit: R_MIPS_GOT_DISP against `no symbol' vm.c:(.text+0x408): relocation truncated to fit: R_MIPS_GOT_DISP against `no symbol' vm.c:(.text+0x40c): relocation truncated to fit: R_MIPS_CALL16 against `__assert' /obj/mips.mips64/src/sys/boot/mips/beri/loader/../../../ficl/libficl.a(vm.o): In function `vmGetWord0': vm.c:(.text+0x490): relocation truncated to fit: R_MIPS_CALL16 against `skipSpace' /obj/mips.mips64/src/sys/boot/mips/beri/loader/../../../ficl/libficl.a(vm.o): In function `vmTextOut': vm.c:(.text+0x590): relocation truncated to fit: R_MIPS_GOT_DISP against `no symbol' vm.c:(.text+0x594): additional relocation overflows omitted from the output *** Error code 1 Stop. bmake[6]: stopped in /src/sys/boot/mips/beri/loader *** Error code 1 Stop. bmake[5]: stopped in /src/sys/boot/mips/beri *** Error code 1 Stop. bmake[4]: stopped in /src/sys/boot/mips *** Error code 1 Stop. bmake[3]: stopped in /src/sys/boot *** Error code 1 Stop. bmake[2]: stopped in /src/sys *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-20 01:40:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-20 01:40:32 - ERROR: failed to build world TB --- 2014-02-20 01:40:32 - 2339.48 user 595.75 system 3339.04 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 02:24:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8514E3C6 for ; Thu, 20 Feb 2014 02:24:09 +0000 (UTC) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D1811DFE for ; Thu, 20 Feb 2014 02:24:08 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d17so651473eek.22 for ; Wed, 19 Feb 2014 18:24:07 -0800 (PST) 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:content-transfer-encoding; bh=qt+9+r33IyyZVP2kc+dqMRgMOqMM/4Abe5AjFzD73EA=; b=zptQxeAxlJb+g7SlsIsqxII/rR9ka7ykL8I3gaY1sYxJP90s64BPlzj+FGBTRFTQPd KHB1a7lc2nN66rmRrAcoAbCXIIsOzn5MEDdScJPAwm1an5d2ix4ChILcz7BIEs6iVt8Q +E1vtesD7sBEwv/z2NZe9HDULSIZ2VMaSgZO9sP1zZqTZ+YW+nLzSZjfb3uC0wR6NMiv ENxF1xxol80U56iQkQtk+/gmuh1nWZuLxeUvnD4pmhH4CjtVZ/afEFnrcm1XSEART6vz jaco96jfQ4FDuvg2o8pW8jZRBw1BErUXaJHinDiq7mzqlXER24+D00TTCEzEisnEKnl+ xxdQ== MIME-Version: 1.0 X-Received: by 10.14.0.132 with SMTP id 4mr5516265eeb.95.1392863047557; Wed, 19 Feb 2014 18:24:07 -0800 (PST) Received: by 10.14.65.4 with HTTP; Wed, 19 Feb 2014 18:24:07 -0800 (PST) In-Reply-To: <20140220011939.GA49492@troutmask.apl.washington.edu> References: <20140220011939.GA49492@troutmask.apl.washington.edu> Date: Wed, 19 Feb 2014 18:24:07 -0800 Message-ID: Subject: Re: Help fixing clang 3.4 From: hiren panchasara To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 02:24:09 -0000 On Wed, Feb 19, 2014 at 5:19 PM, Steve Kargl wrote: > Can someone point to where I disable clang from > issuing an error and aborting on an unknown option? > > % cd /usr/ports/databases/py-sqlite3 > % make > > cc -shared -O2 -pipe -march=3Dopteron -fno-strict-aliasing build/temp.fre= ebsd-11.0-CURRENT-amd64-2.7/_sqlite/cache.o build/temp.freebsd-11.0-CURRENT= -amd64-2.7/_sqlite/connection.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_= sqlite/cursor.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/microprot= ocols.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/module.o build/te= mp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/prepare_protocol.o build/temp.fre= ebsd-11.0-CURRENT-amd64-2.7/_sqlite/row.o build/temp.freebsd-11.0-CURRENT-a= md64-2.7/_sqlite/statement.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sql= ite/util.o -L/usr/local/lib -R/usr/local/lib -lsqlite3 -o build/lib.freebsd= -11.0-CURRENT-amd64-2.7/_sqlite3.so > cc: error: unknown argument: '-R/usr/local/lib' I do not know the answer but I see it being discussed here: http://lists.freebsd.org/pipermail/freebsd-toolchain/2014-January/001103.ht= ml cheers, Hiren > error: command 'cc' failed with exit status 1 > *** Error code 1 > > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 03:08:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BF0DD49 for ; Thu, 20 Feb 2014 03:08:16 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 065B015B1 for ; Thu, 20 Feb 2014 03:08:15 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s1K38Dr3049925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Feb 2014 19:08:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s1K38DsT049924; Wed, 19 Feb 2014 19:08:13 -0800 (PST) (envelope-from sgk) Date: Wed, 19 Feb 2014 19:08:12 -0800 From: Steve Kargl To: hiren panchasara Subject: Re: Help fixing clang 3.4 Message-ID: <20140220030812.GA49876@troutmask.apl.washington.edu> References: <20140220011939.GA49492@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 03:08:16 -0000 On Wed, Feb 19, 2014 at 06:24:07PM -0800, hiren panchasara wrote: > On Wed, Feb 19, 2014 at 5:19 PM, Steve Kargl > wrote: > > Can someone point to where I disable clang from > > issuing an error and aborting on an unknown option? > > > > % cd /usr/ports/databases/py-sqlite3 > > % make > > > > cc ... -R/usr/local/lib -lsqlite3 -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_sqlite3.so > > cc: error: unknown argument: '-R/usr/local/lib' > > I do not know the answer but I see it being discussed here: > http://lists.freebsd.org/pipermail/freebsd-toolchain/2014-January/001103.html > Sigh, I forgot about that discussion. Nothing like getting caught by the libc++ ABI breakage and unbreakage, which is requiring a recompile of everything linked to libc++, only to be foiled by the impossibility of actually doing the recompile. Guess I'll chalk it up to The Joys of Current(tm). -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 06:43:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FB7F97C for ; Thu, 20 Feb 2014 06:43:55 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B9FA1910 for ; Thu, 20 Feb 2014 06:43:55 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id f11so2401195qae.7 for ; Wed, 19 Feb 2014 22:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OWzBTUzYqrvZQIpX5lPf2kT77ougXTCqRNR45Ea+4rA=; b=lyq25ZNsm4Q7mRme6E0WzK2PYlbzVzzCHh+qVYyMUBgSuvwKziQRC4ruVDfDRt1Ju2 FxzlQQ7FxSeFrTvDKqKnD9qr/nPTdSY77HDEGI+e1P5QR4QCyI+XSiqLY5UsxQrl6X8y HNzHHAeFScAnbJbFakL3Fnp5xRAyEDv3b5brk8qOGsvPUNYWRLFbFKvesmJzPpM6ZJeu lZqx4FP7HTJWm5LxxmQmVEsN2LJSMSgnTfceUN5LaVK/rtnp3yzxIN8/aMXbIDWUhBaN A+6p01TOFimFKOCG1C5F16+ON9tqeXHpw88v6LzlDkCBHf7vP27gcclzNr68HZEybJzW HfcA== MIME-Version: 1.0 X-Received: by 10.236.149.2 with SMTP id w2mr239431yhj.114.1392878634338; Wed, 19 Feb 2014 22:43:54 -0800 (PST) Sender: antoine.brodin.freebsd@gmail.com Received: by 10.170.80.11 with HTTP; Wed, 19 Feb 2014 22:43:54 -0800 (PST) In-Reply-To: <20140220011939.GA49492@troutmask.apl.washington.edu> References: <20140220011939.GA49492@troutmask.apl.washington.edu> Date: Thu, 20 Feb 2014 07:43:54 +0100 X-Google-Sender-Auth: R3wkejpTz9JTVEcLPFY_N6C7W0A Message-ID: Subject: Re: Help fixing clang 3.4 From: Antoine Brodin To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 06:43:55 -0000 On Thu, Feb 20, 2014 at 2:19 AM, Steve Kargl wrote: > Can someone point to where I disable clang from > issuing an error and aborting on an unknown option? > > % cd /usr/ports/databases/py-sqlite3 > % make > > cc -shared -O2 -pipe -march=3Dopteron -fno-strict-aliasing build/temp.fre= ebsd-11.0-CURRENT-amd64-2.7/_sqlite/cache.o build/temp.freebsd-11.0-CURRENT= -amd64-2.7/_sqlite/connection.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_= sqlite/cursor.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/microprot= ocols.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/module.o build/te= mp.freebsd-11.0-CURRENT-amd64-2.7/_sqlite/prepare_protocol.o build/temp.fre= ebsd-11.0-CURRENT-amd64-2.7/_sqlite/row.o build/temp.freebsd-11.0-CURRENT-a= md64-2.7/_sqlite/statement.o build/temp.freebsd-11.0-CURRENT-amd64-2.7/_sql= ite/util.o -L/usr/local/lib -R/usr/local/lib -lsqlite3 -o build/lib.freebsd= -11.0-CURRENT-amd64-2.7/_sqlite3.so > cc: error: unknown argument: '-R/usr/local/lib' > error: command 'cc' failed with exit status 1 > *** Error code 1 Hi, You can try this http://docs.freebsd.org/cgi/mid.cgi?CAALwa8m9-dpiO4fpA_BG-QeZyo9wsRpDVXHz_C= TNUYeFLK7GVA Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 07:49:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11D10782 for ; Thu, 20 Feb 2014 07:49:49 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA8251DE7 for ; Thu, 20 Feb 2014 07:49:48 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1WGOO4-00017E-JG>; Thu, 20 Feb 2014 08:49:40 +0100 Received: from g225090122.adsl.alicedsl.de ([92.225.90.122] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1WGOO4-0028nk-E6>; Thu, 20 Feb 2014 08:49:40 +0100 Date: Thu, 20 Feb 2014 08:49:35 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: x11/kde4-workspace: build fails on 11.-0CURRENT due to c++: error: linker command failed: /usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch' Message-ID: <20140220084935.049f6270.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/8/ronnS5Moe_rrfkbFu2Lqf"; protocol="application/pgp-signature" X-Originating-IP: 92.225.90.122 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 07:49:49 -0000 --Sig_/8/ronnS5Moe_rrfkbFu2Lqf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The port x11/kde-workspace (kde-workspace-4.10.5_2 on my installation) fail= s to be updated and therefore a bunch of very important applications (i.e. devel/kdevelop) = do not work anymore. The build/update of x11/kde4-workspace failst due to: [...] [ 98%] Built target kwin gmake[4]: Entering directory `/usr/ports/x11/kde4-workspace/work/.build' Scanning dependencies of target kwin_gles gmake[4]: Leaving directory `/usr/ports/x11/kde4-workspace/work/.build' gmake[4]: Entering directory `/usr/ports/x11/kde4-workspace/work/.build' [ 98%] Building CXX object kwin/CMakeFiles/kwin_gles.dir/kwin_gles_dummy.cp= p.o Linking CXX executable kwin_gles [ 98%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/basic= tab.cpp.o =3D=3D=3D>>> /usr/local/lib/libGLESv2.so: undefined reference to `_glapi_ge= t_dispatch' =3D=3D=3D>>>/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dis= patch' c++: error: linker command failed with exit code 1 (use -v to see invocatio= n) gmake[4]: *** [kwin/kwin_gles] Error 1 gmake[4]: Leaving directory `/usr/ports/x11/kde4-workspace/work/.build' gmake[3]: *** [kwin/CMakeFiles/kwin_gles.dir/all] Error 2 gmake[3]: *** Waiting for unfinished jobs.... [ 98%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/treev= iew.cpp.o [ 98%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/kmenu= edit.cpp.o [ 98%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/menuf= ile.cpp.o [100%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/menui= nfo.cpp.o [100%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/khotk= eys.cpp.o [100%] Building CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/kmenueditadaptor.cpp.o [100%] Bu= ilding CXX object kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/khotkeys_interface.cpp.o = Linking CXX shared library ../lib/libkdeinit4_kmenuedit.so gmake[4]: Leaving directory `/usr/ports/x11/kde4-workspace/wographics/libglesvrk/.build' [100%] Built t= arget kdeinit_kmenuedit gmake[3]: Leaving directory `/usr/ports/x11/kde4-workspac= e/work/.build' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/x11/kde4-workspace/work/.build' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure = to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/x11/kde4-workspace I tried to reinstall port graphics/libglesv2 via portmaster -f graphics/libglesv2 to ensure no fault at this port, but the error still remains. Do I miss something? In the past, I tried to find all the ports which neede= d to be recompiled due to C++ library version bump-up. Is there a fast solution for this? What is going wrong? Thanks in advance, Oliver Hartmann --Sig_/8/ronnS5Moe_rrfkbFu2Lqf Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTBbOTAAoJEOgBcD7A/5N8N6gH/A3lQdfoIbFbtCGW4rjdrVQ7 2NGtcEXWN3sX6k+gjfjz7u1zqPXfgo3Y2/0rWXvhH8HprbIbD9cYAvXDFW7IhoQC MK7EEEaIJ3jcwvsKdLd0FgFPOIEahipu/phYI+y18aQiUL1Pixsm+v6Eaz+3GZum XhQ6miuQDQJh86Ern4q0XTgbrIbYTnG44dUkwEdUEyLNZubgnI1IuTTQW6ivwiHt 92ny2xz614o7Zx+4LGChayEt0uRjXUlTDWnyQDkTzZiwffhuCDnPN6SC1WnG+D97 ffgA+oPYSgiAaYxs9REMFWsMtvUkV4KRnu1aXm4xsP+YQ/KqLjL2pPvzH32EVpo= =0oDV -----END PGP SIGNATURE----- --Sig_/8/ronnS5Moe_rrfkbFu2Lqf-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 12:43:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 069D2228 for ; Thu, 20 Feb 2014 12:43:09 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B13C41BD4 for ; Thu, 20 Feb 2014 12:43:08 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1WGSy2-0024ar-Vy>; Thu, 20 Feb 2014 13:43:07 +0100 Received: from [141.89.176.215] (helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1WGSy2-002cTD-SV>; Thu, 20 Feb 2014 13:43:06 +0100 Date: Thu, 20 Feb 2014 13:43:07 +0100 From: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: x11/kde4-workspace: build fails on 11.-0CURRENT due to c++: error: linker command failed: /usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch' Message-ID: <20140220134307.036a5b36@munin.walstatt.dyndns.org> In-Reply-To: <20140220084935.049f6270.ohartman@zedat.fu-berlin.de> References: <20140220084935.049f6270.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/0z7A3A1GwDP44ZKj682lOUX"; protocol="application/pgp-signature" X-Originating-IP: 141.89.176.215 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 12:43:09 -0000 --Sig_/0z7A3A1GwDP44ZKj682lOUX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 20 Feb 2014 08:49:35 +0100 "O. Hartmann" wrote: >=20 > The port x11/kde-workspace (kde-workspace-4.10.5_2 on my > installation) fails to be updated and therefore a bunch of very > important applications (i.e. devel/kdevelop) do not work anymore. >=20 > The build/update of x11/kde4-workspace failst due to: >=20 > [...] > [ 98%] Built target kwin > gmake[4]: Entering directory > `/usr/ports/x11/kde4-workspace/work/.build' Scanning dependencies of > target kwin_gles gmake[4]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' gmake[4]: Entering > directory `/usr/ports/x11/kde4-workspace/work/.build' [ 98%] Building > CXX object kwin/CMakeFiles/kwin_gles.dir/kwin_gles_dummy.cpp.o > Linking CXX executable kwin_gles [ 98%] Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/basictab.cpp.o >=20 > =3D=3D=3D>>> /usr/local/lib/libGLESv2.so: undefined reference to > `_glapi_get_dispatch' =3D=3D=3D>>>/usr/local/lib/libGLESv2.so: undefined > reference to `_glapi_Dispatch' >=20 > c++: error: linker command failed with exit code 1 (use -v to see > invocation) gmake[4]: *** [kwin/kwin_gles] Error 1 > gmake[4]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' gmake[3]: *** > [kwin/CMakeFiles/kwin_gles.dir/all] Error 2 gmake[3]: *** Waiting for > unfinished jobs.... [ 98%] Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/treeview.cpp.o [ 98%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/kmenuedit.cpp.o [ 98%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/menufile.cpp.o [100%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/menuinfo.cpp.o [100%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/khotkeys.cpp.o [100%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/kmenueditadaptor.cpp.o > [100%] Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/khotkeys_interface.cpp.o > Linking CXX shared library ../lib/libkdeinit4_kmenuedit.so gmake[4]: > Leaving directory > `/usr/ports/x11/kde4-workspace/wographics/libglesvrk/.build' [100%] > Built target kdeinit_kmenuedit gmake[3]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' gmake[2]: *** [all] Error > 2 gmake[2]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' =3D=3D=3D> Compilation failed > unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before > reporting the failure to the maintainer. *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/x11/kde4-workspace >=20 >=20 > I tried to reinstall port graphics/libglesv2 via >=20 > portmaster -f graphics/libglesv2 >=20 > to ensure no fault at this port, but the error still remains. >=20 > Do I miss something? In the past, I tried to find all the ports which > needed to be recompiled due to C++ library version bump-up. >=20 > Is there a fast solution for this? What is going wrong? >=20 > Thanks in advance, >=20 > Oliver Hartmann As I checked recently, this is also true for=20 FreeBSD 9.2-STABLE #0 r261834: Thu Feb 13 16:04:55 CET 2014 amd64 (LLVM/CLANG 3.3). oh --Sig_/0z7A3A1GwDP44ZKj682lOUX Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTBfhbAAoJEOgBcD7A/5N8wsYH/2z1NOeB7rofYbpKlodTx+8o d5OtYUfLg+XrIu9MexxXli7M9WnCrVxm+Qzapt/Zhw7kzILEOrFFFwVvtNEVXdWI ApnIhKVCjQjIv4GWlMcimE0M2KfFcZlIf4dAzfTyMmDgO1NRbBSsy5b2qP6OMJVm m2kdIXM0m1qrZesBu2in7XayIHI+9oCjHW/tkpmp3zhme4lTut7FUVfoOqEAnBKJ oluH15BcyIXYp08HG34ZJLFyn4EhPkFEUpkSvCN0INTKVwdxunGjuNwUpErXjfFu 5lmTxZH15fRMDPU0/P37XchYk7FBxfBp6cdNEAfW1v5M2KSnR5hJs2ZOjKS5PPs= =qO4N -----END PGP SIGNATURE----- --Sig_/0z7A3A1GwDP44ZKj682lOUX-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 19:17:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0424DC1A; Thu, 20 Feb 2014 19:17:38 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBCD714C7; Thu, 20 Feb 2014 19:17:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DBF12B9D0; Thu, 20 Feb 2014 14:17:36 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org, "freebsd-arch@freebsd.org" Subject: Re: [rfc] bind per-cpu timeout threads to each CPU Date: Thu, 20 Feb 2014 14:17:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <530508B7.7060102@FreeBSD.org> <201402191602.54465.jhb@freebsd.org> In-Reply-To: <201402191602.54465.jhb@freebsd.org> MIME-Version: 1.0 Message-Id: <201402201417.34148.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 20 Feb 2014 14:17:37 -0500 (EST) Cc: Adrian Chadd , Alexander Motin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 19:17:38 -0000 On Wednesday, February 19, 2014 4:02:54 pm John Baldwin wrote: > On Wednesday, February 19, 2014 3:04:51 pm Adrian Chadd wrote: > > On 19 February 2014 11:59, Alexander Motin wrote: > > > > >> So if we're moving towards supporting (among others) a pcbgroup / RSS > > >> hash style work load distribution across CPUs to minimise > > >> per-connection lock contention, we really don't want the scheduler to > > >> decide it can schedule things on other CPUs under enough pressure. > > >> That'll just make things worse. > > > > > True, though it is also not obvious that putting second thread on CPU run > > > queue is better then executing it right now on another core. > > > > Well, it depends if you're trying to optimise for "run all runnable > > tasks as quickly as possible" or "run all runnable tasks in contexts > > that minimise lock contention." > > > > The former sounds great as long as there's no real lock contention > > going on. But as you add more chances for contention (something like > > "100,000 concurrent TCP flows") then you may end up having your TCP > > timer firing stuff interfere with more TXing or RXing on the same > > connection. > > > > Chasing this stuff down is a pain, because it only really shows up > > when you're doing lots of concurrency. > > > > I'm happy to make this a boot-time option and leave it off for the > > time being. How's that? > > I think having it be a tunable would be good. OTOH, I could also > see another option which would be to pin all clock threads except > for the "default" one by default and only have the option control > whether or not the default thread is pinned to CPU 0 as callers > who use callout_on() are explicitly asking to run the callout on a > specific CPU. (A further variant of this would be to divorce cpu0's swi from the catch-all softclock and let the catch-all softclock float, but bind all the per-cpu swis) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 21:27:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A11BA9A for ; Thu, 20 Feb 2014 21:27:27 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19C981232 for ; Thu, 20 Feb 2014 21:27:26 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1WGb9M-0000ZH-91 for freebsd-current@freebsd.org; Thu, 20 Feb 2014 13:27:20 -0800 Date: Thu, 20 Feb 2014 13:27:20 -0800 (PST) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1392931640272-5887735.post@n5.nabble.com> Subject: DNS records being cached? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 21:27:27 -0000 Well, explain this if you can: I have unbound running in a jail and host /etc/resolv.conf entry for "name server" is . I recently changed the A rec to a domain, then did "unbound-control flush ". Now, drill from jail shows new IP, while drill from host shows old IP. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/DNS-records-being-cached-tp5887735.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Feb 20 21:48:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8991E49A; Thu, 20 Feb 2014 21:48:07 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F3371470; Thu, 20 Feb 2014 21:48:06 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id w7so2077813qcr.3 for ; Thu, 20 Feb 2014 13:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4GJN0//Tf5Bsda8spC3fhecqJ4H69Oe1dPLf5ZdVP64=; b=Rhmhe5vI3V7pYkm16TajmVoJ9+8UPPBP4RR22ZT15MWKFkDEVPn5ZQxdxMn73aErjz TAfMrWt4MoaBo434h0+WpLgIq6e6TI44MpITOjaUCIIB7zmOp5ggIoFdk28tdBqk76JR w3LHPoFMkDDEq+f6hGVKn7E9xtsz/MqnINTAa7iJm99r9DVxLjiDhOBEUgs8C82SEsxR o7A+d4S2jFPyTSHfLRzQG5wBapJWVjsTE6hnfuyUMf4R/FWM9YYv9kvXc5osdHLDgvqi X5TI4OPo+hO1873TXWrqqfeuvsg5govqlPVy/qwx/P8yRDbaGYj/8XVJx8lwYxg0SfR7 K+Pw== MIME-Version: 1.0 X-Received: by 10.140.42.54 with SMTP id b51mr4580773qga.87.1392932886244; Thu, 20 Feb 2014 13:48:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Thu, 20 Feb 2014 13:48:06 -0800 (PST) In-Reply-To: <201402201417.34148.jhb@freebsd.org> References: <530508B7.7060102@FreeBSD.org> <201402191602.54465.jhb@freebsd.org> <201402201417.34148.jhb@freebsd.org> Date: Thu, 20 Feb 2014 13:48:06 -0800 X-Google-Sender-Auth: vF-zuzXAj2DSvPJ2howbBaEpat4 Message-ID: Subject: Re: [rfc] bind per-cpu timeout threads to each CPU From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Feb 2014 21:48:07 -0000 On 20 February 2014 11:17, John Baldwin wrote: > (A further variant of this would be to divorce cpu0's swi from the > catch-all softclock and let the catch-all softclock float, but bind > all the per-cpu swis) I like this idea. If something (eg per-CPU TCP timers, if it's turned on) makes a very specific decision about the CPU then it should be fixed. Otherwise a lot of the underlying assumptions for things like RSS just aren't guaranteed to hold. It could also perhaps extend to some abstract pool of CPUs later, if we wanted to do things like one flowing swi per socket or whatnot when we start booting on 1024 core boxes... -a From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 08:13:36 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6301C1A for ; Fri, 21 Feb 2014 08:13:36 +0000 (UTC) Received: from zcs03.jnb1.cloudseed.co.za (zcs03.jnb1.cloudseed.co.za [41.154.0.139]) by mx1.freebsd.org (Postfix) with ESMTP id 573091DD0 for ; Fri, 21 Feb 2014 08:13:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTP id 48E8C2B43BF5 for ; Fri, 21 Feb 2014 10:05:49 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs03.jnb1.cloudseed.co.za Received: from zcs03.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs03.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXnag-aQVGwe for ; Fri, 21 Feb 2014 10:05:48 +0200 (SAST) Received: from clue.co.za (ss.school1319.gp-online.net [41.154.77.214]) by zcs03.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 8EE872B43A69 for ; Fri, 21 Feb 2014 10:05:48 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WGkzK-0000gb-E2 for current@freebsd.org; Fri, 21 Feb 2014 09:57:38 +0200 To: current@freebsd.org Subject: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory From: "Ian FREISLICH" X-Attribution: BOFH Date: Fri, 21 Feb 2014 09:57:38 +0200 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 08:13:36 -0000 Hi While recieving my routing table I used to be able to check how far it got by counting the output netstat -rn. It takes about 2 seconds to recieve the routes from my route-server, but over a minute to update the kernel routing table. I'm now getting this error until zebra completes route insertion. [firewall1.jnb1] ~ $ netstat -rn |wc -l netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ $ netstat -rn |wc -l 480446 Is there a sysctl that controls this? There's lots of free memory (14GB). I've tuned other limits to stop dummynet crashing which may have affected this, but in the absence of any documentation of which mbuf sysctls affect dummynet I'm shooting in the dark: net.inet.ip.fw.one_pass=0 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=1024 net.pf.states_hashsize="1048576" kern.ipc.nmbclusters="1048576" kern.ipc.maxmbufmem="10737418240" kern.ipc.nmbufs=13045170 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 08:23:04 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98A64DB7 for ; Fri, 21 Feb 2014 08:23:04 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB0BF1F9A for ; Fri, 21 Feb 2014 08:23:03 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1L8Mfoj070489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 17:22:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1L8Mego033307; Fri, 21 Feb 2014 17:22:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 21 Feb 2014 17:20:17 +0900 (JST) Message-Id: <20140221.172017.821481836359198829.hrs@allbsd.org> To: ianf@clue.co.za Subject: Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Fri_Feb_21_17_20_17_2014_775)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 21 Feb 2014 17:22:53 +0900 (JST) X-Spam-Status: No, score=-93.8 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_VERTICALLINE,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 08:23:04 -0000 ----Security_Multipart0(Fri_Feb_21_17_20_17_2014_775)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Feb_21_17_20_17_2014_030)--" Content-Transfer-Encoding: 7bit ----Next_Part(Fri_Feb_21_17_20_17_2014_030)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ian FREISLICH" wrote in : ia> Hi ia> ia> While recieving my routing table I used to be able to check how far ia> it got by counting the output netstat -rn. It takes about 2 seconds ia> to recieve the routes from my route-server, but over a minute to ia> update the kernel routing table. ia> ia> I'm now getting this error until zebra completes route insertion. ia> ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l ia> netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory ia> 1 ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l ia> 480446 Perhaps does the attached patch fix this? -- Hiroki ----Next_Part(Fri_Feb_21_17_20_17_2014_030)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netstat.diff" Index: usr.bin/netstat/route.c =================================================================== --- usr.bin/netstat/route.c (revision 262283) +++ usr.bin/netstat/route.c (working copy) @@ -614,7 +614,7 @@ if ((buf = malloc(needed)) == 0) { errx(2, "malloc(%lu)", (unsigned long)needed); } - if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) { + if (sysctl(mib, 7, buf, &needed, NULL, 0) < 0) { err(1, "sysctl: net.route.0.%d.dump.%d", af, fibnum); } lim = buf + needed; ----Next_Part(Fri_Feb_21_17_20_17_2014_030)---- ----Security_Multipart0(Fri_Feb_21_17_20_17_2014_775)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlMHDEEACgkQTyzT2CeTzy2cqgCgu/pw9bttvBrktRPytrIqI5Mc KV8AoK1zG1TQXr75wfmPSM0whHXNqdbr =WAB8 -----END PGP SIGNATURE----- ----Security_Multipart0(Fri_Feb_21_17_20_17_2014_775)---- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 09:01:03 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F6CFE70; Fri, 21 Feb 2014 09:01:03 +0000 (UTC) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id E466312F8; Fri, 21 Feb 2014 09:01:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id CA9EE2A8217D; Fri, 21 Feb 2014 10:55:48 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWQnBXqqR4J1; Fri, 21 Feb 2014 10:55:48 +0200 (SAST) Received: from clue.co.za (ss.school1319.gp-online.net [41.154.77.214]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 1E77B2A8215E; Fri, 21 Feb 2014 10:55:48 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WGltZ-0000kf-1A; Fri, 21 Feb 2014 10:55:45 +0200 To: Hiroki Sato From: Ian FREISLICH Subject: Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory In-Reply-To: <20140221.172017.821481836359198829.hrs@allbsd.org> References: <20140221.172017.821481836359198829.hrs@allbsd.org> X-Attribution: BOFH Date: Fri, 21 Feb 2014 10:55:45 +0200 Message-Id: Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 09:01:03 -0000 Hiroki Sato wrote: > ia> While recieving my routing table I used to be able to check how far > ia> it got by counting the output netstat -rn. It takes about 2 seconds > ia> to recieve the routes from my route-server, but over a minute to > ia> update the kernel routing table. > ia> > ia> I'm now getting this error until zebra completes route insertion. > ia> > ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l > ia> netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory > ia> 1 > ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l > ia> 480446 > > Perhaps does the attached patch fix this? Sadly, not. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 09:09:10 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB2D6B6; Fri, 21 Feb 2014 09:09:10 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D94F13A1; Fri, 21 Feb 2014 09:09:10 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s1L98ogE055966; Fri, 21 Feb 2014 01:08:54 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201402210908.s1L98ogE055966@gw.catspoiler.org> Date: Fri, 21 Feb 2014 01:08:50 -0800 (PST) From: Don Lewis Subject: Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory To: ianf@clue.co.za In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 09:09:10 -0000 On 21 Feb, Ian FREISLICH wrote: > Hiroki Sato wrote: >> ia> While recieving my routing table I used to be able to check how far >> ia> it got by counting the output netstat -rn. It takes about 2 seconds >> ia> to recieve the routes from my route-server, but over a minute to >> ia> update the kernel routing table. >> ia> >> ia> I'm now getting this error until zebra completes route insertion. >> ia> >> ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l >> ia> netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory >> ia> 1 >> ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l >> ia> 480446 >> >> Perhaps does the attached patch fix this? > > Sadly, not. Maybe you are running into the wired page limit. Try bumping up the value of the sysctl vm.max_wired knob. From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 09:22:18 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8C0CA91 for ; Fri, 21 Feb 2014 09:22:18 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2E5B01564 for ; Fri, 21 Feb 2014 09:22:18 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1L9LsVM077268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Feb 2014 18:22:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1L9Lq8p033868; Fri, 21 Feb 2014 18:21:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 21 Feb 2014 18:20:37 +0900 (JST) Message-Id: <20140221.182037.200669298555875226.hrs@allbsd.org> To: ianf@clue.co.za Subject: Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory From: Hiroki Sato In-Reply-To: References: <20140221.172017.821481836359198829.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Fri_Feb_21_18_20_37_2014_800)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 21 Feb 2014 18:22:05 +0900 (JST) X-Spam-Status: No, score=-93.8 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_VERTICALLINE,RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 09:22:18 -0000 ----Security_Multipart0(Fri_Feb_21_18_20_37_2014_800)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Feb_21_18_20_37_2014_329)--" Content-Transfer-Encoding: 7bit ----Next_Part(Fri_Feb_21_18_20_37_2014_329)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian FREISLICH wrote in : ia> Hiroki Sato wrote: ia> > ia> While recieving my routing table I used to be able to check how far ia> > ia> it got by counting the output netstat -rn. It takes about 2 seconds ia> > ia> to recieve the routes from my route-server, but over a minute to ia> > ia> update the kernel routing table. ia> > ia> ia> > ia> I'm now getting this error until zebra completes route insertion. ia> > ia> ia> > ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l ia> > ia> netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory ia> > ia> 1 ia> > ia> [firewall1.jnb1] ~ $ netstat -rn |wc -l ia> > ia> 480446 ia> > ia> > Perhaps does the attached patch fix this? ia> ia> Sadly, not. Hm, how about the attached one? I think the cause is just a race when length of the sysctl's output is changed in kernel after the buffer allocation in userspace, not memory shortage. Size of the routing table can quickly change. -- Hiroki ----Next_Part(Fri_Feb_21_18_20_37_2014_329)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netstat-1.diff" Index: usr.bin/netstat/route.c =================================================================== --- usr.bin/netstat/route.c (revision 262283) +++ usr.bin/netstat/route.c (working copy) @@ -69,6 +69,7 @@ #include #include #include +#include #include "netstat.h" #define kget(p, d) (kread((u_long)(p), (char *)&(d), sizeof (d))) @@ -560,7 +561,7 @@ char *buf, *next, *lim; struct rt_msghdr *rtm; struct sockaddr *sa; - int fam = 0, ifindex = 0, size; + int fam = 0, ifindex = 0, size, count = 0; struct ifaddrs *ifap, *ifa; struct sockaddr_dl *sdl; @@ -600,6 +601,7 @@ freeifaddrs(ifap); +retry: mib[0] = CTL_NET; mib[1] = PF_ROUTE; mib[2] = 0; @@ -607,19 +609,24 @@ mib[4] = NET_RT_DUMP; mib[5] = 0; mib[6] = fibnum; - if (sysctl(mib, 7, NULL, &needed, NULL, 0) < 0) { + if (sysctl(mib, nitems(mib), NULL, &needed, NULL, 0) < 0) err(1, "sysctl: net.route.0.%d.dump.%d estimate", af, fibnum); + if ((buf = malloc(needed)) == NULL) + errx(2, "malloc(%zd)", needed); + if (sysctl(mib, nitems(mib), buf, &needed, NULL, 0) < 0) { + if (errno == ENOMEM && count++ < 20) { + warnx("Routing table grew, retrying"); + sleep(1); + free(buf); + goto retry; + } else + err(1, "sysctl: net.route.0.%d.dump.%d", af, fibnum); } - - if ((buf = malloc(needed)) == 0) { - errx(2, "malloc(%lu)", (unsigned long)needed); - } - if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) { - err(1, "sysctl: net.route.0.%d.dump.%d", af, fibnum); - } lim = buf + needed; for (next = buf; next < lim; next += rtm->rtm_msglen) { rtm = (struct rt_msghdr *)next; + if (rtm->rtm_version != RTM_VERSION) + continue; /* * Peek inside header to determine AF */ ----Next_Part(Fri_Feb_21_18_20_37_2014_329)---- ----Security_Multipart0(Fri_Feb_21_18_20_37_2014_800)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlMHGmUACgkQTyzT2CeTzy1+ZQCcDA3RXqqLhsnrSAfBkB0joLyy r70AnAjWvIMo0M9RJkKR9sprugWyW44j =UO1z -----END PGP SIGNATURE----- ----Security_Multipart0(Fri_Feb_21_18_20_37_2014_800)---- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 09:22:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35595C6D for ; Fri, 21 Feb 2014 09:22:45 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC1DE156E for ; Fri, 21 Feb 2014 09:22:44 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1WGmJZ-003uWL-5Q>; Fri, 21 Feb 2014 10:22:37 +0100 Received: from g225107094.adsl.alicedsl.de ([92.225.107.94] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1WGmJZ-0043XA-2H>; Fri, 21 Feb 2014 10:22:37 +0100 Date: Fri, 21 Feb 2014 10:22:32 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [CURRENT]: buildworld fails: libexec/dma-mbox-create: cd: /usr/src/libexec/dma-mbox-create: No such file or directory Message-ID: <20140221102232.5ad6d334.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/=DmxDoOSknyKHrV0fTLERrx"; protocol="application/pgp-signature" X-Originating-IP: 92.225.107.94 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 09:22:45 -0000 --Sig_/=DmxDoOSknyKHrV0fTLERrx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recent sources (At revision 262283) reject to compile with error: =3D=3D=3D> libexec/dma-mbox-create (cleandir) cd: /usr/src/libexec/dma-mbox-create: No such file or directory --Sig_/=DmxDoOSknyKHrV0fTLERrx Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTBxrcAAoJEOgBcD7A/5N8MUwIAI59S0oKxReNZtBgsmMoqKE8 KxTPvfh8Z+PvqXvBZ1Jlf8msFuTkC+gxL4tR2ImYeKp7kAefHKSmIQr3lgrLCgM8 XQPXykxnYvfBbnZJEdN3t2i3BFncXq3e/vzvKrNQCPzNjrmz6bwUJ0x65xnJt/pO 1XMO3Os4Bh7ZrMJ8DOsTxiG28omyZaFwe0QH+EHM/tslreNjvtgzGwVXytqp8Dsq NV1powtwKxeQn10akx++kx6i6wu8qYwMCK8oGRG6I1MWJsNGfD0e0MCEF+82dbmp REnSX/5w26t2xM3fOWW55uZKDrnviLhFsaouU4jZOBZadiD1JC4oji+WsEVkm4A= =hgQb -----END PGP SIGNATURE----- --Sig_/=DmxDoOSknyKHrV0fTLERrx-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 09:32:42 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE7C0C8B; Fri, 21 Feb 2014 09:32:41 +0000 (UTC) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 24D69167F; Fri, 21 Feb 2014 09:32:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id 8D8652A8215E; Fri, 21 Feb 2014 11:32:38 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ceVBIWX13pf; Fri, 21 Feb 2014 11:32:37 +0200 (SAST) Received: from clue.co.za (ss.school1319.gp-online.net [41.154.77.214]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id AD1BC2A8217D; Fri, 21 Feb 2014 11:32:37 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WGmTE-0000nr-Us; Fri, 21 Feb 2014 11:32:36 +0200 To: Hiroki Sato From: Ian FREISLICH Subject: Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory In-Reply-To: <20140221.182037.200669298555875226.hrs@allbsd.org> References: <20140221.182037.200669298555875226.hrs@allbsd.org> <20140221.172017.821481836359198829.hrs@allbsd.org> X-Attribution: BOFH Date: Fri, 21 Feb 2014 11:32:36 +0200 Message-Id: Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 09:32:42 -0000 Hiroki Sato wrote: > Hm, how about the attached one? > > I think the cause is just a race when length of the sysctl's output > is changed in kernel after the buffer allocation in userspace, not > memory shortage. Size of the routing table can quickly change. You are correct. It's growing at about 9000 entries per second (I wish it were faster). This is what the output looks like now. I guess I'm not the average case. [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 314032 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 332293 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying 340368 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying 374400 [firewall1.jnb1] ~ # netstat -rn |wc -l netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: Routing table grew, retrying netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory 1 [firewall1.jnb1] ~ # netstat -rn |wc -l 480073 Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 10:36:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E22A0245 for ; Fri, 21 Feb 2014 10:36:26 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 714B81BAF for ; Fri, 21 Feb 2014 10:36:26 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id cc10so659852wib.16 for ; Fri, 21 Feb 2014 02:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4sSdC3NoAQBr/OyQXOYekQTp7SZerm8MDsDOYbCpOOo=; b=074SKgqjeDTfUxO3wOd/mR07aA3k8awY2xyivrFr4PBPIzq9bg0E4FkkcISQ1SaZsW cJsINgkqPwA4Yq3jb99yBQVSZE3gMlt+aP+dVgIklvD3M0qVKd2rRdDFju7dteabIdob MfClITFPvIylzstrSVklP0PsXfL+ycfPT/aB41OI4mCI42uWDpJipHrOhNFz9tcRv0Kx GJG7qOXLsafmyc5wlEn6yPxe5oL6/Ph9Dsoa5/7r6qgfclfytEc7Nf0VaQtoZX2OxHKy 2OQBCiXaqRX5ibKdRtvATBwzt65iAxONXHi0fxdp/R5djGNKN59g1f04ytqR+9OVXC0e rSlQ== X-Received: by 10.181.11.169 with SMTP id ej9mr2562838wid.18.1392978984230; Fri, 21 Feb 2014 02:36:24 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id ga20sm6634987wic.0.2014.02.21.02.36.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 21 Feb 2014 02:36:22 -0800 (PST) Sender: Baptiste Daroussin Date: Fri, 21 Feb 2014 11:36:20 +0100 From: Baptiste Daroussin To: "O. Hartmann" Subject: Re: [CURRENT]: buildworld fails: libexec/dma-mbox-create: cd: /usr/src/libexec/dma-mbox-create: No such file or directory Message-ID: <20140221103620.GH1699@ithaqua.etoilebsd.net> References: <20140221102232.5ad6d334.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jHkwA2TBA/ec6v+" Content-Disposition: inline In-Reply-To: <20140221102232.5ad6d334.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 10:36:26 -0000 --9jHkwA2TBA/ec6v+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 21, 2014 at 10:22:32AM +0100, O. Hartmann wrote: >=20 > Recent sources (At revision 262283) reject to compile with error: >=20 > =3D=3D=3D> libexec/dma-mbox-create (cleandir) > cd: /usr/src/libexec/dma-mbox-create: No such file or directory Fixed sorry about it regards, Bapt --9jHkwA2TBA/ec6v+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlMHLCQACgkQ8kTtMUmk6EyV8wCeMi6+Xa+G8KFAlY5EfW9omQjd r1oAoKPBz+m+BW3hQKtwH0M7KxCnelAz =3vau -----END PGP SIGNATURE----- --9jHkwA2TBA/ec6v+-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 12:58:07 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0087761E for ; Fri, 21 Feb 2014 12:58:06 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 48DD01982 for ; Fri, 21 Feb 2014 12:58:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA28207; Fri, 21 Feb 2014 14:57:56 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WGpfu-0003Ys-Vi; Fri, 21 Feb 2014 14:57:56 +0200 Message-ID: <53074D18.5030908@FreeBSD.org> Date: Fri, 21 Feb 2014 14:56:56 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Vitalij Satanivskij Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain) References: <20140204100823.GA95709@hell.ukr.net> <52F0F687.6050307@FreeBSD.org> <20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org> <20140205090449.GA9341@hell.ukr.net> <20140205122241.GA38114@hell.ukr.net> <52F4A35E.1080902@FreeBSD.org> <52FA2CA2.5000508@FreeBSD.org> <20140218133841.GA58764@hell.ukr.net> <530363CA.4060507@FreeBSD.org> <20140218134710.GA58844@hell.ukr.net> In-Reply-To: <20140218134710.GA58844@hell.ukr.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Vladimir Sharun , Current FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 12:58:07 -0000 on 18/02/2014 15:47 Vitalij Satanivskij said the following: > No checksume errors or any other errors found for now. Thank you again! Could you please send me an output of sysctl kstat | fgrep 'l2' from a system that has been patched and with a sufficiently long uptime? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 13:02:05 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 461779D1; Fri, 21 Feb 2014 13:02:05 +0000 (UTC) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1F6A1A29; Fri, 21 Feb 2014 13:02:04 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1WGpjn-0005rc-MD ; Fri, 21 Feb 2014 15:01:55 +0200 Date: Fri, 21 Feb 2014 15:01:55 +0200 From: Vitalij Satanivskij To: Andriy Gapon Subject: Re: ARC "pressured out", how to control/stabilize ? (reformatted to text/plain) Message-ID: <20140221130155.GB22233@hell.ukr.net> References: <20140204171040.GA82996@hell.ukr.net> <52F12210.10604@FreeBSD.org> <20140205090449.GA9341@hell.ukr.net> <20140205122241.GA38114@hell.ukr.net> <52F4A35E.1080902@FreeBSD.org> <52FA2CA2.5000508@FreeBSD.org> <20140218133841.GA58764@hell.ukr.net> <530363CA.4060507@FreeBSD.org> <20140218134710.GA58844@hell.ukr.net> <53074D18.5030908@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53074D18.5030908@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Vitalij Satanivskij , Current FreeBSD , Vladimir Sharun X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: satan@ukr.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 13:02:05 -0000 Dear Andriy, system uptime is 8 days, 20:26 Output: kstat.zfs.misc.arcstats.evict_l2_cached: 9771077767680 kstat.zfs.misc.arcstats.evict_l2_eligible: 3844577713152 kstat.zfs.misc.arcstats.evict_l2_ineligible: 8855320643072 kstat.zfs.misc.arcstats.l2_hits: 79824726 kstat.zfs.misc.arcstats.l2_misses: 217864980 kstat.zfs.misc.arcstats.l2_feeds: 760023 kstat.zfs.misc.arcstats.l2_rw_clash: 61903 kstat.zfs.misc.arcstats.l2_read_bytes: 3058416338944 kstat.zfs.misc.arcstats.l2_write_bytes: 2487863166464 kstat.zfs.misc.arcstats.l2_writes_sent: 732146 kstat.zfs.misc.arcstats.l2_writes_done: 732146 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 51888 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 4416 kstat.zfs.misc.arcstats.l2_evict_reading: 1 kstat.zfs.misc.arcstats.l2_free_on_write: 282867 kstat.zfs.misc.arcstats.l2_cdata_free_on_write: 326028 kstat.zfs.misc.arcstats.l2_abort_lowmem: 1348 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 257940027392 kstat.zfs.misc.arcstats.l2_asize: 108789048832 kstat.zfs.misc.arcstats.l2_hdr_size: 881715600 kstat.zfs.misc.arcstats.l2_compress_successes: 60790954 kstat.zfs.misc.arcstats.l2_compress_zeros: 0 kstat.zfs.misc.arcstats.l2_compress_failures: 1738173 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 1168505250 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 29511803 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 1307899433 kstat.zfs.misc.arcstats.l2_write_in_l2: 51108634609 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 637 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 100398037509 kstat.zfs.misc.arcstats.l2_write_full: 97839 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 760023 kstat.zfs.misc.arcstats.l2_write_pios: 732146 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 4642717602824192 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 48013995 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 80483 Andriy Gapon wrote: AG> on 18/02/2014 15:47 Vitalij Satanivskij said the following: AG> > No checksume errors or any other errors found for now. AG> AG> Thank you again! AG> Could you please send me an output of AG> sysctl kstat | fgrep 'l2' AG> from a system that has been patched and with a sufficiently long uptime? AG> AG> -- AG> Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 14:38:29 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from gahrfit.gahr.ch (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D27FEA95; Fri, 21 Feb 2014 14:38:27 +0000 (UTC) Date: Fri, 21 Feb 2014 15:38:23 +0100 From: Pietro Cerutti To: freebsd-ports@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: lang/expect -- update coming Message-ID: <20140221143821.GK149@gahrfit.gahr.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6b3yLyRKT1M6kiA0" Content-Disposition: inline X-PGP-Key: fp="DA6D E106 A5B8 54B8 5DD8 6D49 ADD0 D38E A192 089E"; id="0xA192089E"; get=; get=; User-Agent: Mutt/1.5.22 (2013-10-16) Cc: jmohacsi@bsd.hu, Martin Wilke X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gahr@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:38:29 -0000 --6b3yLyRKT1M6kiA0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, I'm planning to commit an update to bring lang/expect up to the latest 5.45 version. At the same time, I'm going to kill lang/expect-devel, which would otherwise be left lagging behind at 5.44. The following ports use either expect or -devel (maintainers CC'd). devel/pecl-expect net-mgmt/rancid net-mgmt/rancid-devel This is a call to test those three with the new version of lang/expect, which can be found both as a shar [1] or diff [2]. If nothing comes up, I'm planning to update expect and kill expect-devel by the end of next week. Thanks, [1] http://people.freebsd.org/~gahr/expect-5.45.shar [2] http://people.freebsd.org/~gahr/expect-5.45.diff --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --6b3yLyRKT1M6kiA0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJTB2TVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREQTZERTEwNkE1Qjg1NEI4NUREODZENDlB REQwRDM4RUExOTIwODlFAAoJEK3Q046hkgie1gMP/0lcvTCLETpXTZJnktVhJ3/9 NDUC/nLghf4Xr+IYZmUhhuPrXLgnECuEQy/YNhKFxGFW91bqAaDfwWw8HpJgHFcf Bq2gvScNValhs0g8KJ2Ge9MDIkGEwzHLyfiaFjhL3vNPpSnFQiG+Cnn6NTkr09Fq 6YZpYgURIy2e+YCbnxJxOgGh0afg5yFGdc7ETN1uF+H23dEtTfot5S5I2SPZBs5H 5X3cs79WY5CRflBSMS3Fr9vh7XpwgLYzdJOx6REKYxmPFotC/ntHpScqV4aa2OMN Yh35ZX9z/eehIsgYaSoF8nIc2m+nF30nCL2OZLgNQKdrkYopwl6f/TCUflmaC1Vc IjSgERIVx0eodZLKAIQteiHf2D7Q20gvGUrlWmF8b8npbnONDzmQzpphzRi+BRbG csGJsx8ScqZs6BsFYSOUuDjnA/f7Ekhz1FP0ch6J32FiErRQhk6jdRXqc8u/n+BH c4jqsGKkh1fUsC3x3cUDiy09hhaeOtphJeLvDkFWIqJy2JX/W8UEh7dekkapiGR1 cvGIoFsfMPhdyApawaV2RlRrHbskMUEQBo1MNVQFRXbfqN8xo+zhfGXocQSBKbKm Yvt24sdQ83HUheAgp75P3umnbjKMjEr1NjSD0qTLZwd8r+1GbErGoTrRpDOKBY6Z OxWfohNe3k8N14DkZ7S9 =CJwj -----END PGP SIGNATURE----- --6b3yLyRKT1M6kiA0-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 15:38:30 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from gahrfit.gahr.ch (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC70E418; Fri, 21 Feb 2014 15:38:27 +0000 (UTC) Date: Fri, 21 Feb 2014 16:38:24 +0100 From: Pietro Cerutti To: freebsd-ports@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: lang/expect -- update coming Message-ID: <20140221153822.GL149@gahrfit.gahr.ch> References: <20140221143821.GK149@gahrfit.gahr.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1y6imfT/xHuCvpN0" Content-Disposition: inline In-Reply-To: <20140221143821.GK149@gahrfit.gahr.ch> X-PGP-Key: fp="DA6D E106 A5B8 54B8 5DD8 6D49 ADD0 D38E A192 089E"; id="0xA192089E"; get=; get=; User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Martin Wilke , freenx@deweyonline.com, jmohacsi@bsd.hu, wrighrc@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gahr@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:38:30 -0000 --1y6imfT/xHuCvpN0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Feb-21, 15:38, Pietro Cerutti wrote: > All, >=20 > I'm planning to commit an update to bring lang/expect up to the latest > 5.45 version. At the same time, I'm going to kill lang/expect-devel, > which would otherwise be left lagging behind at 5.44. >=20 > The following ports use either expect or -devel (maintainers CC'd). >=20 > devel/pecl-expect > net-mgmt/rancid > net-mgmt/rancid-devel Turns out my regexp-foo sucked this time.. Here's a more complete list. Thanks koobs@ for noticing. devel/pecl-expect misc/dejagnu misc/sshbuddy net/freenx net-mgmt/netmagis-topo et-mgmt/rancid net-mgmt/rancid-devel security/belier --=20 Pietro Cerutti The FreeBSD Project gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp --1y6imfT/xHuCvpN0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJ8BAEBCgBmBQJTB3LkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREQTZERTEwNkE1Qjg1NEI4NUREODZENDlB REQwRDM4RUExOTIwODlFAAoJEK3Q046hkgieUE0QAMrhKZNUm9qP1fQP6dGfq8lF aW1WkFLt8D6plK7GxerjpDQmfWu/veqDvqCQ9ReWekSYVuhyzSsKPjjLCZ9gfuvU uUJvKl1vV2xJ9yQzupf+nFOL0Djm5sgDI9oEg3IxGXkk0fHussVAH5iYVfvTItfn 6AbO5UZkmZB/tTie8Jb5K6ThXWlSSvjv/Z+9wu4ifHvuHGZxGsyBr6lUzDlxO2Y9 GaCIQ/VlXhRYSfY8UuOZ+xk98m1FQsvPfY7sQvS/aNRH0OopXtUBISfwXh+qSOrD bKz4MplrOnqhbyhxOAsZWbaIlFqJ5u3BmZky3cJUULpq7YEhWzEbN1YLpDua3kbO 1VKM9SJTOOCmyZfnR5KEorq4LbmShYFcq+W713JAh6UkPFaq/U8W5xY7xVPvZ5V0 2hZ02LzmPmJv2islatawAsR7Z/1A8v51jd8A2Wojh5GISRBjI6cZTPCD8LVU+RqX /fb9gHMl2NRqYHCoy7ZP2cO/R7ZiqhbribiRRjJVAjS7/qOfdLIbZDlMFwINtxne XtU9kJDLxV2Q3nL0r7nE/OKRDqoq7Lthq2GD/PQwEso1bfUAbPhgifDv8bSXzAgf MgQniGtRI3ZjeDGsODe2yUHnCNVfyyH2sCY3EQh82w+1fsnhdFec60AThOEH35N6 Gpwgev1ltnKEyzGVjTpr =jm43 -----END PGP SIGNATURE----- --1y6imfT/xHuCvpN0-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 15:58:08 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12C95D10; Fri, 21 Feb 2014 15:58:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA1681D87; Fri, 21 Feb 2014 15:58: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 s1LFvxUo095543; Fri, 21 Feb 2014 10:57:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LFvxGU095153; Fri, 21 Feb 2014 15:57:59 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 15:57:59 GMT Message-Id: <201402211557.s1LFvxGU095153@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.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:58:08 -0000 TB --- 2014-02-21 13:00:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 13:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-21 13:00:17 - starting HEAD tinderbox run for i386/i386 TB --- 2014-02-21 13:00:17 - cleaning the object tree TB --- 2014-02-21 13:00:17 - /usr/local/bin/svn stat /src TB --- 2014-02-21 13:00:22 - At svn revision 262294 TB --- 2014-02-21 13:00:23 - building world TB --- 2014-02-21 13:00:23 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 13:00:23 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 13:00:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 13:00:23 - SRCCONF=/dev/null TB --- 2014-02-21 13:00:23 - TARGET=i386 TB --- 2014-02-21 13:00:23 - TARGET_ARCH=i386 TB --- 2014-02-21 13:00:23 - TZ=UTC TB --- 2014-02-21 13:00:23 - __MAKE_CONF=/dev/null TB --- 2014-02-21 13:00:23 - cd /src TB --- 2014-02-21 13:00:23 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 13:00:29 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/local.c cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/mail.c cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/net.c cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/spool.c /src/libexec/dma/../../contrib/dma/spool.c:418:33: error: comparison of integers of different signs: 'unsigned int' and 'time_t' (aka 'int') [-Werror,-Wsign-compare] if (st.st_mtim.tv_sec + period >= now.tv_sec) ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 15:57:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 15:57:54 - ERROR: failed to build world TB --- 2014-02-21 15:57:54 - 8837.23 user 1409.06 system 10656.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 16:51:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FB4B460 for ; Fri, 21 Feb 2014 16:51:48 +0000 (UTC) Received: from um-tip1-missouri-out.um.umsystem.edu (um-tip1-missouri-out.um.umsystem.edu [198.209.49.135]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CB7413E0 for ; Fri, 21 Feb 2014 16:51:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAPqCB1PPoJ7Q/2dsb2JhbABagwY7V8A9gQ4WdIIlAQEFGgFZBA0EAgEZAwECChYPCQMCAQIBIBsCCAIEDQYCAQGIAQ3FBYZbF44TAQEGB0kGgikPgXoEiRCLOgWFF5B1gy2BaAEBBxcEHg X-IPAS-Result: AgQFAPqCB1PPoJ7Q/2dsb2JhbABagwY7V8A9gQ4WdIIlAQEFGgFZBA0EAgEZAwECChYPCQMCAQIBIBsCCAIEDQYCAQGIAQ3FBYZbF44TAQEGB0kGgikPgXoEiRCLOgWFF5B1gy2BaAEBBxcEHg Received: from um-ncas4.um.umsystem.edu ([207.160.158.208]) by um-tip1-exch-relay.um.umsystem.edu with ESMTP; 21 Feb 2014 10:50:38 -0600 Received: from UM-MBX-N02.um.umsystem.edu ([169.254.5.113]) by UM-NCAS4.um.umsystem.edu ([207.160.158.208]) with mapi id 14.03.0174.001; Fri, 21 Feb 2014 10:50:37 -0600 From: "Montgomery-Smith, Stephen" To: "freebsd-current@freebsd.org" Subject: Fwd: [REL - head-i386-default][math/xppaut] Failed for xppaut-7.0 in package Thread-Topic: [REL - head-i386-default][math/xppaut] Failed for xppaut-7.0 in package Thread-Index: AQHPLwi8WJlsqvyM30qf6wL4pD50f5rAUJcA Date: Fri, 21 Feb 2014 16:50:37 +0000 Message-ID: <530783DA.1010006@missouri.edu> References: <201402211327.s1LDRsau019881@beefy1.isc.freebsd.org> In-Reply-To: <201402211327.s1LDRsau019881@beefy1.isc.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [207.160.158.193] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1395FF9AB8366D4CA23ED0E16636C67D@missouri.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 16:51:48 -0000 I keep getting the following error message from pkg-fallout@. It seems to me that the command cp -r ode* /whereever doesn't copy the .* files in the directories ode* in FreeBSD-CURRENT. Is this a bug or a feature? -------- Original Message -------- Subject: [REL - head-i386-default][math/xppaut] Failed for xppaut-7.0 in package Date: Fri, 21 Feb 2014 13:27:54 +0000 From: To: CC: You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: stephen@FreeBSD.org Last committer: stephen@FreeBSD.org Ident: $FreeBSD: head/math/xppaut/Makefile 341303 2014-01-26 23:07:48Z stephen $ Log URL: http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-02-21_03h01m36s/l= ogs/xppaut-7.0.log Build URL: http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-02-21_03h01m36s Log: =3D=3D=3D=3D>> Building math/xppaut build started at Fri Feb 21 13:27:18 UTC 2014 port directory: /usr/ports/math/xppaut building for: FreeBSD head-i386-default-job-04 11.0-CURRENT FreeBSD 11.0-CURRENT r261447 i386 maintained by: stephen@FreeBSD.org Makefile ident: $FreeBSD: head/math/xppaut/Makefile 341303 2014-01-26 23:07:48Z stephen $ Poudriere version: 3.1-pre ---Begin Environment--- UNAME_m=3Di386 UNAME_p=3Di386 OSVERSION=3D1100007 UNAME_v=3DFreeBSD 11.0-CURRENT r261447 UNAME_r=3D11.0-CURRENT BLOCKSIZE=3DK MAIL=3D/var/mail/root STATUS=3D1 MASTERMNT=3D/usr/local/poudriere/data/build/head-i386-default/ref PKG_EXT=3Dtxz tpid=3D97667 PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/= bin:/root/bin POUDRIERE_BUILD_TYPE=3Dbulk PKGNG=3D1 PKGNAME=3Dxppaut-7.0 PKG_DELETE=3D/usr/local/sbin/pkg-static delete -y -f PKG_ADD=3D/usr/local/sbin/pkg-static add PWD=3D/root MASTERNAME=3Dhead-i386-default USER=3Droot HOME=3D/root POUDRIERE_VERSION=3D3.1-pre LOCALBASE=3D/usr/local PACKAGE_BUILDING=3Dyes PKG_VERSION=3D/poudriere/pkg-static version PKG_BIN=3D/usr/local/sbin/pkg-static ---End Environment--- ---Begin OPTIONS List--- ---End OPTIONS List--- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- TMPDIR=3D"/tmp" SHELL=3D/bin/sh CONFIG_SHELL=3D/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- TMPDIR=3D"/tmp" SHELL=3D/bin/sh NO_LINT=3DYES PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" CC=3D"cc" CFLAGS=3D"-O2 -pipe = -w -Wno-return-type -fno-strict-aliasing" CPP=3D"cpp" CPPFLAGS=3D"" LDFLAGS=3D"" CXX=3D"c++" CXXFLAGS=3D"-O2 -pipe -w -Wno-return-type -fno-strict-aliasing" MANPREFIX=3D"/usr/local" BSD_INSTALL_PROGRAM=3D"install -s -o root -g wheel -m 555" BSD_INSTALL_LIB=3D"install -s -o root -g wheel -m 444" BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" BSD_INSTALL_DATA=3D"install -o root -g wheel -m 444" BSD_INSTALL_MAN=3D"install -o root -g wheel -m 444" --End MAKE_ENV-- --SUB_LIST-- PREFIX=3D/usr/local LOCALBASE=3D/usr/local DATADIR=3D/usr/local/share/xppaut DOCSDIR=3D/usr/local/share/doc/xppaut EXAMPLESDIR=3D/usr/local/share/examples/xppaut WWWDIR=3D/usr/local/www/xppaut ETCDIR=3D/usr/local/etc/xppaut --End SUB_LIST-- ---Begin make.conf--- ARCH=3Di386 MACHINE=3Di386 MACHINE_ARCH=3Di386 USE_PACKAGE_DEPENDS=3Dyes BATCH=3Dyes WRKDIRPREFIX=3D/wrkdirs PORTSDIR=3D/usr/ports PACKAGES=3D/packages DISTDIR=3D/distfiles #### /usr/local/etc/poudriere.d/make.conf #### WITH_PKGNG=3Dyes NO_RESTRICTED=3Dyes DISABLE_MAKE_JOBS=3Dpoudriere ---End make.conf--- =3D=3D=3D> Cleaning for xppaut-7.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/sbin/pkg - not found =3D=3D=3D> Verifying install for /usr/local/sbin/pkg in /usr/ports/ports-mgmt/pkg =3D=3D=3D> Installing existing package /packages/All/pkg-1.2.6.txz Installing pkg-1.2.6... done If you are upgrading from the old package format, first run: # pkg2ng =3D=3D=3D> Returning to build of xppaut-7.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Fetching all distfiles required by xppaut-7.0 for building =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Fetching all distfiles required by xppaut-7.0 for building =3D> SHA256 Checksum OK for xppaut7.0.tar.gz. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Fetching all distfiles required by xppaut-7.0 for building =3D=3D=3D> Extracting for xppaut-7.0 =3D> SHA256 Checksum OK for xppaut7.0.tar.gz. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Patching for xppaut-7.0 =3D=3D=3D> Applying FreeBSD patches for xppaut-7.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/libdata/pkgconfig/xbitmaps.pc - not found =3D=3D=3D> Verifying install for /usr/local/libdata/pkgconfig/xbitmaps.p= c in /usr/ports/x11/xbitmaps =3D=3D=3D> Installing existing package /packages/All/xbitmaps-1.1.1.txz Installing xbitmaps-1.1.1... done =3D=3D=3D> Returning to build of xppaut-7.0 =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/libdata/pkgconfig/x11.p= c - not found =3D=3D=3D> Verifying install for /usr/local/libdata/pkgconfig/x11.pc in /usr/ports/x11/libX11 =3D=3D=3D> Installing existing package /packages/All/libX11-1.6.2,1.txz Installing libX11-1.6.2,1...Installing kbproto-1.0.6... done Installing libXau-1.0.8...Installing xproto-7.0.25... done done Installing libXdmcp-1.1.1... done Installing libxcb-1.9.3...Installing libpthread-stubs-0.3_4... done Installing libxml2-2.8.0_3... done done done =3D=3D=3D> Returning to build of xppaut-7.0 =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/libdata/pkgconfig/xproto.pc - found =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Configuring for xppaut-7.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Building for xppaut-7.0 cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c main.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c ggets.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c menu.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c rubber.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c derived.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c many_pops.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c pop_list.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c graphics.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c dialog_box.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c numerics.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c choice_box.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c color.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c init_conds.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c browse.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c kinescope.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c axes2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c abort.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c parserslow2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c storage.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c load_eqn.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c form_ode.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c odesol2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c gear.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c eig_list.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c integrate.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c delay_handle.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c graf_par.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c dormpri.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c my_ps.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c my_svg.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c nullcline.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c torus.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c pp_shoot.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c lunch-new.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c calc.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c adj2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c my_rhs.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c read_dir.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c volterra2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c tabular.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c markov.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c histogram.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c comline.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c edit_rhs.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c do_fit.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c flags.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c del_stab.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c stiff.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c arrayplot.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c array_print.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c aniparse.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c simplenet.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c dae_fun.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c fftn.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c extra.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c scrngif.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c nagroutines.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c homsup.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c txtread.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c menudrive.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c userbut.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c Version.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c backspace.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c dfe.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c due.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c iio.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c inquire.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c rewind.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c rsfe.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c rdfmt.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c sue.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c uio.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c wsfe.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c sfe.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c fmt.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c lio.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c lread.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c open.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c close.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c util.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c endfile.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c wrtfmt.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c wref.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c err.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c fmtlib.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c rsne.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c wsne.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c fc77.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c f2cstart.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c cvode.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c cvdense.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c dense.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c cvband.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c band.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c cvdiag.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c cvspgmr.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c spgmr.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c iterativ.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c vector.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c llnlmath.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c cv2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c autlib1.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c autlib2.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c autlib3.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c autevd.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c run_auto.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c autpp.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c diagram.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c auto_nox.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c auto_x11.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -O2 -pipe -w -Wno-return-type -fno-strict-aliasing -pedantic -O -DNOERRNO -DNON_UNIX_STDIO -DAUTO -DCVODE_YES -DHAVEDLL -DMYSTR1=3D7.0 -DMYSTR2=3D0 -I/usr/local/include -c flowkm_small.c cc -std=3Dc99 -pedantic -D_XOPEN_SOURCE=3D600 -Wall -DAUTO -o xppaut main.o ggets.o menu.o rubber.o derived.o many_pops.o pop_list.o graphics.o dialog_box.o numerics.o choice_box.o color.o init_conds.o browse.o kinescope.o axes2.o abort.o parserslow2.o storage.o load_eqn.o form_ode.o odesol2.o gear.o eig_list.o integrate.o delay_handle.o graf_par.o dormpri.o my_ps.o my_svg.o nullcline.o torus.o pp_shoot.o lunch-new.o calc.o adj2.o my_rhs.o read_dir.o volterra2.o tabular.o markov.o histogram.o comline.o edit_rhs.o do_fit.o flags.o del_stab.o stiff.o arrayplot.o array_print.o aniparse.o simplenet.o dae_fun.o fftn.o extra.o scrngif.o nagroutines.o homsup.o txtread.o menudrive.o userbut.o Version.o backspace.o dfe.o due.o iio.o inquire.o rewind.o rsfe.o rdfmt.o sue.o uio.o wsfe.o sfe.o fmt.o lio.o lread.o open.o close.o util.o endfile.o wrtfmt.o wref.o err.o fmtlib.o rsne.o wsne.o fc77.o f2cstart.o cvode.o cvdense.o dense.o cvband.o band.o cvdiag.o cvspgmr.o spgmr.o iterativ.o vector.o llnlmath.o cv2.o autlib1.o autlib2.o autlib3.o autevd.o run_auto.o autpp.o diagram.o auto_nox.o auto_x11.o flowkm_small.o -L/usr/local/lib -lX11 -lm -lm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/libdata/pkgconfig/xbitmaps.pc - found =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/libdata/pkgconfig/x11.p= c - found =3D=3D=3D> xppaut-7.0 depends on file: /usr/local/libdata/pkgconfig/xproto.pc - found =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Staging for xppaut-7.0 =3D=3D=3D> Generating temporary packing list mkdir -p /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/bin mkdir -p /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/doc/xppaut/html mkdir -p /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/doc/xppaut/xbm mkdir -p /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/man/man1 mkdir -p /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xppaut strip xppaut install -m 755 xppaut /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/bin cp -r ode* /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xppaut cp -r help/* /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/doc/xppaut/html cp README *.pdf /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/doc/xppaut cp *.xbm /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/doc/xppaut/xbm cp xppaut.1 /wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/man/man1 =3D=3D=3D=3D> Compressing man pages (compress-man) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Building package for xppaut-7.0 pkg-static: lstat(/wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xp= paut/ode/._ex.so): No such file or directory pkg-static: lstat(/wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xp= paut/ode/._example.dylib): No such file or directory pkg-static: lstat(/wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xp= paut/ode/._example.so): No such file or directory pkg-static: lstat(/wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xp= paut/ode/._getmax.so): No such file or directory pkg-static: lstat(/wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xp= paut/ode/._getmin.so): No such file or directory pkg-static: lstat(/wrkdirs/usr/ports/math/xppaut/work/stage/usr/local/share/examples/xp= paut/ode/._t.so): No such file or directory *** Error code 1 Stop. make: stopped in /usr/ports/math/xppaut =3D=3D=3D> Cleaning for xppaut-7.0 From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 16:53:24 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B44ED595; Fri, 21 Feb 2014 16:53:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 687B61436; Fri, 21 Feb 2014 16:53:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s1LGrNiu009935; Fri, 21 Feb 2014 11:53:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LGrNdH009928; Fri, 21 Feb 2014 16:53:23 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 16:53:23 GMT Message-Id: <201402211653.s1LGrNdH009928@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 16:53:24 -0000 TB --- 2014-02-21 16:15:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 16:15: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 --- 2014-02-21 16:15:20 - starting HEAD tinderbox run for mips/mips TB --- 2014-02-21 16:15:20 - cleaning the object tree TB --- 2014-02-21 16:15:20 - /usr/local/bin/svn stat /src TB --- 2014-02-21 16:15:24 - At svn revision 262294 TB --- 2014-02-21 16:15:25 - building world TB --- 2014-02-21 16:15:25 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 16:15:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 16:15:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 16:15:25 - SRCCONF=/dev/null TB --- 2014-02-21 16:15:25 - TARGET=mips TB --- 2014-02-21 16:15:25 - TARGET_ARCH=mips TB --- 2014-02-21 16:15:25 - TZ=UTC TB --- 2014-02-21 16:15:25 - __MAKE_CONF=/dev/null TB --- 2014-02-21 16:15:25 - cd /src TB --- 2014-02-21 16:15:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 16:15:32 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c aliases_parse.c cc1: warnings being treated as errors In file included from aliases_parse.c:15: /src/libexec/dma/../../contrib/dma/aliases_parse.y:74: warning: redundant redeclaration of 'yyparse' /src/libexec/dma/../../contrib/dma/dma.h:175: warning: previous declaration of 'yyparse' was here In file included from aliases_parse.c:16: aliases_parse.h:17: warning: redundant redeclaration of 'yylval' /src/libexec/dma/../../contrib/dma/aliases_parse.y:82: warning: previous declaration of 'yylval' was here *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 16:53:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 16:53:23 - ERROR: failed to build world TB --- 2014-02-21 16:53:23 - 1568.12 user 480.74 system 2282.96 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 16:00:56 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CE7BEE8; Fri, 21 Feb 2014 16:00:56 +0000 (UTC) Received: from mail.hylton.cc (mail.hylton.cc [209.102.254.104]) by mx1.freebsd.org (Postfix) with ESMTP id 6744A1E3D; Fri, 21 Feb 2014 16:00:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.hylton.cc (Postfix) with ESMTP id 3FF0C50C90B; Fri, 21 Feb 2014 10:51:47 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.hylton.cc Received: from mail.hylton.cc ([127.0.0.1]) by localhost (mail.hylton.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKG+Tn9Gfu4p; Fri, 21 Feb 2014 10:51:41 -0500 (EST) Received: from mail.hylton.cc (mail.hylton.cc [127.0.1.1]) by mail.hylton.cc (Postfix) with ESMTP id AE04650C90A; Fri, 21 Feb 2014 10:51:41 -0500 (EST) Date: Fri, 21 Feb 2014 10:51:41 -0500 (EST) From: Dewey Hylton To: gahr@FreeBSD.org Message-ID: <1134405947.26568.1392997901552.JavaMail.root@mail> In-Reply-To: <20140221153822.GL149@gahrfit.gahr.ch> Subject: Re: lang/expect -- update coming MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.61.122.214] X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - FF3.0 (Mac)/7.1.4_GA_2555) X-Mailman-Approved-At: Fri, 21 Feb 2014 16:57:23 +0000 Cc: freebsd-stable@FreeBSD.org, Martin Wilke , freebsd-current@FreeBSD.org, jmohacsi@bsd.hu, freebsd-ports@FreeBSD.org, wrighrc@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 16:00:56 -0000 > From: "Pietro Cerutti" > To: freebsd-ports@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org > Cc: jmohacsi@bsd.hu, "Martin Wilke" , wrighrc@gmail.com, freenx@deweyonline.com, pdagog@gmail.com, > "romain garbage" > Sent: Friday, February 21, 2014 10:38:24 AM > Subject: Re: lang/expect -- update coming > > On 2014-Feb-21, 15:38, Pietro Cerutti wrote: > > All, > > > > I'm planning to commit an update to bring lang/expect up to the > > latest > > 5.45 version. At the same time, I'm going to kill > > lang/expect-devel, > > which would otherwise be left lagging behind at 5.44. > > > > The following ports use either expect or -devel (maintainers CC'd). > > > > devel/pecl-expect > > net-mgmt/rancid > > net-mgmt/rancid-devel > > Turns out my regexp-foo sucked this time.. Here's a more complete > list. > Thanks koobs@ for noticing. > > devel/pecl-expect > misc/dejagnu > misc/sshbuddy > net/freenx > net-mgmt/netmagis-topo > et-mgmt/rancid > net-mgmt/rancid-devel > security/belier i'm no longer maintaining the freenx/nxserver ports. they are so outdated at this point they should probably be killed off as well, but i have no idea who might still be using them. From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 17:06:02 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64DA7D60; Fri, 21 Feb 2014 17:06:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 111141578; Fri, 21 Feb 2014 17:06:00 +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 s1LH5xZw098143; Fri, 21 Feb 2014 12:05:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LH5xjw098133; Fri, 21 Feb 2014 17:05:59 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 17:05:59 GMT Message-Id: <201402211705.s1LH5xjw098133@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.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:06:02 -0000 TB --- 2014-02-21 16:15:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 16:15: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 --- 2014-02-21 16:15:20 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-02-21 16:15:20 - cleaning the object tree TB --- 2014-02-21 16:15:20 - /usr/local/bin/svn stat /src TB --- 2014-02-21 16:15:24 - At svn revision 262294 TB --- 2014-02-21 16:15:25 - building world TB --- 2014-02-21 16:15:25 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 16:15:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 16:15:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 16:15:25 - SRCCONF=/dev/null TB --- 2014-02-21 16:15:25 - TARGET=ia64 TB --- 2014-02-21 16:15:25 - TARGET_ARCH=ia64 TB --- 2014-02-21 16:15:25 - TZ=UTC TB --- 2014-02-21 16:15:25 - __MAKE_CONF=/dev/null TB --- 2014-02-21 16:15:25 - cd /src TB --- 2014-02-21 16:15:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 16:15:32 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c aliases_parse.c cc1: warnings being treated as errors In file included from aliases_parse.c:15: /src/libexec/dma/../../contrib/dma/aliases_parse.y:74: warning: redundant redeclaration of 'yyparse' /src/libexec/dma/../../contrib/dma/dma.h:175: warning: previous declaration of 'yyparse' was here In file included from aliases_parse.c:16: aliases_parse.h:17: warning: redundant redeclaration of 'yylval' /src/libexec/dma/../../contrib/dma/aliases_parse.y:82: warning: previous declaration of 'yylval' was here *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 17:05:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 17:05:59 - ERROR: failed to build world TB --- 2014-02-21 17:05:59 - 2218.02 user 551.49 system 3038.89 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 17:17:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84FDE384 for ; Fri, 21 Feb 2014 17:17:23 +0000 (UTC) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33B6A168B for ; Fri, 21 Feb 2014 17:17:23 +0000 (UTC) Received: by mail-yk0-f172.google.com with SMTP id 200so6621396ykr.3 for ; Fri, 21 Feb 2014 09:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gZh1mMNZ9ZpBL8YeqZHssPa1nd8HnJEkNBa3pvNxD1c=; b=K9MHsRVh1MTM1Ex13NbZyaw1JNpYUOy7nTFfpGVOBYfJm8pTPoZG6fQnV0PCC8fi9X PxoTg7Bs+TIhMeAdRMmRN/7w8x0cYen5Nl6IsIR881VO+cWqgFecgkx4mM+STMYGfuq1 8ZZakMS6sQL6tVNfxZ/+dvtwdA/RK4l4/YOBdB3rz69uRt+VEL9JD+r+W/+992ya+EvH hXd0JZ+5+eUyKpLz5UitcvMBTjgGiE3zFtNO3nJns87Mt3cCg9fObsvXHFb9uyjCG0dt A1xnDXQ0E8Gu8sGtToK3SGoMSHP/bfJ8Vm/tKlrn2copWvBa4m/IAV9XJRpikuEtgCVs JOwA== MIME-Version: 1.0 X-Received: by 10.236.120.147 with SMTP id p19mr12778375yhh.6.1393003042335; Fri, 21 Feb 2014 09:17:22 -0800 (PST) Sender: antoine.brodin.freebsd@gmail.com Received: by 10.170.80.11 with HTTP; Fri, 21 Feb 2014 09:17:22 -0800 (PST) In-Reply-To: <530783DA.1010006@missouri.edu> References: <201402211327.s1LDRsau019881@beefy1.isc.freebsd.org> <530783DA.1010006@missouri.edu> Date: Fri, 21 Feb 2014 18:17:22 +0100 X-Google-Sender-Auth: 3RKskUplg83xtVRzEVG0AYLyobg Message-ID: Subject: Re: [REL - head-i386-default][math/xppaut] Failed for xppaut-7.0 in package From: Antoine Brodin To: "Montgomery-Smith, Stephen" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 17:17:23 -0000 On Fri, Feb 21, 2014 at 5:50 PM, Montgomery-Smith, Stephen wrote: > I keep getting the following error message from pkg-fallout@. It seems > to me that the command > cp -r ode* /whereever > doesn't copy the .* files in the directories ode* in FreeBSD-CURRENT. > Is this a bug or a feature? I think new versions of bsdar/libarchive do not extract ._something anymore. Just nuke those files in post-extract if present. Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 17:31:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD4C9C11; Fri, 21 Feb 2014 17:31:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0111868; Fri, 21 Feb 2014 17:31: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 s1LHVG6i008262; Fri, 21 Feb 2014 12:31:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LHVG8j008254; Fri, 21 Feb 2014 17:31:16 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 17:31:16 GMT Message-Id: <201402211731.s1LHVG8j008254@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips64/mips Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:31:19 -0000 TB --- 2014-02-21 16:53:23 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 16:53:23 - 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 --- 2014-02-21 16:53:23 - starting HEAD tinderbox run for mips64/mips TB --- 2014-02-21 16:53:23 - cleaning the object tree TB --- 2014-02-21 16:53:23 - /usr/local/bin/svn stat /src TB --- 2014-02-21 16:53:27 - At svn revision 262294 TB --- 2014-02-21 16:53:28 - building world TB --- 2014-02-21 16:53:28 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 16:53:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 16:53:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 16:53:28 - SRCCONF=/dev/null TB --- 2014-02-21 16:53:28 - TARGET=mips TB --- 2014-02-21 16:53:28 - TARGET_ARCH=mips64 TB --- 2014-02-21 16:53:28 - TZ=UTC TB --- 2014-02-21 16:53:28 - __MAKE_CONF=/dev/null TB --- 2014-02-21 16:53:28 - cd /src TB --- 2014-02-21 16:53:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 16:53:35 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c aliases_parse.c cc1: warnings being treated as errors In file included from aliases_parse.c:15: /src/libexec/dma/../../contrib/dma/aliases_parse.y:74: warning: redundant redeclaration of 'yyparse' /src/libexec/dma/../../contrib/dma/dma.h:175: warning: previous declaration of 'yyparse' was here In file included from aliases_parse.c:16: aliases_parse.h:17: warning: redundant redeclaration of 'yylval' /src/libexec/dma/../../contrib/dma/aliases_parse.y:82: warning: previous declaration of 'yylval' was here *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 17:31:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 17:31:16 - ERROR: failed to build world TB --- 2014-02-21 17:31:16 - 1562.47 user 460.76 system 2273.11 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 17:40:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 112C3292 for ; Fri, 21 Feb 2014 17:40:39 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE55318F6 for ; Fri, 21 Feb 2014 17:40:38 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1WGu5U-0031gp-Vl>; Fri, 21 Feb 2014 18:40:37 +0100 Received: from g229110055.adsl.alicedsl.de ([92.229.110.55] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1WGu5U-000bSS-Sj>; Fri, 21 Feb 2014 18:40:36 +0100 Date: Fri, 21 Feb 2014 18:40:33 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" Message-ID: <20140221184033.7759978f@munin.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/IWV4pIn.Ae+_x/FiuAB9A.r"; protocol="application/pgp-signature" X-Originating-IP: 92.229.110.55 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 17:40:39 -0000 --Sig_/IWV4pIn.Ae+_x/FiuAB9A.r Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET 2014 amd64 I run neither claws-mail nor firfox run after the last buildworld. They fail both with the error Invalid alignment Does anyone see this problem too? I tried to recompile claws-mail and firefox, but without success (compilation succeeded, but the error stays). What happened here? How to solve?=20 Regards, O. Hartmann --Sig_/IWV4pIn.Ae+_x/FiuAB9A.r Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTB4+WAAoJEOgBcD7A/5N86GwH/3I6B41MWfz18zGt7C2m4+0t QI8GwoszSJHdn6qomBIsam1+QmGXXfHjX6Dd2Y7ZS9UZn2gjteAcaXhWIBbs3/CW BDvA+oU4W6UNBLsxDDbx3PlDeloyUg6EHTzDBWTyvRa6f4E3tZRJrd95LLFfofDN 5rtB1oNHmQTaT27P+LFEMM7fcUxwOTTj+qVnELJzPy1DN3tZ8013VfMAvn2s4r2r fh+cvQrLAcPOxdoVZs5ddhfmLIDuX1al8cBFCai6he5P1g8oySK8xbkLiSsyNsfU pxPgN2729320JFnJtylzmEDMuzootmPSnWagmvo/Y71I//AYtRzu7j/l1z3x1m4= =2qW8 -----END PGP SIGNATURE----- --Sig_/IWV4pIn.Ae+_x/FiuAB9A.r-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 17:49:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18C8A604; Fri, 21 Feb 2014 17:49:06 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C833219BA; Fri, 21 Feb 2014 17:49:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d56b:2232:ab24:bb0a] (unknown [IPv6:2001:7b8:3a7:0:d56b:2232:ab24:bb0a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EF8495C45; Fri, 21 Feb 2014 18:49:01 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_4D408C0E-D7CD-4FC9-92ED-3C222662020C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" From: Dimitry Andric In-Reply-To: <20140221184033.7759978f@munin.walstatt.dyndns.org> Date: Fri, 21 Feb 2014 18:49:13 +0100 Message-Id: <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> References: <20140221184033.7759978f@munin.walstatt.dyndns.org> To: "O. Hartmann" X-Mailer: Apple Mail (2.1827) Cc: FreeBSD CURRENT , David Xu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 17:49:06 -0000 --Apple-Mail=_4D408C0E-D7CD-4FC9-92ED-3C222662020C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 21 Feb 2014, at 18:40, O. Hartmann wrote: > On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET 2014 > amd64 I run neither claws-mail nor firfox run after the last > buildworld. They fail both with the error > > Invalid alignment > > Does anyone see this problem too? I tried to recompile claws-mail and > firefox, but without success (compilation succeeded, but the error > stays). > > What happened here? How to solve? Can you try reverting r262277, rebuilding libexec/rtld-elf and reinstalling it, and seeing if that fixes it? -Dimitry --Apple-Mail=_4D408C0E-D7CD-4FC9-92ED-3C222662020C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMHkZwACgkQsF6jCi4glqN9cACg91dU37/NICgKt//1hWK5O6S0 6uIAoPVuEbmzQD2dIOs8ha1hfv+8qqIp =WpXr -----END PGP SIGNATURE----- --Apple-Mail=_4D408C0E-D7CD-4FC9-92ED-3C222662020C-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 18:00:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 984C2D9B; Fri, 21 Feb 2014 18:00:18 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 516961A94; Fri, 21 Feb 2014 18:00:17 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1WGuOW-0037c8-Eq>; Fri, 21 Feb 2014 19:00:16 +0100 Received: from g229110055.adsl.alicedsl.de ([92.229.110.55] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1WGuOW-000cly-BZ>; Fri, 21 Feb 2014 19:00:16 +0100 Date: Fri, 21 Feb 2014 19:00:13 +0100 From: "O. Hartmann" To: Dimitry Andric Subject: Re: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" Message-ID: <20140221190013.475b0654@munin.walstatt.dyndns.org> In-Reply-To: <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> References: <20140221184033.7759978f@munin.walstatt.dyndns.org> <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/cQ68Exg9yOpR/xZ24tUYCs9"; protocol="application/pgp-signature" X-Originating-IP: 92.229.110.55 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , David Xu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 18:00:18 -0000 --Sig_/cQ68Exg9yOpR/xZ24tUYCs9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 21 Feb 2014 18:49:13 +0100 Dimitry Andric wrote: > On 21 Feb 2014, at 18:40, O. Hartmann > wrote: > > On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET > > 2014 amd64 I run neither claws-mail nor firfox run after the last > > buildworld. They fail both with the error > >=20 > > Invalid alignment > >=20 > > Does anyone see this problem too? I tried to recompile claws-mail > > and firefox, but without success (compilation succeeded, but the > > error stays). > >=20 > > What happened here? How to solve?=20 >=20 > Can you try reverting r262277, rebuilding libexec/rtld-elf and > reinstalling it, and seeing if that fixes it? >=20 > -Dimitry >=20 Hello Dimitry, in r262277 there is no change in libexec/rtld-elf, I had to go back to r262270. I did as requested and reinstalling libexec/rtld-elf fixes the reported issue. Regards, Oliver --Sig_/cQ68Exg9yOpR/xZ24tUYCs9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTB5QyAAoJEOgBcD7A/5N8B68H/0Q8U7ytHfbYLBbmMgSQC/Wk amDZd1svurixJc618om8YtblojX71lZEagZhmvf8w9gC4pz+HDoVNgS50dW6ilE2 yE10jZAyudMjiozN9lEqtfAVafxgLYmkxDA+2VljN1kJKly0mO0wXXYzJUQnG1u4 uWdM2zZxOdf9IEhjQ9GOA3zJQKz8KTe3fT52pjBnuNQAHB6NiGaAUtMYgeQhcNK9 JeUffU6r3oc8ob9Ofjj4y1heeM9GWJOnTpFuHTW9Xw3SXYzGzQK9aufPHUUJZd+v YCuFXpc97e1yqFGZ6ZQ7zUhtV5aNn4/bG2eeGcji7oqQ49op8LKUPWjbesSRQKQ= =7Bz+ -----END PGP SIGNATURE----- --Sig_/cQ68Exg9yOpR/xZ24tUYCs9-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 18:03:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40669F1B; Fri, 21 Feb 2014 18:03:31 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7E031B30; Fri, 21 Feb 2014 18:03:30 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1WGuRd-0038XD-B2>; Fri, 21 Feb 2014 19:03:29 +0100 Received: from g229110055.adsl.alicedsl.de ([92.229.110.55] helo=munin.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1WGuRd-000cxa-7d>; Fri, 21 Feb 2014 19:03:29 +0100 Date: Fri, 21 Feb 2014 19:03:30 +0100 From: "O. Hartmann" To: "O. Hartmann" Subject: Re: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" Message-ID: <20140221190330.709105d8@munin.walstatt.dyndns.org> In-Reply-To: <20140221190013.475b0654@munin.walstatt.dyndns.org> References: <20140221184033.7759978f@munin.walstatt.dyndns.org> <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> <20140221190013.475b0654@munin.walstatt.dyndns.org> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/DCErVfsI6tUZ8M5EwK43IvZ"; protocol="application/pgp-signature" X-Originating-IP: 92.229.110.55 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , Dimitry Andric , David Xu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 18:03:31 -0000 --Sig_/DCErVfsI6tUZ8M5EwK43IvZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 21 Feb 2014 19:00:13 +0100 "O. Hartmann" wrote: > On Fri, 21 Feb 2014 18:49:13 +0100 > Dimitry Andric wrote: >=20 > > On 21 Feb 2014, at 18:40, O. Hartmann > > wrote: > > > On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET > > > 2014 amd64 I run neither claws-mail nor firfox run after the last > > > buildworld. They fail both with the error > > >=20 > > > Invalid alignment > > >=20 > > > Does anyone see this problem too? I tried to recompile claws-mail > > > and firefox, but without success (compilation succeeded, but the > > > error stays). > > >=20 > > > What happened here? How to solve?=20 > >=20 > > Can you try reverting r262277, rebuilding libexec/rtld-elf and > > reinstalling it, and seeing if that fixes it? > >=20 > > -Dimitry > >=20 >=20 > Hello Dimitry, >=20 > in r262277 there is no change in libexec/rtld-elf, I had to go back to > r262270. I did as requested and reinstalling libexec/rtld-elf fixes > the reported issue. >=20 > Regards, > Oliver Sorry, it is r262276 --Sig_/DCErVfsI6tUZ8M5EwK43IvZ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTB5TzAAoJEOgBcD7A/5N8zK8H/1LQGmIoG+X3HHh+dN6k1vPx SFWV1mXWDG+pSVNfZC3PYyxfRZzvOQy5clMyx4NODMQ/sTedSBxTpYO/zGQ6DKP7 4X6E9utyeBtR2ABDijfl2TZICc4/Pxta9e2SyPwFDGhBgcrqh5/qCG3OaA+t+zY4 dMoH8GBQh8xHjIMnyggy8/CedgHmCSHFbOAesICJJKM14HS8jHSK7bQB2wnl3UfR B4F1CmGOldbvkmIoQLAwbNrWuBmCwMxiO03gUKTMnpzWKla6CS9xNlVRAKCEcJr0 EoHmeJ0zMiooCH3t1MbdzjQ8aulDZ7hCJiHjsm6CUjoRkKyZUe5dqSawdjV5S5A= =jB6g -----END PGP SIGNATURE----- --Sig_/DCErVfsI6tUZ8M5EwK43IvZ-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 18:11:05 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E12A3B0; Fri, 21 Feb 2014 18:11:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E577A1C15; Fri, 21 Feb 2014 18:11:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s1LIAvn1081343; Fri, 21 Feb 2014 13:10:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LIAvYX081339; Fri, 21 Feb 2014 18:10:57 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 18:10:57 GMT Message-Id: <201402211810.s1LIAvYX081339@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:11:05 -0000 TB --- 2014-02-21 17:31:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 17:31:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-21 17:31:17 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-02-21 17:31:17 - cleaning the object tree TB --- 2014-02-21 17:31:17 - /usr/local/bin/svn stat /src TB --- 2014-02-21 17:31:21 - At svn revision 262294 TB --- 2014-02-21 17:31:22 - building world TB --- 2014-02-21 17:31:22 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 17:31:22 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 17:31:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 17:31:22 - SRCCONF=/dev/null TB --- 2014-02-21 17:31:22 - TARGET=sparc64 TB --- 2014-02-21 17:31:22 - TARGET_ARCH=sparc64 TB --- 2014-02-21 17:31:22 - TZ=UTC TB --- 2014-02-21 17:31:22 - __MAKE_CONF=/dev/null TB --- 2014-02-21 17:31:22 - cd /src TB --- 2014-02-21 17:31:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 17:31:29 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c aliases_parse.c cc1: warnings being treated as errors In file included from aliases_parse.c:15: /src/libexec/dma/../../contrib/dma/aliases_parse.y:74: warning: redundant redeclaration of 'yyparse' /src/libexec/dma/../../contrib/dma/dma.h:175: warning: previous declaration of 'yyparse' was here In file included from aliases_parse.c:16: aliases_parse.h:17: warning: redundant redeclaration of 'yylval' /src/libexec/dma/../../contrib/dma/aliases_parse.y:82: warning: previous declaration of 'yylval' was here *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 18:10:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 18:10:52 - ERROR: failed to build world TB --- 2014-02-21 18:10:52 - 1730.41 user 383.80 system 2374.98 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 18:57:18 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFB73BCC; Fri, 21 Feb 2014 18:57:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13B1210D1; Fri, 21 Feb 2014 18:57:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s1LIvFKv017433; Fri, 21 Feb 2014 13:57:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LIvARk017411; Fri, 21 Feb 2014 18:57:10 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 18:57:10 GMT Message-Id: <201402211857.s1LIvARk017411@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/pc98 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:57:19 -0000 TB --- 2014-02-21 15:57:59 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 15:57:59 - 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 --- 2014-02-21 15:57:59 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-02-21 15:57:59 - cleaning the object tree TB --- 2014-02-21 15:57:59 - /usr/local/bin/svn stat /src TB --- 2014-02-21 15:58:04 - At svn revision 262294 TB --- 2014-02-21 15:58:05 - building world TB --- 2014-02-21 15:58:05 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 15:58:05 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 15:58:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 15:58:05 - SRCCONF=/dev/null TB --- 2014-02-21 15:58:05 - TARGET=pc98 TB --- 2014-02-21 15:58:05 - TARGET_ARCH=i386 TB --- 2014-02-21 15:58:05 - TZ=UTC TB --- 2014-02-21 15:58:05 - __MAKE_CONF=/dev/null TB --- 2014-02-21 15:58:05 - cd /src TB --- 2014-02-21 15:58:05 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 15:58:13 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/local.c cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/mail.c cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/net.c cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/dma/../../contrib/dma/spool.c /src/libexec/dma/../../contrib/dma/spool.c:418:33: error: comparison of integers of different signs: 'unsigned int' and 'time_t' (aka 'int') [-Werror,-Wsign-compare] if (st.st_mtim.tv_sec + period >= now.tv_sec) ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 18:57:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 18:57:10 - ERROR: failed to build world TB --- 2014-02-21 18:57:10 - 9088.23 user 1190.88 system 10750.65 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 19:09:33 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97287F6F; Fri, 21 Feb 2014 19:09:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3798011C4; Fri, 21 Feb 2014 19:09:32 +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 s1LJ9UWW072848; Fri, 21 Feb 2014 14:09:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LJ9Pp9072607; Fri, 21 Feb 2014 19:09:25 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 19:09:25 GMT Message-Id: <201402211909.s1LJ9Pp9072607@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.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:09:33 -0000 TB --- 2014-02-21 17:05:59 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 17:05:59 - 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 --- 2014-02-21 17:05:59 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-02-21 17:05:59 - cleaning the object tree TB --- 2014-02-21 17:05:59 - /usr/local/bin/svn stat /src TB --- 2014-02-21 17:06:03 - At svn revision 262294 TB --- 2014-02-21 17:06:04 - building world TB --- 2014-02-21 17:06:04 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 17:06:04 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 17:06:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 17:06:04 - SRCCONF=/dev/null TB --- 2014-02-21 17:06:04 - TARGET=powerpc TB --- 2014-02-21 17:06:04 - TARGET_ARCH=powerpc TB --- 2014-02-21 17:06:04 - TZ=UTC TB --- 2014-02-21 17:06:04 - __MAKE_CONF=/dev/null TB --- 2014-02-21 17:06:04 - cd /src TB --- 2014-02-21 17:06:04 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 17:06:11 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c aliases_parse.c cc1: warnings being treated as errors In file included from aliases_parse.c:15: /src/libexec/dma/../../contrib/dma/aliases_parse.y:74: warning: redundant redeclaration of 'yyparse' /src/libexec/dma/../../contrib/dma/dma.h:175: warning: previous declaration of 'yyparse' was here In file included from aliases_parse.c:16: aliases_parse.h:17: warning: redundant redeclaration of 'yylval' /src/libexec/dma/../../contrib/dma/aliases_parse.y:82: warning: previous declaration of 'yylval' was here *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 19:09:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 19:09:25 - ERROR: failed to build world TB --- 2014-02-21 19:09:25 - 6377.55 user 883.67 system 7406.15 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 19:10:48 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB014121; Fri, 21 Feb 2014 19:10:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A22741234; Fri, 21 Feb 2014 19:10:46 +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 s1LJAe9a075253; Fri, 21 Feb 2014 14:10:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1LJAeAn075252; Fri, 21 Feb 2014 19:10:40 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 21 Feb 2014 19:10:40 GMT Message-Id: <201402211910.s1LJAeAn075252@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:10:48 -0000 TB --- 2014-02-21 17:06:09 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-21 17:06:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-21 17:06:09 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2014-02-21 17:06:09 - cleaning the object tree TB --- 2014-02-21 17:06:09 - /usr/local/bin/svn stat /src TB --- 2014-02-21 17:06:13 - At svn revision 262294 TB --- 2014-02-21 17:06:14 - building world TB --- 2014-02-21 17:06:14 - CROSS_BUILD_TESTING=YES TB --- 2014-02-21 17:06:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-21 17:06:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-21 17:06:14 - SRCCONF=/dev/null TB --- 2014-02-21 17:06:14 - TARGET=powerpc TB --- 2014-02-21 17:06:14 - TARGET_ARCH=powerpc64 TB --- 2014-02-21 17:06:14 - TZ=UTC TB --- 2014-02-21 17:06:14 - __MAKE_CONF=/dev/null TB --- 2014-02-21 17:06:14 - cd /src TB --- 2014-02-21 17:06:14 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 21 17:06:21 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -I/src/libexec/dma/../../contrib/dma -DHAVE_REALLOCF -DHAVE_STRLCPY -DHAVE_GETPROGNAME -DCONF_PATH='"/etc/dma"' -DLIBEXEC_PATH='"/usr/libexec"' -DDMA_VERSION='"v0.9+"' -DDMA_ROOT_USER='"mailnull"' -DDMA_GROUP='"mail"' -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wformat=2 -Wno-format-extra-args -Werror -c aliases_parse.c cc1: warnings being treated as errors In file included from aliases_parse.c:15: /src/libexec/dma/../../contrib/dma/aliases_parse.y:74: warning: redundant redeclaration of 'yyparse' /src/libexec/dma/../../contrib/dma/dma.h:175: warning: previous declaration of 'yyparse' was here In file included from aliases_parse.c:16: aliases_parse.h:17: warning: redundant redeclaration of 'yylval' /src/libexec/dma/../../contrib/dma/aliases_parse.y:82: warning: previous declaration of 'yylval' was here *** Error code 1 Stop. bmake[3]: stopped in /src/libexec/dma *** Error code 1 Stop. bmake[2]: stopped in /src/libexec *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-21 19:10:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-21 19:10:40 - ERROR: failed to build world TB --- 2014-02-21 19:10:40 - 6429.91 user 895.75 system 7470.80 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 19:49:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8EB1D0A; Fri, 21 Feb 2014 19:49:03 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8471015A7; Fri, 21 Feb 2014 19:49:03 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s1LJn2cC063072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Feb 2014 11:49:02 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s1LJn2Uc063071; Fri, 21 Feb 2014 11:49:02 -0800 (PST) (envelope-from sgk) Date: Fri, 21 Feb 2014 11:49:02 -0800 From: Steve Kargl To: Antoine Brodin Subject: Re: Help fixing clang 3.4 Message-ID: <20140221194902.GA63057@troutmask.apl.washington.edu> References: <20140220011939.GA49492@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 19:49:03 -0000 On Thu, Feb 20, 2014 at 07:43:54AM +0100, Antoine Brodin wrote: > On Thu, Feb 20, 2014 at 2:19 AM, Steve Kargl > wrote: > > Can someone point to where I disable clang from > > issuing an error and aborting on an unknown option? > > > > % cd /usr/ports/databases/py-sqlite3 > > % make > > > > cc ... -R/usr/local/lib -lsqlite3 -o build/lib.freebsd-11.0-CURRENT-amd64-2.7/_sqlite3.so > > cc: error: unknown argument: '-R/usr/local/lib' > > error: command 'cc' failed with exit status 1 > > *** Error code 1 > > You can try this > http://docs.freebsd.org/cgi/mid.cgi?CAALwa8m9-dpiO4fpA_BG-QeZyo9wsRpDVXHz_CTNUYeFLK7GVA > Thanks. That appears to have fixed that particular. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 23:38:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF2C65DF for ; Fri, 21 Feb 2014 23:38:15 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91C8A19CB for ; Fri, 21 Feb 2014 23:38:15 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1WGzfU-0005WF-Hc for freebsd-current@freebsd.org; Fri, 21 Feb 2014 15:38:08 -0800 Date: Fri, 21 Feb 2014 15:38:08 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1393025888512-5887996.post@n5.nabble.com> Subject: base unzip on 10-STABLE/ 11-HEAD "unzip: skipping non-regular entry" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 21 Feb 2014 23:38:15 -0000 Hello, Unfortunately, this is the case with *zips from Dropbox (Download as .zip) directory option. $ /usr/bin/unzip file.zip Archive: file.zip unzip: skipping non-regular entry '' unzip: skipping non-regular entry 'A B C D.pdf' archivers/unzip manages this case though... $ /usr/local/bin/unzip file.zip Archive: file.zip warning: stripped absolute path spec from / mapname: conversion of failed inflating: A B C D.pdf Tested on 10-STABLE, but should be the same on HEAD. -- View this message in context: http://freebsd.1045724.n5.nabble.com/base-unzip-on-10-STABLE-11-HEAD-unzip-skipping-non-regular-entry-tp5887996.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Feb 21 22:09:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04644D49; Fri, 21 Feb 2014 22:09:43 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B278C1259; Fri, 21 Feb 2014 22:09:42 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id v10so3858954pde.14 for ; Fri, 21 Feb 2014 14:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=N+ZI+Nhh0iRA9FgEw5ud/q0cY2YCHF+3pg3nUUqpZBo=; b=CIf1bTgL/N6QDtcyFsP4J3oLIObVFo3dc00gCvyHKWGjRTimtehJdBl/SiG35/NSPT cBo5lH1a+Jd1S394vPkfK1scyyuPLQMFqClko4Ge4XB5pOHm6FNH8Cbxw6ZhFVMG5dIW cHuYgUHtKJD0XmLPpiq+nLgcDRCXWUrREknE984FnvNElC+rEcF3hIjkjl/XUu9xXVtH hZ4a2PMVDsxgrJHw8AmiZDcBNiG6tUmkocyR6D3bPjrNYf+G6XpEb20CrZ4EGTkdMrw+ 14wHhY6RpRiLil/CDFwboD2UITuzJx0EsKGVruiRB/HGTf63//aAyOVame9LeTRbsw3s W1rQ== X-Received: by 10.68.221.42 with SMTP id qb10mr11561926pbc.65.1393020581682; Fri, 21 Feb 2014 14:09:41 -0800 (PST) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id ei4sm24670552pbb.42.2014.02.21.14.09.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Feb 2014 14:09:41 -0800 (PST) Message-ID: <5307CE99.1050605@FreeBSD.org> Date: Sat, 22 Feb 2014 09:09:29 +1100 From: Kubilay Kocak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Dewey Hylton , gahr@FreeBSD.org Subject: Re: lang/expect -- update coming References: <1134405947.26568.1392997901552.JavaMail.root@mail> In-Reply-To: <1134405947.26568.1392997901552.JavaMail.root@mail> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Feb 2014 00:14:12 +0000 Cc: freebsd-stable@FreeBSD.org, Martin Wilke , jmohacsi@bsd.hu, freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org, wrighrc@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: koobs@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 22:09:43 -0000 On 22/02/2014 2:51 AM, Dewey Hylton wrote: >> From: "Pietro Cerutti" >> To: freebsd-ports@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org >> Cc: jmohacsi@bsd.hu, "Martin Wilke" , wrighrc@gmail.com, freenx@deweyonline.com, pdagog@gmail.com, >> "romain garbage" >> Sent: Friday, February 21, 2014 10:38:24 AM >> Subject: Re: lang/expect -- update coming >> >> On 2014-Feb-21, 15:38, Pietro Cerutti wrote: >>> All, >>> >>> I'm planning to commit an update to bring lang/expect up to the >>> latest >>> 5.45 version. At the same time, I'm going to kill >>> lang/expect-devel, >>> which would otherwise be left lagging behind at 5.44. >>> >>> The following ports use either expect or -devel (maintainers CC'd). >>> >>> devel/pecl-expect >>> net-mgmt/rancid >>> net-mgmt/rancid-devel >> >> Turns out my regexp-foo sucked this time.. Here's a more complete >> list. >> Thanks koobs@ for noticing. >> >> devel/pecl-expect >> misc/dejagnu >> misc/sshbuddy >> net/freenx >> net-mgmt/netmagis-topo >> et-mgmt/rancid >> net-mgmt/rancid-devel >> security/belier > > i'm no longer maintaining the freenx/nxserver ports. they are so outdated at this point they should probably be killed off as well, but i have no idea who might still be using them. While the MAINTAINER line references your email, you do, even if not for version updates. As maintainer, you have a couple of PR options up your sleeve: - Reset maintainer, so someone else can pick them up - Set EXPIRE with reason and an appropriate lead time to removal The above can also serve to communicate to users-come-would-be-maintainers that they might need attention and provide the impetus to jump in and have a go :) Koobs From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 02:34:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30697C72; Sat, 22 Feb 2014 02:34:02 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01B7C18AE; Sat, 22 Feb 2014 02:34:01 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s1M2LNU7038741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 18:21:26 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5308099F.4090706@freebsd.org> Date: Sat, 22 Feb 2014 10:21:19 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wojciech A. Koszek" , freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: BSD XXI Manifesto [agree] [intersting] References: <20140218072821.GF34282@FreeBSD.org> In-Reply-To: <20140218072821.GF34282@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 02:34:02 -0000 On 2/18/14, 3:28 PM, Wojciech A. Koszek wrote: > (cross-posted message: eventual discussion let's keep on hackers@) > > Hello, > > After being disappointed with the list of submitted FreeBSD ideas, I created > my own Machiavellist vision of XXI-century FreeBSD. I paste it below. If you > want to add something, it's here: > > https://wiki.freebsd.org/BSD_XXI_Manifesto > > GSOC students could use this as an inspiration for their projects. The idea > is to invite non-C, non-OS, non-kernel developers to help out with FreeBSD > stuff. > > ============ > > BSDXXI manifesto [nice stuff] removed for brevity I like all this.. I thought you meant XXI to mean the "FreeBSD's 21st year" but there is more than one year's worth of stuff there. I really suggest people seriously look at the list.. lots of really neat ideas. peole who are not necessarily C coders could do lots of this if we had a project to gather people under to do it. PCBSD people would be a core of interested people.. From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 04:59:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F21A9ED0 for ; Sat, 22 Feb 2014 04:59:53 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id C7D831FFB for ; Sat, 22 Feb 2014 04:59:52 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 638075F984 for ; Sat, 22 Feb 2014 04:59:50 +0000 (UTC) Message-ID: <53082EC5.3060709@allanjude.com> Date: Fri, 21 Feb 2014 23:59:49 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: BSD XXI Manifesto [agree] [intersting] References: <20140218072821.GF34282@FreeBSD.org> <5308099F.4090706@freebsd.org> In-Reply-To: <5308099F.4090706@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hg19HAhdCiQaeuGpFJua8T3qGahqor1qx" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 04:59:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hg19HAhdCiQaeuGpFJua8T3qGahqor1qx Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-02-21 21:21, Julian Elischer wrote: > On 2/18/14, 3:28 PM, Wojciech A. Koszek wrote: >> (cross-posted message: eventual discussion let's keep on hackers@) >> >> Hello, >> >> After being disappointed with the list of submitted FreeBSD ideas, I >> created >> my own Machiavellist vision of XXI-century FreeBSD. I paste it below. >> If you >> want to add something, it's here: >> >> https://wiki.freebsd.org/BSD_XXI_Manifesto >> >> GSOC students could use this as an inspiration for their projects. The= >> idea >> is to invite non-C, non-OS, non-kernel developers to help out with >> FreeBSD >> stuff. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> BSDXXI manifesto > [nice stuff] removed for brevity >=20 > I like all this.. I thought you meant XXI to mean the "FreeBSD's 21st > year" > but there is more than one year's worth of stuff there. >=20 > I really suggest people seriously look at the list.. lots of really nea= t > ideas. > peole who are not necessarily C coders could do lots of this if we had = a > project to gather people under to do it. > PCBSD people would be a core of interested people.. >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" I can see the remote controlled installer being especially useful for 'appliance' type devices, like FreeNAS, pfSense, FUDO, etc. How would your phone find the address of the machine once it boots off the USB, so you could access the web server? --=20 Allan Jude --hg19HAhdCiQaeuGpFJua8T3qGahqor1qx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTCC7IAAoJEJrBFpNRJZKfv1AQAJ+IXsum+XAxK0ul8hsPLz0v KSu2db4RH05UCeZQz2kxgl10LjH++xmIiMFpivrdFKPD5FWdPVt8eFFFN3meCpmA pS/rmhuLUU5rADzEt9B8ym+PQeK2LsALQOMxuXejaD2Pb352M4yvDwa28PZhr99W sCX9vvv7kidnvRKD9nC/L5/rZW/gQr34XrGWeS0zPq8L78LFPM+hJ4JLhIkTOkea RVY2vNVRuPLV6yCgUzIhCZ2YaDN1LZyKznxSlogJYdpJQ3gRyCDNgQrebg65aO+2 uMFv715CnYA2tSydFVH/3LeSV0D9i+vFuL68YHEPdtEQv5CNx0H1JEMoXaZ/ZBPY 0FwVTkShLD+GSUrR/vYDV7pfjWXMM9riKemMQIVWNqyAAy9iJWpw06ULn4YMvKnK x74tGBEo2uIcbEkXqn6OD67f+jdecBneRehyA+DL/fjUwNwoozyq+rL5GrAOGcB+ 3eSGKBT85lY4TuFJb9P4jsMRR8K3EYq9Q3IGCwt3G7k0HL4/Wp6JcLfbHb+ANIxn nobOroTnvNOlxgOudHCoTVKSyKbLoJNRBiNyyIK7JNrJ/KJqPJtlggufyexRkyXO UQpskuvCH45nxUQNJ0j0o9Fh84naK4v5/30AFgC10zzja2B/RtJ5Mskfb+BtIv8I SgwPukT3lcSvFQQMoFsR =pYyD -----END PGP SIGNATURE----- --hg19HAhdCiQaeuGpFJua8T3qGahqor1qx-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 05:16:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E18734F for ; Sat, 22 Feb 2014 05:16:49 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6C55118E for ; Sat, 22 Feb 2014 05:16:48 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id b8so3138021lan.5 for ; Fri, 21 Feb 2014 21:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zCqwBWJ5uvOW4sobHVqcTqVD87dHhf9jbURERf3fDu4=; b=MCeIUTBL6imNpi9czutbibEbf9YO4rOf92ux+U4XUBftDsseIgGPGkJv6MKJREu0+e eQLMVOoAxbt25JaUArDt4wbzqdVIbImMwnMQFNuYCiEWkud5IcFYyNvwCXdm+E40OKgd zTAyPHjcGoygCxa/tUEbPSmnEQ3QFYSTvDENpvhEtztkjNhGQKUbfa+qDvm5ey16Eu62 0xQ1hdrsgEJf4lM8psqRdYvAH8XbhdNX3diew6b8PtoDJshUzJit9R+VeK+ZowaGwI7b 9+zx2HYNvjZGgzyujzhf/kj/EkFUKWIo+DXTWPYtNECwx8LaxnIvHkE/sEpvIqwqXyVl YyHA== MIME-Version: 1.0 X-Received: by 10.112.129.168 with SMTP id nx8mr5780703lbb.37.1393046206899; Fri, 21 Feb 2014 21:16:46 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.115.4.162 with HTTP; Fri, 21 Feb 2014 21:16:46 -0800 (PST) In-Reply-To: <53082EC5.3060709@allanjude.com> References: <20140218072821.GF34282@FreeBSD.org> <5308099F.4090706@freebsd.org> <53082EC5.3060709@allanjude.com> Date: Fri, 21 Feb 2014 21:16:46 -0800 X-Google-Sender-Auth: 4JpqLj7Zok9K_9jjv6rg7gC8aik Message-ID: Subject: Re: BSD XXI Manifesto [agree] [intersting] From: Luigi Rizzo To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 05:16:49 -0000 On Fri, Feb 21, 2014 at 8:59 PM, Allan Jude wrote: > On 2014-02-21 21:21, Julian Elischer wrote: > > On 2/18/14, 3:28 PM, Wojciech A. Koszek wrote: > >> (cross-posted message: eventual discussion let's keep on hackers@) > >> > >> Hello, > >> > >> After being disappointed with the list of submitted FreeBSD ideas, I > >> created > >> my own Machiavellist vision of XXI-century FreeBSD. I paste it below. > >> If you > >> want to add something, it's here: > >> > >> https://wiki.freebsd.org/BSD_XXI_Manifesto > >> > >> GSOC students could use this as an inspiration for their projects. The > >> idea > >> is to invite non-C, non-OS, non-kernel developers to help out with > >> FreeBSD > >> stuff. > >> > >> ============ > >> > >> BSDXXI manifesto > > [nice stuff] removed for brevity > > > > I like all this.. I thought you meant XXI to mean the "FreeBSD's 21st > > year" > > but there is more than one year's worth of stuff there. > > > > I really suggest people seriously look at the list.. lots of really neat > > ideas. > > peole who are not necessarily C coders could do lots of this if we had a > > project to gather people under to do it. > > PCBSD people would be a core of interested people.. > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > I can see the remote controlled installer being especially useful for > 'appliance' type devices, like FreeNAS, pfSense, FUDO, etc. > > yes i agree the approach is nice. what is unfortunate is that sometimes these appliances are in environments where there is no [open] wireless access so one might consider bringing two usb sticks -- the disk image and a wifi. > How would your phone find the address of the machine once it boots off > the USB, so you could access the web server? > I presume UPNP can come to help here. Otherwise the appliance can try and encode the information with one of the following methods (with a matching app on the phone): - with a QR code on the screen, if it has one; - playing tones on the speakers, if it has one; - flashing leds (e.g. some USB keys have 'activity' leds) cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 06:54:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CAAB231 for ; Sat, 22 Feb 2014 06:54:53 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B0911861 for ; Sat, 22 Feb 2014 06:54:53 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so9740442qgd.1 for ; Fri, 21 Feb 2014 22:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kjT2IzeAtGfeZxdvF5nvTsIOCMNOCJu+zGiBkOsoY48=; b=iRammYgwcbI76OHxIw2PjVYy21ovAOFyM0DcIsIXCQNI3J179viO3n5PoYmAdtqTMW 8y3d0ncl/L/AllDcrzboy3Vcxl0e9bhS/KhAycsrJRtqg/94hkwYiD0hLZBlztLfqZgJ QHdwWQLYSSwYX45WS0ko5L6hAg8SLa1r05hy7cH0/hANisXxJuTx4OssiWrJES3uzQuh Im0K7ZevaA+/ixvCONgSxoZTEbQkze6UqVYL9CWy08bBHnWOOAgA5L7IsY8fWUIAGcFU gn1+1RLb6feqdoKx0R1kUCgtAjHtO0B5VtNryrliKcS2g7/leZ69sN8XKSwoB+eXHemm 2XUQ== MIME-Version: 1.0 X-Received: by 10.140.42.138 with SMTP id c10mr14857031qga.24.1393052092529; Fri, 21 Feb 2014 22:54:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Fri, 21 Feb 2014 22:54:52 -0800 (PST) In-Reply-To: <53082EC5.3060709@allanjude.com> References: <20140218072821.GF34282@FreeBSD.org> <5308099F.4090706@freebsd.org> <53082EC5.3060709@allanjude.com> Date: Fri, 21 Feb 2014 22:54:52 -0800 X-Google-Sender-Auth: Z1C9Z-hqD8b5bEsXQQ5imbw1y9g Message-ID: Subject: Re: BSD XXI Manifesto [agree] [intersting] From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 06:54:53 -0000 On 21 February 2014 20:59, Allan Jude wrote: > I can see the remote controlled installer being especially useful for > 'appliance' type devices, like FreeNAS, pfSense, FUDO, etc. > > How would your phone find the address of the machine once it boots off > the USB, so you could access the web server? "what apple does." -a From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 08:12:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBCCFB39; Sat, 22 Feb 2014 08:12:44 +0000 (UTC) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C94B1DA2; Sat, 22 Feb 2014 08:12:43 +0000 (UTC) Received: from [93.183.237.30] (helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WH7hL-000G8T-0m; Sat, 22 Feb 2014 10:12:35 +0200 Message-ID: <53085BF2.8040703@shurik.kiev.ua> Date: Sat, 22 Feb 2014 10:12:34 +0200 From: Alexandr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" References: <20140221184033.7759978f@munin.walstatt.dyndns.org> <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> <20140221190013.475b0654@munin.walstatt.dyndns.org> <20140221190330.709105d8@munin.walstatt.dyndns.org> In-Reply-To: <20140221190330.709105d8@munin.walstatt.dyndns.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 93.183.237.30 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-SA-Exim-Scanned: No (on graal.it-profi.org.ua); SAEximRunCond expanded to false Cc: FreeBSD CURRENT , Dimitry Andric , David Xu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 08:12:44 -0000 21.02.2014 20:03, O. Hartmann пишет: > On Fri, 21 Feb 2014 19:00:13 +0100 > "O. Hartmann" wrote: > >> On Fri, 21 Feb 2014 18:49:13 +0100 >> Dimitry Andric wrote: >> >>> On 21 Feb 2014, at 18:40, O. Hartmann >>> wrote: >>>> On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET >>>> 2014 amd64 I run neither claws-mail nor firfox run after the last >>>> buildworld. They fail both with the error >>>> >>>> Invalid alignment >>>> >>>> Does anyone see this problem too? I tried to recompile claws-mail >>>> and firefox, but without success (compilation succeeded, but the >>>> error stays). >>>> >>>> What happened here? How to solve? >>> Can you try reverting r262277, rebuilding libexec/rtld-elf and >>> reinstalling it, and seeing if that fixes it? >>> >>> -Dimitry >>> >> Hello Dimitry, >> >> in r262277 there is no change in libexec/rtld-elf, I had to go back to >> r262270. I did as requested and reinstalling libexec/rtld-elf fixes >> the reported issue. >> >> Regards, >> Oliver > Sorry, it is r262276 > I have the same issue with firefox and thunderbird. Reverting libexec/rtld-elf to r262276 solves a problem. From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 09:03:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9245C1D3 for ; Sat, 22 Feb 2014 09:03:25 +0000 (UTC) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48DA811FD for ; Sat, 22 Feb 2014 09:03:25 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id la4so4103328vcb.7 for ; Sat, 22 Feb 2014 01:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3n71cBEXqEKQbXa3wc38ehmUI6Yg2n2txwQehijBZ38=; b=N6smeEHVsm0jMd4lm5j6h4hF0FSpuZHjL67THEbmVHJ01VWaHdmcg7EzpT0N3XR6ma 4hdqXNHbXyRgz/Tdgwh4HJqBdBmHogEkU78IzENGTsI7Y7lMoCUzxtfnUXXthHs5Hml6 hQA+bG96jnNfQ3DYaWK+gsfqKS2vXYW/VkDS+H2CK/NNIR2yO3OizPzbOA3ECMNVpKiS uDqbHav5467bTvVhesHVmN4kfXeTYrwfjm+8ZdaO2YbwvimBBHK8QKTlhlrW0LvNDVA2 10klUEddT+sMoE7+4qmEeSWI+d8SMRnG3FMKjy9A3/o33moRLWs2E8mHOjGtJ+QIWamq d19g== MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr7442757vcf.56.1393059804350; Sat, 22 Feb 2014 01:03:24 -0800 (PST) Received: by 10.58.160.33 with HTTP; Sat, 22 Feb 2014 01:03:24 -0800 (PST) In-Reply-To: <53085BF2.8040703@shurik.kiev.ua> References: <20140221184033.7759978f@munin.walstatt.dyndns.org> <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> <20140221190013.475b0654@munin.walstatt.dyndns.org> <20140221190330.709105d8@munin.walstatt.dyndns.org> <53085BF2.8040703@shurik.kiev.ua> Date: Sat, 22 Feb 2014 10:03:24 +0100 Message-ID: Subject: Re: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" From: "Ranjan1018 ." <214748mv@gmail.com> To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 09:03:25 -0000 The problem is still present in r262325. Verified with Firefox. 2014-02-22 9:12 GMT+01:00 Alexandr : > 21.02.2014 20:03, O. Hartmann =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Fri, 21 Feb 2014 19:00:13 +0100 > > "O. Hartmann" wrote: > > > >> On Fri, 21 Feb 2014 18:49:13 +0100 > >> Dimitry Andric wrote: > >> > >>> On 21 Feb 2014, at 18:40, O. Hartmann > >>> wrote: > >>>> On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET > >>>> 2014 amd64 I run neither claws-mail nor firfox run after the last > >>>> buildworld. They fail both with the error > >>>> > >>>> Invalid alignment > >>>> > >>>> Does anyone see this problem too? I tried to recompile claws-mail > >>>> and firefox, but without success (compilation succeeded, but the > >>>> error stays). > >>>> > >>>> What happened here? How to solve? > >>> Can you try reverting r262277, rebuilding libexec/rtld-elf and > >>> reinstalling it, and seeing if that fixes it? > >>> > >>> -Dimitry > >>> > >> Hello Dimitry, > >> > >> in r262277 there is no change in libexec/rtld-elf, I had to go back to > >> r262270. I did as requested and reinstalling libexec/rtld-elf fixes > >> the reported issue. > >> > >> Regards, > >> Oliver > > Sorry, it is r262276 > > > > I have the same issue with firefox and thunderbird. Reverting > libexec/rtld-elf to r262276 solves a problem. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 13:18:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77D38F4C for ; Sat, 22 Feb 2014 13:18:52 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4677D16A6 for ; Sat, 22 Feb 2014 13:18:52 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id s1MDIl3W040782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 22 Feb 2014 05:18:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <5308A3B1.8040005@freebsd.org> Date: Sat, 22 Feb 2014 21:18:41 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: BSD XXI Manifesto [agree] [intersting] References: <20140218072821.GF34282@FreeBSD.org> <5308099F.4090706@freebsd.org> <53082EC5.3060709@allanjude.com> 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.17 Precedence: 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, 22 Feb 2014 13:18:52 -0000 On 2/22/14, 2:54 PM, Adrian Chadd wrote: > On 21 February 2014 20:59, Allan Jude wrote: > >> I can see the remote controlled installer being especially useful for >> 'appliance' type devices, like FreeNAS, pfSense, FUDO, etc. >> >> How would your phone find the address of the machine once it boots off >> the USB, so you could access the web server? > "what apple does." I redeemed an itunes card to day.. and all I had to do was hold it up to the camera and it read the numbers off the card.. nice.. > > > -a > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 14:44:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CC43BA5 for ; Sat, 22 Feb 2014 14:44:22 +0000 (UTC) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 479971D18 for ; Sat, 22 Feb 2014 14:44:21 +0000 (UTC) Received: from p5b159215.dip0.t-ipconnect.de ([91.21.146.21] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1WHDoL-0007tV-8F; Sat, 22 Feb 2014 15:44:13 +0100 Message-ID: <5308B7B7.2020402@gwdg.de> Date: Sat, 22 Feb 2014 15:44:07 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Ranjan1018 ." <214748mv@gmail.com>, FreeBSD CURRENT Subject: Re: [CURRENT]: claws-mail and firefox fail with "Invalid alignment" References: <20140221184033.7759978f@munin.walstatt.dyndns.org> <016792A4-1420-40B2-8B03-B91D490CE6BF@FreeBSD.org> <20140221190013.475b0654@munin.walstatt.dyndns.org> <20140221190330.709105d8@munin.walstatt.dyndns.org> <53085BF2.8040703@shurik.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 14:44:22 -0000 Am 22.02.2014 10:03, schrieb Ranjan1018 .: > The problem is still present in r262325. Verified with Firefox. Just for the record. With r262334 the problem seems to be solved, Firefox, Thunderbird etc. work again :-) Thanks to davidxu@ for the quick fix. Greetings, Rainer Hurling > 2014-02-22 9:12 GMT+01:00 Alexandr : > >> 21.02.2014 20:03, O. Hartmann пишет: >>> On Fri, 21 Feb 2014 19:00:13 +0100 >>> "O. Hartmann" wrote: >>> >>>> On Fri, 21 Feb 2014 18:49:13 +0100 >>>> Dimitry Andric wrote: >>>> >>>>> On 21 Feb 2014, at 18:40, O. Hartmann >>>>> wrote: >>>>>> On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET >>>>>> 2014 amd64 I run neither claws-mail nor firfox run after the last >>>>>> buildworld. They fail both with the error >>>>>> >>>>>> Invalid alignment >>>>>> >>>>>> Does anyone see this problem too? I tried to recompile claws-mail >>>>>> and firefox, but without success (compilation succeeded, but the >>>>>> error stays). >>>>>> >>>>>> What happened here? How to solve? >>>>> Can you try reverting r262277, rebuilding libexec/rtld-elf and >>>>> reinstalling it, and seeing if that fixes it? >>>>> >>>>> -Dimitry >>>>> >>>> Hello Dimitry, >>>> >>>> in r262277 there is no change in libexec/rtld-elf, I had to go back to >>>> r262270. I did as requested and reinstalling libexec/rtld-elf fixes >>>> the reported issue. >>>> >>>> Regards, >>>> Oliver >>> Sorry, it is r262276 >>> >> >> I have the same issue with firefox and thunderbird. Reverting >> libexec/rtld-elf to r262276 solves a problem. >> _______________________________________________ >> 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" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 18:17:38 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EFDB6B6; Sat, 22 Feb 2014 18:17:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A4161F9D; Sat, 22 Feb 2014 18:17:37 +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 s1MIHV3C046006; Sat, 22 Feb 2014 13:17:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s1MIHVlJ046005; Sat, 22 Feb 2014 18:17:31 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 22 Feb 2014 18:17:31 GMT Message-Id: <201402221817.s1MIHVlJ046005@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.17 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 18:17:38 -0000 TB --- 2014-02-22 15:59:09 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-22 15:59:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-02-22 15:59:09 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-02-22 15:59:09 - cleaning the object tree TB --- 2014-02-22 15:59:09 - /usr/local/bin/svn stat /src TB --- 2014-02-22 15:59:12 - At svn revision 262334 TB --- 2014-02-22 15:59:13 - building world TB --- 2014-02-22 15:59:13 - CROSS_BUILD_TESTING=YES TB --- 2014-02-22 15:59:13 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-22 15:59:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-22 15:59:13 - SRCCONF=/dev/null TB --- 2014-02-22 15:59:13 - TARGET=powerpc TB --- 2014-02-22 15:59:13 - TARGET_ARCH=powerpc TB --- 2014-02-22 15:59:13 - TZ=UTC TB --- 2014-02-22 15:59:13 - __MAKE_CONF=/dev/null TB --- 2014-02-22 15:59:13 - cd /src TB --- 2014-02-22 15:59:13 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Feb 22 15:59:20 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/bin/sh/error.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/bin/sh/eval.c cc -O2 -pipe -DSHELL -I. -I/src/bin/sh -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/bin/sh/exec.c /src/bin/sh/exec.c: In function 'typecmd_impl': /src/bin/sh/exec.c:650: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[5]: stopped in /src/bin/sh *** Error code 1 Stop. bmake[4]: stopped in /obj/powerpc.powerpc/src/rescue/rescue *** Error code 1 Stop. bmake[3]: stopped in /src/rescue/rescue *** Error code 1 Stop. bmake[2]: stopped in /src/rescue *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-22 18:17:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-22 18:17:31 - ERROR: failed to build world TB --- 2014-02-22 18:17:31 - 7117.95 user 969.44 system 8301.83 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 19:54:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AA65C59; Sat, 22 Feb 2014 19:54:17 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 696DD17A2; Sat, 22 Feb 2014 19:54:16 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id e16so3749095lan.40 for ; Sat, 22 Feb 2014 11:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=K5w1uxqc2rBnU816RjYJCKcwu50zKwwdrhdQr1+EHG8=; b=Mc7VfshMk0N0907BOjedgGO0hJGTg2ZiHmCI3D2GgXzfqAseNECpE7XSkAm9ndDz5d 6+SC3lXf+n2YBCixj7Pqgns4x5bZZFq3FaCxZxrO+mK/1wBhX6Zia11m1TEhdVDYxPit F+j4mXtx+jjYYub05LKr7EJZT0Zx9dj1QpAe9H93oiY3b2ovDg04DD+YtT6uJeWyEwo0 O00VDI3h7sDhDKyarj76GVMUEIhJ55Ovv5pt71mI3J1zCgDl+c7RgNM2eIYCzgS1PZeE TgqPmX4+9skjiN9VAAi2HxI/BirPAN3QJOaasaAIeat/FGA/e7pGom4keNOwSNFp3mm0 8a0A== MIME-Version: 1.0 X-Received: by 10.112.166.68 with SMTP id ze4mr7235978lbb.58.1393098853802; Sat, 22 Feb 2014 11:54:13 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.30.211 with HTTP; Sat, 22 Feb 2014 11:54:13 -0800 (PST) Date: Sat, 22 Feb 2014 11:54:13 -0800 X-Google-Sender-Auth: NKxHNY6uR4IfY_nwxBHCgVCzpJo Message-ID: Subject: [HEADSUP] Jenkins running in FreeBSD cluster From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-testing@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 19:54:17 -0000 Hi, I just wanted to let the FreeBSD community know that with the help of some FreeBSD hackers, we have set up an initial Jenkins Continuous Integration server in the FreeBSD cluster. We are the jenkins-admin team and you can contact us at jenkins-admin@freebsd.org. We have a few initial builds going and you can see things here: https://jenkins.freebsd.org We are still working on a few problems, and have some ambitious plans moving forward, which you can read about on our status page: http://wiki.freebsd.org/Jenkins Lastly, if you are able to attend the FreeBSD DevSummit in Ottawa later this year, we will have a working group discussion on Jenkins and Continuous Integration testing for FreeBSD on May 15, 2014: https://wiki.freebsd.org/201405DevSummit/Jenkins We'd love to get more FreeBSD hackers involved to get this going and improve continuous integration and testing on FreeBSD. We would like to use the freebsd-testing@freebsd.org mailing list for followup discussions. I'd like to thank my fellow members of the jenkins-admin team for helping to get things going: Steve Kreuzer Li-Wen Hsu Steve Wills R. Tyler Croy If we can integrate more automated testing of FreeBSD with this, that would be really great! -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Feb 22 23:56:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 972D8A1 for ; Sat, 22 Feb 2014 23:56:03 +0000 (UTC) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by mx1.freebsd.org (Postfix) with ESMTP id 63ADE19C7 for ; Sat, 22 Feb 2014 23:56:02 +0000 (UTC) Received: from BLU179-W28 ([65.55.111.71]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Feb 2014 15:54:56 -0800 X-TMN: [FVuno0oHUShAeLA/q8VquxO/4xSNRDVY] X-Originating-Email: [brunolauze@msn.com] Message-ID: From: =?iso-8859-1?B?QnJ1bm8gTGF1euk=?= To: "freebsd-current@freebsd.org" Subject: libinit idea Date: Sat, 22 Feb 2014 18:54:56 -0500 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2014 23:54:56.0468 (UTC) FILETIME=[7CEC3140:01CF3029] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Feb 2014 23:56:03 -0000 https://github.com/brunolauze/libnit=0A= =0A= I know there's really big debate about init system but here's my tentative = to propose a new model to replace rc.=0A= =0A= Let's call it libinit but the name as no significance for now.=0A= =0A= I started coding a library with the following architecture.=0A= =0A= the main idea is to rewrite rc in C language.=0A= =0A= a utility called system would act a little bit like service command does.= =0A= =0A= a folder would contains libraries instead of scripts inside [target]/etc/rc= .d=0A= so we can add as many librairies a user desire and interlink the order of e= ach piece among all like in rc.=0A= =0A= each library would follow and expose the following pattern:=0A= =0A= char **provide()=3B /* returns all the PROVIDE a library contains */=0A= =0A= then for each provide() value the library would expose :=0A= =0A= XXX_provide()=0A= XXX_require()=0A= XXX_before()=0A= XXX_keywords()=0A= =0A= and optionally:=0A= XXX_canstart()=3B=0A= XXX_prestart()=3B=0A= XXX_start()=3B=0A= XXX_status()=3B=0A= XXX_stop()=3B=0A= =0A= and also:=0A= =0A= XXX_mycommand(int argc=2C char **argv)=3B=0A= =0A= essentially repeating the rc.subr =A0model=0A= =0A= system utilty would source /etc/defaults/rc.conf=2C then source result of r= c_conf_files loaded=0A= =0A= On init=2C /sbin/init would call /sbin/system init instead of running scrip= t /etc/rc=0A= =0A= on init=2C system would scan folder (let's suppose /lib/init.d and /usr/loc= al/init.d for now)=0A= try dlopen() each *.so* files=0A= and grab provide()=3B xxx_provide()=2C xxx_require()=2C xxx_before() and xx= x_keyword() for each one.=0A= compile a list of "service" discovered and do an "rcorder".=0A= =0A= The benefits is to avoid firing so many utility to manage to init the syste= m.=0A= =0A= Replicating all small helper function from rc to C language like load_kld w= ould avoid opening a process and do real syscall at moment.=0A= Heavily use pthread=2C waitpid=2C etc...=0A= =0A= So instead of firing /sbin/devfs /dev rule -s 1 applyset=A0=0A= call direcly what's would run inside devfs -> rule_main in src/sbin/devfs/r= ule.c ...=0A= cut the fat=0A= =0A= here's an example to show /etc/rc.d/abi conversion to abi.c=0A= =0A= abi.h:=0A= #ifndef __ABI_H__=0A= #define __ABI_H__=0A= #include "../default.h"=0A= =0A= #define PROVIDE =A0 =A0 =A0 =A0 abi=0A= #define REQUIRE =A0 =A0 =A0 =A0 { "archdep" }=0A= #define KEYWORD =A0 =A0 =A0 =A0 { NOJAIL }=0A= =0A= #include "../common.h"=0A= =0A= #endif=0A= =0A= =0A= abi.c:=0A= #include "abi.h"=0A= =0A= int sysvipc_start()=0A= {=0A= =A0 =A0 =A0 =A0 if (load_kld("sysvmsg"))=0A= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (load_kld("sysvsem"))=0A= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return load_kld("sysvshm")= =3B=0A= =A0 =A0 =A0 =A0 return -1=3B=0A= }=0A= =0A= int linux_start()=0A= {=0A= =A0 =A0 =A0 =A0 return load_kld("linux")=3B=0A= }=0A= =0A= int srv4_start()=0A= {=0A= =A0 =A0 =A0 =A0 if (load_kld("svr4elf") =3D=3D 0)=0A= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return load_kld("svr4")=3B=0A= =A0 =A0 =A0 =A0 return (-1)=3B=0A= }=0A= =0A= #define __canstart=0A= int abi_canstart()=0A= {=0A= =A0 =A0 =A0 =A0 return is_enabled("sysvipc") || is_enabled("linux") || is_e= nabled("srv4")=3B=0A= }=0A= =0A= int abi_start()=0A= {=0A= =A0 =A0 =A0 =A0 int err1 =3D 0=2C err2 =3D 0=2C err3 =3D 0=3B=0A= =A0 =A0 =A0 =A0 if (is_enabled("sysvipc")) err1 =3D sysvipc_start()=3B=0A= =A0 =A0 =A0 =A0 if (is_enabled("linux")) err2 =3D linux_start()=3B=0A= =A0 =A0 =A0 =A0 if (is_enabled("srv4")) err3 =3D srv4_start()=3B=0A= =A0 =A0 =A0 =A0 return err1 && err2 && err3=3B=0A= }=0A= =0A= #include "../common.c"=0A= =0A= =0A= where common.h and common.c implement everything by default a little bit li= ke rc.subr does.=0A= e.g: PID_FILE and COMMAND macros implement the start by itself=2C etc...=0A= =0A= =0A= as you can see really similar to what we have in the script file...=0A= =0A= Then the system utility would also allow digging into the libraries with co= mmand like:=0A= system accounting rotatelog=0A= etc..=0A= =0A= I uploaded a quick start to show some code and expose more the idea.=0A= =0A= https://github.com/brunolauze/libinit=0A= =0A= =0A= =0A= Thanks in advance for your comments. =