From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 03:14:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82651106566B for ; Sun, 8 Jul 2012 03:14:22 +0000 (UTC) (envelope-from steve@mouf.net) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 21C8A8FC14 for ; Sun, 8 Jul 2012 03:14:22 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.5/8.14.5) with ESMTP id q683EKp0066952 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 7 Jul 2012 23:14:21 -0400 (EDT) (envelope-from steve@mouf.net) Message-ID: <4FF8FB0C.4050706@mouf.net> Date: Sat, 07 Jul 2012 23:14:20 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> <4FF62A6C.7090408@FreeBSD.org> In-Reply-To: <4FF62A6C.7090408@FreeBSD.org> X-Enigmail-Version: 1.4.2 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 (mouf.net [204.109.58.86]); Sat, 07 Jul 2012 23:14:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.5 at mouf.net X-Virus-Status: Clean Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 03:14:22 -0000 Following up to myself, with some things I should have mentioned before: On 07/05/12 19:59, Steve Wills wrote: > On 07/05/12 03:00, Alan Cox wrote: >> On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills wrote: >> >>> Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set >>> it to 1 for some reason that I can't recall. >>> >>> >> That shouldn't cause a crash in pmap_enter(). What is line 3587 of pmap.c >> in your sources? > > 3587 if ((newpte & PG_RW) == 0) > >> You mentioned DRM. Are you using the new Intel graphics >> driver? >> > > No, I'm using ATI Radeon. > For what it's worth, I discovered that twm and xterm don't trigger the issue, but konsole and other kde things do, which is what led me to discover that setting kern.ipc.shm_use_phys back to default fixed it. This wasn't the case before, I think the last time I updated was about a month ago, May 6. Also, I have these other shared memory related settings in sysctl.conf: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 kern.ipc.shm_allow_removed=1 I'm wondering if this is an indication that I have/had some bad settings and they finally bit me, or if this is an indication of a bug. Thanks, Steve From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 03:45:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A31EC1065672; Sun, 8 Jul 2012 03:45:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 093218FC08; Sun, 8 Jul 2012 03:45:01 +0000 (UTC) Received: by werp13 with SMTP id p13so6946195wer.13 for ; Sat, 07 Jul 2012 20:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U+D6VfMM2kQNK9uaMHYA2P8UIhIpkPwnsCLznRT92Mo=; b=HebBeh8J8mi/23+/4aEtilloe6UXx9mJkGKZi2OHiur6X5kOhr952vQaPD6iDrN8ul M1waa7YGNOJ8P21PPBuLQKwlThaWi7vUars37SZgsjDWo5Wd5lMBH/p0fal+PVp+4Who hJzbT57757W8vebE1GAYiS+a40mY4Cj2SQupj/payopyEWK0s/O98Tq89Al39suUDxnj n5xFW5PdZiRppDixTlODv01o0/N1xbJSM2PR+tAEanrvfLNB596uxrgRqfrkNZJ4dm09 wIvd60brxMJ9Xxm2CoWyIV5qVafnLXtOhLPzwhVUJFx+tp5fARDrX60Wzs7fJb+SaF7r z8xw== MIME-Version: 1.0 Received: by 10.181.13.142 with SMTP id ey14mr19229386wid.19.1341719100905; Sat, 07 Jul 2012 20:45:00 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sat, 7 Jul 2012 20:45:00 -0700 (PDT) In-Reply-To: <1341686865.70246.22.camel@revolution.hippie.lan> References: <1341601751.70246.7.camel@revolution.hippie.lan> <1341686865.70246.22.camel@revolution.hippie.lan> Date: Sat, 7 Jul 2012 23:45:00 -0400 Message-ID: From: Arnaud Lacombe To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 03:45:02 -0000 Hi, On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore wrote: > On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore >> wrote: >> > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: >> >> > That's neither correct nor robust in a couple of way: >> >> > 1) you have no guarantee a device unit will always give you the same resource. >> >> this raises the following question: how can a device, today, figure >> >> out which parent in a given devclass would give it access to resources >> >> it needs. >> >> >> >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by >> >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >> >> attachment is conditional to some BIOS setting. How can you tell >> >> gpioled(4) to attach on the chipset provided GPIO without hardcoding >> >> unit number either way ? >> >> >> >> AFAIK, you can not. >> >> >> >> Even hints provided layout description is defeated. Each device in a >> >> given devclass need to have a set of unique attribute to allow a child >> >> to distinguish it from other potential parent in the same devclass... >> >> >> >> - Arnaud >> > >> > Talking about a child being unable to choose the correct parent seems to >> > indicate that this whole problem is turned upside-down somehow; children >> > don't choose their parents. >> > >> actually, I think I was wrong, I thought device were attached to a >> devclass, but they are truly attached to a given device. My mistake. >> >> > Just blue-sky dreaming here on the fly... what we really have is a >> > resource-management problem. A device comes along that needs a GPIO >> > resource, how does it find and use that resource? >> > >> > Well, we have a resource manager, could that help somehow? Could a >> > driver that provides access to GPIO somehow register its availability so >> > that another driver can find and access it? The "resource" may be a >> > callable interface, it doesn't really matter, I'm just wondering if the >> > current rman stuff could be leveraged to help make the connection >> > between unrelated devices. I think that implies that there would have >> > to be something near the root of the hiearchy willing to be the >> > owner/manager of dynamic resources. >> > >> AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. >> The more I think about it, the more FTD is the answer. The open >> question now being "how to map a flexible device structure (FTD) to a >> less flexible structure (Newbus)" :/ >> >> - Arnaud > > Memory- and IO-mapped regions and IRQs are the only current uses of rman > (that I know of), but it was designed to be fairly agnostic about the > resources it manages. It just works with ranges of values (that it > really doesn't know how to interpret at all), leaving lots of room to > define new types of things it can manage. > > The downside is that it's designed to be used hierarchically in the > context of newbus, specifically to help parents manage the resources > that they are able to provide to their children. Trying to use it in a > way that allows devices which are hierarchically unrelated to allocate > resources from each other may amount to a square-peg/round-hole > situation. But the alternative is writing a new facility to allow > registration and allocation of resources using some sort symbolic method > of representing the resources such that the new manager doesn't have to > know much about what it's managing. I think it would be better to find > a way to reuse what we've already got if that's possible. > > I think we have two semi-related aspects to this problem... > > How do we symbolically represent the resources that drivers can provide > to each other? (FDT may be the answer; I don't know much about it.) > > How do devices use that symbolic representation to locate the provider > of the resource, and how is the sharing of those resources managed? > I'd say FDT answer both question, take the DTS for "Freescale i.MX53 Smart Mobile Reference Design Board"[0], We first have SoC generic definition in `imx53.dtsi': soc { compatible = "simple-bus"; aips@50000000 { /* AIPS1 */ compatible = "fsl,aips-bus", "simple-bus"; spba@50000000 { compatible = "fsl,spba-bus", "simple-bus"; esdhc@50004000 { /* ESDHC1 */ compatible = "fsl,imx53-esdhc"; reg = <0x50004000 0x4000>; interrupts = <1>; status = "disabled"; }; [...] gpio2: gpio@53f8c000 { /* GPIO3 */ compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; reg = <0x53f8c000 0x4000>; }; gpio3: gpio@53f90000 { /* GPIO4 */ compatible = "fsl,imx53-gpio", "fsl,imx31-gpio"; reg = <0x53f90000 0x4000>; }; [...] } then board specific definition overriding its parent's in `imx53-smd.dts': soc { aips@50000000 { /* AIPS1 */ spba@50000000 { esdhc@50004000 { /* ESDHC1 */ cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */ wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */ status = "okay"; }; [...] } Now the challenge is to make this to work within newbus. One of the problem I see is mixing FTD enumerated and bus (PCI, PnP ISA, ACPI, USB, ...) enumerated devices, in my specific case, a device using GPIO from a SuperIO and the chipset on the PCI bus. I would have to describe the SuperIO *and* the chipset GPIO in the FDT to be able to refer to them in my device... - Arnaud [0]: see Linux' arch/arm/boot/dts/imx53* > -- Ian > > From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 05:05:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0F4E106564A for ; Sun, 8 Jul 2012 05:05:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 83E468FC0C for ; Sun, 8 Jul 2012 05:05:06 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so18403193pbb.13 for ; Sat, 07 Jul 2012 22:05:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TW9rTklz1TjMt39Mu+Qv/XscBwApKQZokjtafvl8Tzc=; b=UM+rmlcli0B/dRg9REWk3I5Kq6VPiqiXhdmi91RuMRYyTUdkShD04siuT7r/oTMGDo p8hjdfRQlxcYTlawNvutQa5ON7Ia8mCbfiSlNn5WQiN34EJgv0tlgiCuIRs2oAPloTy7 RDWeyMliR7u3K2YT8La1wMCqbXMduJa8ie7XL71Xx5gUgm8VJUtZbWm+zWvSiFWf7AnE /lq/P+o+F30dOzxmh31byqMjT5p4TqJb4+s+q5yhEk6QDJcEYtI/4LRZBNMO6tLrFs21 GvIwYz7DKVdF9U629Wj2xkDnjPeFeO5QP3IGdD2Phm+/aAbbz3Z8yJCaHfCXsg4Kgl3v NfaQ== Received: by 10.66.84.71 with SMTP id w7mr56525402pay.33.1341723900265; Sat, 07 Jul 2012 22:05:00 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id tj8sm25088132pbc.10.2012.07.07.22.04.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 22:04:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 7 Jul 2012 23:04:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1341601751.70246.7.camel@revolution.hippie.lan> <1341686865.70246.22.camel@revolution.hippie.lan> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkjwR9Y0guH7/G3wd3Fjyz95gaGOzafvzdkXWOlnbscwDdKaoy33MV7prTW2NIhq1nUWFh9 Cc: Ian Lepore , FreeBSD Current , FreeBSD Hackers Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 05:05:06 -0000 On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore > wrote: >> On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: >>> Hi, >>>=20 >>> On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore >>> wrote: >>>> On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: >>>>> Hi, >>>>>=20 >>>>> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe = wrote: >>>>>> That's neither correct nor robust in a couple of way: >>>>>> 1) you have no guarantee a device unit will always give you the = same resource. >>>>> this raises the following question: how can a device, today, = figure >>>>> out which parent in a given devclass would give it access to = resources >>>>> it needs. >>>>>=20 >>>>> Say, you have gpiobus0 provided by a superio and gpiobus1 provided = by >>>>> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 >>>>> attachment is conditional to some BIOS setting. How can you tell >>>>> gpioled(4) to attach on the chipset provided GPIO without = hardcoding >>>>> unit number either way ? >>>>>=20 >>>>> AFAIK, you can not. >>>>>=20 >>>>> Even hints provided layout description is defeated. Each device in = a >>>>> given devclass need to have a set of unique attribute to allow a = child >>>>> to distinguish it from other potential parent in the same = devclass... >>>>>=20 >>>>> - Arnaud >>>>=20 >>>> Talking about a child being unable to choose the correct parent = seems to >>>> indicate that this whole problem is turned upside-down somehow; = children >>>> don't choose their parents. >>>>=20 >>> actually, I think I was wrong, I thought device were attached to a >>> devclass, but they are truly attached to a given device. My mistake. >>>=20 >>>> Just blue-sky dreaming here on the fly... what we really have is a >>>> resource-management problem. A device comes along that needs a = GPIO >>>> resource, how does it find and use that resource? >>>>=20 >>>> Well, we have a resource manager, could that help somehow? Could a >>>> driver that provides access to GPIO somehow register its = availability so >>>> that another driver can find and access it? The "resource" may be = a >>>> callable interface, it doesn't really matter, I'm just wondering if = the >>>> current rman stuff could be leveraged to help make the connection >>>> between unrelated devices. I think that implies that there would = have >>>> to be something near the root of the hiearchy willing to be the >>>> owner/manager of dynamic resources. >>>>=20 >>> AFAIR, rman is mostly there to manage memory vs. i/o mapped = resources. >>> The more I think about it, the more FTD is the answer. The open >>> question now being "how to map a flexible device structure (FTD) to = a >>> less flexible structure (Newbus)" :/ >>>=20 >>> - Arnaud >>=20 >> Memory- and IO-mapped regions and IRQs are the only current uses of = rman >> (that I know of), but it was designed to be fairly agnostic about the >> resources it manages. It just works with ranges of values (that it >> really doesn't know how to interpret at all), leaving lots of room to >> define new types of things it can manage. >>=20 >> The downside is that it's designed to be used hierarchically in the >> context of newbus, specifically to help parents manage the resources >> that they are able to provide to their children. Trying to use it in = a >> way that allows devices which are hierarchically unrelated to = allocate >> resources from each other may amount to a square-peg/round-hole >> situation. But the alternative is writing a new facility to allow >> registration and allocation of resources using some sort symbolic = method >> of representing the resources such that the new manager doesn't have = to >> know much about what it's managing. I think it would be better to = find >> a way to reuse what we've already got if that's possible. >>=20 >> I think we have two semi-related aspects to this problem... >>=20 >> How do we symbolically represent the resources that drivers can = provide >> to each other? (FDT may be the answer; I don't know much about it.) >>=20 >> How do devices use that symbolic representation to locate the = provider >> of the resource, and how is the sharing of those resources managed? >>=20 > I'd say FDT answer both question, take the DTS for "Freescale i.MX53 > Smart Mobile Reference Design Board"[0], >=20 > We first have SoC generic definition in `imx53.dtsi': >=20 > soc { > compatible =3D "simple-bus"; > aips@50000000 { /* AIPS1 */ > compatible =3D "fsl,aips-bus", "simple-bus"; >=20 > spba@50000000 { > compatible =3D "fsl,spba-bus", "simple-bus"; >=20 > esdhc@50004000 { /* ESDHC1 */ > compatible =3D "fsl,imx53-esdhc"; > reg =3D <0x50004000 0x4000>; > interrupts =3D <1>; > status =3D "disabled"; > }; >=20 > [...] >=20 > gpio2: gpio@53f8c000 { /* GPIO3 */ > compatible =3D "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg =3D <0x53f8c000 0x4000>; > }; >=20 > gpio3: gpio@53f90000 { /* GPIO4 */ > compatible =3D "fsl,imx53-gpio", "fsl,imx31-gpio"; > reg =3D <0x53f90000 0x4000>; > }; >=20 > [...] > } >=20 > then board specific definition overriding its parent's in = `imx53-smd.dts': >=20 > soc { > aips@50000000 { /* AIPS1 */ > spba@50000000 { > esdhc@50004000 { /* ESDHC1 */ > cd-gpios =3D <&gpio2 13 0>; /* GPIO3_13 */ > wp-gpios =3D <&gpio3 11 0>; /* GPIO4_11 */ > status =3D "okay"; > }; >=20 > [...] > } >=20 > Now the challenge is to make this to work within newbus. >=20 > One of the problem I see is mixing FTD enumerated and bus (PCI, PnP > ISA, ACPI, USB, ...) enumerated devices, in my specific case, a device > using GPIO from a SuperIO and the chipset on the PCI bus. I would have > to describe the SuperIO *and* the chipset GPIO in the FDT to be able > to refer to them in my device... I'm starting to think that newbus device names aren't a good fit here. = gpio2 isn't a newbus name, but an fdt one. I think that you'll the gpio = driver providing GPIO services that can map these pins to actions. = Trying to do it all within newbus likely is a mistake. At the very = least you'll want to make the providers have an earlier pass number than = the devices that are provided for. The GPIO driver should provide a = GPIO service or resource that other devices can access and use. This = would make it non unloadable (or effectively so), must like the PCI bus = is effectively non-unloadable since too many things will depend on this = device.... I face similar challenges in my work to refactor the Atmel GPIO stuff. Warner > - Arnaud >=20 > [0]: see Linux' arch/arm/boot/dts/imx53* >=20 >> -- Ian >>=20 >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 07:57:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAC1D106566B; Sun, 8 Jul 2012 07:57:25 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 87F4E8FC12; Sun, 8 Jul 2012 07:57:25 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so18562532pbb.13 for ; Sun, 08 Jul 2012 00:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Lg5M8da9xZ5KX4uj8T3QiT7t0aitIuf6OSIXLYacx4k=; b=I0O7OV8gLtIkjILuRa4d+m+XY4kJftYXPrkRPRlYODkaSWgydLxGdrSzbJpVW7Shaa Tjj6nXS2JRQT9b4NRXZMcTfinKKNo+eCSQbwiC5i3gdg1OgMVfzX2NvAwv15f7cFejNz 5xj8q7vH5SNdgat/B23mmM6s30Kg+K6mk14e8fuawFE46hWTngOQ8ynlHg8VTpcYr8vN Z8pEDvcERFAT7PH/DdFHD6Bcw+1GeaT9ZmtnVq/ll3V9Cn/YQYrSdlU43c/YWi++r5w1 m05K4iHtL6z2vwJ/pYT2uNeoYEY5FAlryraGhTUKLZzMOH6OdRBw9I1r+uzI1BgYEqtk pCfg== MIME-Version: 1.0 Received: by 10.68.209.197 with SMTP id mo5mr50207879pbc.72.1341734245130; Sun, 08 Jul 2012 00:57:25 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.68.224.226 with HTTP; Sun, 8 Jul 2012 00:57:25 -0700 (PDT) Date: Sun, 8 Jul 2012 03:57:25 -0400 X-Google-Sender-Auth: 2H0wXgBpOKBXyKr8DD_h40jImTU Message-ID: From: Justin Hibbits To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD PowerPC ML Subject: Kernel panic -- Memory modified after free X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 07:57:25 -0000 I upgraded my kernel yesterday, after testing alc@'s patch for mmu_oea (PowerPC 32-bit, AIM), and now I'm seeing the kernel panic in the subject. Unfortunately, I didn't keep my knonw-good working kernel from prior to testing alc@'s patch, so the most recent kernel I have that works is from over a year ago, so booting to it means I get no networking, as the ABI has changed. With this, every time it panics, it shows "Most recently used by 'bus'". Has anyone else seen this kind panic from recent kernels? For further testing, I tried downloading the kernel tarball from allbsd.org, from the 20120601 snapshot, and that also shows the same panic. Also, this only occurs on my G4 tower, which is a dual processor machine. The exact same kernels work fine on my PowerBook, which is single processor. - Justin From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 08:26:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E06CB106564A for ; Sun, 8 Jul 2012 08:26:26 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (ns25270.ovh.net [91.121.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id A15D18FC08 for ; Sun, 8 Jul 2012 08:26:26 +0000 (UTC) Received: from bob75-9-88-181-0-131.fbx.proxad.net ([88.181.0.131] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Snmfc-000NE3-Bw for freebsd-current@freebsd.org; Sun, 08 Jul 2012 10:16:44 +0200 Message-ID: <4FF941EC.9050900@FreeBSD.org> Date: Sun, 08 Jul 2012 10:16:44 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120623 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> <4FF62A6C.7090408@FreeBSD.org> <4FF8FB0C.4050706@mouf.net> In-Reply-To: <4FF8FB0C.4050706@mouf.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 08:26:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.07.2012 05:14, Steve Wills wrote: > For what it's worth, I discovered that twm and xterm don't trigger > the issue, but konsole and other kde things do, which is what led > me to discover that setting kern.ipc.shm_use_phys back to default > fixed it. I encountered the same issue with x11-wm/awesome, but everything's ok with twm. A kernel from 2012-06-23 doesn't crash but a kernel from 2012-07-03 does crash. Here're the sysctls/tunables I have regarding shm: In /boot/loader.conf: kern.ipc.shmmni="1024" kern.ipc.shmseg="1024" In /etc/sysctl.conf: kern.ipc.shmmax=2147483648 kern.ipc.shm_use_phys=1 kern.ipc.shm_allow_removed=1 - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5QesACgkQa+xGJsFYOlPRwQCcClck3824nWltHoIVzuzmLBLz dyUAoIhVeREUZH26QdcJkyyXfna9LYQQ =mKU0 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 10:49:33 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C2F5106566C for ; Sun, 8 Jul 2012 10:49:33 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id B3D918FC08 for ; Sun, 8 Jul 2012 10:49:32 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q68AnUf3051026 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 11:49:31 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FF965BA.90407@unsane.co.uk> Date: Sun, 08 Jul 2012 11:49:30 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rick Macklem References: <528064981.93665.1341703581872.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <528064981.93665.1341703581872.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 10:49:33 -0000 On 08/07/2012 00:26, Rick Macklem wrote: > Vincent Hoffman wrote: >> >> Hi Rick, >> >> I'm afraid this didnt make any real difference for me. >> Since I couldnt test it on the live system I tried it on a test vm. >> on the vm (nfs server) I set a looping mount/umount >> while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; >> done >> >> and on the client I set a loop of tars of large directorys to the nfs >> mount running under time to see how well it survived. Then replicated >> the test with the patch and without. >> > Just to confirm, you patched both the kernel and mountd and replaced both > on the server? > > Also, I'm not sure how ZFS handles it's exports. I can't remember if you've > tried an exported UFS volume. It might be something ZFS specific? > > rick Hi Rick, yes I patched both the kernel and mountd, rebuilt kernel and world (to be sure), added the -S flag to mountd in rc.conf and rebooted. This is a test VM running -CURRENT and is only exporting a ufs2 filesystem. (11:43:05 <~>) 0 $ cat /etc/exports /usr/local/export -maproot=root -alldirs XX.XX.XX.XX Client is a 8.3-RELEASE box but I see the same with linux clients. (I can confirm that it works fine when I am not running the mount/umount loop) The production system has been fine since I removed the SIGHUP call in mount.c so thanks for that suggestion. Vince > >> [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt >> x nopatch.txt >> + atomicpatch.txt >> +--------------------------------------------------------------------------------------------------+ >> | >> * >> | >> | >> * >> | >> | >> x* >> | >> | xx* >> x >> | >> | +x** >> xx >> | >> | **** xxx >> x >> | >> | **** xxx +x+ >> + >> | >> | ****+*xx +x+ x >> + >> | >> | ****+*x****++++x + + >> x | >> | *************+*xx+ +++x * x >> x | >> | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + >> + +| >> |||_______M_M_A__A_______|______| >> | >> +--------------------------------------------------------------------------------------------------+ >> N Min Max Median Avg Stddev >> x 101 1.25 106.8 14.08 21.892178 22.196005 >> + 101 1.21 186.93 18.46 27.995842 30.523218 >> No difference proven at 95.0% confidence >> >> >> (excuse wrapped ascii art) >> >> I think I'll have a look at the nfse patch set and see how that >> performs. >> >> Thanks for all your work on NFS on FreeBSD. >> >> Vince >> >>>>> Also, you could easily hack mount.c so that it doesn't send a >>>>> SIGHUP >>>>> to mountd (which causes the exports to be reloaded) every time a >>>>> local >>>>> fs is mounted. >>>> True and I may have to do that for the production NAS for the time >>>> being. >>>> Thanks for looking at this. >>>> >>>> Vince >>>>> rick >>>>> >>>>>>> thanks, Vince >> >> _______________________________________________ >> 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 Jul 8 12:46:42 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C71CE106566B for ; Sun, 8 Jul 2012 12:46:42 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9355A8FC14 for ; Sun, 8 Jul 2012 12:46:42 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 74BF360DF for ; Sun, 8 Jul 2012 08:46:34 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=J2Ow66tS/fWd7Pg7awkwgL+6A6eHd1fS+y6DRtjzl74maAQ/KJCf88QTfPrgp8ZJ1 yptA9uDxPIjlUlH6WG4dmbn0mucJ6tMuNTBT9GjWe0CSlCDZFCYCmNGBPQ/TmWi Message-ID: <4FF98128.6050607@protected-networks.net> Date: Sun, 08 Jul 2012 08:46:32 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 12:46:42 -0000 Sorry, no symbols but this happened twice last night while being the target of a dump over NFS .. root@mail:/var/crash # less info.0 Dump header from device /dev/ada0s1 Architecture: i386 Architecture Version: 2 Dump Length: 252809216B (241 MB) Blocksize: 512 Dumptime: Sun Jul 8 00:21:23 2012 Hostname: mail.auburn.protected-networks.net Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 root@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN Panic String: sleeping thread Dump Parity: 2996346376 Bounds: 0 Dump Status: good (kgdb) bt #0 0xc07530cd in doadump () #1 0xc0753656 in kern_reboot () #2 0xc0753cfc in panic () #3 0xc079a34e in propagate_priority () #4 0xc079b5e4 in turnstile_wait () #5 0xc073ea71 in _mtx_lock_sleep () #6 0xc09c4772 in vm_page_unwire () #7 0xc07db039 in vfs_vmio_release () #8 0xc07dd476 in getnewbuf () #9 0xc07de50b in getblk () #10 0xc0966d99 in ffs_balloc_ufs2 () #11 0xc099281e in ffs_write () #12 0xc0a38b05 in VOP_WRITE_APV () #13 0xc068a65e in nfsvno_write () #14 0xc06882e7 in nfsrvd_write () #15 0xc066ea05 in nfsrvd_dorpc () #16 0xc067d42f in nfssvc_program () #17 0xc09356e2 in svc_run_internal () #18 0xc0935b70 in svc_thread_start () #19 0xc07204fb in fork_exit () #20 0xc09fe7a4 in fork_trampoline () From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 13:10:15 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC5B910656D1 for ; Sun, 8 Jul 2012 13:10:15 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 625B78FC16 for ; Sun, 8 Jul 2012 13:10:13 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q68CemCd044295; Sun, 8 Jul 2012 08:40:48 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q68CelUE044294; Sun, 8 Jul 2012 08:40:47 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 8 Jul 2012 08:40:47 -0400 From: David Schultz To: Peter Jeremy Message-ID: <20120708124047.GA44061@zim.MIT.EDU> Mail-Followup-To: Peter Jeremy , Steve Kargl , freebsd-current@freebsd.org References: <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120529045612.GB4445@server.rulingia.com> Cc: freebsd-current@FreeBSD.ORG, Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 13:10:15 -0000 On Tue, May 29, 2012, Peter Jeremy wrote: > On 2012-May-28 15:54:06 -0700, Steve Kargl wrote: > >Given that cephes was written years before C99 was even > >conceived, I suspect all functions are sub-standard. > > Well, most of cephes was written before C99. The C99 parts of > cephes were written to turn it into a complete C99 implementation. I'm a bit late to the party, but I thought I'd chime in with some context. We did consider using Cephes years ago, and even got permission from the author to release it under an acceptable license. We later decided not to use it for technical reasons. By the way, virtually none of the people who have complained about the missing functions actually need them. Mostly they just want to compile some software that was written by a naive programmer who thought it would be cool to use the most precise type available. The complex functions are even less commonly needed, and the truth is that they have no business being part of the C standard anyway. The question remains of what to do about the missing functions. Bruce and Steve have been working on expl and logl for years. If those ever get in the tree, the remaining long double functions are easy. Those functions are basically done, modulo a bunch of cleanup and testing, and I encourage any mathematically inclined folks who are interested in pushing things along to get in touch with them. I'm not going to have any time myself for a few months at least. Lastly, there's the question of mediocre alternatives, such as solutions that get the boundary cases wrong or don't handle 128-bit floating point. For the exponential and logarithmic functions, Bruce and Steve have already written good implementations, so there's no reason to settle for less. As for the other long double functions, bringing in some Cephes code in a separate directory as a temporary fix might be the way to go. I don't like that solution, and Steve raises some good technical points about why it isn't ideal; however, a better solution is more than a decade overdue, and people are justified in finding that unacceptable. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 13:16:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D88106566C; Sun, 8 Jul 2012 13:16:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E5FC68FC16; Sun, 8 Jul 2012 13:16:03 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q68D78a8045636; Sun, 8 Jul 2012 16:07:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q68D6ot5045116; Sun, 8 Jul 2012 16:06:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q68D6oqI045115; Sun, 8 Jul 2012 16:06:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2012 16:06:50 +0300 From: Konstantin Belousov To: Jean-S?bastien P?dron Message-ID: <20120708130650.GV2338@deviant.kiev.zoral.com.ua> References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> <4FF62A6C.7090408@FreeBSD.org> <4FF8FB0C.4050706@mouf.net> <4FF941EC.9050900@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QILrdhYozogw5Vly" Content-Disposition: inline In-Reply-To: <4FF941EC.9050900@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 13:16:05 -0000 --QILrdhYozogw5Vly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2012 at 10:16:44AM +0200, Jean-S?bastien P?dron wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 08.07.2012 05:14, Steve Wills wrote: > > For what it's worth, I discovered that twm and xterm don't trigger > > the issue, but konsole and other kde things do, which is what led > > me to discover that setting kern.ipc.shm_use_phys back to default > > fixed it. >=20 > I encountered the same issue with x11-wm/awesome, but everything's ok > with twm. A kernel from 2012-06-23 doesn't crash but a kernel from > 2012-07-03 does crash. >=20 > Here're the sysctls/tunables I have regarding shm: >=20 > In /boot/loader.conf: > kern.ipc.shmmni=3D"1024" > kern.ipc.shmseg=3D"1024" >=20 > In /etc/sysctl.conf: > kern.ipc.shmmax=3D2147483648 > kern.ipc.shm_use_phys=3D1 > kern.ipc.shm_allow_removed=3D1 >=20 You know, this is not much useful ? Backtrace is. --QILrdhYozogw5Vly Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5heoACgkQC3+MBN1Mb4iYmQCfU8nyuNFWmRKeyBhcqr5P3ES3 KBYAn14yI/NvAjkQilEF5jzMxMoYcreM =+85o -----END PGP SIGNATURE----- --QILrdhYozogw5Vly-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 13:35:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DE3F106566C for ; Sun, 8 Jul 2012 13:35:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8D98FC08 for ; Sun, 8 Jul 2012 13:35:50 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q68DZ8Rt053232; Sun, 8 Jul 2012 16:35:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q68DYtFR045268; Sun, 8 Jul 2012 16:34:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q68DYtxu045267; Sun, 8 Jul 2012 16:34:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2012 16:34:55 +0300 From: Konstantin Belousov To: Michael Butler Message-ID: <20120708133455.GX2338@deviant.kiev.zoral.com.ua> References: <4FF98128.6050607@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b/3kIrr+SWblMf9a" Content-Disposition: inline In-Reply-To: <4FF98128.6050607@protected-networks.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 13:35:51 -0000 --b/3kIrr+SWblMf9a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: > Sorry, no symbols but this happened twice last night while being the > target of a dump over NFS .. >=20 > root@mail:/var/crash # less info.0 > Dump header from device /dev/ada0s1 > Architecture: i386 > Architecture Version: 2 > Dump Length: 252809216B (241 MB) > Blocksize: 512 > Dumptime: Sun Jul 8 00:21:23 2012 > Hostname: mail.auburn.protected-networks.net > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 > root@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN > Panic String: sleeping thread > Dump Parity: 2996346376 > Bounds: 0 > Dump Status: good >=20 >=20 > (kgdb) bt > #0 0xc07530cd in doadump () > #1 0xc0753656 in kern_reboot () > #2 0xc0753cfc in panic () > #3 0xc079a34e in propagate_priority () > #4 0xc079b5e4 in turnstile_wait () > #5 0xc073ea71 in _mtx_lock_sleep () > #6 0xc09c4772 in vm_page_unwire () > #7 0xc07db039 in vfs_vmio_release () > #8 0xc07dd476 in getnewbuf () > #9 0xc07de50b in getblk () > #10 0xc0966d99 in ffs_balloc_ufs2 () > #11 0xc099281e in ffs_write () > #12 0xc0a38b05 in VOP_WRITE_APV () > #13 0xc068a65e in nfsvno_write () > #14 0xc06882e7 in nfsrvd_write () > #15 0xc066ea05 in nfsrvd_dorpc () > #16 0xc067d42f in nfssvc_program () > #17 0xc09356e2 in svc_run_internal () > #18 0xc0935b70 in svc_thread_start () > #19 0xc07204fb in fork_exit () > #20 0xc09fe7a4 in fork_trampoline () You need to provide: 1. exact version of your kernel sources 2. complete panic message. There should be backtrace of the 'sleeping thread', not the paniced thread, right after the panic message. --b/3kIrr+SWblMf9a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5jH4ACgkQC3+MBN1Mb4gFpQCggGKbB331F/Ld6b8bUFc+4zST AGUAoLtAw0y4uoHT0uWJCknCbA7xwren =RpsY -----END PGP SIGNATURE----- --b/3kIrr+SWblMf9a-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 13:46:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 008D8106566C for ; Sun, 8 Jul 2012 13:46:13 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A1A408FC0C for ; Sun, 8 Jul 2012 13:46:12 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 5C0AB6194; Sun, 8 Jul 2012 09:46:11 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=HSAfcQbFv4nes/hp8DksSRTPyvyO3vaXFl1l8p0YiPXmAWwfDcTzLmO7xIPwj2GzB ylcNBarrDR7v9gp/v0aJJVQLUHJOFiXpvYfeBa72Tar1SgwL6FKCvjsnTPv3zjB Message-ID: <4FF98F21.9060003@protected-networks.net> Date: Sun, 08 Jul 2012 09:46:09 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120708133455.GX2338@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 13:46:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/12 09:34, Konstantin Belousov wrote: > On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: >> Sorry, no symbols but this happened twice last night while being the >> target of a dump over NFS .. >> >> root@mail:/var/crash # less info.0 >> Dump header from device /dev/ada0s1 >> Architecture: i386 >> Architecture Version: 2 >> Dump Length: 252809216B (241 MB) >> Blocksize: 512 >> Dumptime: Sun Jul 8 00:21:23 2012 >> Hostname: mail.auburn.protected-networks.net >> Magic: FreeBSD Kernel Dump >> Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 >> root@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN >> Panic String: sleeping thread >> Dump Parity: 2996346376 >> Bounds: 0 >> Dump Status: good >> >> >> (kgdb) bt >> #0 0xc07530cd in doadump () >> #1 0xc0753656 in kern_reboot () >> #2 0xc0753cfc in panic () >> #3 0xc079a34e in propagate_priority () >> #4 0xc079b5e4 in turnstile_wait () >> #5 0xc073ea71 in _mtx_lock_sleep () >> #6 0xc09c4772 in vm_page_unwire () >> #7 0xc07db039 in vfs_vmio_release () >> #8 0xc07dd476 in getnewbuf () >> #9 0xc07de50b in getblk () >> #10 0xc0966d99 in ffs_balloc_ufs2 () >> #11 0xc099281e in ffs_write () >> #12 0xc0a38b05 in VOP_WRITE_APV () >> #13 0xc068a65e in nfsvno_write () >> #14 0xc06882e7 in nfsrvd_write () >> #15 0xc066ea05 in nfsrvd_dorpc () >> #16 0xc067d42f in nfssvc_program () >> #17 0xc09356e2 in svc_run_internal () >> #18 0xc0935b70 in svc_thread_start () >> #19 0xc07204fb in fork_exit () >> #20 0xc09fe7a4 in fork_trampoline () > > You need to provide: > 1. exact version of your kernel sources This is the CVS equivalent of SVN r238221 > 2. complete panic message. There should be backtrace of the 'sleeping > thread', not the paniced thread, right after the panic message. > Sorry, that is the entire info file - nothing more than I've posted is logged, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5jyEACgkQQv9rrgRC1JLMGwCfZ+LwlzmVPgXvKz4BRAtEYk2W TI0Ani60MowM1vCvnyx68toimxcw7PYO =pdMc -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 14:34:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F77110656FC for ; Sun, 8 Jul 2012 14:34:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E50358FC15 for ; Sun, 8 Jul 2012 14:34:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q68EVQmA069684; Sun, 8 Jul 2012 17:31:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q68EVD1i045538; Sun, 8 Jul 2012 17:31:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q68EVDox045537; Sun, 8 Jul 2012 17:31:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2012 17:31:13 +0300 From: Konstantin Belousov To: Michael Butler Message-ID: <20120708143113.GZ2338@deviant.kiev.zoral.com.ua> References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JefYhWJ8RkX3aR0a" Content-Disposition: inline In-Reply-To: <4FF98F21.9060003@protected-networks.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 14:34:17 -0000 --JefYhWJ8RkX3aR0a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2012 at 09:46:09AM -0400, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 07/08/12 09:34, Konstantin Belousov wrote: > > On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: > >> Sorry, no symbols but this happened twice last night while being the > >> target of a dump over NFS .. > >> > >> root@mail:/var/crash # less info.0 > >> Dump header from device /dev/ada0s1 > >> Architecture: i386 > >> Architecture Version: 2 > >> Dump Length: 252809216B (241 MB) > >> Blocksize: 512 > >> Dumptime: Sun Jul 8 00:21:23 2012 > >> Hostname: mail.auburn.protected-networks.net > >> Magic: FreeBSD Kernel Dump > >> Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 20= 12 > >> root@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN > >> Panic String: sleeping thread > >> Dump Parity: 2996346376 > >> Bounds: 0 > >> Dump Status: good > >> > >> > >> (kgdb) bt > >> #0 0xc07530cd in doadump () > >> #1 0xc0753656 in kern_reboot () > >> #2 0xc0753cfc in panic () > >> #3 0xc079a34e in propagate_priority () > >> #4 0xc079b5e4 in turnstile_wait () > >> #5 0xc073ea71 in _mtx_lock_sleep () > >> #6 0xc09c4772 in vm_page_unwire () > >> #7 0xc07db039 in vfs_vmio_release () > >> #8 0xc07dd476 in getnewbuf () > >> #9 0xc07de50b in getblk () > >> #10 0xc0966d99 in ffs_balloc_ufs2 () > >> #11 0xc099281e in ffs_write () > >> #12 0xc0a38b05 in VOP_WRITE_APV () > >> #13 0xc068a65e in nfsvno_write () > >> #14 0xc06882e7 in nfsrvd_write () > >> #15 0xc066ea05 in nfsrvd_dorpc () > >> #16 0xc067d42f in nfssvc_program () > >> #17 0xc09356e2 in svc_run_internal () > >> #18 0xc0935b70 in svc_thread_start () > >> #19 0xc07204fb in fork_exit () > >> #20 0xc09fe7a4 in fork_trampoline () > >=20 > > You need to provide: > > 1. exact version of your kernel sources >=20 > This is the CVS equivalent of SVN r238221 >=20 > > 2. complete panic message. There should be backtrace of the 'sleeping > > thread', not the paniced thread, right after the panic message. > >=20 >=20 > Sorry, that is the entire info file - nothing more than I've posted is > logged, Catch it next time ? This should be quite reproducable, if real. Actually, try this. diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 9485fdd..de33afc 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1030,7 +1030,6 @@ rescan0: ++pageout_lock_miss; if (object->flags & OBJ_MIGHTBEDIRTY) vnodes_skipped++; - vm_page_lock_queues(); goto unlock_and_continue; } KASSERT(mp !=3D NULL, @@ -1041,7 +1040,6 @@ rescan0: if (vget(vp, LK_EXCLUSIVE | LK_TIMELOCK, curthread)) { VM_OBJECT_LOCK(object); - vm_page_lock_queues(); ++pageout_lock_miss; if (object->flags & OBJ_MIGHTBEDIRTY) vnodes_skipped++; @@ -1082,15 +1080,17 @@ rescan0: * If the page has become held it might * be undergoing I/O, so skip it */ + KASSERT(queues_locked, ("unlocked queues 2")); + mtx_assert(&vm_page_queue_mtx, MA_OWNED); if (m->hold_count) { - vm_page_lock_queues(); - queues_locked =3D TRUE; vm_page_unlock(m); vm_page_requeue(m); if (object->flags & OBJ_MIGHTBEDIRTY) vnodes_skipped++; goto unlock_and_continue; } + vm_page_unlock_queues(); + queues_locked =3D FALSE; } =20 /* --JefYhWJ8RkX3aR0a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5mbAACgkQC3+MBN1Mb4hoMACbB3G9Gwu3YQ1fYAZHkwsN/GQm 3u4AnAl42Vp5wGz65vGg1t/qNF1r2wEh =yNBm -----END PGP SIGNATURE----- --JefYhWJ8RkX3aR0a-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 15:02:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59005106566C; Sun, 8 Jul 2012 15:02:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B2E428FC0A; Sun, 8 Jul 2012 15:02:29 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q68F2cFH079795; Sun, 8 Jul 2012 18:02:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q68F2Qcq045687; Sun, 8 Jul 2012 18:02:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q68F2P0l045686; Sun, 8 Jul 2012 18:02:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2012 18:02:25 +0300 From: Konstantin Belousov To: amd64@freebsd.org Message-ID: <20120708150225.GA2338@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jsn5+Lu/ZvzbAGtZ" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org Subject: XSAVEOPT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 15:02:30 -0000 --Jsn5+Lu/ZvzbAGtZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please find at http://people.freebsd.org/~kib/misc/xsaveopt.1.patch a patch to finally add suport for using XSAVEOPT for our amd64 context switch code. See Intel SDM for description of the XSAVEOPT instruction. Summary is that the instruction allows to not write parts of the FPU state which was not touched by the thread. Context switch then would write less to the PCB when thread is moved out from CPU. This is mainly to facilitate the ever-growing size of the FPU register file, in particular, AVX/YMM registers. Normal applications do not touch YMM, so saving them on each context switch if FPU was used is waste. Main complication is that any consumer of the ucontext_t still expect to see fully populated machine state, including the extended states which were not saved. Since CPU only avoids save when corresponding state is pristine, we can use the copy of initial state. CPUID provides an enumerator that allows OS to easily pick up neccesary area and copy over. I tried hard, but was unable to measure any statistically significant difference in the context switch times between XSAVE and XSAVEOPT using lmbench lat_ctx, on Core i7 2600K. --Jsn5+Lu/ZvzbAGtZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5oQEACgkQC3+MBN1Mb4jQTQCggprKu1UUYowMeCiIXyzewViq VuAAn2UY0I/7AhGmFB+1x0OylSnd24VC =9G5R -----END PGP SIGNATURE----- --Jsn5+Lu/ZvzbAGtZ-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 15:18:03 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85BE6106566B for ; Sun, 8 Jul 2012 15:18:03 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1BB8FC0A for ; Sun, 8 Jul 2012 15:18:03 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 370DA6194; Sun, 8 Jul 2012 11:18:02 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=PHypqx/yeDmX0Bb96iGKz6fYxtxzKoYmbLzZmbjNHDwB5nyzv8MLTKt9b6xUj0xhE aVIa/O3dB2U26iy75x46ZGC+kjPAs2nCdk0KRs9ZHdz8PrIecXI3bu91TGx5SYx Message-ID: <4FF9A4A8.5050903@protected-networks.net> Date: Sun, 08 Jul 2012 11:18:00 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> <20120708143113.GZ2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120708143113.GZ2338@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 15:18:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/12 10:31, Konstantin Belousov wrote: > Catch it next time ? This should be quite reproducable, if real. > > Actually, try this. > > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index 9485fdd..de33afc 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1030,7 +1030,6 @@ rescan0: > ++pageout_lock_miss; > if (object->flags & OBJ_MIGHTBEDIRTY) > vnodes_skipped++; > - vm_page_lock_queues(); > goto unlock_and_continue; > } > KASSERT(mp != NULL, > @@ -1041,7 +1040,6 @@ rescan0: > if (vget(vp, LK_EXCLUSIVE | LK_TIMELOCK, > curthread)) { > VM_OBJECT_LOCK(object); > - vm_page_lock_queues(); > ++pageout_lock_miss; > if (object->flags & OBJ_MIGHTBEDIRTY) > vnodes_skipped++; > @@ -1082,15 +1080,17 @@ rescan0: > * If the page has become held it might > * be undergoing I/O, so skip it > */ > + KASSERT(queues_locked, ("unlocked queues 2")); > + mtx_assert(&vm_page_queue_mtx, MA_OWNED); > if (m->hold_count) { > - vm_page_lock_queues(); > - queues_locked = TRUE; > vm_page_unlock(m); > vm_page_requeue(m); > if (object->flags & OBJ_MIGHTBEDIRTY) > vnodes_skipped++; > goto unlock_and_continue; > } > + vm_page_unlock_queues(); > + queues_locked = FALSE; > } > > /* > Just waiting for the second of two attached RAID arrays to finish rebuilding and I'll give this a shot - thanks! imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5pKgACgkQQv9rrgRC1JKXAgCdEJhZIKRmLbAzIROKmN2WuZCU mb4AnR3Z+BrN7uqwYnXwubBEBx/QlWf8 =Ne6G -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:57:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 550DD106566B for ; Sun, 8 Jul 2012 16:57:44 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1BADA8FC08 for ; Sun, 8 Jul 2012 16:57:44 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id F29276194; Sun, 8 Jul 2012 12:57:41 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=PKY+/kQJR9kt7oaopnOGn6FlseJbN7gRPiOu3AqOKbSrxmHn/WPcS5YGE9I6t2wAi hGUYNP8UpZ9f1n9WktY3+4tF7dbrT5mbBlQLFftVoUE7N+Os1TjsLUA8ETCIFdS Message-ID: <4FF9BC03.1040008@protected-networks.net> Date: Sun, 08 Jul 2012 12:57:39 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> <20120708143113.GZ2338@deviant.kiev.zoral.com.ua> <4FF9A4A8.5050903@protected-networks.net> In-Reply-To: <4FF9A4A8.5050903@protected-networks.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 16:57:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/12 11:18, Michael Butler wrote: > On 07/08/12 10:31, Konstantin Belousov wrote: >> Catch it next time ? This should be quite reproducable, if real. > >> Actually, try this. > >> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c >> index 9485fdd..de33afc 100644 >> --- a/sys/vm/vm_pageout.c >> +++ b/sys/vm/vm_pageout.c >> @@ -1030,7 +1030,6 @@ rescan0: >> ++pageout_lock_miss; >> if (object->flags & OBJ_MIGHTBEDIRTY) >> vnodes_skipped++; >> - vm_page_lock_queues(); >> goto unlock_and_continue; [ .. snip .. ] > Just waiting for the second of two attached RAID arrays to finish > rebuilding and I'll give this a shot - thanks! I repeated the dumps from last night over NFS with this patch installed and no more panics :-) imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/5vAMACgkQQv9rrgRC1JJtPACgnyrSlf8jebp9iQLmTiXkaMYs /LUAn2BUlKUJ5aSMZ4biyqG9zZSRzPZA =WGNA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 16:59:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72D3E1065707; Sun, 8 Jul 2012 16:59:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DF6398FC19; Sun, 8 Jul 2012 16:59:25 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q68GxYKl016681; Sun, 8 Jul 2012 19:59:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q68GxMqA084244; Sun, 8 Jul 2012 19:59:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q68GxMpx084243; Sun, 8 Jul 2012 19:59:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jul 2012 19:59:22 +0300 From: Konstantin Belousov To: Michael Butler Message-ID: <20120708165922.GE2338@deviant.kiev.zoral.com.ua> References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> <20120708143113.GZ2338@deviant.kiev.zoral.com.ua> <4FF9A4A8.5050903@protected-networks.net> <4FF9BC03.1040008@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XLR3b0NScy54cC0V" Content-Disposition: inline In-Reply-To: <4FF9BC03.1040008@protected-networks.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 16:59:26 -0000 --XLR3b0NScy54cC0V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2012 at 12:57:39PM -0400, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 07/08/12 11:18, Michael Butler wrote: > > On 07/08/12 10:31, Konstantin Belousov wrote: > >> Catch it next time ? This should be quite reproducable, if real. > >=20 > >> Actually, try this. > >=20 > >> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > >> index 9485fdd..de33afc 100644 > >> --- a/sys/vm/vm_pageout.c > >> +++ b/sys/vm/vm_pageout.c > >> @@ -1030,7 +1030,6 @@ rescan0: > >> ++pageout_lock_miss; > >> if (object->flags & OBJ_MIGHTBEDIRTY) > >> vnodes_skipped++; > >> - vm_page_lock_queues(); > >> goto unlock_and_continue; >=20 > [ .. snip .. ] >=20 > > Just waiting for the second of two attached RAID arrays to finish > > rebuilding and I'll give this a shot - thanks! >=20 > I repeated the dumps from last night over NFS with this patch installed > and no more panics :-) But, are panics reproducable without the patch ? --XLR3b0NScy54cC0V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEUEARECAAYFAk/5vGkACgkQC3+MBN1Mb4i7VwCfX2z+Vj4cewoGE2kQMqp3NFFu hcYAmI/pIY4LahrbteG1hbhae90F8ko= =SUYd -----END PGP SIGNATURE----- --XLR3b0NScy54cC0V-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:35:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EBDE106566B for ; Sun, 8 Jul 2012 17:35:52 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id D03AD8FC0A for ; Sun, 8 Jul 2012 17:35:51 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q68HZo8x066111 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 18:35:50 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FF9C4F6.9020402@unsane.co.uk> Date: Sun, 08 Jul 2012 18:35:50 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rick Macklem References: <497527423.2441665.1341141539082.JavaMail.root@erie.cs.uoguelph.ca> <4FF82B13.8000906@unsane.co.uk> In-Reply-To: <4FF82B13.8000906@unsane.co.uk> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 17:35:52 -0000 On 07/07/2012 13:26, Vincent Hoffman wrote: > On 01/07/2012 12:18, Rick Macklem wrote: >> Vincent Hoffman wrote: >>> On 01/07/2012 01:53, Rick Macklem wrote: >>>> To modify mountd to use the kernel changes is more work than I have >>>> time for, in part because mountd.c is a very ugly old piece of C >>>> code, imho. >>>> >>>> I do have a patch that suspends/resumes execution of the nfsd >>>> threads >>>> (new, experimental for FreeBSD8.n only) when mountd reloads >>>> /etc/exports. >>>> This approach has certain disadvantages vs Andrey's transactional >>>> load/commit >>>> model, but it is simple and might be sufficient for your problem. >>>> If you want to try this patch, it is at: >>>> http://people.freebsd.org/~rmacklem/atomic-export.patch >>>> (The patch affects both the kernel and mountd.c.) >>> Happy to try it, to be certain I have understood, this is for the >>> newnfs >>> server (experimental in 8.x default for 8 >>> 9+) >> Yes, that is correct. For the old (default on 8.x) it will have no effect. >> >>> I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when >>> i >>> get a minute. >> Also, to enable it, you must add a "-S" flag to mountd_flags, after you've >> replaced the mountd executable. >> >> The patch is pretty straightforward, but has not seen much testing. >> Hopefully, it might be useful for you, rick > Hi Rick, > > I'm afraid this didnt make any real difference for me. > Since I couldnt test it on the live system I tried it on a test vm. > on the vm (nfs server) I set a looping mount/umount > while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done > > and on the client I set a loop of tars of large directorys to the nfs > mount running under time to see how well it survived. Then replicated > the test with the patch and without. > > > [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt > x nopatch.txt > + atomicpatch.txt > +--------------------------------------------------------------------------------------------------+ > | > * > | > | > * > | > | > x* > | > | xx* > x > | > | +x** > xx > | > | **** xxx > x > | > | **** xxx +x+ > + > | > | ****+*xx +x+ x > + > | > | ****+*x****++++x + + > x | > | *************+*xx+ +++x * x > x | > | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + > + +| > |||_______M_M_A__A_______|______| > | > +--------------------------------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 101 1.25 106.8 14.08 21.892178 22.196005 > + 101 1.21 186.93 18.46 27.995842 30.523218 > No difference proven at 95.0% confidence > > > (excuse wrapped ascii art) > > I think I'll have a look at the nfse patch set and see how that performs. Replying to myself just as a record, I have tried nfse and I didnt get the permission denied at all. The only issue I had with it is that it strictly adheres to the syntax in exports(5) while mountd is a little more flexible. I had /usr/local/export -alldirs -maproot=root 85.xx.xx.xx /usr is the root of that filesystem mountd - allowed this but actually silently exports /usr (and all dirs below) nfse - didnt allow this, it needed to be the correct /usr -alldirs -maproot=root 85.xx.xx.xx which is I guess a POLA violation but follows the documentation. this was using nfse in mountd compatibility mode. I havent played with its more advanced features. Vince > Thanks for all your work on NFS on FreeBSD. > > Vince > From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:39:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F1C1065670; Sun, 8 Jul 2012 17:39:17 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id E6DE38FC08; Sun, 8 Jul 2012 17:39:16 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 52DFA606DB; Sun, 8 Jul 2012 12:39:16 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 51509603DA; Sun, 8 Jul 2012 12:39:16 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id np8NiJDa5yXz; Sun, 8 Jul 2012 12:39:16 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id D7A9960302; Sun, 8 Jul 2012 12:39:15 -0500 (CDT) Message-ID: <4FF9C5C2.80509@rice.edu> Date: Sun, 08 Jul 2012 12:39:14 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Konstantin Belousov References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> <20120708143113.GZ2338@deviant.kiev.zoral.com.ua> <4FF9A4A8.5050903@protected-networks.net> <4FF9BC03.1040008@protected-networks.net> <20120708165922.GE2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120708165922.GE2338@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Michael Butler , current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 17:39:17 -0000 On 07/08/2012 11:59, Konstantin Belousov wrote: > On Sun, Jul 08, 2012 at 12:57:39PM -0400, Michael Butler wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/08/12 11:18, Michael Butler wrote: >>> On 07/08/12 10:31, Konstantin Belousov wrote: >>>> Catch it next time ? This should be quite reproducable, if real. >>>> Actually, try this. >>>> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c >>>> index 9485fdd..de33afc 100644 >>>> --- a/sys/vm/vm_pageout.c >>>> +++ b/sys/vm/vm_pageout.c >>>> @@ -1030,7 +1030,6 @@ rescan0: >>>> ++pageout_lock_miss; >>>> if (object->flags& OBJ_MIGHTBEDIRTY) >>>> vnodes_skipped++; >>>> - vm_page_lock_queues(); >>>> goto unlock_and_continue; >> [ .. snip .. ] >> >>> Just waiting for the second of two attached RAID arrays to finish >>> rebuilding and I'll give this a shot - thanks! >> I repeated the dumps from last night over NFS with this patch installed >> and no more panics :-) > But, are panics reproducable without the patch ? The patch looks correct. I'm sorry that I didn't catch this problem when I reviewed the original patch yesterday. :-( I don't think that you really need these assertions: + KASSERT(queues_locked, ("unlocked queues 2")); + mtx_assert(&vm_page_queue_mtx, MA_OWNED); The control flow from the preceding acquire is straightforward and vm_page_requeue() itself asserts that the page queues lock is held. Alan From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:52:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC1471065672 for ; Sun, 8 Jul 2012 17:52:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 905E08FC15 for ; Sun, 8 Jul 2012 17:52:00 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19177103pbb.13 for ; Sun, 08 Jul 2012 10:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=eTj7yQhuvGXLfSUV5eJBHuMjRAIikBt+v8WH9O/TEQs=; b=Z6FeKjS+bUD858DAZx3/0tasdUUGxxZ4IB9PGEb5GYQmJmcZ8Hp+sEEZq7ZOEIGgNR IZA4abcXV4+j7ymbhd93YTFGxZFoPB3L4MObn9diFqqZniw3SDrcBfVtcf8ARl9jkVUK wSzRoyy7YSAbshA9YI1/isUNMHzfi55XM6hp/67F+p2aDcqnk8srgDcXMhBh+a0itj/Z cFQBtnHYByqcbJaQftYfTXd/UoVljHr2PHP7+0AzPAP5MZ9m70Ee4YqFjAbJ0iH7Ge/S lEhI7C3u0oq3IK43afOIM5hsswmh83o1Vqd4uqHv8Kwjb+RGr50Uj9waVdTG4Jrby4PY Dvpw== Received: by 10.66.82.228 with SMTP id l4mr23423418pay.41.1341769920319; Sun, 08 Jul 2012 10:52:00 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id hf5sm26053369pbc.4.2012.07.08.10.51.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 10:51:59 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120708124047.GA44061@zim.MIT.EDU> Date: Sun, 8 Jul 2012 11:51:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> References: <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkLSKV5epsw0iV9Ky+rDzr0ppD8zgZWC+nYKE5/RXsw88wmkBREIWFvm9wyK91p0t3jFPvv Cc: freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 17:52:00 -0000 On Jul 8, 2012, at 6:40 AM, David Schultz wrote: > On Tue, May 29, 2012, Peter Jeremy wrote: >> On 2012-May-28 15:54:06 -0700, Steve Kargl = wrote: >>> Given that cephes was written years before C99 was even >>> conceived, I suspect all functions are sub-standard. >>=20 >> Well, most of cephes was written before C99. The C99 parts of >> cephes were written to turn it into a complete C99 implementation. >=20 > I'm a bit late to the party, but I thought I'd chime in with some > context. We did consider using Cephes years ago, and even got > permission from the author to release it under an acceptable license. > We later decided not to use it for technical reasons. >=20 > By the way, virtually none of the people who have complained about the > missing functions actually need them. Mostly they just want to > compile some software that was written by a naive programmer who > thought it would be cool to use the most precise type available. The > complex functions are even less commonly needed, and the truth is that > they have no business being part of the C standard anyway. >=20 > The question remains of what to do about the missing functions. Bruce > and Steve have been working on expl and logl for years. If those ever > get in the tree, the remaining long double functions are easy. Those > functions are basically done, modulo a bunch of cleanup and testing, > and I encourage any mathematically inclined folks who are interested > in pushing things along to get in touch with them. I'm not going to > have any time myself for a few months at least. Where can I find these? > Lastly, there's the question of mediocre alternatives, such as > solutions that get the boundary cases wrong or don't handle 128-bit > floating point. For the exponential and logarithmic functions, Bruce > and Steve have already written good implementations, so there's no > reason to settle for less. As for the other long double functions, > bringing in some Cephes code in a separate directory as a temporary > fix might be the way to go. I don't like that solution, and Steve > raises some good technical points about why it isn't ideal; however, a > better solution is more than a decade overdue, and people are > justified in finding that unacceptable. Don't let the perfect be the enemy of the good. It is better to have OK = implementations of these functions than none at all. We originally had = so-so double support, but bruce spent many years optimizing them to make = them very good. If we were just starting out, and hadn't let 10 years = get behind us, I'd give the substandard argument some weight. But now = that we're 13 years down the line from c99's publication I think we need = to relax our standards a bit. I'd even argue that these functions being = a little bad could easily spur people to make them better. Their = absence makes people just #define llexp(x) lexp(x), etc. :( Warner Warner= From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 17:56:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C97A6106566C; Sun, 8 Jul 2012 17:56:01 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD628FC08; Sun, 8 Jul 2012 17:56:01 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19181344pbb.13 for ; Sun, 08 Jul 2012 10:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4bl0V4CE2QUnGjoowrnoa1Xr544oLF9xYBX3wuWbBpg=; b=CmC1CjVgMBJ9QhjzObZJb8nSO/qkOxid7yeV8pYupjAZnfSPozu6+gISwF07YwbV34 HHkN0ID+uhA3/9EHsdsVyRNRcfFLg4ksFoSC7YG/KZyLCnv93joMrirVNjuClLQKktDg c8zq8UHBzINFHNxsgMR8aJymBbb1EsWECkmn3+5ZJt9kA0NofdHcnc/ku3w/znLMWQNu tDC+fsa2wfgAFwyDTbCavl93uWgh0lI+i7HaXN8z89rJ2tgokMRLTaKgNVNHy5JyXGD9 BiZGVNQHqR6lyyEDfXHGF83fhHQ7J7tBVzfW7cJonNL0GB/f4WsQ/jlQrPipxGFUIIGV e1Rg== MIME-Version: 1.0 Received: by 10.68.238.166 with SMTP id vl6mr53518580pbc.96.1341770161291; Sun, 08 Jul 2012 10:56:01 -0700 (PDT) Received: by 10.68.226.7 with HTTP; Sun, 8 Jul 2012 10:56:01 -0700 (PDT) In-Reply-To: <4FF941EC.9050900@FreeBSD.org> References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> <4FF62A6C.7090408@FreeBSD.org> <4FF8FB0C.4050706@mouf.net> <4FF941EC.9050900@FreeBSD.org> Date: Sun, 8 Jul 2012 12:56:01 -0500 Message-ID: From: Alan Cox To: =?ISO-8859-1?Q?Jean=2DS=E9bastien_P=E9dron?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 17:56:01 -0000 On Sun, Jul 8, 2012 at 3:16 AM, Jean-S=E9bastien P=E9dron wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08.07.2012 05:14, Steve Wills wrote: > > For what it's worth, I discovered that twm and xterm don't trigger > > the issue, but konsole and other kde things do, which is what led > > me to discover that setting kern.ipc.shm_use_phys back to default > > fixed it. > > I encountered the same issue with x11-wm/awesome, but everything's ok > with twm. A kernel from 2012-06-23 doesn't crash but a kernel from > 2012-07-03 does crash. > > In r237513 on 6/23 I made a mistake that was corrected in r238124 on 7/5. I can vaguely see a connection between kern.ipc.shm_use_phys and the problem fixed in r238124. So, I'd like to know if this problem still exists. Wait, however, until you see Kostik commit a change to vm_pageout.c, before you update your system. Here're the sysctls/tunables I have regarding shm: > > In /boot/loader.conf: > kern.ipc.shmmni=3D"1024" > kern.ipc.shmseg=3D"1024" > > In /etc/sysctl.conf: > kern.ipc.shmmax=3D2147483648 > kern.ipc.shm_use_phys=3D1 > kern.ipc.shm_allow_removed=3D1 > > - -- > Jean-S=E9bastien P=E9dron > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk/5QesACgkQa+xGJsFYOlPRwQCcClck3824nWltHoIVzuzmLBLz > dyUAoIhVeREUZH26QdcJkyyXfna9LYQQ > =3DmKU0 > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Jul 8 19:06:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 116BE106566B for ; Sun, 8 Jul 2012 19:06:54 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id C81288FC14 for ; Sun, 8 Jul 2012 19:06:53 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q68J6kPq077591 for ; Sun, 8 Jul 2012 14:06:46 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4FF9DA46.2010502@missouri.edu> Date: Sun, 08 Jul 2012 14:06:46 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FC3A154.8030702@missouri.edu> <20120528203159.GA76340@troutmask.apl.washington.edu> <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> In-Reply-To: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 19:06:54 -0000 Here is a technical question. I know that people always talk about ulp's in the context of how good a function implementation is. I think the ulp is the number of base 2 digits at the end of the mantissa that we cannot rely on. So if one were to write a naive implementation of lexp(x) that used Taylor's series if x is positive, and 1/lexp(-x) is x is negative - well one could fairly easily estimate an upper bound on the ulp, but it wouldn't be low (like ulp=1 or 2), but probably rather higher (ulp of the order of 10 or 20). So do people really work hard to get that last drop of ulp out of their calculations? Would a ulp=10 be considered unacceptable? Also, looking through the source code for the FreeBSD implementation of exp, I saw that they used some rather smart rational function. (I don't know how they came up with it.) Presumably a big part of the issue is to make the functions work rather fast. And a naive implementation of Taylor's series wouldn't be fast. But if people want lexp rather than exp, they must have already decided that accuracy is more important than speed. From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 19:46:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78E8F106564A; Sun, 8 Jul 2012 19:46:58 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E43B8FC08; Sun, 8 Jul 2012 19:46:58 +0000 (UTC) Received: by obbun3 with SMTP id un3so23249944obb.13 for ; Sun, 08 Jul 2012 12:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=peV9A6YahevQC7vYzBuapp3ytCl+XJdIssjdWIkgTwQ=; b=etrgPGbuw8qe1oMLF2PN+psMpoIuKCZls6M2i7fuqAf8AjwM+dV/0dRpuadBnb35z+ 4KGhY9lSpGayIb4xMpficXjswozmnzEtXsKoCmxX7wy8pCqJSCiO+yu3gCtJt5z9l5h1 sazF/20HtkZM6+SNtgH6TI7BfXWegXevPXzVIwHpQ2iAxTRXTDtbJiw13iaQU68imefe o3vTiUqgurkGKlHtgnx3oHqWmIxnp8v4dFOHH+PTHOI5xwyaReOqrW9BA8wYt8M2GEz9 GYLwaOIL0XmKCeHbkeB4rNM/NZntMuIgfVVKhCWG7Jxz3VEMWblujudA/f9f4F+Gq3gU cotw== MIME-Version: 1.0 Received: by 10.60.22.165 with SMTP id e5mr18113359oef.60.1341776817235; Sun, 08 Jul 2012 12:46:57 -0700 (PDT) Received: by 10.182.32.234 with HTTP; Sun, 8 Jul 2012 12:46:57 -0700 (PDT) In-Reply-To: References: <20120607203753.2466c63a.miwi@FreeBSD.org> <4fd44f39.06db440a.4ccb.ffffe4e1SMTPIN_ADDED@mx.google.com> <4fd465a3.46e8440a.7470.0336SMTPIN_ADDED@mx.google.com> Date: Sun, 8 Jul 2012 22:46:57 +0300 Message-ID: From: Alexander Yerenkow To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 Cc: Ivan Klymenko , ports@freebsd.org, freebsd-current , x11@freebsd.org Subject: Re: [CFT] Xorg 7.7 ready for testing! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 19:46:58 -0000 Hello All! I'm created unofficial pkg repo for patched xorg tree. I'm still experimenting with it, but I already have built all required packages for CURRENT i386. You can find it here: http://pkgng.gits.kiev.ua/packages/test10-32-kmsxorg/ If anyone want to test new xorg, you can install all required packages using ports/pkg. pkg install -x xorg\* pkg install -x xf86\* pkg install xterm Also, you can try kde4 in this repo, pkg install kde I'll provide xorg testing enthusiasts with prebuilt images for "simply boot it and report any feedback" in near future. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:42:44 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2777A1065673; Sun, 8 Jul 2012 23:42:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4FC8FC18; Sun, 8 Jul 2012 23:42:43 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q68NaPBE053527; Sun, 8 Jul 2012 16:36:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q68NaO5K053526; Sun, 8 Jul 2012 16:36:24 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 16:36:24 -0700 From: Steve Kargl To: Warner Losh Message-ID: <20120708233624.GA53462@troutmask.apl.washington.edu> References: <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , freebsd-current@FreeBSD.ORG, Peter Jeremy Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 23:42:44 -0000 On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote: > > On Jul 8, 2012, at 6:40 AM, David Schultz wrote: > > > On Tue, May 29, 2012, Peter Jeremy wrote: > >> On 2012-May-28 15:54:06 -0700, Steve Kargl wrote: > >>> Given that cephes was written years before C99 was even > >>> conceived, I suspect all functions are sub-standard. > >> > >> Well, most of cephes was written before C99. The C99 parts of > >> cephes were written to turn it into a complete C99 implementation. > > > > I'm a bit late to the party, but I thought I'd chime in with some > > context. We did consider using Cephes years ago, and even got > > permission from the author to release it under an acceptable license. > > We later decided not to use it for technical reasons. > > > > By the way, virtually none of the people who have complained about the > > missing functions actually need them. Mostly they just want to > > compile some software that was written by a naive programmer who > > thought it would be cool to use the most precise type available. The > > complex functions are even less commonly needed, and the truth is that > > they have no business being part of the C standard anyway. > > > > The question remains of what to do about the missing functions. Bruce > > and Steve have been working on expl and logl for years. If those ever > > get in the tree, the remaining long double functions are easy. Those > > functions are basically done, modulo a bunch of cleanup and testing, > > and I encourage any mathematically inclined folks who are interested > > in pushing things along to get in touch with them. I'm not going to > > have any time myself for a few months at least. > > Where can I find these? I've posted expl() a few times for the ld80 version. I don't have an ld128 version, which is why I have yet to submit a formal patch for expl(). I also have an ld80 expm1l(). I have a copy of bde's ld80 logl(). IIRC, bde wrote an ld128, but I don't have nor do I know if it has been tested. > > Lastly, there's the question of mediocre alternatives, such as > > solutions that get the boundary cases wrong or don't handle 128-bit > > floating point. For the exponential and logarithmic functions, Bruce > > and Steve have already written good implementations, so there's no > > reason to settle for less. As for the other long double functions, > > bringing in some Cephes code in a separate directory as a temporary > > fix might be the way to go. I don't like that solution, and Steve > > raises some good technical points about why it isn't ideal; however, a > > better solution is more than a decade overdue, and people are > > justified in finding that unacceptable. > > Don't let the perfect be the enemy of the good. It is better to > have OK implementations of these functions than none at all. You'll need to define OK, because some of the implementations I've read are poor. I also hope that before anything is committed to libm that the person doing the committing does some rather thorough testing of the code. > We originally had so-so double support, but bruce spent many > years optimizing them to make them very good. If we were > just starting out, and hadn't let 10 years get behind us, I'd > give the substandard argument some weight. But now that we're > 13 years down the line from c99's publication I think we need > to relax our standards a bit. I'd even argue that these > functions being a little bad could easily spur people to make > them better. Their absence makes people just > #define llexp(x) lexp(x), etc. :( Of course, the converse argument is that people have had 10 years to learn enough about floating point to actually write and submit code. I knew very little about FP before I wrote sqrtl(). I had a need for sqrtl() and so I went looking for a solution. PS: I also wrote sincos[fl](), which is very handy for the complex trig functions. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:48:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 604F5106566B for ; Sun, 8 Jul 2012 23:48:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-scalar.mail.uoguelph.ca (esa-scalar.mail.uoguelph.ca [66.199.40.18]) by mx1.freebsd.org (Postfix) with ESMTP id 28CB28FC14 for ; Sun, 8 Jul 2012 23:48:24 +0000 (UTC) Received: from zcs3.mail.uoguelph.ca (new.mail.uoguelph.ca [131.104.93.37]) by esa-scalar.mail.uoguelph.ca (8.14.1/8.14.1) with ESMTP id q68NmB7t030139; Sun, 8 Jul 2012 19:48:11 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 3F2F4B4040; Sun, 8 Jul 2012 19:48:11 -0400 (EDT) Date: Sun, 8 Jul 2012 19:48:11 -0400 (EDT) From: Rick Macklem To: Vincent Hoffman Message-ID: <854827461.102645.1341791291213.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4FF9C4F6.9020402@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 23:48:24 -0000 Vincent Hoffman wrote: > On 07/07/2012 13:26, Vincent Hoffman wrote: > > On 01/07/2012 12:18, Rick Macklem wrote: > >> Vincent Hoffman wrote: > >>> On 01/07/2012 01:53, Rick Macklem wrote: > >>>> To modify mountd to use the kernel changes is more work than I > >>>> have > >>>> time for, in part because mountd.c is a very ugly old piece of C > >>>> code, imho. > >>>> > >>>> I do have a patch that suspends/resumes execution of the nfsd > >>>> threads > >>>> (new, experimental for FreeBSD8.n only) when mountd reloads > >>>> /etc/exports. > >>>> This approach has certain disadvantages vs Andrey's transactional > >>>> load/commit > >>>> model, but it is simple and might be sufficient for your problem. > >>>> If you want to try this patch, it is at: > >>>> http://people.freebsd.org/~rmacklem/atomic-export.patch > >>>> (The patch affects both the kernel and mountd.c.) > >>> Happy to try it, to be certain I have understood, this is for the > >>> newnfs > >>> server (experimental in 8.x default for 8 > >>> 9+) > >> Yes, that is correct. For the old (default on 8.x) it will have no > >> effect. > >> > >>> I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm > >>> when > >>> i > >>> get a minute. > >> Also, to enable it, you must add a "-S" flag to mountd_flags, after > >> you've > >> replaced the mountd executable. > >> > >> The patch is pretty straightforward, but has not seen much testing. > >> Hopefully, it might be useful for you, rick > > Hi Rick, > > > > I'm afraid this didnt make any real difference for me. > > Since I couldnt test it on the live system I tried it on a test vm. > > on the vm (nfs server) I set a looping mount/umount > > while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp > > ; done > > > > and on the client I set a loop of tars of large directorys to the > > nfs > > mount running under time to see how well it survived. Then > > replicated > > the test with the patch and without. > > > > > > [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt > > x nopatch.txt > > + atomicpatch.txt > > +--------------------------------------------------------------------------------------------------+ > > | > > * > > | > > | > > * > > | > > | > > x* > > | > > | xx* > > x > > | > > | +x** > > xx > > | > > | **** xxx > > x > > | > > | **** xxx +x+ > > + > > | > > | ****+*xx +x+ x > > + > > | > > | ****+*x****++++x + + > > x | > > | *************+*xx+ +++x * x > > x | > > | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + > > + +| > > |||_______M_M_A__A_______|______| > > | > > +--------------------------------------------------------------------------------------------------+ > > N Min Max Median Avg Stddev > > x 101 1.25 106.8 14.08 21.892178 22.196005 > > + 101 1.21 186.93 18.46 27.995842 30.523218 > > No difference proven at 95.0% confidence > > > > > > (excuse wrapped ascii art) > > > > I think I'll have a look at the nfse patch set and see how that > > performs. > Replying to myself just as a record, I have tried nfse and I didnt get > the permission denied at all. > The only issue I had with it is that it strictly adheres to the syntax > in exports(5) while mountd is a little more flexible. > > I had > /usr/local/export -alldirs -maproot=root 85.xx.xx.xx > > /usr is the root of that filesystem > > mountd - allowed this but actually silently exports /usr (and all dirs > below) > Not exactly correct. mountd exports the entire file system in the kernel for the NFS server, since exports can only be attached to the mount points in the kernel. However, when the client's mount protocol requests a mount file handle for anything other than /usr/local/export, it will refuse that. (Which means that to mount anything other than /usr/local/export, the client must maliciously "guess" the file handle for mounting.) Put another way, a "non-malicious" NFSv3 client will only be able to mount /usr/local/export. Robert Watson calls this an "administrative control" and feels that it is necessary. Until this is resolved by "the collective", I do not see how mountd can be replaced by "nfse", although I'd like to see mountd replaced because of the above problem + mountd.c is very old, ugly (implies difficult to change) code. > nfse - didnt allow this, it needed to be the correct > /usr -alldirs -maproot=root 85.xx.xx.xx > > which is I guess a POLA violation but follows the documentation. > this was using nfse in mountd compatibility mode. I havent played with > its more advanced features. > > Vince > > Thanks for all your work on NFS on FreeBSD. > > > > Vince > > > > > _______________________________________________ > 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 Jul 8 23:56:56 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADD36106564A for ; Sun, 8 Jul 2012 23:56:56 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 694558FC08 for ; Sun, 8 Jul 2012 23:56:56 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q68Nur8f046816; Sun, 8 Jul 2012 19:56:53 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q68NuqP9046815; Sun, 8 Jul 2012 19:56:52 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 8 Jul 2012 19:56:52 -0400 From: David Schultz To: Steve Kargl Message-ID: <20120708235652.GA46771@zim.MIT.EDU> Mail-Followup-To: Steve Kargl , Warner Losh , Peter Jeremy , freebsd-current@FreeBSD.ORG References: <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120708233624.GA53462@troutmask.apl.washington.edu> Cc: freebsd-current@FreeBSD.ORG, Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 23:56:56 -0000 On Sun, Jul 08, 2012, Steve Kargl wrote: > > > The question remains of what to do about the missing functions. Bruce > > > and Steve have been working on expl and logl for years. If those ever > > > get in the tree, the remaining long double functions are easy. Those > > > functions are basically done, modulo a bunch of cleanup and testing, > > > and I encourage any mathematically inclined folks who are interested > > > in pushing things along to get in touch with them. I'm not going to > > > have any time myself for a few months at least. > > > > Where can I find these? > > I've posted expl() a few times for the ld80 version. > I don't have an ld128 version, which is why I have > yet to submit a formal patch for expl(). I also > have an ld80 expm1l(). I have a copy of bde's ld80 > logl(). IIRC, bde wrote an ld128, but I don't have > nor do I know if it has been tested. Yes, Bruce has ld128 versions, and clusteradm very kindly got us a sparc64 machine to test on. That was about the time I ran out of time to keep working on it. If someone wants to pick it up, that would be great. > PS: I also wrote sincos[fl](), which is very handy for the > complex trig functions. Yes, you should commit that! From owner-freebsd-current@FreeBSD.ORG Sun Jul 8 23:58:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32769106567B for ; Sun, 8 Jul 2012 23:58:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF0F8FC14 for ; Sun, 8 Jul 2012 23:58:49 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q68NwmjE053660; Sun, 8 Jul 2012 16:58:48 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q68NwmKO053659; Sun, 8 Jul 2012 16:58:48 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 16:58:48 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120708235848.GB53462@troutmask.apl.washington.edu> References: <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF9DA46.2010502@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 08 Jul 2012 23:58:49 -0000 On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: > Here is a technical question. I know that people always talk about > ulp's in the context of how good a function implementation is. I think > the ulp is the number of base 2 digits at the end of the mantissa that > we cannot rely on. There are a few definitions of ULP (units in the last place). Google 'Muller ULP' and check goldberg's paper (google 'goldberg floating point'. Here's how I define ULP for my testing and the MPFR code. /* From a das email: ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(z). I use: mpfr_sub(err, acc_out, approx_out, GMP_RNDN); mpfr_abs(err, err, GMP_RNDN); mpfr_mul_2si(ulpx, err, -mpfr_get_exp(acc_out) + LDBL_MANT_DIG, GMP_RNDN); ulp = mpfr_get_d(ulpx, GMP_RNDN); if (ulp 0.506 && mpfr_cmpabs(err, ldbl_minx) 0) { print warning...; } */ #include "gmp.h" #include "mpfr.h" #include "sgk.h" static mpfr_t mp_ulp_err; /* * Set the precision of the ULP computation. */ void mp_ulp_init(int prec) { mpfr_init2(mp_ulp_err, (mpfr_prec_t)prec); } /* * Given the 'approximate' value of a function and * an 'accurate' value compute the ULP. */ double mp_ulp(mpfr_t approximate, mpfr_t accurate, int dig) { double ulp; mpfr_sub(mp_ulp_err, accurate, approximate, RD); mpfr_abs(mp_ulp_err, mp_ulp_err, RD); mpfr_mul_2si(mp_ulp_err, mp_ulp_err, - mpfr_get_exp(accurate) + dig, RD); ulp = mpfr_get_d(mp_ulp_err, RD); return (ulp); } > So if one were to write a naive implementation of lexp(x) that used > Taylor's series if x is positive, and 1/lexp(-x) is x is negative - well > one could fairly easily estimate an upper bound on the ulp, but it > wouldn't be low (like ulp=1 or 2), but probably rather higher (ulp of > the order of 10 or 20). I've already written an ld80 expl(). I have tested billions if not trillions of values. Don't recall the max ULP I saw, but I know it was less than 1. I don't have an ld128 version, so I won't submit a patch for libm. > So do people really work hard to get that last drop of ulp out of their > calculations? I know very few scientist who work hard to reduce the ULP. Most have little understanding of floating point. > Would a ulp=10 be considered unacceptable? Yes, it is unacceptable for the math library. Remember ULPs propagate and can quickly grow if the initial ulp for a result is large. > Also, looking through the source code for the FreeBSD implementation of > exp, I saw that they used some rather smart rational function. (I don't > know how they came up with it.) See Steven Moshier's book, which is the basis for CEPHES. Instead of using a minimax polynomial approximation for the function in some interval, one uses a minimax approximation with a rational function. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 00:29:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 550F5106564A for ; Mon, 9 Jul 2012 00:29:32 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id F16D28FC12 for ; Mon, 9 Jul 2012 00:29:31 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q690TU92016677; Sun, 8 Jul 2012 19:29:30 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4FFA25EA.5090705@missouri.edu> Date: Sun, 08 Jul 2012 19:29:30 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> In-Reply-To: <20120708235848.GB53462@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 00:29:32 -0000 On 07/08/2012 06:58 PM, Steve Kargl wrote: > On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: >> So do people really work hard to get that last drop of ulp out of their >> calculations? > > I know very few scientist who work hard to reduce the ULP. Most > have little understanding of floating point. > >> Would a ulp=10 be considered unacceptable? > > Yes, it is unacceptable for the math library. Remember ULPs > propagate and can quickly grow if the initial ulp for a > result is large. OK. But suppose I wanted ld80 precision. What would be the advantage of using an ld80 expl function with a ulp of 1 over an ld128 expl function with a ulp of 10? The error propagation in the latter case could not be worse than the error propagation in the latter case. In other words, if I were asked to write a super-fantastic expl function, where run time was not a problem, I would use mpfr, use Taylor's series with a floating point precision that had way more digits than I needed, and then just truncate away the last digits when returning the answer. And this would be guaranteed to give the correct answer to just above 0.5 ulp (which I assume is best possible). From a scientist's point of view, I would think ulp is a rather unimportant concept. The concepts of absolute and relative error are much more important to them. The only way I can see ULP errors greatly propagating is if one is performing iteration type calculations (like f(f(f(f(x))))). This sort of thing is done when computing Julia sets and such like. And in that case, as far as I can see, a slightly better ulp is not going to drastically change the limitations of whatever floating point precision you are using. From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 01:09:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB2E106566C for ; Mon, 9 Jul 2012 01:09:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-scalar.mail.uoguelph.ca (esa-scalar.mail.uoguelph.ca [66.199.40.18]) by mx1.freebsd.org (Postfix) with ESMTP id 57EC58FC12 for ; Mon, 9 Jul 2012 01:09:00 +0000 (UTC) Received: from zcs3.mail.uoguelph.ca (new.mail.uoguelph.ca [131.104.93.37]) by esa-scalar.mail.uoguelph.ca (8.14.1/8.14.1) with ESMTP id q6918sQE009887; Sun, 8 Jul 2012 21:08:55 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DD05B79451; Sun, 8 Jul 2012 21:08:54 -0400 (EDT) Date: Sun, 8 Jul 2012 21:08:54 -0400 (EDT) From: Rick Macklem To: Vincent Hoffman Message-ID: <1458419708.103582.1341796134892.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4FF965BA.90407@unsane.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_103581_1076447948.1341796134891" X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 01:09:00 -0000 ------=_Part_103581_1076447948.1341796134891 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Vincent Hoffman: > On 08/07/2012 00:26, Rick Macklem wrote: > > Vincent Hoffman wrote: > >> > >> Hi Rick, > >> > >> I'm afraid this didnt make any real difference for me. > >> Since I couldnt test it on the live system I tried it on a test vm. > >> on the vm (nfs server) I set a looping mount/umount > >> while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp > >> ; > >> done > >> > >> and on the client I set a loop of tars of large directorys to the > >> nfs > >> mount running under time to see how well it survived. Then > >> replicated > >> the test with the patch and without. > >> > > Just to confirm, you patched both the kernel and mountd and replaced > > both > > on the server? > > > > Also, I'm not sure how ZFS handles it's exports. I can't remember if > > you've > > tried an exported UFS volume. It might be something ZFS specific? > > > > rick > > Hi Rick, > > yes I patched both the kernel and mountd, rebuilt kernel and world (to > be sure), added the -S flag to mountd in rc.conf and rebooted. > This is a test VM running -CURRENT and is only exporting a ufs2 > filesystem. > (11:43:05 <~>) 0 $ cat /etc/exports > /usr/local/export -maproot=root -alldirs XX.XX.XX.XX > > Client is a 8.3-RELEASE box but I see the same with linux clients. > (I can confirm that it works fine when I am not running the > mount/umount > loop) > Oops, the patch I sent you worked for NFSv4 only. If you also apply the attached patch, it seems to work for NFSv3 as well. The patch is also at: http://people.freebsd.org/~rmacklem/atomic-export2.patch You must also run the new/experimental server. (I can't remember if I mentioned that before.) rick > > The production system has been fine since I removed the SIGHUP call in > mount.c so thanks for that suggestion. > > > Vince > > > >> [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt > >> x nopatch.txt > >> + atomicpatch.txt > >> +--------------------------------------------------------------------------------------------------+ > >> | > >> * > >> | > >> | > >> * > >> | > >> | > >> x* > >> | > >> | xx* > >> x > >> | > >> | +x** > >> xx > >> | > >> | **** xxx > >> x > >> | > >> | **** xxx +x+ > >> + > >> | > >> | ****+*xx +x+ x > >> + > >> | > >> | ****+*x****++++x + + > >> x | > >> | *************+*xx+ +++x * x > >> x | > >> | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + > >> + +| > >> |||_______M_M_A__A_______|______| > >> | > >> +--------------------------------------------------------------------------------------------------+ > >> N Min Max Median Avg Stddev > >> x 101 1.25 106.8 14.08 21.892178 22.196005 > >> + 101 1.21 186.93 18.46 27.995842 30.523218 > >> No difference proven at 95.0% confidence > >> > >> > >> (excuse wrapped ascii art) > >> > >> I think I'll have a look at the nfse patch set and see how that > >> performs. > >> > >> Thanks for all your work on NFS on FreeBSD. > >> > >> Vince > >> > >>>>> Also, you could easily hack mount.c so that it doesn't send a > >>>>> SIGHUP > >>>>> to mountd (which causes the exports to be reloaded) every time a > >>>>> local > >>>>> fs is mounted. > >>>> True and I may have to do that for the production NAS for the > >>>> time > >>>> being. > >>>> Thanks for looking at this. > >>>> > >>>> Vince > >>>>> rick > >>>>> > >>>>>>> thanks, Vince > >> > >> _______________________________________________ > >> 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" ------=_Part_103581_1076447948.1341796134891 Content-Type: text/x-patch; name=atomic-export2.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=atomic-export2.patch LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHNvY2tldC5jLnNhdgkyMDEyLTA3LTA4IDIwOjMyOjM3 LjAwMDAwMDAwMCAtMDQwMAorKysgZnMvbmZzc2VydmVyL25mc19uZnNkc29ja2V0LmMJMjAxMi0w Ny0wOCAyMDo0MjowMy4wMDAwMDAwMDAgLTA0MDAKQEAgLTM1Miw3ICszNTIsNyBAQCBBUFBMRVNU QVRJQyB2b2lkCiBuZnNydmRfZG9ycGMoc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgaW50IGlz ZGdyYW0sCiAgICAgTkZTUFJPQ19UICpwKQogewotCWludCBlcnJvciA9IDAsIGxrdHlwZTsKKwlp bnQgZXJyb3IgPSAwLCBnb3RyZWYgPSAwLCBsa3R5cGU7CiAJdm5vZGVfdCB2cDsKIAltb3VudF90 IG1wID0gTlVMTDsKIAlzdHJ1Y3QgbmZzcnZmaCBmaDsKQEAgLTM3OCw2ICszNzgsMTEgQEAgbmZz cnZkX2RvcnBjKHN0cnVjdCBuZnNydl9kZXNjcmlwdCAqbmQsIAogCQkJCW5kLT5uZF9yZXBzdGF0 ID0gTkZTRVJSX0dBUkJBR0U7CiAJCQkJZ290byBvdXQ7CiAJCQl9CisJCQlnb3RyZWYgPSAxOwor CQkJTkZTTE9DS1Y0Uk9PVE1VVEVYKCk7CisJCQluZnN2NF9nZXRyZWYoJm5mc3Y0cm9vdGZzX2xv Y2ssIE5VTEwsCisJCQkgICAgTkZTVjRST09UTE9DS01VVEVYUFRSLCBOVUxMKTsKKwkJCU5GU1VO TE9DS1Y0Uk9PVE1VVEVYKCk7CiAJCQlpZiAobmQtPm5kX3Byb2NudW0gPT0gTkZTUFJPQ19SRUFE IHx8CiAJCQkgICAgbmQtPm5kX3Byb2NudW0gPT0gTkZTUFJPQ19SRUFERElSIHx8CiAJCQkgICAg bmQtPm5kX3Byb2NudW0gPT0gTkZTUFJPQ19SRUFETElOSyB8fApAQCAtNDcxLDYgKzQ3NiwxMSBA QCBuZnNydmRfZG9ycGMoc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgCiAJCW5kLT5uZF9mbGFn ICY9IH5ORF9TQVZFUkVQTFk7CiAKIG91dDoKKwlpZiAoZ290cmVmICE9IDApIHsKKwkJTkZTTE9D S1Y0Uk9PVE1VVEVYKCk7CisJCW5mc3Y0X3JlbHJlZigmbmZzdjRyb290ZnNfbG9jayk7CisJCU5G U1VOTE9DS1Y0Uk9PVE1VVEVYKCk7CisJfQogCU5GU0VYSVRDT0RFMigwLCBuZCk7CiB9CiAK ------=_Part_103581_1076447948.1341796134891-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 01:22:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BB76106564A; Mon, 9 Jul 2012 01:22:19 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE648FC0C; Mon, 9 Jul 2012 01:22:18 +0000 (UTC) Received: by werp13 with SMTP id p13so7396880wer.13 for ; Sun, 08 Jul 2012 18:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pXICLcFOZ+Eei5tfX/FTSS3eI+kM+W0rnm/YTkAhd7w=; b=CvZxxpvVqxo428ODPph5dk07TLbGstkvCS5/tg8Py4L3qAi8PF1Ei/W1MLXWuH04EC 1DBZnaJALRA74W7HRWP+fs2fAT0VO1EUYGGfpkd3mppo0vIiMw9E6+eGA02PrH6J6Jl0 8XHVdJ9ySiJuBX/ZtIGmtXMHLDIyGuQvhrFWM41JA+YWuhHK2i12AmPBKa5R+u4Na7Fe gFDAGwDQSTn6AUtU64/QgQlQD8WgwNf2M3QaEfDW1fTXkQd9FlHoUlRF6VVqnrR3iuNi iEC4kQgaacjBW1AkF3dEe4HxdK7cvTK3sLSKfFaO9lu14lUUShx3oAVKe4oP10624vsZ NCxw== MIME-Version: 1.0 Received: by 10.180.86.106 with SMTP id o10mr25293370wiz.22.1341796937633; Sun, 08 Jul 2012 18:22:17 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 18:22:17 -0700 (PDT) Date: Sun, 8 Jul 2012 21:22:17 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 01:22:19 -0000 Hi folks, Ok, yet another Newbus' limitation. Assuming a device exports more than one interface, and one of its child has need to use more than one interface, each interfaces cannot register, concurrently, its own ivar. While I try to always have a single child per interface/resource, I need to keep some compatibility with the old way of doing thing (POLA wrt. drivers I cannot/will not convert and userland). So, it would have been nice if ivar had been per-interface, not global and unique to one device. Unless I am mistaken, ivar are the only way for a parent can transmit information to a child. I can not simply implement a new METHOD to get that ivar as the device implements multiple time the same function (actually, up to 4 time for one, 3 for the other, with possible crossovers...), each one physically distinct. Each child is being tied to a pair. Thus, I need to pass each child discriminator(s) for each interfaces right after having been *created*, which cannot be done later on. Of course, it is out-of-question to have crossover in the interfaces definitions. The best way I could achieve this currently is to pass the child's device to its parent, and do a lookup based on that pointer to get information I need, but erk.... my 1c, - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 01:22:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E31E1065672; Mon, 9 Jul 2012 01:22:40 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 330EC8FC14; Mon, 9 Jul 2012 01:22:40 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.5/8.14.5) with ESMTP id q691McUX081601 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 8 Jul 2012 21:22:39 -0400 (EDT) (envelope-from swills@FreeBSD.org) Message-ID: <4FFA325E.8070907@FreeBSD.org> Date: Sun, 08 Jul 2012 21:22:38 -0400 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120604 Thunderbird/12.0.1 MIME-Version: 1.0 To: alc@FreeBSD.org References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> <4FF62A6C.7090408@FreeBSD.org> <4FF8FB0C.4050706@mouf.net> <4FF941EC.9050900@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 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 (mouf.net [204.109.58.86]); Sun, 08 Jul 2012 21:22:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.97.5 at mouf.net X-Virus-Status: Clean Cc: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9?=, freebsd-current@FreeBSD.org, Alan Cox , =?ISO-8859-1?Q?dron?= Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 01:22:40 -0000 On 07/08/12 13:56, Alan Cox wrote: > > >> In r237513 on 6/23 I made a mistake that was corrected in r238124 on 7/5. >> I can vaguely see a connection between kern.ipc.shm_use_phys and the >> problem fixed in r238124. So, I'd like to know if this problem still >> exists. Wait, however, until you see Kostik commit a change to >> vm_pageout.c, before you update your system. > > I booted r238261 with kern.ipc.shm_use_phys=1 and the problem seems to have disappeared. Thanks! Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:01:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8D28106564A for ; Mon, 9 Jul 2012 02:01:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE398FC08 for ; Mon, 9 Jul 2012 02:01:08 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q69217Ku054020; Sun, 8 Jul 2012 19:01:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q69217tv054019; Sun, 8 Jul 2012 19:01:07 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 19:01:07 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120709020107.GA53977@troutmask.apl.washington.edu> References: <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFA25EA.5090705@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 02:01:08 -0000 On Sun, Jul 08, 2012 at 07:29:30PM -0500, Stephen Montgomery-Smith wrote: > On 07/08/2012 06:58 PM, Steve Kargl wrote: > >On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote: > > >>So do people really work hard to get that last drop of ulp out of their > >>calculations? > > > >I know very few scientist who work hard to reduce the ULP. Most > >have little understanding of floating point. > > > >> Would a ulp=10 be considered unacceptable? > > > >Yes, it is unacceptable for the math library. Remember ULPs > >propagate and can quickly grow if the initial ulp for a > >result is large. > > OK. But suppose I wanted ld80 precision. What would be the advantage > of using an ld80 expl function with a ulp of 1 over an ld128 expl > function with a ulp of 10? The error propagation in the latter case > could not be worse than the error propagation in the latter case. Well, on the most popular hardware (that being i386/amd64), ld80 will use hardware fp instruction while ld128 must be done completely in software. The speed difference is significant. > In other words, if I were asked to write a super-fantastic expl > function, where run time was not a problem, I would use mpfr, use > Taylor's series with a floating point precision that had way more digits > than I needed, and then just truncate away the last digits when > returning the answer. And this would be guaranteed to give the correct > answer to just above 0.5 ulp (which I assume is best possible). It's more like 1 ULP after truncation (, which isn't truncation but rounding). The problem is run-time that 'run-time is the problem'. Try writing a expl() and simply use mpfr_exp() with 64-bit precision. If you're doing any serious simulation where exp() will be evaluate millions or billions of time, you'll notice the difference. > The only way I can see ULP errors greatly propagating is if one is > performing iteration type calculations (like f(f(f(f(x))))). Have you read Goldberg's paper? Not to mention, I've seen way too many examples of 'x - y' where cancellation of significant digits causes problems. Throw in rather poor estimates of function results with real poor ULP and you have problems. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:07:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E561065670 for ; Mon, 9 Jul 2012 02:07:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 922B98FC0A for ; Mon, 9 Jul 2012 02:07:57 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19700679pbb.13 for ; Sun, 08 Jul 2012 19:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Qvwq/c+hjCJyYlYmS5vgdJVoqX3YK0aM5QlBryKHhCw=; b=pe0NomKb/soDPI+1OY7edNP6P73RPD6xuHPXAMmMoXMxs9VH77C4dky15kT9Cgy5AM AMqbMxQ8aoYXwTF5lKEG0BK4oiGgxwTkhWh+I+QJ8B6BHNWb8AZpsgMzJHHqS8XyQJwm wczlK0MU6ExiWigElWBA+oe7+7ac039soU2F+QN8HrA+T2MTNmRI9juBxmUPMgNMYVen nO3JUGRx8WLgqf0xguODv4nMv0a/TNNECsA9SisZGPb4hvXtUMIQH3YjP5Oyq5+h+wNs c3MIpFQmvoHzFVkS1s3+PUHNHTB/53fKaA1n/lV3wY07GhmCI1J4JFp6uVjbMo/yyOdc DGUQ== Received: by 10.68.236.129 with SMTP id uu1mr56103384pbc.77.1341799677392; Sun, 08 Jul 2012 19:07:57 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id or5sm7285160pbb.44.2012.07.08.19.07.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 19:07:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 20:07:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmSP+KlXs6eluMAbSZsBDcXEbNToQN1SNMfS7YEuXJmHsBt4Dov0C4p2gHVPj9lA+PK2x3s Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 02:07:58 -0000 On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: > Ok, yet another Newbus' limitation. Assuming a device exports more > than one interface, and one of its child has need to use more than one > interface, each interfaces cannot register, concurrently, its own > ivar. While I try to always have a single child per > interface/resource, I need to keep some compatibility with the old way > of doing thing (POLA wrt. drivers I cannot/will not convert and > userland). So, it would have been nice if ivar had been per-interface, > not global and unique to one device. There's one pointer for the ivars. The bus code gets to determine what = the ivar looks like, because the interface is totally private to the = bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. So I'm not sure I understand what you are saying here. The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: enum pci_device_ivars { PCI_IVAR_SUBVENDOR, PCI_IVAR_SUBDEVICE, PCI_IVAR_VENDOR, .... }; We could easily reserve the upper 16-bits of this field to be that key. = This value could then be used to differentiate them. But this wouldn't = scale too well. Given that there's only about a dozen or two in the = tree, that's right at the moment, it wouldn't be hard to do something = like: enum ivar_namespace { IVAR_PCI =3D 1, IVAR_PCCARD, IVAR_USB, etc }; #define IVAR_SHIFT 16 and the above could be changed to: enum pci_device_ivars { PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, PCI_IVAR_SUBDEVICE, PCI_IVAR_VENDOR, .... }; and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. > Unless I am mistaken, ivar are the only way for a parent can transmit > information to a child. I can not simply implement a new METHOD to get > that ivar as the device implements multiple time the same function > (actually, up to 4 time for one, 3 for the other, with possible > crossovers...), each one physically distinct. Each child is being tied > to a pair. Thus, I need to pass each child discriminator(s) for each > interfaces right after having been *created*, which cannot be done > later on. Of course, it is out-of-question to have crossover in the > interfaces definitions. ivars are but one way to communicate this. However, they are the = generic way to convert a key to a value and store a key on a value. I = don't really understand what you are trying to say here, perhaps an = example would help illustrate what you are trying to do, since I don't = quite understand the problem here. > The best way I could achieve this currently is to pass the child's > device to its parent, and do a lookup based on that pointer to get > information I need, but erk.... That doesn't make any sense. The child's parent already sets that = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. Warner= From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:06:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A3AF106564A for ; Mon, 9 Jul 2012 02:06:06 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42A878FC17 for ; Mon, 9 Jul 2012 02:06:06 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19698313pbb.13 for ; Sun, 08 Jul 2012 19:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Nc0kQc1SrqvB8abUx3tL+jlIPvqeUlvqWX78CDdVGgs=; b=lowp5VjNRT3aMvFTVrYEDNBjxv9AJlMPrP5jqFautcekyaimAi8F6lLXBIYETrx3LR TbgS03IuD9vR6n96LbX2mBUmMkiumvg7VAxS5I4oU4/cMh5PhaQHAiT+aP/nJ1nPWlnu CnbOMHuG9SxnagcwndAd3hOgtFBaqmKwaBgHjBbeJZTOp7hxYjLeCmdfEtimfktKbgHn OteI/RBK6yMUhmZVYDA8grDJEe+J7F8iOiuNLgktAkqNhiVWfaz8ypFKSiv6qZ4Ph7jt AIJ85NH8KYXtc2yGIj5wZoVjS2ffc8IQ57QlgBlaLO5alIJdnBUe2jJbHdTFRMjkt5Fj TMHA== MIME-Version: 1.0 Received: by 10.68.195.97 with SMTP id id1mr56964500pbc.91.1341799565978; Sun, 08 Jul 2012 19:06:05 -0700 (PDT) Received: by 10.68.208.168 with HTTP; Sun, 8 Jul 2012 19:06:05 -0700 (PDT) Date: Mon, 9 Jul 2012 02:06:05 +0000 Message-ID: From: Matthew Fleming To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 09 Jul 2012 02:13:11 +0000 Subject: Build error on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:06:06 -0000 I'm getting a compile error during buildworld here: ===> libexec/atrun (all) cc -g -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/usr/data/sb/head/libexec/atrun/../../usr.bin/at -I/usr/data/sb/head/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/data/sb/head/libexec/atrun/atrun.c ${CTFCONVERT_CMD} expands to empty string cc -g -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/usr/data/sb/head/libexec/atrun/../../usr.bin/at -I/usr/data/sb/head/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/data/sb/head/libexec/atrun/gloadavg.c ${CTFCONVERT_CMD} expands to empty string cc -g -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/usr/data/sb/head/libexec/atrun/../../usr.bin/at -I/usr/data/sb/head/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil /usr/obj/usr/data/sb/head/tmp/usr/lib/libc.so: undefined reference to `log' *** [atrun] Error code 1 Stop in /usr/data/sb/head/libexec/atrun. *** [all] Error code 1 Stop in /usr/data/sb/head/libexec. *** [libexec.all__D] Error code 1 Stop in /usr/data/sb/head. *** [everything] Error code 1 Stop in /usr/data/sb/head. *** [buildworld] Error code 1 At first I thought maybe it was because of an old install (CURRENT as of December 2011) so I built and installed stable/9. That went off just fine. I thought it may be because my svn checkout of CURRENT got interrupted, so I re-extracted from scratch and see the same thing. I've also tried completely removing /usr/obj. I've build with no -j flag. Looking at the sources I don't see the symbol "log" in libc anywhere except as a DEBUG local variable that is only used in one file, always under DEBUG. The only thing I see that's of interested is the libexec.all__D target which I haven't yet grepped for to see what it is. My make.conf and src.conf are pretty sparse: root@:/data/sb/head # cat /etc/make.conf #LIBC_EXTRAMK=/usr/data/sb/ino64/tools/tools/shlib-compat/Makefile.sysfake CFLAGS=-g # added by use.perl 2011-09-17 07:04:17 PERL_VERSION=5.12.4 root@:/data/sb/head # cat /etc/src.conf #WITHOUT_CLANG=yes Clearly the tinderbox machines aren't hitting this, and I didn't see anything in the mailing list either. So it's almost certainly something on my end, but I'm at a loss as to what it could be. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:13:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A67F106564A for ; Mon, 9 Jul 2012 02:13:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 505DB8FC12 for ; Mon, 9 Jul 2012 02:13:27 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19707409pbb.13 for ; Sun, 08 Jul 2012 19:13:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MUlG0hCggpUMKt1VKaRoQI8d4weBB6+P9t7RvEq3Ooc=; b=apNW+NZjSecj2W1vzeFJDr1FAqTILpGoUgEL4Mshe7rbH0uhTcjigwKw6tAEhyTzC3 JXF39hYKz3xru5SDZp3k8l+YMkq+PHZ4Z8fKq7btGIPnXVbWLhYQYGscl0PnW48If9zS ksGdqlbco+mY5XqkJkfvqHmvRm+JK/aUX0D+NckMFuqNA+peOCZKymWIJ4TSEgJ/Z5gd Brin7JuFJe3l6PDiaxsFA0dgf20Dyf1ahjZvB7XnQPMW/+uAVG5S6qzvYe0S3zdp8Uz/ xgkkj1ss1qF124D0SCp+neh7c56gl0mDVNzgH6esLdJpwR8e4xTlKLsFHFaNbM4zo0OH Ue6Q== Received: by 10.68.225.231 with SMTP id rn7mr35483873pbc.13.1341800007140; Sun, 08 Jul 2012 19:13:27 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id pz9sm5116171pbb.61.2012.07.08.19.13.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 19:13:25 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120709020107.GA53977@troutmask.apl.washington.edu> Date: Sun, 8 Jul 2012 20:13:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmcxjBhrgNDb0XyxwcgLs0sWh6TtWcfe9J9/7j5RKH65rfgAPHQ/8OQFKN3odSd7SHkdG5+ Cc: Stephen Montgomery-Smith , freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 02:13:27 -0000 On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote: > Not to mention, I've seen way too many examples of 'x - y' > where cancellation of significant digits causes > problems. Throw in rather poor estimates of function > results with real poor ULP and you have problems. Are these problems significantly more or less than the usual #define I = talked about before? If the functions are so so, but much better than = the double version, we have a significant win, even if things aren't = perfect. If we weren't 13 past the publication date of the c99 standard, I'd be = more sympathetic to the 'we need a high quality implementation' = arguments. However, we can't let the perfect be the enemy of the good = here. We claim c99 conformance, yet don't have these functions.=20 After all, many of the original functions that were in our library had = sub-optimial performance which bruce optimized over many years. Why = can't we use this model here? Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:33:05 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E370106566C for ; Mon, 9 Jul 2012 02:33:05 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAA38FC16 for ; Mon, 9 Jul 2012 02:33:05 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:54188 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1So3mZ-0000rY-4D; Sun, 08 Jul 2012 22:33:03 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <2244ACD7-892A-4CA7-90B1-FFF41AF6B317@FreeBSD.org> Date: Sun, 8 Jul 2012 22:33:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49BAAAB5-BF68-43B3-8D7C-B4E49DE29ED3@neville-neil.com> References: <86hatodavd.wl%gnn@neville-neil.com> <1341340703.6639@da3m0n8t3r.com> <20120704194917.GA15426@misty.eyesbeyond.com> <2244ACD7-892A-4CA7-90B1-FFF41AF6B317@FreeBSD.org> To: Greg Lewis X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Waitman Gobble , current@FreeBSD.org Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 02:33:05 -0000 On Jul 5, 2012, at 10:38 , George Neville-Neil wrote: >=20 > On Jul 4, 2012, at 15:49 , Greg Lewis wrote: >=20 >> On Tue, Jul 03, 2012 at 11:38:23AM -0700, Waitman Gobble wrote: >>> gnn@freebsd.org wrote .. >>>> Howdy, >>>>=20 >>>> Can someone tell me if anyone is working on this Java NIO bug? >>>>=20 >>>> = http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thre= ad-bug-td4700530.html >>>>=20 >>>> I would like to avoid using Linux just to run Zookeeper: >>>>=20 >>>> = http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-= FreeBSD-td5208183.html >>>=20 >>> Hi George, >>>=20 >>> There is/was a patch from David Xu=20 >>> = http://lists.freebsd.org/pipermail/freebsd-java/2010-August/008747.html >>> maybe this fixes it?=20 >>=20 >> This patch was incorporated into the openjdk6 port soon after it was >> posted. However, I can still reproduce the problem. Using >> = -Djava.nio.channels.spi.SelectorProvider=3Dsun.nio.ch.KqueueSelectorProvid= er >> makes no difference. >>=20 >>> also looks like New I/O was updated in jdk7... but would have to = check it out to see if issue still exists.. >>=20 >> I can't reproduce the problem with the current openjdk7 port. I = haven't >> tried out Zookeeper though, so YMMV. I would say it's definitely = worth >> a try though. >>=20 >> I don't believe anyone is currently working on a fix for the openjdk6 = port >> for this. >=20 > I'm going to give zookeeper a try with openjdk7. >=20 > Thanks! >=20 A followup. zookeeper is now ported to Freebsd = (/usr/ports/devel/zookeeper) Best, George From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 02:39:17 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EDF55106566C for ; Mon, 9 Jul 2012 02:39:17 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 41184151ACA; Mon, 9 Jul 2012 02:39:17 +0000 (UTC) Message-ID: <4FFA4454.5070803@FreeBSD.org> Date: Sun, 08 Jul 2012 19:39:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Neville-Neil References: <86hatodavd.wl%gnn@neville-neil.com> <1341340703.6639@da3m0n8t3r.com> <20120704194917.GA15426@misty.eyesbeyond.com> <2244ACD7-892A-4CA7-90B1-FFF41AF6B317@FreeBSD.org> <49BAAAB5-BF68-43B3-8D7C-B4E49DE29ED3@neville-neil.com> In-Reply-To: <49BAAAB5-BF68-43B3-8D7C-B4E49DE29ED3@neville-neil.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Greg Lewis , Waitman Gobble , current@FreeBSD.org Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 02:39:18 -0000 On 07/08/2012 19:33, George Neville-Neil wrote: > A followup. zookeeper is now ported to Freebsd (/usr/ports/devel/zookeeper) George, did you see the PR and the followup from me regarding the port? -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:01:57 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85D4E1065672; Mon, 9 Jul 2012 03:01:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 53DDF8FC08; Mon, 9 Jul 2012 03:01:57 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:54753 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1So4EX-00047m-1V; Sun, 08 Jul 2012 23:01:57 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: <4FFA4454.5070803@FreeBSD.org> Date: Sun, 8 Jul 2012 23:01:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86hatodavd.wl%gnn@neville-neil.com> <1341340703.6639@da3m0n8t3r.com> <20120704194917.GA15426@misty.eyesbeyond.com> <2244ACD7-892A-4CA7-90B1-FFF41AF6B317@FreeBSD.org> <49BAAAB5-BF68-43B3-8D7C-B4E49DE29ED3@neville-neil.com> <4FFA4454.5070803@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Greg Lewis , Waitman Gobble , current@FreeBSD.org Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:01:57 -0000 On Jul 8, 2012, at 22:39 , Doug Barton wrote: > On 07/08/2012 19:33, George Neville-Neil wrote: >> A followup. zookeeper is now ported to Freebsd = (/usr/ports/devel/zookeeper) >=20 > George, did you see the PR and the followup from me regarding the = port? >=20 I got a mail from jgh@ but only today figured out what the PR was. I'll look at the patches from him tomorrow. Best, George From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:05:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51FC61065676 for ; Mon, 9 Jul 2012 03:05:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 22A408FC0A for ; Mon, 9 Jul 2012 03:05:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q693545I054256; Sun, 8 Jul 2012 20:05:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q69354cJ054255; Sun, 8 Jul 2012 20:05:04 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 20:05:04 -0700 From: Steve Kargl To: Warner Losh Message-ID: <20120709030504.GA54131@troutmask.apl.washington.edu> References: <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@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.4.2.3i Cc: Stephen Montgomery-Smith , freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:05:05 -0000 On Sun, Jul 08, 2012 at 08:13:21PM -0600, Warner Losh wrote: > > On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote: > > Not to mention, I've seen way too many examples of 'x - y' > > where cancellation of significant digits causes > > problems. Throw in rather poor estimates of function > > results with real poor ULP and you have problems. > > Are these problems significantly more or less than the > usual #define I talked about before? If the functions > are so so, but much better than the double version, we > have a significant win, even if things aren't perfect. The answer is more complicated than the question asked. On i386, the precision of long double and double is 53 bits. On amd64, the precision of long double and double are 64 and 53 bits. On i386 and amd64, emax and emin are 1024 and -1023 (could be off by one here) for double and 16384 and -16383 for long double. Now, consider 2**emin <= exp(x) <= 2**emax for some set of x (where I'm using the Fortran exponential operator ** instead of powl(2,{emin|emax}) because FreeBSD does not have a powl()). The sets for long double and double are significantly different. > If we weren't 13 past the publication date of the c99 standard, > I'd be more sympathetic to the 'we need a high quality > implementation' arguments. However, we can't let the perfect > be the enemy of the good here. We claim c99 conformance, yet > don't have these functions. AFAIK, neither gcc in base nor clang would be c99 complaint even if all of the c99 math functions were available. > After all, many of the original functions that were in our > library had sub-optimial performance which bruce optimized > over many years. Why can't we use this model here? I think the fear is that committing sub-optimal code would take many many more years to fix. AFAICT, bde longer commits code to src/ (since the switch from cvs to svn), and he depends on his code reviews to get things fixed. With das and me both having little to no time for FreeBSD, that leaves no one to review/commit his suggested fixes (not that I would question bde's opinion on a code change). -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:26:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2721065677; Mon, 9 Jul 2012 03:26:01 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4902A8FC0A; Mon, 9 Jul 2012 03:26:01 +0000 (UTC) Received: by werp13 with SMTP id p13so7439734wer.13 for ; Sun, 08 Jul 2012 20:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fJ27icMVKEL0eJOZFIhObd1y0nbMis9Ks6oAQn0CXPU=; b=SKycEEWZ9rbahqOE6ou1VDv92MdwoBPXCIuYki65u3IJaCcmGmmWGqoWwcy13I10PN pUpvCIv0qC49C5ruZP7P82dcczcv6mlMfwUZ9D+RkUadFvhmPLMFHQtnOCf/bQla8aKP grpSKcIp9Wun8Hh3VnxgOPp7nsDgMiCdriXCuN+OycYo8mq9W9I3NPnkS08f5AnWW7Uc Yo2hqmkpCgd9E1RNjFrqPJ5/hKIONIq8POJIv0jSPT1V2agXJl3APbBk4Og06ps5pBIx rm1ynOeA1IXvQ2vTdJQjPvgQqEjjFGGSo4Tr44LBYD1rsUnYy8iKknDDj3Ji68p6m0X3 DH6w== MIME-Version: 1.0 Received: by 10.180.86.106 with SMTP id o10mr25853106wiz.22.1341804360296; Sun, 08 Jul 2012 20:26:00 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:26:00 -0700 (PDT) In-Reply-To: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> Date: Sun, 8 Jul 2012 23:26:00 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:26:02 -0000 Hi, On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: > > On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >> Ok, yet another Newbus' limitation. Assuming a device exports more >> than one interface, and one of its child has need to use more than one >> interface, each interfaces cannot register, concurrently, its own >> ivar. While I try to always have a single child per >> interface/resource, I need to keep some compatibility with the old way >> of doing thing (POLA wrt. drivers I cannot/will not convert and >> userland). So, it would have been nice if ivar had been per-interface, >> not global and unique to one device. > > There's one pointer for the ivars. The bus code gets to determine what t= he ivar looks like, because the interface is totally private to the bus. S= o long as it returns the right thing for any key that's presented, it doesn= 't matter quite how things are done. > > So I'm not sure I understand what you are saying here. > dev0 implements two interfaces: A and B. dev1, child of dev0, needs to use both interfaces. There is no generic way for dev0 to export independent ivars for both interface. For now, I restricted the function of the second interface not to need ivar, but that's kind of hackish. - Arnaud > The problem, more basically, is that the ivar keys are not unique. Curre= ntly, there's no bits used in the key to define the values to be non-overla= pping. For example: > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > We could easily reserve the upper 16-bits of this field to be that key. = This value could then be used to differentiate them. But this wouldn't sca= le too well. Given that there's only about a dozen or two in the tree, tha= t's right at the moment, it wouldn't be hard to do something like: > > enum ivar_namespace { > IVAR_PCI =3D 1, > IVAR_PCCARD, > IVAR_USB, > etc > }; > #define IVAR_SHIFT 16 > > and the above could be changed to: > > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > and then we'd have an unambiguous key, and the bus could easily implement= multiple interfaces. > > but then again, most of the existing interfaces in the kernel are mutuall= y exclusive, so you could implement this just for your new interfaces. > >> Unless I am mistaken, ivar are the only way for a parent can transmit >> information to a child. I can not simply implement a new METHOD to get >> that ivar as the device implements multiple time the same function >> (actually, up to 4 time for one, 3 for the other, with possible >> crossovers...), each one physically distinct. Each child is being tied >> to a pair. Thus, I need to pass each child discriminator(s) for each >> interfaces right after having been *created*, which cannot be done >> later on. Of course, it is out-of-question to have crossover in the >> interfaces definitions. > > ivars are but one way to communicate this. However, they are the generic= way to convert a key to a value and store a key on a value. I don't reall= y understand what you are trying to say here, perhaps an example would help= illustrate what you are trying to do, since I don't quite understand the p= roblem here. > >> The best way I could achieve this currently is to pass the child's >> device to its parent, and do a lookup based on that pointer to get >> information I need, but erk.... > > That doesn't make any sense. The child's parent already sets that child'= s ivar when the child is created. The child's parent already gets a pointe= r to the child when asked to do the key to value translation. Again, perha= ps an example would help here. > > Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:31:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E41521065673 for ; Mon, 9 Jul 2012 03:31:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD29B8FC1E for ; Mon, 9 Jul 2012 03:31:46 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19804940pbb.13 for ; Sun, 08 Jul 2012 20:31:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=s0Nw9VUfRbX8IqJVyeJxrQ2ZD0MN1pqek1LCN5jPloU=; b=F4eCDDTxhNJq57pW83gJVpuA/y8iu+NsTaEKWeJ/ydOi06O4C2qivfW7m1vKPbLS0B ljjDG/Ehr0USILwnpfF9y4W4RVxn7LET+VAgwy962SStkCNsjB68GfVk3N3JHGFIbF3Z 7z3ipsGuS6KCpZIu+pjIHKolT64XZRdcm7u+rFhgfe6Ul//kCgY+0dL5OXHxW/WMEzc9 DOKa1CKFGvk0BmFLjZj2vk3m2KxIDVaQ/0TeSG/btvlZ8YnX4uwJELre2POJHf795c26 vVsHjzJ4+q4iLL+gYwmmroGoplCJvlD3idqTJI8W1RansrmL3EBParm+OGxWFq29MZEO Rleg== Received: by 10.68.132.166 with SMTP id ov6mr57538341pbb.24.1341804706256; Sun, 08 Jul 2012 20:31:46 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id pc6sm17677069pbc.47.2012.07.08.20.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 20:31:45 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 21:31:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlE5BDVwpHRnFFJGgxXtUw2Q6mVCTgau30S4d7VLcEaNUMTmXTkw2AO0IyJZFpL2ZsMADeQ Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:31:47 -0000 On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>> Ok, yet another Newbus' limitation. Assuming a device exports more >>> than one interface, and one of its child has need to use more than = one >>> interface, each interfaces cannot register, concurrently, its own >>> ivar. While I try to always have a single child per >>> interface/resource, I need to keep some compatibility with the old = way >>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>> userland). So, it would have been nice if ivar had been = per-interface, >>> not global and unique to one device. >>=20 >> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>=20 >> So I'm not sure I understand what you are saying here. >>=20 > dev0 implements two interfaces: A and B. dev1, child of dev0, needs to > use both interfaces. There is no generic way for dev0 to export > independent ivars for both interface. For now, I restricted the > function of the second interface not to need ivar, but that's kind of > hackish. Only if the IVARs for interface A and interface B have overlapping = values. If the Ivar keys don't overlap, then there's no problems at = all. Certainly less hackish than not using them at all. Since dev0 = knows the layout of the ivar that it set on its child, this presents no = problems at all. It would return the values from A from the right part = of the ivar, and those from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. Warner > - Arnaud >=20 >> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>=20 >> enum ivar_namespace { >> IVAR_PCI =3D 1, >> IVAR_PCCARD, >> IVAR_USB, >> etc >> }; >> #define IVAR_SHIFT 16 >>=20 >> and the above could be changed to: >>=20 >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>=20 >> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>=20 >>> Unless I am mistaken, ivar are the only way for a parent can = transmit >>> information to a child. I can not simply implement a new METHOD to = get >>> that ivar as the device implements multiple time the same function >>> (actually, up to 4 time for one, 3 for the other, with possible >>> crossovers...), each one physically distinct. Each child is being = tied >>> to a pair. Thus, I need to pass each child discriminator(s) for each >>> interfaces right after having been *created*, which cannot be done >>> later on. Of course, it is out-of-question to have crossover in the >>> interfaces definitions. >>=20 >> ivars are but one way to communicate this. However, they are the = generic way to convert a key to a value and store a key on a value. I = don't really understand what you are trying to say here, perhaps an = example would help illustrate what you are trying to do, since I don't = quite understand the problem here. >>=20 >>> The best way I could achieve this currently is to pass the child's >>> device to its parent, and do a lookup based on that pointer to get >>> information I need, but erk.... >>=20 >> That doesn't make any sense. The child's parent already sets that = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. >>=20 >> Warner From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:41:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82C46106566C for ; Mon, 9 Jul 2012 03:41:46 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 534178FC14 for ; Mon, 9 Jul 2012 03:41:46 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q693fhiA028963; Sun, 8 Jul 2012 22:41:45 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4FFA52F8.2080700@missouri.edu> Date: Sun, 08 Jul 2012 22:41:44 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> In-Reply-To: <20120709020107.GA53977@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:41:46 -0000 On 07/08/2012 09:01 PM, Steve Kargl wrote: > Have you read Goldberg's paper? I must admit that I had not. I found it at: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html > Not to mention, I've seen way too many examples of 'x - y' > where cancellation of significant digits causes > problems. Throw in rather poor estimates of function > results with real poor ULP and you have problems. I think that if a program includes "x-y" where cancellation causes huge loss of digits, then the program should be considered highly flawed. The programmer might get lucky, and a few extra ULP might save his skin, but it would be better if the program catastrophically failed so that he would realize they need to do something smarter. I got my first scientific calculator around 1975, and I remember my surprise when I discovered that (1/3)*3-1 on my calculator did not produce zero. Years later I bought another calculator, and imagine my further surprise when (1/3)*3-1 did produce zero. They must have done something very smart, I thought. The problem is, these kinds of tricks can only help you so much. Calculations like arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)))))))))-x are probably not going to be correct no matter how smart the programmer is. The paper by Goldberg has some really nice stuff. I teach a class on numerical methods. One example I present is the problem using equation (4) of Goldberg's paper to solve quadratic equations. I tell them that the smart thing to do is to use equation (4) or equation (5) depending on whether b has the same sign as sqrt(b^2-4ac). This is a very good illustration of how to overcome the "x-y" problem, and in my opinion it has to be understood by the programmer, not the writer of the square-root package. Trying to compensate by getting that lost drop of ULP out of square root is looking in the wrong direction. But there is other stuff in his paper I don't like, and it comes across as nit-picking rather than really thinking through why he wants the extra accuracy. I feel like he is saving the pennies, but losing the dollars. For example, computing the quadratic formula when b^2 and 4ac are roughly equal (discussed in his proof of Theorem 4). He says that roughly half the digits of the final answer will be contaminated. He recommends performing the calculation with double the precision, and then retaining what is left. The reason I don't like his solution is this. The contamination of half the digits is real, not some artifact of the computing method. Unless you know EXACTLY what a, b and c are, only half the digits of the quadratic formula are valid, no matter how you calculate it. For example, maybe a is calculated by some other part of the program as 1/3. Since 1/3 cannot be represented exactly in base 2, it will not be exactly 1/3. That part of the program doesn't know that this number is going to be used later on in the quadratic formula, so it computes it in single precision. Now the quadratic formula algorithm converts a to double precision. But a will still be 1/3 to single precision. The only way to avoid this error is to perform EVERY pertinent calculation prior to the use of quadratic formula in double precision. (And suppose instead the data comes from a scientific experiment - the programmer needs to be performing an error analysis, not hoping his implementation of quadratic formula is performed in double precision.) Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). There are two reasons why I might compute large sums. One is accounting, when I better be using high enough precision that the arithmetic is exact. The other is something like numerical integration. But in the latter case, unless the summands have a very special form, it is likely that each summand will only be accurate to within e. Thus the true sum is only known to within n*e, and so the naive method really hasn't lost any precision at all. And typically n*e will be so small compared to the true answer that it won't matter. If it does matter, the problem is that n is too big. The algorithm will take decades to run. Focus efforts on producing a different numerical integration method, instead of getting that lost drop of ULP. I cannot envision any non-contrived circumstance where the Kahan summation formula is going to give an answer that is significantly more reliable than naive summation. I can envision a circumstance when the reduction in speed of the Kahan summation formula over naive summation could be significant. I think the example I like best that illustrates floating point errors is inverting badly conditioned matrices. And any scientist who works with large matrices had better know what ill-conditioned means. The proper answer is that if your matrix is ill-conditioned, give up. You need to look at the problem where your matrix came from, and rethink how you concert it into a matrix problem, so that the matrix is not ill-conditioned. Chasing that last drop of ULP simply will not help one iota. Stephen From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:46:53 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73DB5106564A; Mon, 9 Jul 2012 03:46:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8E798FC0A; Mon, 9 Jul 2012 03:46:52 +0000 (UTC) Received: by werp13 with SMTP id p13so7447212wer.13 for ; Sun, 08 Jul 2012 20:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ALLlTh0eWvI4aHxdoIL83Z53L3zNOWvCsKlEW9UR30U=; b=fHSfS0XlH/2vRaCiEWmLtt5yBn/7SV26JYFLU4AAgEPf1gwS0m2ur4hN/pizZB162/ yCvFhK5jp8qdlUBESZj6Ljjs0FeSqkk/oxS8cjJS05pua3NjX8e+OsvyqsUe3RLc1HV8 DJgAZkEAwLdzgBIKEvQNzhyQvFUvqWsZAAWK3CZc/l2DecgI+wJyBzlYbdJCVDWd/J/H t4TIgtAtHAwXy15N577TBa/7wIkQ/v9dtywJ/e6QrsdD0Z6SxEDpmHnSzDEPC7jRCJ9w z3Gyp0zuf3AejNvEC4o2bvfK/HtjS1cAl0RLbDJ+x5XLm0UxIrAMv6ZS3OOEDjVcMcmH oeFQ== MIME-Version: 1.0 Received: by 10.217.3.209 with SMTP id r59mr14189629wes.108.1341805611796; Sun, 08 Jul 2012 20:46:51 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:46:51 -0700 (PDT) In-Reply-To: <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> Date: Sun, 8 Jul 2012 23:46:51 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:46:53 -0000 On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: > > On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>> >>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>> than one interface, and one of its child has need to use more than one >>>> interface, each interfaces cannot register, concurrently, its own >>>> ivar. While I try to always have a single child per >>>> interface/resource, I need to keep some compatibility with the old way >>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>> userland). So, it would have been nice if ivar had been per-interface, >>>> not global and unique to one device. >>> >>> There's one pointer for the ivars. The bus code gets to determine what= the ivar looks like, because the interface is totally private to the bus. = So long as it returns the right thing for any key that's presented, it doe= sn't matter quite how things are done. >>> >>> So I'm not sure I understand what you are saying here. >>> >> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >> use both interfaces. There is no generic way for dev0 to export >> independent ivars for both interface. For now, I restricted the >> function of the second interface not to need ivar, but that's kind of >> hackish. > > Only if the IVARs for interface A and interface B have overlapping values= . If the Ivar keys don't overlap, then there's no problems at all. Certai= nly less hackish than not using them at all. Since dev0 knows the layout o= f the ivar that it set on its child, this presents no problems at all. It = would return the values from A from the right part of the ivar, and those f= rom B in the right part. Apart from the coordination of Ivar numbers, as I= outlined in my last post, there's no issue here. > I think we should not be talking about the same API here. I have no idea what you mean by "the key to value translation", nor "Ivar numbers". What I refer to is that device_set_ivars() / device_get_ivars() acts on a single instance variables from `struct device': `ivars'. In that case, I do not really see how to set that specific field to two distinct values for each interfaces. - Arnaud > Warner > >> - Arnaud >> >>> The problem, more basically, is that the ivar keys are not unique. Cur= rently, there's no bits used in the key to define the values to be non-over= lapping. For example: >>> enum pci_device_ivars { >>> PCI_IVAR_SUBVENDOR, >>> PCI_IVAR_SUBDEVICE, >>> PCI_IVAR_VENDOR, >>> .... >>> }; >>> >>> We could easily reserve the upper 16-bits of this field to be that key.= This value could then be used to differentiate them. But this wouldn't s= cale too well. Given that there's only about a dozen or two in the tree, t= hat's right at the moment, it wouldn't be hard to do something like: >>> >>> enum ivar_namespace { >>> IVAR_PCI =3D 1, >>> IVAR_PCCARD, >>> IVAR_USB, >>> etc >>> }; >>> #define IVAR_SHIFT 16 >>> >>> and the above could be changed to: >>> >>> enum pci_device_ivars { >>> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >>> PCI_IVAR_SUBDEVICE, >>> PCI_IVAR_VENDOR, >>> .... >>> }; >>> >>> and then we'd have an unambiguous key, and the bus could easily impleme= nt multiple interfaces. >>> >>> but then again, most of the existing interfaces in the kernel are mutua= lly exclusive, so you could implement this just for your new interfaces. >>> >>>> Unless I am mistaken, ivar are the only way for a parent can transmit >>>> information to a child. I can not simply implement a new METHOD to get >>>> that ivar as the device implements multiple time the same function >>>> (actually, up to 4 time for one, 3 for the other, with possible >>>> crossovers...), each one physically distinct. Each child is being tied >>>> to a pair. Thus, I need to pass each child discriminator(s) for each >>>> interfaces right after having been *created*, which cannot be done >>>> later on. Of course, it is out-of-question to have crossover in the >>>> interfaces definitions. >>> >>> ivars are but one way to communicate this. However, they are the gener= ic way to convert a key to a value and store a key on a value. I don't rea= lly understand what you are trying to say here, perhaps an example would he= lp illustrate what you are trying to do, since I don't quite understand the= problem here. >>> >>>> The best way I could achieve this currently is to pass the child's >>>> device to its parent, and do a lookup based on that pointer to get >>>> information I need, but erk.... >>> >>> That doesn't make any sense. The child's parent already sets that chil= d's ivar when the child is created. The child's parent already gets a poin= ter to the child when asked to do the key to value translation. Again, per= haps an example would help here. >>> >>> Warner > From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 03:59:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F311F1065670; Mon, 9 Jul 2012 03:59:12 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 616F68FC12; Mon, 9 Jul 2012 03:59:12 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so2289693wib.1 for ; Sun, 08 Jul 2012 20:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vuTa1iouTc9jB8ljAgnrc1sQ5y9CsDgdP2qoGAZPbw4=; b=vYSVByUD6emmo1ZGwNsWVHmynuv08ZoMhTIIrWBpgnXe5MN/VbCc5hXgCTMhfVdfqX pgUrv+lF5UU/pvBeftfsKtFkvx3+jTZHMzvnnnZDb8B77S12FPWZVKgOoOKkwLra160F Dqg1woO2HQiOmc+b8gkLckR2qYveagtcxlpIdNL32DKxrL7jhK2kehxvZAr87+xPa4Nn dCcmr5pzEu1YBANokMCT81+QD3FUF8txTmOdpXVAXtvdu4A7e5RFamlLXdu8cEl9jRG/ QWQskxgwGccVsu4wXHNpNLFlLyMgV85eF5gJmyYfYdXebRsBnxX74xpkHuSyIes/B22W YzXg== MIME-Version: 1.0 Received: by 10.180.14.34 with SMTP id m2mr26009127wic.22.1341806345314; Sun, 08 Jul 2012 20:59:05 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 20:59:05 -0700 (PDT) In-Reply-To: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> Date: Sun, 8 Jul 2012 23:59:05 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 03:59:13 -0000 Hi, On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: > > On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >> Ok, yet another Newbus' limitation. Assuming a device exports more >> than one interface, and one of its child has need to use more than one >> interface, each interfaces cannot register, concurrently, its own >> ivar. While I try to always have a single child per >> interface/resource, I need to keep some compatibility with the old way >> of doing thing (POLA wrt. drivers I cannot/will not convert and >> userland). So, it would have been nice if ivar had been per-interface, >> not global and unique to one device. > > There's one pointer for the ivars. The bus code gets to determine what t= he ivar looks like, because the interface is totally private to the bus. S= o long as it returns the right thing for any key that's presented, it doesn= 't matter quite how things are done. > > So I'm not sure I understand what you are saying here. > > The problem, more basically, is that the ivar keys are not unique. Curre= ntly, there's no bits used in the key to define the values to be non-overla= pping. For example: > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > We could easily reserve the upper 16-bits of this field to be that key. = This value could then be used to differentiate them. But this wouldn't sca= le too well. Given that there's only about a dozen or two in the tree, tha= t's right at the moment, it wouldn't be hard to do something like: > > enum ivar_namespace { > IVAR_PCI =3D 1, > IVAR_PCCARD, > IVAR_USB, > etc > }; > #define IVAR_SHIFT 16 > > and the above could be changed to: > > enum pci_device_ivars { > PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, > PCI_IVAR_SUBDEVICE, > PCI_IVAR_VENDOR, > .... > }; > > and then we'd have an unambiguous key, and the bus could easily implement= multiple interfaces. > > but then again, most of the existing interfaces in the kernel are mutuall= y exclusive, so you could implement this just for your new interfaces. > ok, I think I got it now. You and I are exactly saying the same thing, just in different terms; there is no way to currently specify multiple independent (/overlapping) ivars in a child... - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 04:15:45 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 997B5106566B for ; Mon, 9 Jul 2012 04:15:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D437814E3B9; Mon, 9 Jul 2012 04:15:44 +0000 (UTC) Message-ID: <4FFA5AF0.607@FreeBSD.org> Date: Sun, 08 Jul 2012 21:15:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120624 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Neville-Neil References: <86hatodavd.wl%gnn@neville-neil.com> <1341340703.6639@da3m0n8t3r.com> <20120704194917.GA15426@misty.eyesbeyond.com> <2244ACD7-892A-4CA7-90B1-FFF41AF6B317@FreeBSD.org> <49BAAAB5-BF68-43B3-8D7C-B4E49DE29ED3@neville-neil.com> <4FFA4454.5070803@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Greg Lewis , Waitman Gobble , current@FreeBSD.org Subject: Re: Java and NIO? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 04:15:45 -0000 On 07/08/2012 20:01, George Neville-Neil wrote: > > On Jul 8, 2012, at 22:39 , Doug Barton wrote: > >> On 07/08/2012 19:33, George Neville-Neil wrote: >>> A followup. zookeeper is now ported to Freebsd (/usr/ports/devel/zookeeper) >> >> George, did you see the PR and the followup from me regarding the port? >> > > I got a mail from jgh@ but only today figured out what the PR was. Are you not getting your gnn@FreeBSD.org mail? > I'll look at the patches from him tomorrow. I copied the text from my message below for your convenience. > http://www.freebsd.org/cgi/query-pr.cgi?pr=169693 Furthermore the rc.d script is a mess, and should not have been committed like it was (numerous missing bits, bad format, set_rcvar, hard-coded /usr/local, no REQUIRE, no KEYWORD: shutdown, etc.). Please read http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html and then ask in freebsd-rc@ if you have any additional questions. Sorry to be so blunt, but I'm really, really tired of repeating the same stuff over and over again, and this script is really a mess. Also, don't install the script in do-install, see the web page above (and/or the PR) for USE_RC_SUBR. And FYI, there is no need to have the function in that script. You could use (for example) start_cmd="$command start" just as well. Not to mention that the function you have should be using $1 as the argument to $command, not $rc_arg. Reasons why left as an exercise for the reader ... Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 04:37:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4F0F1065672 for ; Mon, 9 Jul 2012 04:37:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF1B8FC0C for ; Mon, 9 Jul 2012 04:37:12 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so19888467pbb.13 for ; Sun, 08 Jul 2012 21:37:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jojy+TpzE3UZwtEJ/jX0QxlF/++XKd4pwlt2h/66jqk=; b=hxW372d1h1U1/pp3Zv29/lShZ0OQQHNqlg66RXYeT55UfObYn3qcXls7HyuuD8f6hQ wk0aAPEWQzt/cQZgvWtQBguOj+DZrI2V4z0WgDwa9zdhAZMiuKF6kQk0Gakk0CLYVQQs bwd0U/iBA9jKBdVfTU1bLCzg9kMfGKrflHbm3AqqNQubHieZ654SVxtLLUUiFjIrjSD3 lLA2zYFfJeT0rcFd31/OrIuVT+EXsPCM3yZHVatUQWpQI9LKzV60pXM7LgEAOtfQFFTH Mo8XhrwAVXf4iCS1K2SpBaQPPMtYO1I4DuRBvJBX791WReyy6yefnJ1dROxp/4UHWzVn WsfQ== Received: by 10.68.232.197 with SMTP id tq5mr56266726pbc.53.1341808631827; Sun, 08 Jul 2012 21:37:11 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id nj4sm12980987pbc.5.2012.07.08.21.37.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 21:37:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 22:37:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnMAy24EbjLUkDsBRFBVEVvFEug91mt4OBr1NnH/ttVDuZMiS3J50Op+qtsvpo8i+87F3DB Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 04:37:12 -0000 On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: > On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>=20 >>> Hi, >>>=20 >>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>>>=20 >>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>> than one interface, and one of its child has need to use more than = one >>>>> interface, each interfaces cannot register, concurrently, its own >>>>> ivar. While I try to always have a single child per >>>>> interface/resource, I need to keep some compatibility with the old = way >>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>> userland). So, it would have been nice if ivar had been = per-interface, >>>>> not global and unique to one device. >>>>=20 >>>> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>>>=20 >>>> So I'm not sure I understand what you are saying here. >>>>=20 >>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs = to >>> use both interfaces. There is no generic way for dev0 to export >>> independent ivars for both interface. For now, I restricted the >>> function of the second interface not to need ivar, but that's kind = of >>> hackish. >>=20 >> Only if the IVARs for interface A and interface B have overlapping = values. If the Ivar keys don't overlap, then there's no problems at = all. Certainly less hackish than not using them at all. Since dev0 = knows the layout of the ivar that it set on its child, this presents no = problems at all. It would return the values from A from the right part = of the ivar, and those from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. >>=20 > I think we should not be talking about the same API here. I have no > idea what you mean by "the key to value translation", nor "Ivar > numbers". What I refer to is that device_set_ivars() / > device_get_ivars() acts on a single instance variables from `struct > device': `ivars'. In that case, I do not really see how to set that > specific field to two distinct values for each interfaces. We are talking about the ivar interface. You are just misunderstanding = how it is used. Let us say that dev0 wants to implement interface A and B. The = interface it implements is the device_read _ivar method. That method = looks like: int pci_read_ivar(device_t dev, device_t child, int which, uintptr_t = *result) { struct pci_ivar *iv =3D device_get_ivar(child); switch (which) { case PCI_IVAR_SUBVENDOR: *result =3D iv->subvendor; break; ... default: return EINVAL; } return 0; } So, if you wanted to implement interface A and interface B, you would = have to support reading and writing A_IVAR_* and B_IVAR_*. The above = routine would look like: struct mydev_ivar { int a_1; int a_2; int b_1; int b_2; }; int mydev_read_ivar(device_t dev, device child, int which, uintpr_t = *result) { struct mydev_ivar *iv =3D device_get_ivar(child); switch (which) { case A_IVAR_1: *result =3D iv->a_1; break; case A_IVAR_2: *result =3D iv->a_2; break; case B_IVAR_1: *result =3D iv->b_1; break; case B_IVAR_2: *result =3D iv->b_2; break; default: return EINVAL; } return 0; } and similar for the write routine. Now, there are some busses that = provide convenience structures and functions for dealing with the ivars. = In that case, you'd be able to use the wrapper structures and routines = like so: struct mdev_ivar { struct a_ivar a; struct b_ivar b; }; int mydev_read_ivar(device_t dev, device child, int which, uintpr_t = *result) { struct mydev_ivar *iv =3D device_get_ivar(child); switch (which) { case A_IVAR_1: case A_IVAR_2: return a_helper_read_ivar(&iv->a, which, result); case B_IVAR_1: case B_IVAR_2: return b_helper_read_ivar(&iv->b, which, result); default: return EINVAL; } return 0; } Both of these work only if the A_IVAR values are disjoint from the = B_IVAR values. Your mydev device is the one that sets the ivar on dev1, = in your example, so it would know how to malloc and create the = mydev_ivar structure, even if the interfaces it is implementing provide = helper functions, like I've outlined above. Warner > - Arnaud >=20 >> Warner >>=20 >>> - Arnaud >>>=20 >>>> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >>>> enum pci_device_ivars { >>>> PCI_IVAR_SUBVENDOR, >>>> PCI_IVAR_SUBDEVICE, >>>> PCI_IVAR_VENDOR, >>>> .... >>>> }; >>>>=20 >>>> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>>>=20 >>>> enum ivar_namespace { >>>> IVAR_PCI =3D 1, >>>> IVAR_PCCARD, >>>> IVAR_USB, >>>> etc >>>> }; >>>> #define IVAR_SHIFT 16 >>>>=20 >>>> and the above could be changed to: >>>>=20 >>>> enum pci_device_ivars { >>>> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >>>> PCI_IVAR_SUBDEVICE, >>>> PCI_IVAR_VENDOR, >>>> .... >>>> }; >>>>=20 >>>> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>>>=20 >>>> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>>>=20 >>>>> Unless I am mistaken, ivar are the only way for a parent can = transmit >>>>> information to a child. I can not simply implement a new METHOD to = get >>>>> that ivar as the device implements multiple time the same function >>>>> (actually, up to 4 time for one, 3 for the other, with possible >>>>> crossovers...), each one physically distinct. Each child is being = tied >>>>> to a pair. Thus, I need to pass each child discriminator(s) for = each >>>>> interfaces right after having been *created*, which cannot be done >>>>> later on. Of course, it is out-of-question to have crossover in = the >>>>> interfaces definitions. >>>>=20 >>>> ivars are but one way to communicate this. However, they are the = generic way to convert a key to a value and store a key on a value. I = don't really understand what you are trying to say here, perhaps an = example would help illustrate what you are trying to do, since I don't = quite understand the problem here. >>>>=20 >>>>> The best way I could achieve this currently is to pass the child's >>>>> device to its parent, and do a lookup based on that pointer to get >>>>> information I need, but erk.... >>>>=20 >>>> That doesn't make any sense. The child's parent already sets that = child's ivar when the child is created. The child's parent already gets = a pointer to the child when asked to do the key to value translation. = Again, perhaps an example would help here. >>>>=20 >>>> Warner >>=20 From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 04:39:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C49106566C for ; Mon, 9 Jul 2012 04:39:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 039878FC17 for ; Mon, 9 Jul 2012 04:39:09 +0000 (UTC) Received: by ggnm2 with SMTP id m2so11210530ggn.13 for ; Sun, 08 Jul 2012 21:39:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2PU0KfHfGfWSG2xPJJRgEFUcsAIsKBa/gwQArzMPjPE=; b=iSmpg7NzVyhRKLYOmWj+41WZ+u/AHaL7UI4wK8KUIOc1DmcD/IQU4DeqrBnr1qgEiv ayjkJqX87Ij3g27IEZXeHtdkdnVYDiSoEesapiuYsbqqEkjNnqt3N+liWfqMMvQ2oWte nLtd1Z25+eogzxJDFvxI6T3BYnuVpqgmAZT+eylvEq90RKHw03+lB2vsZ6Ugc1TGDISC d3YdjFZXf1tn0kMbQBfNnx2Zp9TBqxRQ2iXEcjPFV3ovlewplgOdb5utOyfdktzLyS+Z F6vq4kBpwU9nXG4c7h0q0NmvRSMRbrviu9mo+pc3VQy6ZKaoKe9PUd3sajVhnhckzhdU J6rg== Received: by 10.66.74.97 with SMTP id s1mr62555882pav.11.1341808749146; Sun, 08 Jul 2012 21:39:09 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id jp10sm26913168pbb.16.2012.07.08.21.39.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 21:39:08 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 8 Jul 2012 22:39:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmBR/a637MN5rSH8aP1+9vBZlXE9aLZw7u0Opz3DinlUyPOEm3Bhr4Gxb3uYFhj9h8e3Z+K Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 04:39:10 -0000 On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>=20 >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>> Ok, yet another Newbus' limitation. Assuming a device exports more >>> than one interface, and one of its child has need to use more than = one >>> interface, each interfaces cannot register, concurrently, its own >>> ivar. While I try to always have a single child per >>> interface/resource, I need to keep some compatibility with the old = way >>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>> userland). So, it would have been nice if ivar had been = per-interface, >>> not global and unique to one device. >>=20 >> There's one pointer for the ivars. The bus code gets to determine = what the ivar looks like, because the interface is totally private to = the bus. So long as it returns the right thing for any key that's = presented, it doesn't matter quite how things are done. >>=20 >> So I'm not sure I understand what you are saying here. >>=20 >> The problem, more basically, is that the ivar keys are not unique. = Currently, there's no bits used in the key to define the values to be = non-overlapping. For example: >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> We could easily reserve the upper 16-bits of this field to be that = key. This value could then be used to differentiate them. But this = wouldn't scale too well. Given that there's only about a dozen or two = in the tree, that's right at the moment, it wouldn't be hard to do = something like: >>=20 >> enum ivar_namespace { >> IVAR_PCI =3D 1, >> IVAR_PCCARD, >> IVAR_USB, >> etc >> }; >> #define IVAR_SHIFT 16 >>=20 >> and the above could be changed to: >>=20 >> enum pci_device_ivars { >> PCI_IVAR_SUBVENDOR =3D IVAR_PCI << IVAR_SHIFT, >> PCI_IVAR_SUBDEVICE, >> PCI_IVAR_VENDOR, >> .... >> }; >>=20 >> and then we'd have an unambiguous key, and the bus could easily = implement multiple interfaces. >>=20 >> but then again, most of the existing interfaces in the kernel are = mutually exclusive, so you could implement this just for your new = interfaces. >>=20 > ok, I think I got it now. You and I are exactly saying the same thing, > just in different terms; there is no way to currently specify multiple > independent (/overlapping) ivars in a child... There's no way to support overlapping IVAR keys, yes. However, if you = are designing the ivars for multiple inheritance, then you'll need to = make them non-overlapping. Thankfully, this is trivial to do. Warner Warner= From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 05:02:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB07106566C for ; Mon, 9 Jul 2012 05:02:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 69FFF8FC08 for ; Mon, 9 Jul 2012 05:02:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6952cWH054746; Sun, 8 Jul 2012 22:02:38 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6952cs9054745; Sun, 8 Jul 2012 22:02:38 -0700 (PDT) (envelope-from sgk) Date: Sun, 8 Jul 2012 22:02:38 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120709050238.GA54634@troutmask.apl.washington.edu> References: <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> <4FFA52F8.2080700@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFA52F8.2080700@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 05:02:39 -0000 On Sun, Jul 08, 2012 at 10:41:44PM -0500, Stephen Montgomery-Smith wrote: > On 07/08/2012 09:01 PM, Steve Kargl wrote: > > >Have you read Goldberg's paper? > > I must admit that I had not. I found it at: > > http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html Yes, it's easy to find. Unfortunately, many people don't know that it exists. I've read that paper between 10 and 20 times and I still learn something new with every reading. > >Not to mention, I've seen way too many examples of 'x - y' > >where cancellation of significant digits causes > >problems. Throw in rather poor estimates of function > >results with real poor ULP and you have problems. > > I think that if a program includes "x-y" where cancellation causes huge > loss of digits, then the program should be considered highly flawed. > The programmer might get lucky, and a few extra ULP might save his skin, > but it would be better if the program catastrophically failed so that he > would realize they need to do something smarter. > > I got my first scientific calculator around 1975, and I remember my > surprise when I discovered that (1/3)*3-1 on my calculator did not > produce zero. Years later I bought another calculator, and imagine my > further surprise when (1/3)*3-1 did produce zero. They must have done > something very smart, I thought. Yes. They used CORDIC arithmetic instead of (binary) floating point. > The problem is, these kinds of tricks can only help you so much. > Calculations like > arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)))))))))-x are probably > not going to be correct no matter how smart the programmer is. Well, I would claim that any programmer who wrote such an expression is not smart. > The paper by Goldberg has some really nice stuff. I teach a class on > numerical methods. It may be profitable to at least have your students read the paper. I don't know about others, but I find doing floating point arithematic correctly very difficult. > One example I present is the problem using equation > (4) of Goldberg's paper to solve quadratic equations. I tell them that > the smart thing to do is to use equation (4) or equation (5) depending > on whether b has the same sign as sqrt(b^2-4ac). This is a very good > illustration of how to overcome the "x-y" problem, and in my opinion it > has to be understood by the programmer, not the writer of the > square-root package. Trying to compensate by getting that lost drop of > ULP out of square root is looking in the wrong direction. Careful. IEEE 754 specifies and one can prove that sqrt() can be computed correctly to less than or equal to 1/2 ULP for all input in all rounding modes. Computing the roots of the quartic equation, which uses the sqrt() function, is a different matter. > But there is other stuff in his paper I don't like, and it comes across > as nit-picking rather than really thinking through why he wants the > extra accuracy. I feel like he is saving the pennies, but losing the > dollars. well, in Goldberg's defense, think about the title of the paper. I think his major aim in the paper is get scientist to think about what and how they compute some number. > Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). Oh my. I'm a fan of Kahan's summation formula. But, I assume that one applies it to situations where it is needed. > There are two reasons why I might compute large sums. One is > accounting, when I better be using high enough precision that the > arithmetic is exact. If you're doing accouting, hopefully, you're using BCD. Accouting and floating point simply do not mix. > The other is something like numerical integration. > But in the latter case, unless the summands have a very special form, > it is likely that each summand will only be accurate to within e. Thus > the true sum is only known to within n*e, and so the naive method really > hasn't lost any precision at all. And typically n*e will be so small > compared to the true answer that it won't matter. If it does matter, > the problem is that n is too big. The algorithm will take decades to > run. Focus efforts on producing a different numerical integration > method, instead of getting that lost drop of ULP. I cannot envision any > non-contrived circumstance where the Kahan summation formula is going to > give an answer that is significantly more reliable than naive summation. > I can envision a circumstance when the reduction in speed of the Kahan > summation formula over naive summation could be significant. I can envision a use. Try computing the RMS height of a numerically generated random rough surface in the scattering of an incident acoustic field from said surface. The RMS height is a main component in the first order perturbation theory expansion of the scattered field. You get the RMS height wrong, you have no idea what the scatter field strength is. > I think the example I like best that illustrates floating point errors > is inverting badly conditioned matrices. And any scientist who works > with large matrices had better know what ill-conditioned means. The > proper answer is that if your matrix is ill-conditioned, give up. You > need to look at the problem where your matrix came from, and rethink how > you concert it into a matrix problem, so that the matrix is not > ill-conditioned. Chasing that last drop of ULP simply will not help one > iota. Yep. Another example is the use of upward recurion to compute Bessel functions where the argument is larger than the order. The algorithm is known to be unstable. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 05:18:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3591A106564A; Mon, 9 Jul 2012 05:18:00 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 90E658FC08; Mon, 9 Jul 2012 05:17:59 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so2069602wib.13 for ; Sun, 08 Jul 2012 22:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/Fgc51bagA4OIHukFXEdz+x40tkf/RC5w8RhoUsBCTE=; b=cTV3smi106Ka69hyE9BE8LW+dp+EQ8QU47IcgrAP+ptXMBwonco1PVD3N9hOhmNNej 2uJUVs6JEeTiXP8s9XFHEwZXuWSVvN31s52J8xIhPqFpKf/vu+dGB3ti3Wz6uq4/eKvC Vx9trLXww4UxoshkOoabz/NGe+5hAOpgR50QY2hGsbnOjY5LVxn+GoKY5W4EU/gmtsyV utNIuWrLdLD7Cyvr/eLFMv4df8K3o78jJ7EaM0pdfh4QnhviitKU0esWYeeG92j0IZQr GMgmHoZN6uau4HV+bDxRLRFPTd3rwl0zcpwJByF0KvF04sf312kCImFMDVrqbfDvQvtI HUBQ== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr26490361wib.3.1341811072926; Sun, 08 Jul 2012 22:17:52 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Sun, 8 Jul 2012 22:17:52 -0700 (PDT) In-Reply-To: <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> Date: Mon, 9 Jul 2012 01:17:52 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 05:18:00 -0000 Hi, On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: > > On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: > >> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: >>> >>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>> >>>> Hi, >>>> >>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>>>> >>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>>> than one interface, and one of its child has need to use more than o= ne >>>>>> interface, each interfaces cannot register, concurrently, its own >>>>>> ivar. While I try to always have a single child per >>>>>> interface/resource, I need to keep some compatibility with the old w= ay >>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>> userland). So, it would have been nice if ivar had been per-interfac= e, >>>>>> not global and unique to one device. >>>>> >>>>> There's one pointer for the ivars. The bus code gets to determine wh= at the ivar looks like, because the interface is totally private to the bus= . So long as it returns the right thing for any key that's presented, it d= oesn't matter quite how things are done. >>>>> >>>>> So I'm not sure I understand what you are saying here. >>>>> >>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs to >>>> use both interfaces. There is no generic way for dev0 to export >>>> independent ivars for both interface. For now, I restricted the >>>> function of the second interface not to need ivar, but that's kind of >>>> hackish. >>> >>> Only if the IVARs for interface A and interface B have overlapping valu= es. If the Ivar keys don't overlap, then there's no problems at all. Cert= ainly less hackish than not using them at all. Since dev0 knows the layout= of the ivar that it set on its child, this presents no problems at all. I= t would return the values from A from the right part of the ivar, and those= from B in the right part. Apart from the coordination of Ivar numbers, as= I outlined in my last post, there's no issue here. >>> >> I think we should not be talking about the same API here. I have no >> idea what you mean by "the key to value translation", nor "Ivar >> numbers". What I refer to is that device_set_ivars() / >> device_get_ivars() acts on a single instance variables from `struct >> device': `ivars'. In that case, I do not really see how to set that >> specific field to two distinct values for each interfaces. > > We are talking about the ivar interface. You are just misunderstanding h= ow it is used. > yes I indeed did... silly, silly me :-) - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 08:10:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3A93106567B for ; Mon, 9 Jul 2012 08:10:07 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (ns25270.ovh.net [91.121.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 83FEB8FC16 for ; Mon, 9 Jul 2012 08:10:07 +0000 (UTC) Received: from [46.255.176.2] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1So91S-0000Ne-Bz for freebsd-current@freebsd.org; Mon, 09 Jul 2012 10:08:46 +0200 Message-ID: <4FFA918E.8070307@FreeBSD.org> Date: Mon, 09 Jul 2012 10:08:46 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <7F5E65B1-24AF-4942-A273-093EBAE94B7D@FreeBSD.org> <168031EF-1CBD-4B14-A99E-D5C90B01111C@FreeBSD.org> <4FF62A6C.7090408@FreeBSD.org> <4FF8FB0C.4050706@mouf.net> <4FF941EC.9050900@FreeBSD.org> <20120708130650.GV2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120708130650.GV2338@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: panic after starting X with r238120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 08:10:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.07.2012 15:06, Konstantin Belousov wrote: > You know, this is not much useful ? Backtrace is. Sorry, I forgot to mention that I had the same backtrace than Steve. I'll buildworld again (probably not today) and report back. - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/6kY4ACgkQa+xGJsFYOlMvHgCeNW76VSjVkf4/on2LYFKGR5Bs R7UAoNYkQtmvpzlblqd3mudp57Kg2K22 =oIqg -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 09:45:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320701065676 for ; Mon, 9 Jul 2012 09:45:05 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 837008FC1F for ; Mon, 9 Jul 2012 09:45:04 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SoAWc-0005iw-3U; Mon, 09 Jul 2012 12:45:02 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 871E81CC1E; Mon, 9 Jul 2012 12:44:56 +0300 (EEST) Date: Mon, 9 Jul 2012 12:44:56 +0300 From: Andrey Simonenko To: Vincent Hoffman Message-ID: <20120709094456.GA1338@pm513-1.comsys.ntu-kpi.kiev.ua> References: <497527423.2441665.1341141539082.JavaMail.root@erie.cs.uoguelph.ca> <4FF82B13.8000906@unsane.co.uk> <4FF9C4F6.9020402@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FF9C4F6.9020402@unsane.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-07-09 12:45:02 X-Connected-IP: 10.18.52.101:26977 X-Message-Linecount: 211 X-Body-Linecount: 193 X-Message-Size: 8376 X-Body-Size: 7574 Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 09:45:05 -0000 Hello again, On Sun, Jul 08, 2012 at 06:35:50PM +0100, Vincent Hoffman wrote: > Replying to myself just as a record, I have tried nfse and I didnt get > the permission denied at all. > The only issue I had with it is that it strictly adheres to the syntax > in exports(5) while mountd is a little more flexible. > > I had > /usr/local/export -alldirs -maproot=root 85.xx.xx.xx > > /usr is the root of that filesystem > > mountd - allowed this but actually silently exports /usr (and all dirs > below) > > nfse - didnt allow this, it needed to be the correct > /usr -alldirs -maproot=root 85.xx.xx.xx > > which is I guess a POLA violation but follows the documentation. > this was using nfse in mountd compatibility mode. I havent played with > its more advanced features. The -alldirs option in the exports(5) file does not mean only "all directories". Please read these lines from exports(5) DESCRIPTION: The second is to specify the pathname of the root of the file system fol- lowed by the -alldirs flag; this form allows the host(s) to mount at any point within the file system, including regular files if the -r option is used on mountd(8). The -alldirs option specifies that this pathname must be the root (mount point) of some file system. And read these lines from EXAMPLES: The file system rooted at /cdrom will be exported read-only to the entire network 192.168.33.0/24, including all its subdirectories. Since /cdrom is the conventional mountpoint for a CD-ROM device, this export will fail if no CD-ROM medium is currently mounted there since that line would then attempt to export a subdirectory of the root file system with the -alldirs option which is not allowed. The -quiet option will then sup- press the error message for this condition that would normally be sys- logged. As soon as an actual CD-ROM is going to be mounted, mount(8) will notify mountd(8) about this situation, and the /cdrom file system will be exported as intended. Note that without using the -alldirs option, the export would always succeed. While there is no CD-ROM medium mounted under /cdrom, it would export the (normally empty) directory /cdrom of the root file system instead. Here -alldirs means that /cdrom should be a file system. As I remember this even worked before revision 1.85 of mountd/mountd.c, then mountd.c began to use nmount(2). Now if one puts /cdrom in /etc/exports and there is no file system mounted on /cdrom, then the entire / will be exported. Just create /etc/exports with one line "/cdrom -alldirs" and try to mount :/ on another system, you will get access to the / of the . The current version of mountd is not "little more flexible", it does not follow traditional -alldirs option's logic and does not follow description of the -alldirs option in the exports(5) manual page, I guess this is a POLA violation. Now let's back to your example where /usr is the root of the file system: /usr/local/export -alldirs -maproot=root 1.2.3.4 1. mountd exports /usr and all subdirectories under it for NFSv2/3 clients. Actually it has to export /usr/local/export only and all subdirectories under it only if /usr/local/export is or will be the root of some file system. 2. nfse in the compatibility mode sees that there is the -alldirs option and will export /usr/local/export and all subdirectories under it only if /usr/local/exports is or will be the root of some file system. If one runs "nfse -Ct ..." for this file then its output will be: configure: reading file /etc/exports configure: converting configuration to native format Pathname /usr/local/export Export specifications: -rw -sec sys -maproot 0:0:5 -host 1.2.3.4 Subdirectories for NFSv2/3: /usr/local/export -alldirs -host 1.2.3.4 Warning: subdirectories exports are insecure This is output in nfse native format. Using NFSE part in the kernel, nfse verifies whether /usr/local/export is a mount point, whether file system supports NFS, and only if everything is correct, it starts to export it. When file system is unmounted or when another file system is mounted, then NFSE part in the kernel is informed by EVENTHANDLERs vfs_mount_event/vfs_unmount_event and NFS server verifies whether it still can export this file system (it can be unmounted or it can be shadowed). The userland utility nfse got information of VFS events via kevents VQ_MOUNT/VQ_UNMOUNT and only the verifies using NFSE part in the kernel whether some file system is still exported or can become exported. There is one implementation mistake when "nfse -C ..." is used. The nfse utility follows implementation mistake from mountd and verifies what is a file system and what is not a file system using the f_mntonname field in the struct mount{}. This is wrong since parts of mount point directory can be renamed and this is not reflected in the f_mntonname value. That's why I do not recommend compatibility mode. But this implementation mistake is just a compatibility mode rule. When nfse is used in native mode, then it never checks f_mntonname values and mount points can be renamed. 3. The corresponding configuration in the nfse native nfs.exports(5) format should be: /usr/local/export -maproot root 1.2.3.4 /usr/local/export -subdir -alldirs And the output of "nfse -t ..." will be: configure: reading file /etc/nfs.exports Pathname /usr/local/export Export specifications: -rw -sec sys -maproot 0:0:5 -host 1.2.3.4 Subdirectories for NFSv2/3: /usr/local/export -alldirs * Warning: subdirectories exports are insecure Well, one can duplicate 1.2.3.4 in the -subdir line, this is just a style decision in this example. Let's consider the same example but without the -alldirs options: /usr/local/export -maproot=root 1.2.3.4 1. mountd will export /usr and will administratively export /usr/local/export for NFSv2/3 clients. A client can guess a filehandle and try to access any part of the /usr file system. If /usr is not a mount point, then mountd will export /. 2. nfse in the compatibility mode will do exactly the same as mountd does (suppose that /usr is mount point when nfse was started): configure: reading file /etc/exports configure: converting configuration to native format Pathname /usr Export specifications: -rw -sec sys -maproot 0:0:5 -host 1.2.3.4 Subdirectories for NFSv2/3: /usr/local/export -host 1.2.3.4 Warning: subdirectories exports are insecure 3. nfse in the native mode will export /usr if it is or will be a mount point: configure: reading file /etc/nfs.exports Pathname /usr/local/export Export specifications: -rw -sec sys -maproot 0:0:5 -host 1.2.3.4 Let's back again to your example. I guess you wanted administratively export subdirectory /usr/local/exports and all subdirectories under it from the /usr file system. It is impossible to write such configuration using the exports(5) file syntax. But it is possible to do this with the nfs.exports(5) syntax: /usr -maproot=root 1.2.3.4 /usr/local/export -subdir -alldirs And "nfse -t ..." output: configure: reading file /etc/nfs.exports Pathname /usr Export specifications: -rw -sec sys -maproot 0:0:5 -host 1.2.3.4 Subdirectories for NFSv2/3: /usr/local/export -alldirs * Warning: subdirectories exports are insecure Am I correct? Did I correctly understand your example? From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 09:50:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C452B106566C for ; Mon, 9 Jul 2012 09:50:18 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 393C58FC12 for ; Mon, 9 Jul 2012 09:50:18 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SoAbh-00069J-Dj; Mon, 09 Jul 2012 12:50:17 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 970F71CC1E; Mon, 9 Jul 2012 12:50:12 +0300 (EEST) Date: Mon, 9 Jul 2012 12:50:12 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120709095012.GB1338@pm513-1.comsys.ntu-kpi.kiev.ua> References: <4FF9C4F6.9020402@unsane.co.uk> <854827461.102645.1341791291213.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <854827461.102645.1341791291213.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-07-09 12:50:17 X-Connected-IP: 10.18.52.101:37514 X-Message-Linecount: 50 X-Body-Linecount: 33 X-Message-Size: 2376 X-Body-Size: 1573 Cc: freebsd-current@freebsd.org, Vincent Hoffman Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 09:50:18 -0000 On Sun, Jul 08, 2012 at 07:48:11PM -0400, Rick Macklem wrote: > > > Replying to myself just as a record, I have tried nfse and I didnt get > > the permission denied at all. > > The only issue I had with it is that it strictly adheres to the syntax > > in exports(5) while mountd is a little more flexible. > > > > I had > > /usr/local/export -alldirs -maproot=root 85.xx.xx.xx > > > > /usr is the root of that filesystem > > > > mountd - allowed this but actually silently exports /usr (and all dirs > > below) > > > Not exactly correct. mountd exports the entire file system in the kernel > for the NFS server, since exports can only be attached to the mount points > in the kernel. However, when the client's mount protocol requests a mount > file handle for anything other than /usr/local/export, it will refuse that. > (Which means that to mount anything other than /usr/local/export, the client > must maliciously "guess" the file handle for mounting.) > > Put another way, a "non-malicious" NFSv3 client will only be able to mount > /usr/local/export. Robert Watson calls this an "administrative control" and > feels that it is necessary. According to the exports(5) manual page and this example (/usr is the mount point and the -alldir option is given), this example means the following: "export /usr/local/export only if it is or will be a mount point and administratively export all subdirectories under it for NFSv2/3 clients". Good description of the -alldirs option is given in the EXAMPLES section from exports(5) in paragraph about "/cdrom -alldirs". From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 09:59:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2BFC106566B for ; Mon, 9 Jul 2012 09:59:23 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 868D98FC08 for ; Mon, 9 Jul 2012 09:59:23 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q699xEML005109; Mon, 9 Jul 2012 10:59:15 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20120709050238.GA54634@troutmask.apl.washington.edu> Date: Mon, 9 Jul 2012 10:59:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <66FC3CF4-6013-453B-958A-979ED07C1920@gid.co.uk> References: <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> <4FFA52F8.2080700@missouri.edu> <20120709050238.GA54634@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1278) Cc: Stephen Montgomery-Smith , freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 09:59:24 -0000 Hi, On 9 Jul 2012, at 06:02, Steve Kargl wrote: > If you're doing accouting, hopefully, you're using BCD. Would be nice, but it's far too slow for financial analysis; the chip = designers go out of their way to provide fast floating point. = Fortunately 53 bits is usually plenty with 2dp max. -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 10:18:34 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AD521065680 for ; Mon, 9 Jul 2012 10:18:34 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C88B8FC15 for ; Mon, 9 Jul 2012 10:18:33 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q69AIWXP004852 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 9 Jul 2012 11:18:32 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FFAAFF8.70104@unsane.co.uk> Date: Mon, 09 Jul 2012 11:18:32 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rick Macklem References: <1458419708.103582.1341796134892.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1458419708.103582.1341796134892.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 10:18:34 -0000 On 09/07/2012 02:08, Rick Macklem wrote: > Vincent Hoffman: >> On 08/07/2012 00:26, Rick Macklem wrote: >>> Vincent Hoffman wrote: >>>> Hi Rick, >>>> >>>> I'm afraid this didnt make any real difference for me. >>>> Since I couldnt test it on the live system I tried it on a test vm. >>>> on the vm (nfs server) I set a looping mount/umount >>>> while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp >>>> ; >>>> done >>>> >>>> and on the client I set a loop of tars of large directorys to the >>>> nfs >>>> mount running under time to see how well it survived. Then >>>> replicated >>>> the test with the patch and without. >>>> >>> Just to confirm, you patched both the kernel and mountd and replaced >>> both >>> on the server? >>> >>> Also, I'm not sure how ZFS handles it's exports. I can't remember if >>> you've >>> tried an exported UFS volume. It might be something ZFS specific? >>> >>> rick >> Hi Rick, >> >> yes I patched both the kernel and mountd, rebuilt kernel and world (to >> be sure), added the -S flag to mountd in rc.conf and rebooted. >> This is a test VM running -CURRENT and is only exporting a ufs2 >> filesystem. >> (11:43:05 <~>) 0 $ cat /etc/exports >> /usr/local/export -maproot=root -alldirs XX.XX.XX.XX >> >> Client is a 8.3-RELEASE box but I see the same with linux clients. >> (I can confirm that it works fine when I am not running the >> mount/umount >> loop) >> > Oops, the patch I sent you worked for NFSv4 only. If you also apply the > attached patch, it seems to work for NFSv3 as well. > The patch is also at: > http://people.freebsd.org/~rmacklem/atomic-export2.patch > > You must also run the new/experimental server. (I can't remember if I > mentioned that before.) > > rick You did mention that :) Thanks I'll give this one a go. Vince > >> The production system has been fine since I removed the SIGHUP call in >> mount.c so thanks for that suggestion. >> >> >> Vince >>>> [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt >>>> x nopatch.txt >>>> + atomicpatch.txt >>>> +--------------------------------------------------------------------------------------------------+ >>>> | >>>> * >>>> | >>>> | >>>> * >>>> | >>>> | >>>> x* >>>> | >>>> | xx* >>>> x >>>> | >>>> | +x** >>>> xx >>>> | >>>> | **** xxx >>>> x >>>> | >>>> | **** xxx +x+ >>>> + >>>> | >>>> | ****+*xx +x+ x >>>> + >>>> | >>>> | ****+*x****++++x + + >>>> x | >>>> | *************+*xx+ +++x * x >>>> x | >>>> | ****************x**++*x+***x+ x*+ x ++*+ + x+ +x + >>>> + +| >>>> |||_______M_M_A__A_______|______| >>>> | >>>> +--------------------------------------------------------------------------------------------------+ >>>> N Min Max Median Avg Stddev >>>> x 101 1.25 106.8 14.08 21.892178 22.196005 >>>> + 101 1.21 186.93 18.46 27.995842 30.523218 >>>> No difference proven at 95.0% confidence >>>> >>>> >>>> (excuse wrapped ascii art) >>>> >>>> I think I'll have a look at the nfse patch set and see how that >>>> performs. >>>> >>>> Thanks for all your work on NFS on FreeBSD. >>>> >>>> Vince >>>> >>>>>>> Also, you could easily hack mount.c so that it doesn't send a >>>>>>> SIGHUP >>>>>>> to mountd (which causes the exports to be reloaded) every time a >>>>>>> local >>>>>>> fs is mounted. >>>>>> True and I may have to do that for the production NAS for the >>>>>> time >>>>>> being. >>>>>> Thanks for looking at this. >>>>>> >>>>>> Vince >>>>>>> rick >>>>>>> >>>>>>>>> thanks, Vince >>>> _______________________________________________ >>>> 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 Mon Jul 9 12:59:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 873AB1065679 for ; Mon, 9 Jul 2012 12:59:47 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 3671F8FC1B for ; Mon, 9 Jul 2012 12:59:47 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.10]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q69CxY7u010381; Mon, 9 Jul 2012 06:59:40 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 19:59:32 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <201207051049.26199.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207091959.33029.erichfreebsdlist@ovitrap.com> Cc: Subject: Re: side note on the X220 running CURRENT: head phone jack works X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 12:59:47 -0000 Hi, On Friday, July 06, 2012 03:24:34 AM Kevin Oberman wrote: > On Wed, Jul 4, 2012 at 8:49 PM, Erich Dollansky > wrote: > > Hi, > > > > there have been some people here - including me - wondering whether the head phone jack works. Yes, it does. > > > > I just have had the chance to connect the head phone jack. It works when vlc is set to use /dev/dsp1.0. > > > > Using /dev/dsp0.1 brings sound to the built-in speakers. > > The "proper" fix is to add the following to /boot/loader.conf: it is the general way as it should work with all applications. > # Out : speaker + headphones > hint.hdac.0.cad0.nid25.config="as=1 seq=15" > # In : mic + external mic > hint.hdac.0.cad0.nid35.config="as=2" > hint.hdac.0.cad0.nid27.config="as=2 seq=15" > I added this to the loader.conf file and will test when I will get my hands on the equipment. Thanks! Erich From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 13:19:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6962106564A for ; Mon, 9 Jul 2012 13:19:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF598FC15 for ; Mon, 9 Jul 2012 13:19:57 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q69DJvAI008822 for ; Mon, 9 Jul 2012 06:19:57 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q69DJved008821 for current@freebsd.org; Mon, 9 Jul 2012 06:19:57 -0700 (PDT) (envelope-from david) Date: Mon, 9 Jul 2012 06:19:57 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20120709131957.GI1552@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5me2qT3T17SWzdxI" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 13:19:58 -0000 --5me2qT3T17SWzdxI Content-Type: multipart/mixed; boundary="+PbGPm1eXpwOoWkI" Content-Disposition: inline --+PbGPm1eXpwOoWkI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just finished updating from r238227 to r238290 on the "head" slice of my laptop, and was unable to make use of the wlan(4) NIC; I captured the following via cut/paste from ttyv0: =2E.. Setting hostname: localhost. Starting dhclient. em0: no link .............. giving up /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting wpa_supplicant. ioctl[SIOCG80211, op 98, len 32]: Invalid argument /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Starting dhclient. dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT dhclient: Setting hostname from localhost to null string ifconfig: ioctl (SIOCAIFADDR): Invalid argument dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT dhclient: reason was PREINIT; no action taken dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 wlan0: not found exiting. /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting Network: lo0 em0 iwn0 fwe0 fwip0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D4219b ether 00:24:e8:9c:11:0f nd6 options=3D29 media: Ethernet autoselect status: no carrier iwn0: flags=3D8802 metric 0 mtu 2290 ether 00:21:6a:26:34:c0 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 4a:4f:c0:37:06:01 nd6 options=3D29 ch 1 dma -1 fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 4a.4f.c0.0.10.37.6.1.a.2.ff.fe.0.0.0.0 nd6 options=3D29 Starting devd. ifconfig: create: bad value Starting wpa_supplicant. ioctl[SIOCG80211, op 98, len 32]: Invalid argument /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant Starting dhclient. dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT dhclient: Leaving hostname set to ifconfig: ioctl (SIOCAIFADDR): Invalid argument dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT dhclient: reason was PREINIT; no action taken dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 wlan0: not found exiting. /etc/rc.d/dhclient: WARNING: failed to start dhclient Starting Network: iwn0. iwn0: flags=3D8802 metric 0 mtu 2290 ether 00:21:6a:26:34:c0 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ifconfig: create: bad value Starting wpa_supplicant. ioctl[SIOCG80211, op 98, len 32]: Invalid argument /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant =2E... Yesterday, I had updated to: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #614 238227= M: Sun Jul 8 06:47:51 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 and things seemed OK -- I was certainly able to use the NIC. :-} uname output from this morning: FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #615 238290M: Mon Jul 9 05:39:1= 5 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I glanced through the list of commits to head in that range, but didn't note anything glaringly obvious (yet). I hadn't tried a wired NIC on the laptop; I can, if there's anything likely to be of value in doing so. I've attached a copy of the associated dmesg.boot. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+PbGPm1eXpwOoWkI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot.10.0-CURRENT" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #615 238290M: Mon Jul 9 05:39:15 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc8400000 MEMGUARD map limit: 0xcad34000 MEMGUARD map size: 42192 KBytes CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.07-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x10676 Family =3D 6 Model =3D 17 St= epping =3D 6 Features=3D0xbfebfbff Features2=3D0x8e3fd AMD Features=3D0x20100000 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 4294967296 (4096 MB) avail memory =3D 3639406592 (3470 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 100000, df351c00 (3) failed cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x930,0x934 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xf5000000-0xf5fff= fff,0xe0000000-0xefffffff,0xf2000000-0xf3ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io pci0: at device 3.0 (no driver attached) atapci0: port 0xef78-0xef7f,0xef70-0xef73,0xef80-0xe= f87,0xef74-0xef77,0xef90-0xef9f irq 18 at device 3.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0xefe0-0xefff mem 0x= f6fe0000-0xf6ffffff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:24:e8:9c:11:0f uhci0: port 0x6f60-0x6f7f irq 20 at de= vice 26.0 on pci0 uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci1: port 0x6f80-0x6f9f irq 21 at de= vice 26.1 on pci0 uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci2: port 0x6fa0-0x6fbf irq 22 at de= vice 26.2 on pci0 uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 ehci0: mem 0xfed1c400-0xfed1c7ff i= rq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xf6fdc000-0xf6fdffff irq 21 at de= vice 27.0 on pci0 pcib2: at device 28.0 on pci0 pci11: on pcib2 pcib3: at device 28.1 on pci0 pci12: on pcib3 iwn0: mem 0xf1ffe000-0xf1ffffff irq 17 at= device 0.0 on pci12 pcib4: at device 28.2 on pci0 pci13: on pcib4 pcib5: at device 28.3 on pci0 pci14: on pcib5 uhci3: port 0x6f00-0x6f1f irq 20 at de= vice 29.0 on pci0 uhci3: LegSup =3D 0x2f00 usbus4 on uhci3 uhci4: port 0x6f20-0x6f3f irq 21 at de= vice 29.1 on pci0 uhci4: LegSup =3D 0x2f00 usbus5 on uhci4 uhci5: port 0x6f40-0x6f5f irq 22 at de= vice 29.2 on pci0 uhci5: LegSup =3D 0x2f00 usbus6 on uhci5 ehci1: mem 0xfed1c000-0xfed1c3ff i= rq 20 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7 on ehci1 pcib6: at device 30.0 on pci0 pci3: on pcib6 cbb0: irq 19 at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xf1bff800-0xf1bfffff ir= q 17 at device 1.1 on pci3 fwohci0: OHCI version 1.10 (ROM=3D0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 4a:4f:c0:00:10:37:06:01 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x35fe000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 4a:4f:c0:37:06:01 fwe0: Ethernet address: 4a:4f:c0:37:06:01 fwip0: on firewire0 fwip0: Firewire address: 4a:4f:c0:00:10:37:06:01 @ 0xfffe00000000, S400, ma= xrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000000, SelfID Count=3D1, CYCLEMAS= TER mode sdhci0: mem 0xf1bff600-0xf1bff6ff irq 18 at device 1.2 on= pci3 sdhci0: 1 slot(s) allocated pci3: at device 1.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x6e70-0x6e77,0x6e78-0x6e7b,= 0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 = at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ichsmb0: port 0x1100-0x111f mem 0xf6= fd9f00-0xf6fd9fff irq 19 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on ac= pi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xce7ff,0xce800-0xcffff pnpid ORM0= 000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 ppc0: parallel port not found. ctl: CAM Target Layer loaded coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 firewire0: 1 nodes, maxhop <=3D 0 cable IRM irm(0) (me)=20 firewire0: bus manager 0=20 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forward= ing enabled, default to deny, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 13,10 and 11,14 on hdaa0 pcm1: at nid 15 and 24 on hdaa0 pcm2: at nid 30 on hdaa0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 Expensive timeout(9) function: 0xc0a954c0(0xcb532000) 0.002174787 s ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Expensive timeout(9) function: 0xc055fb60(0xcb9eb380) 0.004884419 s uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 cd0 at ahcich1 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ada0s4a [rw]... lock order reversal: 1st 0xcf2d84c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2158 2nd 0xe20fd710 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:260 3rd 0xcf2f9da8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2158 KDB: stack backtrace: db_trace_self_wrapper(c0f9f9db,632e7262,3531323a,6f000a38,632e7370,...) at = 0xc0525676 =3D db_trace_self_wrapper+0x26 kdb_backtrace(c0a8ec2b,c0fa357b,c1290098,86e,f0d4732c,...) at 0xc0a8a55a = =3D kdb_backtrace+0x2a _witness_debugger(c0fa357b,cf2f9da8,c0f8b5d3,caebd580,c0fab7d2,...) at 0xc0= aa0895 =3D _witness_debugger+0x25 witness_checkorder(cf2f9da8,9,c0fab7d2,86e,0,...) at 0xc0aa1d9f =3D witness= _checkorder+0x86f __lockmgr_args(cf2f9da8,80100,cf2f9dc8,0,0,...) at 0xc0a37b05 =3D __lockmgr= _args+0x8b5 ffs_lock(f0d47438,c0aa179c,c0fa8ba7,5e2,c10d1508,...) at 0xc0ccf3aa =3D ffs= _lock+0x8a VOP_LOCK1_APV(c1102980,f0d47438,cee79c74,c1114da0,cf2f9d50,...) at 0xc0df93= d3 =3D VOP_LOCK1_APV+0xf3 _vn_lock(cf2f9d50,80100,c0fab7d2,86e,eb,...) at 0xc0b0558e =3D _vn_lock+0x5e vget(cf2f9d50,80100,cee79bc0,50,0,...) at 0xc0af77e9 =3D vget+0xb9 vfs_hash_get(cf29c7b0,78c03,80000,cee79bc0,f0d47584,...) at 0xc0ae67a6 =3D = vfs_hash_get+0xe6 ffs_vgetf(cf29c7b0,78c03,80000,f0d47584,1,...) at 0xc0cc86d9 =3D ffs_vgetf+= 0x49 softdep_sync_buf(cf2d8470,e20fd6b0,1,106,0,...) at 0xc0cc5859 =3D softdep_s= ync_buf+0xac9 ffs_syncvnode(cf2d8470,1,0,c12900a8,cee79c74,...) at 0xc0ccf69c =3D ffs_syn= cvnode+0x24c ffs_truncate(cf2d8470,200,0,880,caf23e80,...) at 0xc0ca6eee =3D ffs_truncat= e+0x83e ufs_direnter(cf2d8470,cf2f9d50,f0d478f0,f0d47b98,0,...) at 0xc0cd6cfa =3D u= fs_direnter+0x93a ufs_makeinode(f0d47b98,c1102ec0,f0d47ae8,f0d47a44,c0dfa24a,...) at 0xc0cdcf= 2c =3D ufs_makeinode+0x61c ufs_create(f0d47ae8,cf29c7b0,c1115020,cf2d8470,f0d47afc,...) at 0xc0cdd260 = =3D ufs_create+0x30 VOP_CREATE_APV(c1102980,f0d47ae8,f0d47b98,f0d47a80,0,...) at 0xc0dfa24a =3D= VOP_CREATE_APV+0xda vn_open_cred(f0d47b58,f0d47c20,1a4,0,caf23e80,...) at 0xc0b04e6a =3D vn_ope= n_cred+0x20a vn_open(f0d47b58,f0d47c20,1a4,cee63738,8,...) at 0xc0b050fb =3D vn_open+0x3b kern_openat(cee79bc0,ffffff9c,2882e7a8,0,602,...) at 0xc0b0356c =3D kern_op= enat+0x1ec kern_open(cee79bc0,2882e7a8,0,601,1b6,...) at 0xc0b03985 =3D kern_open+0x35 sys_open(cee79bc0,f0d47ccc,c0ff12e8,c0fa449c,0,...) at 0xc0b039c0 =3D sys_o= pen+0x30 syscall(f0d47d08) at 0xc0dd342e =3D syscall+0x2fe Xint0x80_syscall() at 0xc0dbd271 =3D Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, sys_open), eip =3D 0x281ee443, esp =3D 0xbfb= fcdec, ebp =3D 0xbfbfcea8 --- --+PbGPm1eXpwOoWkI-- --5me2qT3T17SWzdxI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/62nwACgkQmprOCmdXAD36+wCeKfd8Z4vzzf1iCO179wYn3rB2 U1wAn1irs1r26JSWPivq2h2JfFp2Y/lp =z+oT -----END PGP SIGNATURE----- --5me2qT3T17SWzdxI-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:38:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE8911065670; Mon, 9 Jul 2012 15:38:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BEA728FC14; Mon, 9 Jul 2012 15:38:16 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 37DF1B911; Mon, 9 Jul 2012 11:38:16 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:15:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120528221731.GA76723@troutmask.apl.washington.edu> <20120708233624.GA53462@troutmask.apl.washington.edu> <20120708235652.GA46771@zim.MIT.EDU> In-Reply-To: <20120708235652.GA46771@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091115.14220.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:16 -0400 (EDT) Cc: David Schultz , Peter Jeremy , Warner Losh , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:38:17 -0000 On Sunday, July 08, 2012 7:56:52 pm David Schultz wrote: > On Sun, Jul 08, 2012, Steve Kargl wrote: > > > > The question remains of what to do about the missing functions. Bruce > > > > and Steve have been working on expl and logl for years. If those ever > > > > get in the tree, the remaining long double functions are easy. Those > > > > functions are basically done, modulo a bunch of cleanup and testing, > > > > and I encourage any mathematically inclined folks who are interested > > > > in pushing things along to get in touch with them. I'm not going to > > > > have any time myself for a few months at least. > > > > > > Where can I find these? > > > > I've posted expl() a few times for the ld80 version. > > I don't have an ld128 version, which is why I have > > yet to submit a formal patch for expl(). I also > > have an ld80 expm1l(). I have a copy of bde's ld80 > > logl(). IIRC, bde wrote an ld128, but I don't have > > nor do I know if it has been tested. > > Yes, Bruce has ld128 versions, and clusteradm very kindly got us a > sparc64 machine to test on. That was about the time I ran out of time > to keep working on it. If someone wants to pick it up, that would be > great. > > > PS: I also wrote sincos[fl](), which is very handy for the > > complex trig functions. > > Yes, you should commit that! So it sounds like there are at least some outstanding patches that should go into the tree. Can we at least get these things committed (even if they are only enabled for certain platforms for now)? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:38:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4EA7106566B; Mon, 9 Jul 2012 15:38:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 607588FC08; Mon, 9 Jul 2012 15:38:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B4049B972; Mon, 9 Jul 2012 11:38:17 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:19:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1341601751.70246.7.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: <201207091119.42549.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:17 -0400 (EDT) Cc: Ian Lepore , Arnaud Lacombe , FreeBSD Hackers Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:38:19 -0000 On Friday, July 06, 2012 4:45:55 pm Arnaud Lacombe wrote: > Hi, > > On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore > wrote: > > On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: > >> Hi, > >> > >> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe wrote: > >> > That's neither correct nor robust in a couple of way: > >> > 1) you have no guarantee a device unit will always give you the same resource. > >> this raises the following question: how can a device, today, figure > >> out which parent in a given devclass would give it access to resources > >> it needs. > >> > >> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by > >> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 > >> attachment is conditional to some BIOS setting. How can you tell > >> gpioled(4) to attach on the chipset provided GPIO without hardcoding > >> unit number either way ? > >> > >> AFAIK, you can not. > >> > >> Even hints provided layout description is defeated. Each device in a > >> given devclass need to have a set of unique attribute to allow a child > >> to distinguish it from other potential parent in the same devclass... > >> > >> - Arnaud > > > > Talking about a child being unable to choose the correct parent seems to > > indicate that this whole problem is turned upside-down somehow; children > > don't choose their parents. > > > actually, I think I was wrong, I thought device were attached to a > devclass, but they are truly attached to a given device. My mistake. > > > Just blue-sky dreaming here on the fly... what we really have is a > > resource-management problem. A device comes along that needs a GPIO > > resource, how does it find and use that resource? > > > > Well, we have a resource manager, could that help somehow? Could a > > driver that provides access to GPIO somehow register its availability so > > that another driver can find and access it? The "resource" may be a > > callable interface, it doesn't really matter, I'm just wondering if the > > current rman stuff could be leveraged to help make the connection > > between unrelated devices. I think that implies that there would have > > to be something near the root of the hiearchy willing to be the > > owner/manager of dynamic resources. > > > AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. > The more I think about it, the more FTD is the answer. The open > question now being "how to map a flexible device structure (FTD) to a > less flexible structure (Newbus)" :/ Note that IRQs are also managed in rman. However, that is a complicated beast. Generally there is some sideband way for interrupt controllers to register their available interrupt pins with the platform's nexus driver (often the actual PIC is not managed via new-bus). You then need something else to let a given device know which interrupt pin it wants (e.g. PCI interrupt routing). However, you could make a similar approach work for GPIO perhaps, where devices make GPIO pins available to a rman that other devices then allocate from. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:38:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECB56106564A; Mon, 9 Jul 2012 15:38:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C04D28FC0A; Mon, 9 Jul 2012 15:38:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1DD16B98B; Mon, 9 Jul 2012 11:38:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:22:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> In-Reply-To: <4FF98F21.9060003@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091122.38865.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:19 -0400 (EDT) Cc: Konstantin Belousov , Michael Butler , current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:38:20 -0000 On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: > On 07/08/12 09:34, Konstantin Belousov wrote: > > On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: > >> Sorry, no symbols but this happened twice last night while being the > >> target of a dump over NFS .. > >> > >> root@mail:/var/crash # less info.0 > >> Dump header from device /dev/ada0s1 > >> Architecture: i386 > >> Architecture Version: 2 > >> Dump Length: 252809216B (241 MB) > >> Blocksize: 512 > >> Dumptime: Sun Jul 8 00:21:23 2012 > >> Hostname: mail.auburn.protected-networks.net > >> Magic: FreeBSD Kernel Dump > >> Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 > >> root@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN > >> Panic String: sleeping thread > >> Dump Parity: 2996346376 > >> Bounds: 0 > >> Dump Status: good > >> > >> > >> (kgdb) bt > >> #0 0xc07530cd in doadump () > >> #1 0xc0753656 in kern_reboot () > >> #2 0xc0753cfc in panic () > >> #3 0xc079a34e in propagate_priority () > >> #4 0xc079b5e4 in turnstile_wait () > >> #5 0xc073ea71 in _mtx_lock_sleep () > >> #6 0xc09c4772 in vm_page_unwire () > >> #7 0xc07db039 in vfs_vmio_release () > >> #8 0xc07dd476 in getnewbuf () > >> #9 0xc07de50b in getblk () > >> #10 0xc0966d99 in ffs_balloc_ufs2 () > >> #11 0xc099281e in ffs_write () > >> #12 0xc0a38b05 in VOP_WRITE_APV () > >> #13 0xc068a65e in nfsvno_write () > >> #14 0xc06882e7 in nfsrvd_write () > >> #15 0xc066ea05 in nfsrvd_dorpc () > >> #16 0xc067d42f in nfssvc_program () > >> #17 0xc09356e2 in svc_run_internal () > >> #18 0xc0935b70 in svc_thread_start () > >> #19 0xc07204fb in fork_exit () > >> #20 0xc09fe7a4 in fork_trampoline () > > > > You need to provide: > > 1. exact version of your kernel sources > > This is the CVS equivalent of SVN r238221 > > > 2. complete panic message. There should be backtrace of the 'sleeping > > thread', not the paniced thread, right after the panic message. > > > > Sorry, that is the entire info file - nothing more than I've posted is > logged, For future reference, you can look at the core.txt.0 file generated by crashinfo. It should contain the dmesg near the bottom and you could have gotten the stack trace of the broken thread from that. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:38:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECB56106564A; Mon, 9 Jul 2012 15:38:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C04D28FC0A; Mon, 9 Jul 2012 15:38:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1DD16B98B; Mon, 9 Jul 2012 11:38:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:22:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> In-Reply-To: <4FF98F21.9060003@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091122.38865.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:19 -0400 (EDT) Cc: Konstantin Belousov , Michael Butler , current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:38:20 -0000 On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: > On 07/08/12 09:34, Konstantin Belousov wrote: > > On Sun, Jul 08, 2012 at 08:46:32AM -0400, Michael Butler wrote: > >> Sorry, no symbols but this happened twice last night while being the > >> target of a dump over NFS .. > >> > >> root@mail:/var/crash # less info.0 > >> Dump header from device /dev/ada0s1 > >> Architecture: i386 > >> Architecture Version: 2 > >> Dump Length: 252809216B (241 MB) > >> Blocksize: 512 > >> Dumptime: Sun Jul 8 00:21:23 2012 > >> Hostname: mail.auburn.protected-networks.net > >> Magic: FreeBSD Kernel Dump > >> Version String: FreeBSD 10.0-CURRENT #87: Sat Jul 7 22:39:55 EDT 2012 > >> root@mail.auburn.protected-networks.net:/usr/obj/usr/src/sys/AUBURN > >> Panic String: sleeping thread > >> Dump Parity: 2996346376 > >> Bounds: 0 > >> Dump Status: good > >> > >> > >> (kgdb) bt > >> #0 0xc07530cd in doadump () > >> #1 0xc0753656 in kern_reboot () > >> #2 0xc0753cfc in panic () > >> #3 0xc079a34e in propagate_priority () > >> #4 0xc079b5e4 in turnstile_wait () > >> #5 0xc073ea71 in _mtx_lock_sleep () > >> #6 0xc09c4772 in vm_page_unwire () > >> #7 0xc07db039 in vfs_vmio_release () > >> #8 0xc07dd476 in getnewbuf () > >> #9 0xc07de50b in getblk () > >> #10 0xc0966d99 in ffs_balloc_ufs2 () > >> #11 0xc099281e in ffs_write () > >> #12 0xc0a38b05 in VOP_WRITE_APV () > >> #13 0xc068a65e in nfsvno_write () > >> #14 0xc06882e7 in nfsrvd_write () > >> #15 0xc066ea05 in nfsrvd_dorpc () > >> #16 0xc067d42f in nfssvc_program () > >> #17 0xc09356e2 in svc_run_internal () > >> #18 0xc0935b70 in svc_thread_start () > >> #19 0xc07204fb in fork_exit () > >> #20 0xc09fe7a4 in fork_trampoline () > > > > You need to provide: > > 1. exact version of your kernel sources > > This is the CVS equivalent of SVN r238221 > > > 2. complete panic message. There should be backtrace of the 'sleeping > > thread', not the paniced thread, right after the panic message. > > > > Sorry, that is the entire info file - nothing more than I've posted is > logged, For future reference, you can look at the core.txt.0 file generated by crashinfo. It should contain the dmesg near the bottom and you could have gotten the stack trace of the broken thread from that. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:38:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB831065672; Mon, 9 Jul 2012 15:38:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 261DF8FC0C; Mon, 9 Jul 2012 15:38:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 85394B9B0; Mon, 9 Jul 2012 11:38:20 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:24:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120708150225.GA2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120708150225.GA2338@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207091124.52044.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:20 -0400 (EDT) Cc: Konstantin Belousov , amd64@freebsd.org Subject: Re: XSAVEOPT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:38:21 -0000 On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote: > Please find at > http://people.freebsd.org/~kib/misc/xsaveopt.1.patch > a patch to finally add suport for using XSAVEOPT for our amd64 context > switch code. See Intel SDM for description of the XSAVEOPT instruction. > > Summary is that the instruction allows to not write parts of the FPU > state which was not touched by the thread. Context switch then would > write less to the PCB when thread is moved out from CPU. This is mainly > to facilitate the ever-growing size of the FPU register file, in > particular, AVX/YMM registers. Normal applications do not touch YMM, so > saving them on each context switch if FPU was used is waste. > > Main complication is that any consumer of the ucontext_t still expect to > see fully populated machine state, including the extended states which were > not saved. Since CPU only avoids save when corresponding state is pristine, > we can use the copy of initial state. CPUID provides an enumerator that > allows OS to easily pick up neccesary area and copy over. > > I tried hard, but was unable to measure any statistically significant > difference in the context switch times between XSAVE and XSAVEOPT using > lmbench lat_ctx, on Core i7 2600K. Hmm, I thought one of the ideas of xsaveopt was to let you just always execute it during a context switch and dispense with the need for using the CR0_TS flag at all? Maybe that isn't true though. It would seem rather silly to switch out the state if you don't need to (when preempting a thread that uses the FPU to run a thread that doesn't and then switching back for example). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:38:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A96CF106564A; Mon, 9 Jul 2012 15:38:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D83E8FC17; Mon, 9 Jul 2012 15:38:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E2A7BB9B9; Mon, 9 Jul 2012 11:38:21 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 9 Jul 2012 11:27:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> In-Reply-To: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091127.30289.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 11:38:22 -0400 (EDT) Cc: FreeBSD Hackers , Arnaud Lacombe , Warner Losh Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:38:22 -0000 On Monday, July 09, 2012 12:39:03 am Warner Losh wrote: > > On Jul 8, 2012, at 9:59 PM, Arnaud Lacombe wrote: > > > Hi, > > > > On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: > >> > >> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: > >>> Ok, yet another Newbus' limitation. Assuming a device exports more > >>> than one interface, and one of its child has need to use more than one > >>> interface, each interfaces cannot register, concurrently, its own > >>> ivar. While I try to always have a single child per > >>> interface/resource, I need to keep some compatibility with the old way > >>> of doing thing (POLA wrt. drivers I cannot/will not convert and > >>> userland). So, it would have been nice if ivar had been per-interface, > >>> not global and unique to one device. > >> > >> There's one pointer for the ivars. The bus code gets to determine what the ivar looks like, because the interface is totally private to the bus. So long as it returns the right thing for any key that's presented, it doesn't matter quite how things are done. > >> > >> So I'm not sure I understand what you are saying here. > >> > >> The problem, more basically, is that the ivar keys are not unique. Currently, there's no bits used in the key to define the values to be non- overlapping. For example: > >> enum pci_device_ivars { > >> PCI_IVAR_SUBVENDOR, > >> PCI_IVAR_SUBDEVICE, > >> PCI_IVAR_VENDOR, > >> .... > >> }; > >> > >> We could easily reserve the upper 16-bits of this field to be that key. This value could then be used to differentiate them. But this wouldn't scale too well. Given that there's only about a dozen or two in the tree, that's right at the moment, it wouldn't be hard to do something like: > >> > >> enum ivar_namespace { > >> IVAR_PCI = 1, > >> IVAR_PCCARD, > >> IVAR_USB, > >> etc > >> }; > >> #define IVAR_SHIFT 16 > >> > >> and the above could be changed to: > >> > >> enum pci_device_ivars { > >> PCI_IVAR_SUBVENDOR = IVAR_PCI << IVAR_SHIFT, > >> PCI_IVAR_SUBDEVICE, > >> PCI_IVAR_VENDOR, > >> .... > >> }; > >> > >> and then we'd have an unambiguous key, and the bus could easily implement multiple interfaces. > >> > >> but then again, most of the existing interfaces in the kernel are mutually exclusive, so you could implement this just for your new interfaces. > >> > > ok, I think I got it now. You and I are exactly saying the same thing, > > just in different terms; there is no way to currently specify multiple > > independent (/overlapping) ivars in a child... > > There's no way to support overlapping IVAR keys, yes. However, if you are designing the ivars for multiple inheritance, then you'll need to make them non-overlapping. Thankfully, this is trivial to do. Also, I think we should do this in general. We already have one example (e.g. ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can provide both ACPI and PCI IVARs to child devices). I think we should assign each bus it's own IVAR range. It would make it easier to determine if a specific IVAR is event supported. Certainly I think ISA and PCI at a minimum should be changed to start at, say, 200 and 300. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 15:41:41 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C746A106566C; Mon, 9 Jul 2012 15:41:41 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8DEBF8FC0C; Mon, 9 Jul 2012 15:41:41 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 33C7B617C; Mon, 9 Jul 2012 11:41:39 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=im9sS8IaDMKYTMyJguvtyZnGE7ZzFg+ASDmSGI1hd6bOEauXafrL+xBZLgOdltYMq hHc4divl+njuLg/JYrp6tOs7N+gwQE9IU5jFbERGUwq5WL7oBzbqw3wctFzR+1+ Message-ID: <4FFAFBB2.6070909@protected-networks.net> Date: Mon, 09 Jul 2012 11:41:38 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FF98128.6050607@protected-networks.net> <20120708133455.GX2338@deviant.kiev.zoral.com.ua> <4FF98F21.9060003@protected-networks.net> <201207091122.38865.jhb@freebsd.org> In-Reply-To: <201207091122.38865.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 15:41:41 -0000 On 07/09/12 11:22, John Baldwin wrote: > On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: [ .. snip .. ] >> >> Sorry, that is the entire info file - nothing more than I've posted is >> logged, > For future reference, you can look at the core.txt.0 file generated > by crashinfo. It should contain the dmesg near the bottom and you could > have gotten the stack trace of the broken thread from that. While that's usually the case in my experience, none was written with this :-( imb From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 16:05:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 179D4106564A for ; Mon, 9 Jul 2012 16:05:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DEBF48FC17 for ; Mon, 9 Jul 2012 16:05:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 36459B9B0; Mon, 9 Jul 2012 12:05:18 -0400 (EDT) From: John Baldwin To: Kaho Toshikazu Date: Mon, 9 Jul 2012 11:53:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201206301349.58930.erich@alogreentechnologies.com> <201207060813.39867.jhb@freebsd.org> <14213.1341617155@elam.kais.kyoto-u.ac.jp> In-Reply-To: <14213.1341617155@elam.kais.kyoto-u.ac.jp> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091153.25092.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 12:05:18 -0400 (EDT) Cc: Matthias Apitz , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: no keyboard after booting r235646 in laptop FS Amilo D 7830 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 16:05:19 -0000 On Friday, July 06, 2012 7:25:55 pm Kaho Toshikazu wrote: > Hello, > > John Baldwin wrote: > > > Almost all systems use one of the IDs we do support as a _CID if not a _HID. > > In fact, in this case it likely seems to be a BIOS bug as it used the same > > value for the _CID and _HID. I suspect it is supposed to be using 0303 as its > > _CID. > > I don't think the BIOS should say PNP0303 as a keyboard _CID. > Using _CID may help some systems, but it may not be helpful > for many systems having keyboard probe problem. > I think it's a specification bug made by Microsoft, > same devices connected different type devices should not have > different ID but same ID. Well, my point is that having a _HID and _CID with the same ID is pointless. It really does look like a typo in the BIOS source. > People with this problem can override AML code, > but I don't think it is a bad idea adding other IDs to the list for probing. Adding IDs is cheap, so I'm fine with doing so. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 16:05:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC37D106566B for ; Mon, 9 Jul 2012 16:05:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A201E8FC19 for ; Mon, 9 Jul 2012 16:05:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F414EB943; Mon, 9 Jul 2012 12:05:18 -0400 (EDT) From: John Baldwin To: Michael Butler Date: Mon, 9 Jul 2012 11:54:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FF98128.6050607@protected-networks.net> <201207091122.38865.jhb@freebsd.org> <4FFAFBB2.6070909@protected-networks.net> In-Reply-To: <4FFAFBB2.6070909@protected-networks.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207091154.25414.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Jul 2012 12:05:19 -0400 (EDT) Cc: Konstantin Belousov , current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 16:05:19 -0000 On Monday, July 09, 2012 11:41:38 am Michael Butler wrote: > On 07/09/12 11:22, John Baldwin wrote: > > On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: > > [ .. snip .. ] > > >> > >> Sorry, that is the entire info file - nothing more than I've posted is > >> logged, > > > For future reference, you can look at the core.txt.0 file generated > > by crashinfo. It should contain the dmesg near the bottom and you could > > have gotten the stack trace of the broken thread from that. > > While that's usually the case in my experience, none was written with > this :-( Humm, you can also get to it in kgdb via this: printf "%s", msgbufp->msg_ptr -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 16:08:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 738C5106566B; Mon, 9 Jul 2012 16:08:30 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 375B28FC16; Mon, 9 Jul 2012 16:08:30 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id C9A7E617C; Mon, 9 Jul 2012 12:08:23 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=gupo9ooYzCGDFD/iFhmaPSmAyTKJqHKuU6eG0BWjOlNyFP+5n6w+rkVNNZWeWJdC/ CoA8j299d/v9vXrNZIBpwKVzJ9F7UurMpq5wLfZksS+Dtsu0ClqQN8uHlADOsRo Message-ID: <4FFB01F5.80803@protected-networks.net> Date: Mon, 09 Jul 2012 12:08:21 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <4FF98128.6050607@protected-networks.net> <201207091122.38865.jhb@freebsd.org> <4FFAFBB2.6070909@protected-networks.net> <201207091154.25414.jhb@freebsd.org> In-Reply-To: <201207091154.25414.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , current@freebsd.org Subject: Re: sleeping thread panic? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 16:08:30 -0000 On 07/09/12 11:54, John Baldwin wrote: > On Monday, July 09, 2012 11:41:38 am Michael Butler wrote: >> On 07/09/12 11:22, John Baldwin wrote: >>> On Sunday, July 08, 2012 9:46:09 am Michael Butler wrote: >> >> [ .. snip .. ] >> >>>> >>>> Sorry, that is the entire info file - nothing more than I've posted is >>>> logged, >> >>> For future reference, you can look at the core.txt.0 file generated >>> by crashinfo. It should contain the dmesg near the bottom and you could >>> have gotten the stack trace of the broken thread from that. >> >> While that's usually the case in my experience, none was written with >> this :-( > > Humm, you can also get to it in kgdb via this: > > printf "%s", msgbufp->msg_ptr > Thanks! Archived for future reference :-) imb From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 19:26:51 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAFCA106564A; Mon, 9 Jul 2012 19:26:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2B78FC0A; Mon, 9 Jul 2012 19:26:48 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q69JQq9p073401; Mon, 9 Jul 2012 22:26:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q69JQdd7077639; Mon, 9 Jul 2012 22:26:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q69JQdfZ077638; Mon, 9 Jul 2012 22:26:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Jul 2012 22:26:39 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120709192639.GT2338@deviant.kiev.zoral.com.ua> References: <20120708150225.GA2338@deviant.kiev.zoral.com.ua> <201207091124.52044.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UefMXxAhg/xpzpuf" Content-Disposition: inline In-Reply-To: <201207091124.52044.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: amd64@freebsd.org, freebsd-current@freebsd.org Subject: Re: XSAVEOPT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 19:26:51 -0000 --UefMXxAhg/xpzpuf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 09, 2012 at 11:24:52AM -0400, John Baldwin wrote: > On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote: > > Please find at > > http://people.freebsd.org/~kib/misc/xsaveopt.1.patch > > a patch to finally add suport for using XSAVEOPT for our amd64 context > > switch code. See Intel SDM for description of the XSAVEOPT instruction. > >=20 > > Summary is that the instruction allows to not write parts of the FPU > > state which was not touched by the thread. Context switch then would > > write less to the PCB when thread is moved out from CPU. This is mainly > > to facilitate the ever-growing size of the FPU register file, in > > particular, AVX/YMM registers. Normal applications do not touch YMM, so > > saving them on each context switch if FPU was used is waste. > >=20 > > Main complication is that any consumer of the ucontext_t still expect to > > see fully populated machine state, including the extended states which = were > > not saved. Since CPU only avoids save when corresponding state is prist= ine, > > we can use the copy of initial state. CPUID provides an enumerator that > > allows OS to easily pick up neccesary area and copy over. > >=20 > > I tried hard, but was unable to measure any statistically significant > > difference in the context switch times between XSAVE and XSAVEOPT using > > lmbench lat_ctx, on Core i7 2600K. >=20 > Hmm, I thought one of the ideas of xsaveopt was to let you just always ex= ecute > it during a context switch and dispense with the need for using the CR0_T= S=20 > flag at all? Maybe that isn't true though. It would seem rather silly to > switch out the state if you don't need to (when preempting a thread that = uses=20 > the FPU to run a thread that doesn't and then switching back for example). To always execute XSAVEOPT, we would need always execute XRSTOR. Not executing XSAVEOPT is always faster then executing it. In fact, during the testing, I never seen a situation when x87 of XMM areas would be not saved by XSAVEOPT. Only YMM registers were omited if the process did not touched them since start. --UefMXxAhg/xpzpuf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/7MG8ACgkQC3+MBN1Mb4j4hgCgtmMK7yKhh+XkYS/zNyMM3rCf qUEAoO4WsJjXHDVs3A3wcbC/1oVDRjGG =drT7 -----END PGP SIGNATURE----- --UefMXxAhg/xpzpuf-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 23:15:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E93B106566C for ; Mon, 9 Jul 2012 23:15:21 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id D933B8FC0C for ; Mon, 9 Jul 2012 23:15:20 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SoNAf-0002ZY-Nj for freebsd-current@freebsd.org; Tue, 10 Jul 2012 00:15:13 +0100 Received: from cpc1-aztw9-0-0-cust540.18-1.cable.virginmedia.com ([82.33.90.29] helo=mech-aslap239.men.bris.ac.uk) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SoNAe-0007Vb-KL for freebsd-current@freebsd.org; Tue, 10 Jul 2012 00:15:13 +0100 Received: from mech-aslap239.men.bris.ac.uk (localhost [127.0.0.1]) by mech-aslap239.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q69NFB1I001195 for ; Tue, 10 Jul 2012 00:15:11 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-aslap239.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q69MqAtd001053 for freebsd-current@freebsd.org; Mon, 9 Jul 2012 23:52:10 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-aslap239.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Mon, 9 Jul 2012 23:52:10 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 23:15:21 -0000 I'm on amd64 r238259. I'm still not clear on the /usr/src/UPDATING entry from 20110424 on replacing the ATA drivers by CAM drivers. If I *do not* have device ata in the kernel, I have neither /dev/cd* or /dev/acd*, even though I have in the kernel: options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device ada device cd # CD If I then add device ata to the kernel, then /dev/cd0 appears: cd0 at ata0 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [248633 x 2048 byte records] Is that expected? My understanding of the above /usr/src/UPDATING entry is that device ata should not be needed. Am I wrong? # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ada0s1b none swap sw 0 0 /dev/ada0s1a / ufs rw 1 1 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/da0s1 /mnt msdosfs rw,noauto 0 0 # Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Jul 9 23:39:03 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66FD2106566B for ; Mon, 9 Jul 2012 23:39:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 449008FC0A for ; Mon, 9 Jul 2012 23:39:03 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q69NcvrK016371 for ; Mon, 9 Jul 2012 16:38:57 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q69NcvMc016364 for freebsd-current@freebsd.org; Mon, 9 Jul 2012 16:38:57 -0700 (PDT) (envelope-from sgk) Date: Mon, 9 Jul 2012 16:38:57 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20120709233857.GA12046@troutmask.apl.washington.edu> References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 09 Jul 2012 23:39:03 -0000 On Mon, Jul 09, 2012 at 11:52:10PM +0100, Anton Shterenlikht wrote: > I'm on amd64 r238259. > > I'm still not clear on the /usr/src/UPDATING > entry from 20110424 on replacing the ATA > drivers by CAM drivers. > > If I *do not* have device ata in the kernel, > I have neither /dev/cd* or /dev/acd*, > even though I have in the kernel: > > options ATA_CAM # Handle legacy controllers with CAM > options ATA_STATIC_ID # Static device numbering > device ada > device cd # CD > man 4 cam I suspect that you are missing 'device scbus' in your config file. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 00:14:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1A261065672 for ; Tue, 10 Jul 2012 00:14:01 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A83ED8FC1A for ; Tue, 10 Jul 2012 00:14:01 +0000 (UTC) Received: by obbun3 with SMTP id un3so1530752obb.13 for ; Mon, 09 Jul 2012 17:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bXLBvlAkUDLJJ8ATEGfBWKLr+tiSYNUXw3nkO35FHzo=; b=Bz2093KeB9ANXTwyCoiKeNcZkrUFfBE5UvBzeG9JdTcjPhLZqGMvnlL9WF9TVDtxdq 872jc7cR64tBXg/r0yeLWQFr61+n250MJe+WgBFB73cq4XqhlUHrnQFocN0IHJsbxF9h K5bTJblq6QfZZa034ytMtVPxxsXOIxuucudNzQ6XQlmuo9JK1e9uP0ixW/XAIu9yvLQh wdjOjgpLpfyeBm5Mh3h2U3km5M3zJLG6zujo5EZ4K5P1Ye4oEk73dFWEtekD256ktTnm N2AQc4lCjcyAmNq4wPMiCS2VLYqOLOttYbTjml4aKoasmAzjwd1WXSiYYEfwyusk6bOi 2xAg== MIME-Version: 1.0 Received: by 10.182.110.102 with SMTP id hz6mr38173955obb.79.1341879241145; Mon, 09 Jul 2012 17:14:01 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Mon, 9 Jul 2012 17:14:01 -0700 (PDT) In-Reply-To: <20120709233857.GA12046@troutmask.apl.washington.edu> References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> <20120709233857.GA12046@troutmask.apl.washington.edu> Date: Mon, 9 Jul 2012 17:14:01 -0700 Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 00:14:02 -0000 On Mon, Jul 9, 2012 at 4:38 PM, Steve Kargl wrote: > On Mon, Jul 09, 2012 at 11:52:10PM +0100, Anton Shterenlikht wrote: >> I'm on amd64 r238259. >> >> I'm still not clear on the /usr/src/UPDATING >> entry from 20110424 on replacing the ATA >> drivers by CAM drivers. >> >> If I *do not* have device ata in the kernel, >> I have neither /dev/cd* or /dev/acd*, >> even though I have in the kernel: >> >> options ATA_CAM # Handle legacy controllers with CAM >> options ATA_STATIC_ID # Static device numbering >> device ada >> device cd # CD >> > > man 4 cam > > I suspect that you are missing 'device scbus' in > your config file. device scbus # SCSI bus (required for ATA/SCSI) Probably. And as the fine print says... Note that to use CAM-based ATA kernel should include CAM devices scbus, pass, da (or explicitly ada), cd and optionally others. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 05:33:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D743106566B; Tue, 10 Jul 2012 05:33:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DADC38FC0C; Tue, 10 Jul 2012 05:33:39 +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 q6A5L5a9004144; Tue, 10 Jul 2012 01:21:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A5L5JP004139; Tue, 10 Jul 2012 05:21:05 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 05:21:05 GMT Message-Id: <201207100521.q6A5L5JP004139@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:33:40 -0000 TB --- 2012-07-10 03:01:42 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 03:01:42 - 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 --- 2012-07-10 03:01:42 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-10 03:01:42 - cleaning the object tree TB --- 2012-07-10 03:01:42 - cvsupping the source tree TB --- 2012-07-10 03:01:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-10 03:02:24 - building world TB --- 2012-07-10 03:02:24 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 03:02:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 03:02:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 03:02:24 - SRCCONF=/dev/null TB --- 2012-07-10 03:02:24 - TARGET=powerpc TB --- 2012-07-10 03:02:24 - TARGET_ARCH=powerpc TB --- 2012-07-10 03:02:24 - TZ=UTC TB --- 2012-07-10 03:02:24 - __MAKE_CONF=/dev/null TB --- 2012-07-10 03:02:24 - cd /src TB --- 2012-07-10 03:02:24 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 03:02:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 05:17:19 UTC 2012 TB --- 2012-07-10 05:17:19 - generating LINT kernel config TB --- 2012-07-10 05:17:19 - cd /src/sys/powerpc/conf TB --- 2012-07-10 05:17:19 - /usr/bin/make -B LINT TB --- 2012-07-10 05:17:19 - cd /src/sys/powerpc/conf TB --- 2012-07-10 05:17:19 - /usr/sbin/config -m LINT TB --- 2012-07-10 05:17:19 - building LINT kernel TB --- 2012-07-10 05:17:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 05:17:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 05:17:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 05:17:19 - SRCCONF=/dev/null TB --- 2012-07-10 05:17:19 - TARGET=powerpc TB --- 2012-07-10 05:17:19 - TARGET_ARCH=powerpc TB --- 2012-07-10 05:17:19 - TZ=UTC TB --- 2012-07-10 05:17:19 - __MAKE_CONF=/dev/null TB --- 2012-07-10 05:17:19 - cd /src TB --- 2012-07-10 05:17:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 05:17:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 05:21:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 05:21:05 - ERROR: failed to build LINT kernel TB --- 2012-07-10 05:21:05 - 6772.30 user 886.02 system 8362.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 05:45:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE69106564A; Tue, 10 Jul 2012 05:45:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4C42A8FC0A; Tue, 10 Jul 2012 05:45:56 +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 q6A5jtIw095677; Tue, 10 Jul 2012 01:45:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A5jtE1095672; Tue, 10 Jul 2012 05:45:55 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 05:45:55 GMT Message-Id: <201207100545.q6A5jtE1095672@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:45:56 -0000 TB --- 2012-07-10 04:39:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 04:39: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 --- 2012-07-10 04:39:59 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 04:39:59 - cleaning the object tree TB --- 2012-07-10 04:39:59 - cvsupping the source tree TB --- 2012-07-10 04:39:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 04:41:35 - building world TB --- 2012-07-10 04:41:35 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 04:41:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 04:41:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 04:41:35 - SRCCONF=/dev/null TB --- 2012-07-10 04:41:35 - TARGET=sparc64 TB --- 2012-07-10 04:41:35 - TARGET_ARCH=sparc64 TB --- 2012-07-10 04:41:35 - TZ=UTC TB --- 2012-07-10 04:41:35 - __MAKE_CONF=/dev/null TB --- 2012-07-10 04:41:35 - cd /src TB --- 2012-07-10 04:41:35 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 04:41:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 05:41:59 UTC 2012 TB --- 2012-07-10 05:41:59 - generating LINT kernel config TB --- 2012-07-10 05:41:59 - cd /src/sys/sparc64/conf TB --- 2012-07-10 05:41:59 - /usr/bin/make -B LINT TB --- 2012-07-10 05:41:59 - cd /src/sys/sparc64/conf TB --- 2012-07-10 05:41:59 - /usr/sbin/config -m LINT TB --- 2012-07-10 05:41:59 - building LINT kernel TB --- 2012-07-10 05:41:59 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 05:41:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 05:41:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 05:41:59 - SRCCONF=/dev/null TB --- 2012-07-10 05:41:59 - TARGET=sparc64 TB --- 2012-07-10 05:41:59 - TARGET_ARCH=sparc64 TB --- 2012-07-10 05:41:59 - TZ=UTC TB --- 2012-07-10 05:41:59 - __MAKE_CONF=/dev/null TB --- 2012-07-10 05:41:59 - cd /src TB --- 2012-07-10 05:41:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 05:41:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 05:45:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 05:45:55 - ERROR: failed to build LINT kernel TB --- 2012-07-10 05:45:55 - 3120.60 user 547.45 system 3955.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 06:32:15 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FAAB106564A; Tue, 10 Jul 2012 06:32:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 570BB8FC12; Tue, 10 Jul 2012 06:32:15 +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 q6A6WED9009844; Tue, 10 Jul 2012 02:32:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A6WEAd009843; Tue, 10 Jul 2012 06:32:14 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 06:32:14 GMT Message-Id: <201207100632.q6A6WEAd009843@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 06:32:15 -0000 TB --- 2012-07-10 03:50:39 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 03:50:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 03:50:39 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-10 03:50:40 - cleaning the object tree TB --- 2012-07-10 03:50:40 - cvsupping the source tree TB --- 2012-07-10 03:50:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-10 03:51:28 - building world TB --- 2012-07-10 03:51:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 03:51:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 03:51:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 03:51:28 - SRCCONF=/dev/null TB --- 2012-07-10 03:51:28 - TARGET=powerpc TB --- 2012-07-10 03:51:28 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 03:51:28 - TZ=UTC TB --- 2012-07-10 03:51:28 - __MAKE_CONF=/dev/null TB --- 2012-07-10 03:51:28 - cd /src TB --- 2012-07-10 03:51:28 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 03:51:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 10 06:28:46 UTC 2012 TB --- 2012-07-10 06:28:46 - generating LINT kernel config TB --- 2012-07-10 06:28:46 - cd /src/sys/powerpc/conf TB --- 2012-07-10 06:28:46 - /usr/bin/make -B LINT TB --- 2012-07-10 06:28:46 - cd /src/sys/powerpc/conf TB --- 2012-07-10 06:28:46 - /usr/sbin/config -m LINT TB --- 2012-07-10 06:28:46 - building LINT kernel TB --- 2012-07-10 06:28:46 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 06:28:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 06:28:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 06:28:46 - SRCCONF=/dev/null TB --- 2012-07-10 06:28:46 - TARGET=powerpc TB --- 2012-07-10 06:28:46 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 06:28:46 - TZ=UTC TB --- 2012-07-10 06:28:46 - __MAKE_CONF=/dev/null TB --- 2012-07-10 06:28:46 - cd /src TB --- 2012-07-10 06:28:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 06:28:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 06:32:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 06:32:14 - ERROR: failed to build LINT kernel TB --- 2012-07-10 06:32:14 - 8211.63 user 1080.95 system 9694.49 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:26:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A66F1106566B; Tue, 10 Jul 2012 08:26:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 62A5F8FC18; Tue, 10 Jul 2012 08:26:05 +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 q6A8Q4ld061283; Tue, 10 Jul 2012 04:26:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A8Q4Dp061279; Tue, 10 Jul 2012 08:26:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 08:26:04 GMT Message-Id: <201207100826.q6A8Q4Dp061279@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:26:05 -0000 TB --- 2012-07-10 06:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 06:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 06:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-10 06:40:01 - cleaning the object tree TB --- 2012-07-10 06:40:01 - cvsupping the source tree TB --- 2012-07-10 06:40:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-10 06:41:08 - building world TB --- 2012-07-10 06:41:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 06:41:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 06:41:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 06:41:08 - SRCCONF=/dev/null TB --- 2012-07-10 06:41:08 - TARGET=arm TB --- 2012-07-10 06:41:08 - TARGET_ARCH=arm TB --- 2012-07-10 06:41:08 - TZ=UTC TB --- 2012-07-10 06:41:08 - __MAKE_CONF=/dev/null TB --- 2012-07-10 06:41:08 - cd /src TB --- 2012-07-10 06:41:08 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 06:41:08 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 07:49:42 UTC 2012 TB --- 2012-07-10 07:49:42 - cd /src/sys/arm/conf TB --- 2012-07-10 07:49:42 - /usr/sbin/config -m ATMEL TB --- 2012-07-10 07:49:42 - building ATMEL kernel TB --- 2012-07-10 07:49:42 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 07:49:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 07:49:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 07:49:42 - SRCCONF=/dev/null TB --- 2012-07-10 07:49:42 - TARGET=arm TB --- 2012-07-10 07:49:42 - TARGET_ARCH=arm TB --- 2012-07-10 07:49:42 - TZ=UTC TB --- 2012-07-10 07:49:42 - __MAKE_CONF=/dev/null TB --- 2012-07-10 07:49:42 - cd /src TB --- 2012-07-10 07:49:42 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Jul 10 07:49:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Jul 10 07:53:11 UTC 2012 TB --- 2012-07-10 07:53:11 - cd /src/sys/arm/conf TB --- 2012-07-10 07:53:11 - /usr/sbin/config -m AVILA TB --- 2012-07-10 07:53:11 - building AVILA kernel TB --- 2012-07-10 07:53:11 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 07:53:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 07:53:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 07:53:11 - SRCCONF=/dev/null TB --- 2012-07-10 07:53:11 - TARGET=arm TB --- 2012-07-10 07:53:11 - TARGET_ARCH=arm TB --- 2012-07-10 07:53:11 - TZ=UTC TB --- 2012-07-10 07:53:11 - __MAKE_CONF=/dev/null TB --- 2012-07-10 07:53:11 - cd /src TB --- 2012-07-10 07:53:11 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue Jul 10 07:53:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Tue Jul 10 07:56:16 UTC 2012 TB --- 2012-07-10 07:56:16 - cd /src/sys/arm/conf TB --- 2012-07-10 07:56:16 - /usr/sbin/config -m BWCT TB --- 2012-07-10 07:56:16 - building BWCT kernel TB --- 2012-07-10 07:56:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 07:56:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 07:56:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 07:56:16 - SRCCONF=/dev/null TB --- 2012-07-10 07:56:16 - TARGET=arm TB --- 2012-07-10 07:56:16 - TARGET_ARCH=arm TB --- 2012-07-10 07:56:16 - TZ=UTC TB --- 2012-07-10 07:56:16 - __MAKE_CONF=/dev/null TB --- 2012-07-10 07:56:16 - cd /src TB --- 2012-07-10 07:56:16 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Jul 10 07:56:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Tue Jul 10 07:58:27 UTC 2012 TB --- 2012-07-10 07:58:27 - cd /src/sys/arm/conf TB --- 2012-07-10 07:58:27 - /usr/sbin/config -m CAMBRIA TB --- 2012-07-10 07:58:27 - building CAMBRIA kernel TB --- 2012-07-10 07:58:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 07:58:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 07:58:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 07:58:27 - SRCCONF=/dev/null TB --- 2012-07-10 07:58:27 - TARGET=arm TB --- 2012-07-10 07:58:27 - TARGET_ARCH=arm TB --- 2012-07-10 07:58:27 - TZ=UTC TB --- 2012-07-10 07:58:27 - __MAKE_CONF=/dev/null TB --- 2012-07-10 07:58:27 - cd /src TB --- 2012-07-10 07:58:27 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Tue Jul 10 07:58:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Tue Jul 10 08:01:29 UTC 2012 TB --- 2012-07-10 08:01:29 - cd /src/sys/arm/conf TB --- 2012-07-10 08:01:29 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-07-10 08:01:29 - building CNS11XXNAS kernel TB --- 2012-07-10 08:01:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:01:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:01:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:01:29 - SRCCONF=/dev/null TB --- 2012-07-10 08:01:29 - TARGET=arm TB --- 2012-07-10 08:01:29 - TARGET_ARCH=arm TB --- 2012-07-10 08:01:29 - TZ=UTC TB --- 2012-07-10 08:01:29 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:01:29 - cd /src TB --- 2012-07-10 08:01:29 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Tue Jul 10 08:01:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Tue Jul 10 08:04:05 UTC 2012 TB --- 2012-07-10 08:04:05 - cd /src/sys/arm/conf TB --- 2012-07-10 08:04:05 - /usr/sbin/config -m CRB TB --- 2012-07-10 08:04:05 - building CRB kernel TB --- 2012-07-10 08:04:05 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:04:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:04:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:04:05 - SRCCONF=/dev/null TB --- 2012-07-10 08:04:05 - TARGET=arm TB --- 2012-07-10 08:04:05 - TARGET_ARCH=arm TB --- 2012-07-10 08:04:05 - TZ=UTC TB --- 2012-07-10 08:04:05 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:04:05 - cd /src TB --- 2012-07-10 08:04:05 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Tue Jul 10 08:04:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Tue Jul 10 08:07:31 UTC 2012 TB --- 2012-07-10 08:07:31 - cd /src/sys/arm/conf TB --- 2012-07-10 08:07:31 - /usr/sbin/config -m DB-78XXX TB --- 2012-07-10 08:07:31 - building DB-78XXX kernel TB --- 2012-07-10 08:07:31 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:07:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:07:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:07:31 - SRCCONF=/dev/null TB --- 2012-07-10 08:07:31 - TARGET=arm TB --- 2012-07-10 08:07:31 - TARGET_ARCH=arm TB --- 2012-07-10 08:07:31 - TZ=UTC TB --- 2012-07-10 08:07:31 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:07:31 - cd /src TB --- 2012-07-10 08:07:31 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Tue Jul 10 08:07:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Tue Jul 10 08:10:19 UTC 2012 TB --- 2012-07-10 08:10:19 - cd /src/sys/arm/conf TB --- 2012-07-10 08:10:19 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-07-10 08:10:19 - building DB-88F5XXX kernel TB --- 2012-07-10 08:10:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:10:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:10:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:10:19 - SRCCONF=/dev/null TB --- 2012-07-10 08:10:19 - TARGET=arm TB --- 2012-07-10 08:10:19 - TARGET_ARCH=arm TB --- 2012-07-10 08:10:19 - TZ=UTC TB --- 2012-07-10 08:10:19 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:10:19 - cd /src TB --- 2012-07-10 08:10:19 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Tue Jul 10 08:10:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Tue Jul 10 08:13:01 UTC 2012 TB --- 2012-07-10 08:13:01 - cd /src/sys/arm/conf TB --- 2012-07-10 08:13:01 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-07-10 08:13:01 - building DB-88F6XXX kernel TB --- 2012-07-10 08:13:01 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:13:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:13:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:13:01 - SRCCONF=/dev/null TB --- 2012-07-10 08:13:01 - TARGET=arm TB --- 2012-07-10 08:13:01 - TARGET_ARCH=arm TB --- 2012-07-10 08:13:01 - TZ=UTC TB --- 2012-07-10 08:13:01 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:13:01 - cd /src TB --- 2012-07-10 08:13:01 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Tue Jul 10 08:13:01 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Tue Jul 10 08:15:53 UTC 2012 TB --- 2012-07-10 08:15:53 - cd /src/sys/arm/conf TB --- 2012-07-10 08:15:53 - /usr/sbin/config -m DOCKSTAR TB --- 2012-07-10 08:15:53 - building DOCKSTAR kernel TB --- 2012-07-10 08:15:53 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:15:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:15:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:15:53 - SRCCONF=/dev/null TB --- 2012-07-10 08:15:53 - TARGET=arm TB --- 2012-07-10 08:15:53 - TARGET_ARCH=arm TB --- 2012-07-10 08:15:53 - TZ=UTC TB --- 2012-07-10 08:15:53 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:15:53 - cd /src TB --- 2012-07-10 08:15:53 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Tue Jul 10 08:15:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Tue Jul 10 08:18:29 UTC 2012 TB --- 2012-07-10 08:18:29 - cd /src/sys/arm/conf TB --- 2012-07-10 08:18:29 - /usr/sbin/config -m EP80219 TB --- 2012-07-10 08:18:29 - building EP80219 kernel TB --- 2012-07-10 08:18:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:18:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:18:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:18:29 - SRCCONF=/dev/null TB --- 2012-07-10 08:18:29 - TARGET=arm TB --- 2012-07-10 08:18:29 - TARGET_ARCH=arm TB --- 2012-07-10 08:18:29 - TZ=UTC TB --- 2012-07-10 08:18:29 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:18:29 - cd /src TB --- 2012-07-10 08:18:29 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Tue Jul 10 08:18:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EP80219 completed on Tue Jul 10 08:21:23 UTC 2012 TB --- 2012-07-10 08:21:23 - cd /src/sys/arm/conf TB --- 2012-07-10 08:21:23 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-07-10 08:21:23 - building ETHERNUT5 kernel TB --- 2012-07-10 08:21:23 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:21:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:21:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:21:23 - SRCCONF=/dev/null TB --- 2012-07-10 08:21:23 - TARGET=arm TB --- 2012-07-10 08:21:23 - TARGET_ARCH=arm TB --- 2012-07-10 08:21:23 - TZ=UTC TB --- 2012-07-10 08:21:23 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:21:23 - cd /src TB --- 2012-07-10 08:21:23 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Tue Jul 10 08:21:23 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_led.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_rx.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tdma.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_beacon.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_rx_edma.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/modules/ath/../../dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 08:26:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 08:26:04 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-07-10 08:26:04 - 4164.95 user 821.38 system 6363.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 08:59:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27C24106566B for ; Tue, 10 Jul 2012 08:59:02 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C8F1A8FC16 for ; Tue, 10 Jul 2012 08:59:01 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SoWHc-0001NA-AZ; Tue, 10 Jul 2012 11:59:00 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 04EF51CC2D; Tue, 10 Jul 2012 11:58:55 +0300 (EEST) Date: Tue, 10 Jul 2012 11:58:54 +0300 From: Andrey Simonenko To: Vincent Hoffman Message-ID: <20120710085854.GA2947@pm513-1.comsys.ntu-kpi.kiev.ua> References: <497527423.2441665.1341141539082.JavaMail.root@erie.cs.uoguelph.ca> <4FF82B13.8000906@unsane.co.uk> <4FF9C4F6.9020402@unsane.co.uk> <20120709094456.GA1338@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709094456.GA1338@pm513-1.comsys.ntu-kpi.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-07-10 11:59:00 X-Connected-IP: 10.18.52.101:37451 X-Message-Linecount: 36 X-Body-Linecount: 17 X-Message-Size: 1672 X-Body-Size: 790 Cc: Rick Macklem , freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 08:59:02 -0000 This message contains only corrections to typos from my previous message. On Mon, Jul 09, 2012 at 12:44:56PM +0300, Andrey Simonenko wrote: > > Here -alldirs means that /cdrom should be a file system. As I remember > this even worked before revision 1.85 of mountd/mountd.c, then mountd.c > began to use nmount(2). Now if one puts /cdrom in /etc/exports and ^^^^^^\ "/cdrom -alldirs" > Let's consider the same example but without the -alldirs options: > > /usr/local/export -maproot=root 1.2.3.4 > > 3. nfse in the native mode will export /usr if it is or will be a mount point: ^^^^\ /usr/local/export From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 09:29:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78FDF106566B; Tue, 10 Jul 2012 09:29:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7E38FC08; Tue, 10 Jul 2012 09:29:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6A9Tmhk038909; Tue, 10 Jul 2012 05:29:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A9TmJT038899; Tue, 10 Jul 2012 09:29:48 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 09:29:48 GMT Message-Id: <201207100929.q6A9TmJT038899@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:29:49 -0000 TB --- 2012-07-10 06:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 06:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 06:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-10 06:40:01 - cleaning the object tree TB --- 2012-07-10 06:40:01 - cvsupping the source tree TB --- 2012-07-10 06:40:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-10 06:41:08 - building world TB --- 2012-07-10 06:41:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 06:41:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 06:41:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 06:41:08 - SRCCONF=/dev/null TB --- 2012-07-10 06:41:08 - TARGET=pc98 TB --- 2012-07-10 06:41:08 - TARGET_ARCH=i386 TB --- 2012-07-10 06:41:08 - TZ=UTC TB --- 2012-07-10 06:41:08 - __MAKE_CONF=/dev/null TB --- 2012-07-10 06:41:08 - cd /src TB --- 2012-07-10 06:41:08 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 06:41:08 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 09:21:15 UTC 2012 TB --- 2012-07-10 09:21:15 - generating LINT kernel config TB --- 2012-07-10 09:21:15 - cd /src/sys/pc98/conf TB --- 2012-07-10 09:21:15 - /usr/bin/make -B LINT TB --- 2012-07-10 09:21:15 - cd /src/sys/pc98/conf TB --- 2012-07-10 09:21:15 - /usr/sbin/config -m LINT TB --- 2012-07-10 09:21:16 - building LINT kernel TB --- 2012-07-10 09:21:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 09:21:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 09:21:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 09:21:16 - SRCCONF=/dev/null TB --- 2012-07-10 09:21:16 - TARGET=pc98 TB --- 2012-07-10 09:21:16 - TARGET_ARCH=i386 TB --- 2012-07-10 09:21:16 - TZ=UTC TB --- 2012-07-10 09:21:16 - __MAKE_CONF=/dev/null TB --- 2012-07-10 09:21:16 - cd /src TB --- 2012-07-10 09:21:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 09:21:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 09:29:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 09:29:48 - ERROR: failed to build LINT kernel TB --- 2012-07-10 09:29:48 - 6692.59 user 956.95 system 10186.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 09:31:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAA1C1065672; Tue, 10 Jul 2012 09:31:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 71B918FC1D; Tue, 10 Jul 2012 09:31:44 +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 q6A9VhSb048085; Tue, 10 Jul 2012 05:31:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A9VhvF048084; Tue, 10 Jul 2012 09:31:43 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 09:31:43 GMT Message-Id: <201207100931.q6A9VhvF048084@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:31:44 -0000 TB --- 2012-07-10 06:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 06:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 06:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-10 06:40:01 - cleaning the object tree TB --- 2012-07-10 06:40:01 - cvsupping the source tree TB --- 2012-07-10 06:40:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-10 06:47:25 - building world TB --- 2012-07-10 06:47:25 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 06:47:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 06:47:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 06:47:25 - SRCCONF=/dev/null TB --- 2012-07-10 06:47:25 - TARGET=i386 TB --- 2012-07-10 06:47:25 - TARGET_ARCH=i386 TB --- 2012-07-10 06:47:25 - TZ=UTC TB --- 2012-07-10 06:47:25 - __MAKE_CONF=/dev/null TB --- 2012-07-10 06:47:25 - cd /src TB --- 2012-07-10 06:47:25 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 06:47:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 09:22:42 UTC 2012 TB --- 2012-07-10 09:22:42 - generating LINT kernel config TB --- 2012-07-10 09:22:42 - cd /src/sys/i386/conf TB --- 2012-07-10 09:22:42 - /usr/bin/make -B LINT TB --- 2012-07-10 09:22:43 - cd /src/sys/i386/conf TB --- 2012-07-10 09:22:43 - /usr/sbin/config -m LINT TB --- 2012-07-10 09:22:43 - building LINT kernel TB --- 2012-07-10 09:22:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 09:22:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 09:22:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 09:22:43 - SRCCONF=/dev/null TB --- 2012-07-10 09:22:43 - TARGET=i386 TB --- 2012-07-10 09:22:43 - TARGET_ARCH=i386 TB --- 2012-07-10 09:22:43 - TZ=UTC TB --- 2012-07-10 09:22:43 - __MAKE_CONF=/dev/null TB --- 2012-07-10 09:22:43 - cd /src TB --- 2012-07-10 09:22:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 09:22:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 09:31:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 09:31:43 - ERROR: failed to build LINT kernel TB --- 2012-07-10 09:31:43 - 6770.58 user 958.38 system 10302.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 09:51:40 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E42001065672; Tue, 10 Jul 2012 09:51:40 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6F39C8FC1B; Tue, 10 Jul 2012 09:51:40 +0000 (UTC) Received: from wald.nfv.gwdg.de ([134.76.242.31] helo=pc028.nfv) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SoWSP-0004bF-Va; Tue, 10 Jul 2012 11:10:10 +0200 Message-ID: <4FFBF16D.2030007@gwdg.de> Date: Tue, 10 Jul 2012 11:10:05 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> In-Reply-To: <20120708233624.GA53462@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: David Schultz , freebsd-current@FreeBSD.ORG, Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 09:51:41 -0000 On 09.07.2012 01:36 (UTC+2), Steve Kargl wrote: > On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote: >> >> On Jul 8, 2012, at 6:40 AM, David Schultz wrote: >> >>> On Tue, May 29, 2012, Peter Jeremy wrote: >>>> On 2012-May-28 15:54:06 -0700, Steve Kargl wrote: >>>>> Given that cephes was written years before C99 was even >>>>> conceived, I suspect all functions are sub-standard. >>>> >>>> Well, most of cephes was written before C99. The C99 parts of >>>> cephes were written to turn it into a complete C99 implementation. >>> >>> I'm a bit late to the party, but I thought I'd chime in with some >>> context. We did consider using Cephes years ago, and even got >>> permission from the author to release it under an acceptable license. >>> We later decided not to use it for technical reasons. >>> >>> By the way, virtually none of the people who have complained about the >>> missing functions actually need them. Mostly they just want to >>> compile some software that was written by a naive programmer who >>> thought it would be cool to use the most precise type available. The >>> complex functions are even less commonly needed, and the truth is that >>> they have no business being part of the C standard anyway. >>> >>> The question remains of what to do about the missing functions. Bruce >>> and Steve have been working on expl and logl for years. If those ever >>> get in the tree, the remaining long double functions are easy. Those >>> functions are basically done, modulo a bunch of cleanup and testing, >>> and I encourage any mathematically inclined folks who are interested >>> in pushing things along to get in touch with them. I'm not going to >>> have any time myself for a few months at least. >> >> Where can I find these? > > I've posted expl() a few times for the ld80 version. > I don't have an ld128 version, which is why I have > yet to submit a formal patch for expl(). I also > have an ld80 expm1l(). I have a copy of bde's ld80 > logl(). IIRC, bde wrote an ld128, but I don't have > nor do I know if it has been tested. Do you think your version from http://www.freebsd.org/cgi/query-pr.cgi?pr=152415 for expl() ld80 version could be the one getting into head? Would you be willing to commit it? As far as I understand from discussions on R mailing list (r-devel@r-project.org), they plan to reduce the emulation and/or workaround of long and complex math functions for FreeBSD and other systems with their next releases of R devel. So we could really need some progress with our C99 conform math functions ;-) >>> Lastly, there's the question of mediocre alternatives, such as >>> solutions that get the boundary cases wrong or don't handle 128-bit >>> floating point. For the exponential and logarithmic functions, Bruce >>> and Steve have already written good implementations, so there's no >>> reason to settle for less. As for the other long double functions, >>> bringing in some Cephes code in a separate directory as a temporary >>> fix might be the way to go. I don't like that solution, and Steve >>> raises some good technical points about why it isn't ideal; however, a >>> better solution is more than a decade overdue, and people are >>> justified in finding that unacceptable. >> >> Don't let the perfect be the enemy of the good. It is better to >> have OK implementations of these functions than none at all. > > You'll need to define OK, because some of the implementations > I've read are poor. I also hope that before anything is > committed to libm that the person doing the committing does > some rather thorough testing of the code. > >> We originally had so-so double support, but bruce spent many >> years optimizing them to make them very good. If we were >> just starting out, and hadn't let 10 years get behind us, I'd >> give the substandard argument some weight. But now that we're >> 13 years down the line from c99's publication I think we need >> to relax our standards a bit. I'd even argue that these >> functions being a little bad could easily spur people to make >> them better. Their absence makes people just >> #define llexp(x) lexp(x), etc. :( > > Of course, the converse argument is that people have had 10 years > to learn enough about floating point to actually write and submit > code. I knew very little about FP before I wrote sqrtl(). I had > a need for sqrtl() and so I went looking for a solution. > > PS: I also wrote sincos[fl](), which is very handy for the > complex trig functions. > > From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 10:05:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA6EB106566C; Tue, 10 Jul 2012 10:05:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8457E8FC22; Tue, 10 Jul 2012 10:05:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6AA5bgi099190; Tue, 10 Jul 2012 06:05:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AA5bgi099187; Tue, 10 Jul 2012 10:05:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 10:05:37 GMT Message-Id: <201207101005.q6AA5bgi099187@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:05:38 -0000 TB --- 2012-07-10 06:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 06:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 06:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-10 06:40:01 - cleaning the object tree TB --- 2012-07-10 06:40:01 - cvsupping the source tree TB --- 2012-07-10 06:40:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-10 06:41:03 - building world TB --- 2012-07-10 06:41:03 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 06:41:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 06:41:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 06:41:03 - SRCCONF=/dev/null TB --- 2012-07-10 06:41:03 - TARGET=amd64 TB --- 2012-07-10 06:41:03 - TARGET_ARCH=amd64 TB --- 2012-07-10 06:41:03 - TZ=UTC TB --- 2012-07-10 06:41:03 - __MAKE_CONF=/dev/null TB --- 2012-07-10 06:41:03 - cd /src TB --- 2012-07-10 06:41:03 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 06:41:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 10 09:57:43 UTC 2012 TB --- 2012-07-10 09:57:43 - generating LINT kernel config TB --- 2012-07-10 09:57:43 - cd /src/sys/amd64/conf TB --- 2012-07-10 09:57:43 - /usr/bin/make -B LINT TB --- 2012-07-10 09:57:43 - cd /src/sys/amd64/conf TB --- 2012-07-10 09:57:43 - /usr/sbin/config -m LINT TB --- 2012-07-10 09:57:43 - building LINT kernel TB --- 2012-07-10 09:57:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 09:57:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 09:57:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 09:57:43 - SRCCONF=/dev/null TB --- 2012-07-10 09:57:43 - TARGET=amd64 TB --- 2012-07-10 09:57:43 - TARGET_ARCH=amd64 TB --- 2012-07-10 09:57:43 - TZ=UTC TB --- 2012-07-10 09:57:43 - __MAKE_CONF=/dev/null TB --- 2012-07-10 09:57:43 - cd /src TB --- 2012-07-10 09:57:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 09:57:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 10:05:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 10:05:37 - ERROR: failed to build LINT kernel TB --- 2012-07-10 10:05:37 - 8182.17 user 1275.46 system 12336.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 10:19:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C2691065676; Tue, 10 Jul 2012 10:19:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DF4CB8FC2A; Tue, 10 Jul 2012 10:19:41 +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 q6AAJf9p093135; Tue, 10 Jul 2012 06:19:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AAJfkI093134; Tue, 10 Jul 2012 10:19:41 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 10:19:41 GMT Message-Id: <201207101019.q6AAJfkI093134@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:19:42 -0000 TB --- 2012-07-10 08:26:05 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 08:26:05 - 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 --- 2012-07-10 08:26:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-10 08:26:05 - cleaning the object tree TB --- 2012-07-10 08:26:05 - cvsupping the source tree TB --- 2012-07-10 08:26:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-10 08:28:12 - building world TB --- 2012-07-10 08:28:12 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 08:28:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 08:28:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 08:28:12 - SRCCONF=/dev/null TB --- 2012-07-10 08:28:12 - TARGET=ia64 TB --- 2012-07-10 08:28:12 - TARGET_ARCH=ia64 TB --- 2012-07-10 08:28:12 - TZ=UTC TB --- 2012-07-10 08:28:12 - __MAKE_CONF=/dev/null TB --- 2012-07-10 08:28:12 - cd /src TB --- 2012-07-10 08:28:12 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 08:28:13 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 10:13:33 UTC 2012 TB --- 2012-07-10 10:13:33 - generating LINT kernel config TB --- 2012-07-10 10:13:33 - cd /src/sys/ia64/conf TB --- 2012-07-10 10:13:33 - /usr/bin/make -B LINT TB --- 2012-07-10 10:13:33 - cd /src/sys/ia64/conf TB --- 2012-07-10 10:13:33 - /usr/sbin/config -m LINT TB --- 2012-07-10 10:13:34 - building LINT kernel TB --- 2012-07-10 10:13:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 10:13:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 10:13:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 10:13:34 - SRCCONF=/dev/null TB --- 2012-07-10 10:13:34 - TARGET=ia64 TB --- 2012-07-10 10:13:34 - TARGET_ARCH=ia64 TB --- 2012-07-10 10:13:34 - TZ=UTC TB --- 2012-07-10 10:13:34 - __MAKE_CONF=/dev/null TB --- 2012-07-10 10:13:34 - cd /src TB --- 2012-07-10 10:13:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 10:13:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 10:19:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 10:19:41 - ERROR: failed to build LINT kernel TB --- 2012-07-10 10:19:41 - 4491.33 user 696.03 system 6816.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 10:34:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2F97106564A; Tue, 10 Jul 2012 10:34:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3298FC14; Tue, 10 Jul 2012 10:34:23 +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 q6AAYM99094780; Tue, 10 Jul 2012 06:34:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AAYMs4094775; Tue, 10 Jul 2012 10:34:22 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 10:34:22 GMT Message-Id: <201207101034.q6AAYMs4094775@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:34:23 -0000 TB --- 2012-07-10 09:29:48 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 09:29:48 - 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 --- 2012-07-10 09:29:48 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-10 09:29:48 - cleaning the object tree TB --- 2012-07-10 09:29:48 - cvsupping the source tree TB --- 2012-07-10 09:29:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-10 09:30:29 - building world TB --- 2012-07-10 09:30:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 09:30:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 09:30:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 09:30:29 - SRCCONF=/dev/null TB --- 2012-07-10 09:30:29 - TARGET=mips TB --- 2012-07-10 09:30:29 - TARGET_ARCH=mips TB --- 2012-07-10 09:30:29 - TZ=UTC TB --- 2012-07-10 09:30:29 - __MAKE_CONF=/dev/null TB --- 2012-07-10 09:30:29 - cd /src TB --- 2012-07-10 09:30:29 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 09:30:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 10:33:26 UTC 2012 TB --- 2012-07-10 10:33:26 - cd /src/sys/mips/conf TB --- 2012-07-10 10:33:26 - /usr/sbin/config -m ADM5120 TB --- 2012-07-10 10:33:26 - skipping ADM5120 kernel TB --- 2012-07-10 10:33:26 - cd /src/sys/mips/conf TB --- 2012-07-10 10:33:26 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-10 10:33:26 - skipping ALCHEMY kernel TB --- 2012-07-10 10:33:26 - cd /src/sys/mips/conf TB --- 2012-07-10 10:33:26 - /usr/sbin/config -m AP93 TB --- 2012-07-10 10:33:26 - building AP93 kernel TB --- 2012-07-10 10:33:26 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 10:33:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 10:33:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 10:33:26 - SRCCONF=/dev/null TB --- 2012-07-10 10:33:26 - TARGET=mips TB --- 2012-07-10 10:33:26 - TARGET_ARCH=mips TB --- 2012-07-10 10:33:26 - TZ=UTC TB --- 2012-07-10 10:33:26 - __MAKE_CONF=/dev/null TB --- 2012-07-10 10:33:26 - cd /src TB --- 2012-07-10 10:33:26 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Tue Jul 10 10:33:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1628: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 10:34:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 10:34:22 - ERROR: failed to build AP93 kernel TB --- 2012-07-10 10:34:22 - 2581.01 user 565.34 system 3874.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 11:27:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818011065670; Tue, 10 Jul 2012 11:27:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 50A878FC0A; Tue, 10 Jul 2012 11:27:06 +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 q6ABR534081367; Tue, 10 Jul 2012 07:27:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ABR5rc081366; Tue, 10 Jul 2012 11:27:05 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 11:27:05 GMT Message-Id: <201207101127.q6ABR5rc081366@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 11:27:06 -0000 TB --- 2012-07-10 10:19:41 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 10:19: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 --- 2012-07-10 10:19:41 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 10:19:41 - cleaning the object tree TB --- 2012-07-10 10:20:37 - cvsupping the source tree TB --- 2012-07-10 10:20:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 10:21:11 - building world TB --- 2012-07-10 10:21:11 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 10:21:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 10:21:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 10:21:11 - SRCCONF=/dev/null TB --- 2012-07-10 10:21:11 - TARGET=sparc64 TB --- 2012-07-10 10:21:11 - TARGET_ARCH=sparc64 TB --- 2012-07-10 10:21:11 - TZ=UTC TB --- 2012-07-10 10:21:11 - __MAKE_CONF=/dev/null TB --- 2012-07-10 10:21:11 - cd /src TB --- 2012-07-10 10:21:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 10:21:12 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 11:23:02 UTC 2012 TB --- 2012-07-10 11:23:02 - generating LINT kernel config TB --- 2012-07-10 11:23:02 - cd /src/sys/sparc64/conf TB --- 2012-07-10 11:23:02 - /usr/bin/make -B LINT TB --- 2012-07-10 11:23:02 - cd /src/sys/sparc64/conf TB --- 2012-07-10 11:23:02 - /usr/sbin/config -m LINT TB --- 2012-07-10 11:23:02 - building LINT kernel TB --- 2012-07-10 11:23:02 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 11:23:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 11:23:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 11:23:02 - SRCCONF=/dev/null TB --- 2012-07-10 11:23:02 - TARGET=sparc64 TB --- 2012-07-10 11:23:02 - TARGET_ARCH=sparc64 TB --- 2012-07-10 11:23:02 - TZ=UTC TB --- 2012-07-10 11:23:02 - __MAKE_CONF=/dev/null TB --- 2012-07-10 11:23:02 - cd /src TB --- 2012-07-10 11:23:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 11:23:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 11:27:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 11:27:05 - ERROR: failed to build LINT kernel TB --- 2012-07-10 11:27:05 - 3139.87 user 574.82 system 4044.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 11:50:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C61D106566C; Tue, 10 Jul 2012 11:50:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0308FC12; Tue, 10 Jul 2012 11:50: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 q6ABo4HE061146; Tue, 10 Jul 2012 07:50:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ABo4XD061145; Tue, 10 Jul 2012 11:50:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 11:50:04 GMT Message-Id: <201207101150.q6ABo4XD061145@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 11:50:05 -0000 TB --- 2012-07-10 09:31:44 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 09:31: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 --- 2012-07-10 09:31:44 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-10 09:31:44 - cleaning the object tree TB --- 2012-07-10 09:33:31 - cvsupping the source tree TB --- 2012-07-10 09:33:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-10 09:34:23 - building world TB --- 2012-07-10 09:34:23 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 09:34:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 09:34:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 09:34:23 - SRCCONF=/dev/null TB --- 2012-07-10 09:34:23 - TARGET=powerpc TB --- 2012-07-10 09:34:23 - TARGET_ARCH=powerpc TB --- 2012-07-10 09:34:23 - TZ=UTC TB --- 2012-07-10 09:34:23 - __MAKE_CONF=/dev/null TB --- 2012-07-10 09:34:23 - cd /src TB --- 2012-07-10 09:34:23 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 09:34:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 11:46:17 UTC 2012 TB --- 2012-07-10 11:46:17 - generating LINT kernel config TB --- 2012-07-10 11:46:17 - cd /src/sys/powerpc/conf TB --- 2012-07-10 11:46:17 - /usr/bin/make -B LINT TB --- 2012-07-10 11:46:17 - cd /src/sys/powerpc/conf TB --- 2012-07-10 11:46:17 - /usr/sbin/config -m LINT TB --- 2012-07-10 11:46:17 - building LINT kernel TB --- 2012-07-10 11:46:17 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 11:46:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 11:46:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 11:46:17 - SRCCONF=/dev/null TB --- 2012-07-10 11:46:17 - TARGET=powerpc TB --- 2012-07-10 11:46:17 - TARGET_ARCH=powerpc TB --- 2012-07-10 11:46:17 - TZ=UTC TB --- 2012-07-10 11:46:17 - __MAKE_CONF=/dev/null TB --- 2012-07-10 11:46:17 - cd /src TB --- 2012-07-10 11:46:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 11:46:17 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 11:50:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 11:50:04 - ERROR: failed to build LINT kernel TB --- 2012-07-10 11:50:04 - 6734.05 user 883.08 system 8300.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:48:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A568B1065672; Tue, 10 Jul 2012 12:48:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 757C48FC16; Tue, 10 Jul 2012 12:48:13 +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 q6ACmCTw086257; Tue, 10 Jul 2012 08:48:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ACmCPC086256; Tue, 10 Jul 2012 12:48:12 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 12:48:12 GMT Message-Id: <201207101248.q6ACmCPC086256@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 12:48:13 -0000 TB --- 2012-07-10 10:05:38 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 10:05:38 - 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 --- 2012-07-10 10:05:38 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-10 10:05:38 - cleaning the object tree TB --- 2012-07-10 10:08:03 - cvsupping the source tree TB --- 2012-07-10 10:08:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-10 10:09:09 - building world TB --- 2012-07-10 10:09:09 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 10:09:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 10:09:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 10:09:09 - SRCCONF=/dev/null TB --- 2012-07-10 10:09:09 - TARGET=powerpc TB --- 2012-07-10 10:09:09 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 10:09:09 - TZ=UTC TB --- 2012-07-10 10:09:09 - __MAKE_CONF=/dev/null TB --- 2012-07-10 10:09:09 - cd /src TB --- 2012-07-10 10:09:09 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 10:09:11 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 10 12:44:42 UTC 2012 TB --- 2012-07-10 12:44:42 - generating LINT kernel config TB --- 2012-07-10 12:44:42 - cd /src/sys/powerpc/conf TB --- 2012-07-10 12:44:42 - /usr/bin/make -B LINT TB --- 2012-07-10 12:44:42 - cd /src/sys/powerpc/conf TB --- 2012-07-10 12:44:42 - /usr/sbin/config -m LINT TB --- 2012-07-10 12:44:43 - building LINT kernel TB --- 2012-07-10 12:44:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 12:44:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 12:44:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 12:44:43 - SRCCONF=/dev/null TB --- 2012-07-10 12:44:43 - TARGET=powerpc TB --- 2012-07-10 12:44:43 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 12:44:43 - TZ=UTC TB --- 2012-07-10 12:44:43 - __MAKE_CONF=/dev/null TB --- 2012-07-10 12:44:43 - cd /src TB --- 2012-07-10 12:44:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 12:44:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 12:48:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 12:48:12 - ERROR: failed to build LINT kernel TB --- 2012-07-10 12:48:12 - 8205.66 user 1090.00 system 9754.69 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:48:21 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 440AD10656B8 for ; Tue, 10 Jul 2012 12:48:21 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7FE8FC19 for ; Tue, 10 Jul 2012 12:48:20 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SoZrX-0005Lf-5h for freebsd-current@freebsd.org; Tue, 10 Jul 2012 13:48:19 +0100 Received: from cpc1-aztw9-0-0-cust540.18-1.cable.virginmedia.com ([82.33.90.29] helo=mech-aslap239.men.bris.ac.uk) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SoZrW-0007c1-In for freebsd-current@freebsd.org; Tue, 10 Jul 2012 13:48:19 +0100 Received: from mech-aslap239.men.bris.ac.uk (localhost [127.0.0.1]) by mech-aslap239.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6ACmIkE000958 for ; Tue, 10 Jul 2012 13:48:19 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-aslap239.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q69NGjt2001204 for freebsd-current@freebsd.org; Tue, 10 Jul 2012 00:16:45 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-aslap239.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Tue, 10 Jul 2012 00:16:45 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20120709231645.GA1077@mech-aslap239.men.bris.ac.uk> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: xdm breaks sound X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 12:48:21 -0000 On amd64 r238259M I have sound working fine until I launch xdm. Then I no longer can get any sound until a reboot. I started seeing this about a month ago, but never had the time to report. I see lots of: hdac0: Unexpected unsolicited response from address 0: 0000000f on the console. I set hw.snd.verbose=4, and now I'm lost in the logs, see below. Please advise Many thanks kernel: hdaa0: tracing via nid 22 kernel: hdaa0: nid 22 returned 0 kernel: hdaa0: nid 13 returned 0 kernel: hdaa0: tracing via nid 17 kernel: hdaa0: tracing via nid 3 kernel: hdaa0: nid 3 returned 3 kernel: hdaa0: nid 17 returned 3 kernel: hdaa0: tracing via nid 18 kernel: hdaa0: tracing via nid 8 kernel: hdaa0: nid 8 returned 0 kernel: hdaa0: nid 18 returned 0 kernel: hdaa0: tracing via nid 19 kernel: hdaa0: tracing via nid 9 kernel: hdaa0: nid 9 returned 0 kernel: hdaa0: nid 19 returned 0 kernel: hdaa0: tracing via nid 26 kernel: hdaa0: tracing via nid 5 kernel: hdaa0: nid 5 returned 0 kernel: hdaa0: nid 26 returned 0 kernel: hdaa0: tracing via nid 28 kernel: hdaa0: tracing via nid 24 kernel: hdaa0: nid 24 returned 0 kernel: hdaa0: nid 28 returned 0 kernel: hdaa0: nid 14 returned 3 kernel: hdaa0: nid 5 returned 3 kernel: hdaa0: Pin 5 traced to DAC 3 kernel: hdaa0: Tracing pin 6 with min nid 0 and hpredir 0 kernel: hdaa0: tracing via nid 6 kernel: hdaa0: tracing via nid 14 kernel: hdaa0: tracing via nid 13 kernel: hdaa0: tracing via nid 16 kernel: hdaa0: nid 16 returned 0 kernel: hdaa0: tracing via nid 22 kernel: hdaa0: nid 22 returned 0 kernel: hdaa0: nid 13 returned 0 kernel: hdaa0: tracing via nid 17 kernel: hdaa0: tracing via nid 3 kernel: hdaa0: nid 3 returned 3 kernel: hdaa0: nid 17 returned 3 kernel: hdaa0: nid 14 returned 3 kernel: hdaa0: nid 6 returned 3 kernel: hdaa0: Pin 6 traced to DAC 3 and hpredir 0 kernel: hdaa0: Association 0 (1) trace succeeded kernel: hdaa0: Tracing association 1 (2) kernel: hdaa0: Tracing pin 8 to ADC 4 kernel: hdaa0: tracing via nid 8 kernel: hdaa0: tracing via nid 18 kernel: hdaa0: tracing via nid 14 kernel: hdaa0: nid 14 busy by association 0 kernel: hdaa0: nid 18 returned 0 kernel: hdaa0: tracing via nid 30 kernel: hdaa0: tracing via nid 12 kernel: hdaa0: tracing via nid 21 kernel: hdaa0: tracing via nid 4 kernel: hdaa0: nid 4 returned 4 kernel: hdaa0: nid 21 returned 4 kernel: hdaa0: nid 12 returned 4 kernel: hdaa0: nid 30 returned 4 kernel: hdaa0: nid 8 returned 4 kernel: hdaa0: Pin 8 traced to ADC 4 kernel: hdaa0: Tracing pin 9 to ADC 4 kernel: hdaa0: tracing via nid 9 kernel: hdaa0: tracing via nid 19 kernel: hdaa0: tracing via nid 14 kernel: hdaa0: nid 14 busy by association 0 kernel: hdaa0: nid 19 returned 0 kernel: hdaa0: tracing via nid 21 kernel: hdaa0: tracing via nid 4 kernel: hdaa0: nid 4 returned 4 kernel: hdaa0: nid 21 returned 4 kernel: hdaa0: nid 9 returned 4 kernel: hdaa0: Pin 9 traced to ADC 4 kernel: hdaa0: Association 1 (2) trace succeeded kernel: hdaa0: Tracing association 2 (5) kernel: hdaa0: Association 2 (5) trace failed kernel: hdaa0: Tracing association 3 (15) kernel: hdaa0: Tracing pin 22 with min nid 0 kernel: hdaa0: tracing via nid 22 kernel: hdaa0: nid 22 returned 0 kernel: hdaa0: Unable to trace pin 22 seq 0 with min nid 0 kernel: hdaa0: Association 3 (15) trace failed kernel: hdaa0: Looking for additional DAC for association 0 (1) kernel: hdaa0: Looking for additional ADC for association 1 (2) kernel: hdaa0: Tracing input monitor kernel: hdaa0: Tracing nid 12 to out kernel: hdaa0: tracing via nid 12 kernel: hdaa0: tracing via nid 21 kernel: hdaa0: nid 21 busy by input association 1 kernel: hdaa0: nid 12 returned 0 kernel: hdaa0: Tracing other input monitors kernel: hdaa0: Tracing nid 8 to out kernel: hdaa0: tracing via nid 8 kernel: hdaa0: tracing via nid 18 kernel: hdaa0: tracing via nid 14 kernel: hdaa0: nid 14 found output association 0 kernel: hdaa0: nid 18 returned 1 kernel: hdaa0: tracing via nid 30 kernel: hdaa0: nid 30 busy by input association 1 kernel: hdaa0: nid 8 returned 1 kernel: hdaa0: nid 8 is input monitor kernel: hdaa0: Tracing nid 9 to out kernel: hdaa0: tracing via nid 9 kernel: hdaa0: tracing via nid 19 kernel: hdaa0: tracing via nid 14 kernel: hdaa0: nid 14 found output association 0 kernel: hdaa0: nid 19 returned 1 kernel: hdaa0: tracing via nid 21 kernel: hdaa0: nid 21 busy by input association 1 kernel: hdaa0: nid 9 returned 1 kernel: hdaa0: nid 9 is input monitor kernel: hdaa0: Tracing beeper kernel: hdaa0: Tracing nid 16 to out kernel: hdaa0: tracing via nid 16 kernel: hdaa0: tracing via nid 13 kernel: hdaa0: tracing via nid 14 kernel: hdaa0: nid 14 found output association 0 kernel: hdaa0: nid 13 returned 1 kernel: hdaa0: nid 16 returned 1 kernel: hdaa0: nid 16 traced to out kernel: hdaa0: Disabling unassociated widgets... kernel: hdaa0: Disabling unassociated nid 2. kernel: hdaa0: Disabling unassociated nid 22. kernel: hdaa0: Disabling unassociated nid 24. kernel: hdaa0: Disabling unassociated nid 26. kernel: hdaa0: Disabling unassociated nid 28. kernel: hdaa0: Disabling connection from output pin nid 21 conn 5 cnid 5. kernel: hdaa0: Disabling connection to input pin nid 9 conn 1. kernel: hdaa0: Disabling nonselected inputs... kernel: hdaa0: Disabling useless... kernel: hdaa0: Disabling ctl 13 nid 24 cnid -1 due to disabled widget. kernel: hdaa0: Disabling ctl 14 nid 24 cnid -1 due to disabled widget. kernel: hdaa0: Disabling ctl 15 nid 26 cnid -1 due to disabled widget. kernel: hdaa0: Disabling ctl 17 nid 28 cnid -1 due to disabled widget. kernel: hdaa0: Disabling nid 13 connection 1 due to disabled child widget. kernel: hdaa0: Disabling nid 14 connection 4 due to disabled child widget. kernel: hdaa0: Disabling nid 14 connection 6 due to disabled child widget. kernel: hdaa0: Disabling nid 21 connection 6 due to disabled child widget. kernel: hdaa0: Disabling crossassociatement connections... kernel: hdaa0: Disabling crossassociatement connection nid 21 conn 2 cnid 14. kernel: hdaa0: Disabling useless... kernel: hdaa0: Binding associations to channels... kernel: hdaa0: Assigning names to signal sources... kernel: hdaa0: Preparing PCM devices... kernel: hdaa0: Assigning mixers to the tree... kernel: hdaa0: Preparing pin controls... kernel: hdaa0: AFG commit... kernel: hdaa0: Setting amplifier nid=5 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=5 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=6 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=7 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=8 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=9 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=9 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=24 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=24 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=26 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=27 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=28 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=29 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting selector nid=2 index=0 kernel: hdaa0: Setting selector nid=4 index=0 kernel: hdaa0: Setting selector nid=5 index=1 kernel: hdaa0: Setting selector nid=6 index=1 kernel: hdaa0: Setting selector nid=7 index=0 kernel: hdaa0: Setting selector nid=9 index=0 kernel: hdaa0: Setting selector nid=10 index=0 kernel: hdaa0: Setting selector nid=11 index=0 kernel: hdaa0: Setting selector nid=12 index=0 kernel: hdaa0: Setting selector nid=13 index=0 kernel: hdaa0: Setting selector nid=14 index=0 kernel: hdaa0: Setting selector nid=15 index=0 kernel: hdaa0: Setting selector nid=17 index=0 kernel: hdaa0: Setting selector nid=18 index=0 kernel: hdaa0: Setting selector nid=19 index=0 kernel: hdaa0: Setting selector nid=20 index=0 kernel: hdaa0: Setting selector nid=21 index=1 kernel: hdaa0: Setting selector nid=24 index=0 kernel: hdaa0: Setting selector nid=26 index=0 kernel: hdaa0: Setting selector nid=27 index=0 kernel: hdaa0: Setting selector nid=28 index=0 kernel: hdaa0: Setting selector nid=29 index=0 kernel: hdaa0: Setting selector nid=30 index=0 kernel: hdaa0: Setting selector nid=31 index=0 kernel: hdaa0: Applying direct built-in patches... kernel: hdaa0: Pin sense init... kernel: hdaa0: Headphones redirection for association 0 nid=6 using unsolicited responses. kernel: hdaa0: Creating PCM devices... kernel: hdaa0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref kernel: hdaa0: kernel: hdaa0: +-------------------+ kernel: hdaa0: | DUMPING HDA NODES | kernel: hdaa0: +-------------------+ kernel: hdaa0: kernel: hdaa0: Default Parameter kernel: hdaa0: ----------------- kernel: hdaa0: Stream cap: 0x00000001 kernel: hdaa0: PCM kernel: hdaa0: PCM cap: 0x000e007f kernel: hdaa0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz kernel: hdaa0: IN amp: 0x00270300 kernel: hdaa0: OUT amp: 0x80053f3d kernel: hdaa0: kernel: hdaa0: nid: 2 [DISABLED] kernel: hdaa0: Name: audio output kernel: hdaa0: Widget cap: 0x00030311 kernel: hdaa0: DIGITAL STEREO kernel: hdaa0: Stream cap: 0x00000005 kernel: hdaa0: AC3 PCM kernel: hdaa0: PCM cap: 0x00020060 kernel: hdaa0: 16 bits, 44 48 KHz kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=1 [GHOST!] [UNKNOWN] (selected) kernel: hdaa0: + <- nid=4 [audio input] kernel: hdaa0: kernel: hdaa0: nid: 3 kernel: hdaa0: Name: audio output kernel: hdaa0: Widget cap: 0x00000441 kernel: hdaa0: PWR PROC STEREO kernel: hdaa0: Association: 0 (0x00008001) kernel: hdaa0: OSS: pcm (pcm) kernel: hdaa0: Stream cap: 0x00000001 kernel: hdaa0: PCM kernel: hdaa0: PCM cap: 0x000e007f kernel: hdaa0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz kernel: hdaa0: kernel: hdaa0: nid: 4 kernel: hdaa0: Name: audio input kernel: hdaa0: Widget cap: 0x00100511 kernel: hdaa0: PWR STEREO kernel: hdaa0: Association: 1 (0x00004001) kernel: hdaa0: Stream cap: 0x00000001 kernel: hdaa0: PCM kernel: hdaa0: PCM cap: 0x0006007f kernel: hdaa0: 16 20 bits, 8 11 16 22 32 44 48 KHz kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=21 [audio selector] kernel: hdaa0: kernel: hdaa0: nid: 5 kernel: hdaa0: Name: pin: Speaker (Fixed) kernel: hdaa0: Widget cap: 0x00400187 kernel: hdaa0: UNSOL STEREO kernel: hdaa0: Association: 0 (0x00000001) kernel: hdaa0: Pin cap: 0x0001173f kernel: hdaa0: ISC TRQD PDC HP OUT IN VREF[ 50 80 GROUND HIZ ] EAPD kernel: hdaa0: Pin config: 0x92174110 kernel: hdaa0: Pin control: 0x00000040 OUT kernel: hdaa0: EAPD: 0x00000002 kernel: hdaa0: Output amp: 0x80053f3d kernel: hdaa0: mute=1 step=63 size=5 offset=61 kernel: hdaa0: Input amp: 0x00270300 kernel: hdaa0: mute=0 step=3 size=39 offset=0 kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=3 [audio output] kernel: hdaa0: + <- nid=14 [audio mixer] (selected) kernel: hdaa0: kernel: hdaa0: nid: 6 kernel: hdaa0: Name: pin: Headphones (Grey Jack) kernel: hdaa0: Widget cap: 0x00400185 kernel: hdaa0: UNSOL STEREO kernel: hdaa0: Association: 0 (0x00008000) kernel: hdaa0: Pin cap: 0x0000001f kernel: hdaa0: ISC TRQD PDC HP OUT kernel: hdaa0: Pin config: 0x0421201f kernel: hdaa0: Pin control: 0x000000c0 HP OUT kernel: hdaa0: Output amp: 0x80053f3d kernel: hdaa0: mute=1 step=63 size=5 offset=61 kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=3 [audio output] kernel: hdaa0: + <- nid=14 [audio mixer] (selected) kernel: hdaa0: kernel: hdaa0: nid: 7 [DISABLED] kernel: hdaa0: Name: pin: Line-out (None) kernel: hdaa0: Widget cap: 0x00400104 kernel: hdaa0: Pin cap: 0x00000010 kernel: hdaa0: OUT kernel: hdaa0: Pin config: 0x410710f0 kernel: hdaa0: Pin control: 0x00000000 kernel: hdaa0: Output amp: 0x80053f3d kernel: hdaa0: mute=1 step=63 size=5 offset=61 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 8 kernel: hdaa0: Name: pin: Mic (Grey Jack) kernel: hdaa0: Widget cap: 0x00400083 kernel: hdaa0: UNSOL STEREO kernel: hdaa0: Association: 1 (0x00000001) kernel: hdaa0: OSS: mic (mic) kernel: hdaa0: Pin cap: 0x00001727 kernel: hdaa0: ISC TRQD PDC IN VREF[ 50 80 GROUND HIZ ] kernel: hdaa0: Pin config: 0x04a12020 kernel: hdaa0: Pin control: 0x00000024 IN VREFs kernel: hdaa0: Input amp: 0x00270300 kernel: hdaa0: mute=0 step=3 size=39 offset=0 kernel: hdaa0: kernel: hdaa0: nid: 9 kernel: hdaa0: Name: pin: Line-in (Blue Jack) kernel: hdaa0: Widget cap: 0x00400187 kernel: hdaa0: UNSOL STEREO kernel: hdaa0: Association: 1 (0x00004000) kernel: hdaa0: OSS: line (line) kernel: hdaa0: Pin cap: 0x00001737 kernel: hdaa0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] kernel: hdaa0: Pin config: 0x0181302e kernel: hdaa0: Pin control: 0x00000024 IN VREFs kernel: hdaa0: Output amp: 0x80053f3d kernel: hdaa0: mute=1 step=63 size=5 offset=61 kernel: hdaa0: Input amp: 0x00270300 kernel: hdaa0: mute=0 step=3 size=39 offset=0 kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=3 [audio output] (selected) kernel: hdaa0: + [DISABLED] <- nid=14 [audio mixer] kernel: hdaa0: kernel: hdaa0: nid: 10 [DISABLED] kernel: hdaa0: Name: pin: SPDIF-out (None) kernel: hdaa0: Widget cap: 0x00400301 kernel: hdaa0: DIGITAL STEREO kernel: hdaa0: Pin cap: 0x00000010 kernel: hdaa0: OUT kernel: hdaa0: Pin config: 0x4145f0f0 kernel: hdaa0: Pin control: 0x00000000 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=2 [audio output] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 11 [DISABLED] kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x00300101 kernel: hdaa0: STEREO kernel: hdaa0: connections: 6 kernel: hdaa0: | kernel: hdaa0: + <- nid=3 [audio output] (selected) kernel: hdaa0: + <- nid=12 [audio mixer] kernel: hdaa0: + <- nid=9 [pin: Line-in (Blue Jack)] kernel: hdaa0: + <- nid=14 [audio mixer] kernel: hdaa0: + <- nid=5 [pin: Speaker (Fixed)] kernel: hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 12 kernel: hdaa0: Name: audio mixer kernel: hdaa0: Widget cap: 0x00200101 kernel: hdaa0: STEREO kernel: hdaa0: Association: 1 (0x00000001) kernel: hdaa0: OSS: mic kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + <- nid=30 [audio selector] kernel: hdaa0: + [DISABLED] <- nid=31 [audio selector] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 13 kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010c kernel: hdaa0: Association: -2 (0x00000000) kernel: hdaa0: OSS: speaker kernel: hdaa0: Output amp: 0x800b0f0f kernel: hdaa0: mute=1 step=15 size=11 offset=15 kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + <- nid=16 [beep widget] (selected) kernel: hdaa0: + [DISABLED] <- nid=22 [pin: Digital-out (Fixed)] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 14 kernel: hdaa0: Name: audio mixer kernel: hdaa0: Widget cap: 0x00200101 kernel: hdaa0: STEREO kernel: hdaa0: Association: 0 (0x00008001) kernel: hdaa0: OSS: pcm, speaker, line, mic kernel: hdaa0: connections: 8 kernel: hdaa0: | kernel: hdaa0: + <- nid=13 [audio selector] kernel: hdaa0: + <- nid=17 [audio selector] kernel: hdaa0: + <- nid=18 [audio selector] kernel: hdaa0: + <- nid=19 [audio selector] kernel: hdaa0: + [DISABLED] <- nid=26 [audio selector] [DISABLED] kernel: hdaa0: + [DISABLED] <- nid=27 [audio selector] [DISABLED] kernel: hdaa0: + [DISABLED] <- nid=28 [audio selector] [DISABLED] kernel: hdaa0: + [DISABLED] <- nid=29 [audio selector] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 15 [DISABLED] kernel: hdaa0: Name: audio mixer kernel: hdaa0: Widget cap: 0x00200100 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=11 [audio selector] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 16 kernel: hdaa0: Name: beep widget kernel: hdaa0: Widget cap: 0x00700000 kernel: hdaa0: Association: -2 (0x00000000) kernel: hdaa0: OSS: speaker (speaker) kernel: hdaa0: kernel: hdaa0: nid: 17 kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Association: 0 (0x00008001) kernel: hdaa0: OSS: pcm kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=3 [audio output] kernel: hdaa0: kernel: hdaa0: nid: 18 kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Association: -2 (0x00000000) kernel: hdaa0: OSS: mic kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=8 [pin: Mic (Grey Jack)] kernel: hdaa0: kernel: hdaa0: nid: 19 kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Association: -2 (0x00000000) kernel: hdaa0: OSS: line kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=9 [pin: Line-in (Blue Jack)] kernel: hdaa0: kernel: hdaa0: nid: 20 [DISABLED] kernel: hdaa0: Name: power widget kernel: hdaa0: Widget cap: 0x00500500 kernel: hdaa0: PWR kernel: hdaa0: connections: 13 kernel: hdaa0: | kernel: hdaa0: + <- nid=13 [audio selector] (selected) kernel: hdaa0: + <- nid=14 [audio mixer] kernel: hdaa0: + <- nid=15 [audio mixer] [DISABLED] kernel: hdaa0: + <- nid=16 [beep widget] kernel: hdaa0: + <- nid=19 [audio selector] kernel: hdaa0: + <- nid=20 [power widget] [DISABLED] kernel: hdaa0: + <- nid=21 [audio selector] kernel: hdaa0: + <- nid=22 [pin: Digital-out (Fixed)] [DISABLED] kernel: hdaa0: + <- nid=23 [pin: AUX (None)] [DISABLED] kernel: hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] kernel: hdaa0: + <- nid=25 [pin: CD (None)] [DISABLED] kernel: hdaa0: + <- nid=26 [audio selector] [DISABLED] kernel: hdaa0: + <- nid=29 [audio selector] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 21 kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Association: 1 (0x00004001) kernel: hdaa0: OSS: line, mic kernel: hdaa0: Output amp: 0x80050f00 kernel: hdaa0: mute=1 step=15 size=5 offset=0 kernel: hdaa0: connections: 8 kernel: hdaa0: | kernel: hdaa0: + <- nid=12 [audio mixer] kernel: hdaa0: + <- nid=9 [pin: Line-in (Blue Jack)] (selected) kernel: hdaa0: + [DISABLED] <- nid=14 [audio mixer] kernel: hdaa0: + [DISABLED] <- nid=15 [audio mixer] [DISABLED] kernel: hdaa0: + [DISABLED] <- nid=25 [pin: CD (None)] [DISABLED] kernel: hdaa0: + [DISABLED] <- nid=5 [pin: Speaker (Fixed)] kernel: hdaa0: + [DISABLED] <- nid=24 [pin: Mic (Both)] [DISABLED] kernel: hdaa0: + [DISABLED] <- nid=23 [pin: AUX (None)] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 22 [DISABLED] kernel: hdaa0: Name: pin: Digital-out (Fixed) kernel: hdaa0: Widget cap: 0x00400000 kernel: hdaa0: Pin cap: 0x00000020 kernel: hdaa0: IN kernel: hdaa0: Pin config: 0x995711f0 kernel: hdaa0: Pin control: 0x00000000 kernel: hdaa0: kernel: hdaa0: nid: 23 [DISABLED] kernel: hdaa0: Name: pin: AUX (None) kernel: hdaa0: Widget cap: 0x00400081 kernel: hdaa0: UNSOL STEREO kernel: hdaa0: Pin cap: 0x00000027 kernel: hdaa0: ISC TRQD PDC IN kernel: hdaa0: Pin config: 0x5993e0f0 kernel: hdaa0: Pin control: 0x00000000 kernel: hdaa0: kernel: hdaa0: nid: 24 [DISABLED] kernel: hdaa0: Name: pin: Mic (Both) kernel: hdaa0: Widget cap: 0x00400187 kernel: hdaa0: UNSOL STEREO kernel: hdaa0: Pin cap: 0x00001737 kernel: hdaa0: ISC TRQD PDC OUT IN VREF[ 50 80 GROUND HIZ ] kernel: hdaa0: Pin config: 0xf0a79159 kernel: hdaa0: Pin control: 0x00000000 kernel: hdaa0: Output amp: 0x80053f3d kernel: hdaa0: mute=1 step=63 size=5 offset=61 kernel: hdaa0: Input amp: 0x00270300 kernel: hdaa0: mute=0 step=3 size=39 offset=0 kernel: hdaa0: connections: 2 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=3 [audio output] (selected) kernel: hdaa0: + <- nid=14 [audio mixer] kernel: hdaa0: kernel: hdaa0: nid: 25 [DISABLED] kernel: hdaa0: Name: pin: CD (None) kernel: hdaa0: Widget cap: 0x00400001 kernel: hdaa0: STEREO kernel: hdaa0: Pin cap: 0x00000020 kernel: hdaa0: IN kernel: hdaa0: Pin config: 0x593310f0 kernel: hdaa0: Pin control: 0x00000000 kernel: hdaa0: kernel: hdaa0: nid: 26 [DISABLED] kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=5 [pin: Speaker (Fixed)] kernel: hdaa0: kernel: hdaa0: nid: 27 [DISABLED] kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=23 [pin: AUX (None)] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 28 [DISABLED] kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 29 [DISABLED] kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Output amp: 0x80051f17 kernel: hdaa0: mute=1 step=31 size=5 offset=23 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + [DISABLED] <- nid=25 [pin: CD (None)] [DISABLED] kernel: hdaa0: kernel: hdaa0: nid: 30 kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Association: 1 (0x00000001) kernel: hdaa0: OSS: mic kernel: hdaa0: Output amp: 0x80000000 kernel: hdaa0: mute=1 step=0 size=0 offset=0 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=8 [pin: Mic (Grey Jack)] kernel: hdaa0: kernel: hdaa0: nid: 31 [DISABLED] kernel: hdaa0: Name: audio selector kernel: hdaa0: Widget cap: 0x0030010d kernel: hdaa0: STEREO kernel: hdaa0: Output amp: 0x80000000 kernel: hdaa0: mute=1 step=0 size=0 offset=0 kernel: hdaa0: connections: 1 kernel: hdaa0: | kernel: hdaa0: + <- nid=24 [pin: Mic (Both)] [DISABLED] kernel: hdaa0: kernel: hdaa0: +------------------------+ kernel: hdaa0: | DUMPING HDA AMPLIFIERS | kernel: hdaa0: +------------------------+ kernel: hdaa0: kernel: hdaa0: 1: nid 5 in (out) index 0 ossmask=0x00000001 kernel: hdaa0: mute: 1 step: 63 size: 5 off: 61 kernel: hdaa0: 2: nid 5 out (in ) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 0 step: 3 size: 39 off: 0 [DISABLED] kernel: hdaa0: 3: nid 6 in (out) index 0 ossmask=0x00000001 kernel: hdaa0: mute: 1 step: 63 size: 5 off: 61 kernel: hdaa0: 4: nid 7 in (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 63 size: 5 off: 61 [DISABLED] kernel: hdaa0: 5: nid 8 out (in ) index 0 ossmask=0x00000080 kernel: hdaa0: mute: 0 step: 3 size: 39 off: 0 kernel: hdaa0: 6: nid 9 in (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 63 size: 5 off: 61 [DISABLED] kernel: hdaa0: 7: nid 9 out (in ) index 0 ossmask=0x00000040 kernel: hdaa0: mute: 0 step: 3 size: 39 off: 0 kernel: hdaa0: 8: nid 13 out (out) index 0 ossmask=0x00001021 kernel: hdaa0: mute: 1 step: 15 size: 11 off: 15 kernel: hdaa0: 9: nid 17 out (out) index 0 ossmask=0x00000011 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 kernel: hdaa0: 10: nid 18 out (out) index 0 ossmask=0x00001081 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 kernel: hdaa0: 11: nid 19 out (out) index 0 ossmask=0x00001041 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 kernel: hdaa0: 12: nid 21 out (out) index 0 ossmask=0x000008c0 kernel: hdaa0: mute: 1 step: 15 size: 5 off: 0 kernel: hdaa0: 13: nid 24 in (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 63 size: 5 off: 61 [DISABLED] kernel: hdaa0: 14: nid 24 out (in ) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 0 step: 3 size: 39 off: 0 [DISABLED] kernel: hdaa0: 15: nid 26 out (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 [DISABLED] kernel: hdaa0: 16: nid 27 out (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 [DISABLED] kernel: hdaa0: 17: nid 28 out (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 [DISABLED] kernel: hdaa0: 18: nid 29 out (out) index 0 ossmask=0x00000000 kernel: hdaa0: mute: 1 step: 31 size: 5 off: 23 [DISABLED] kernel: hdaa0: 19: nid 30 out (out) index 0 ossmask=0x00000880 kernel: hdaa0: mute: 1 step: 0 size: 0 off: 0 kernel: hdaa0: kernel: pcm0: at nid 5,6 and 8,9 on hdaa0 kernel: pcm0: +--------------------------------------+ kernel: pcm0: | DUMPING PCM Playback/Record Channels | kernel: pcm0: +--------------------------------------+ kernel: pcm0: kernel: pcm0: Playback: kernel: pcm0: kernel: pcm0: Stream cap: 0x00000001 kernel: pcm0: PCM kernel: pcm0: PCM cap: 0x000e007f kernel: pcm0: 16 20 24 bits, 8 11 16 22 32 44 48 KHz kernel: pcm0: DAC: 3 kernel: pcm0: kernel: pcm0: Record: kernel: pcm0: kernel: pcm0: Stream cap: 0x00000001 kernel: pcm0: PCM kernel: pcm0: PCM cap: 0x0006007f kernel: pcm0: 16 20 bits, 8 11 16 22 32 44 48 KHz kernel: pcm0: DAC: 4 kernel: pcm0: kernel: pcm0: +-------------------------------+ kernel: pcm0: | DUMPING Playback/Record Paths | kernel: pcm0: +-------------------------------+ kernel: pcm0: kernel: pcm0: Playback: kernel: pcm0: kernel: pcm0: nid=5 [pin: Speaker (Fixed)] kernel: pcm0: | kernel: pcm0: + <- nid=14 [audio mixer] [src: pcm, speaker, line, mic] kernel: pcm0: | kernel: pcm0: + <- nid=13 [audio selector] [src: speaker] kernel: pcm0: | kernel: pcm0: + <- nid=16 [beep widget] [src: speaker] kernel: pcm0: + <- nid=17 [audio selector] [src: pcm] kernel: pcm0: | kernel: pcm0: + <- nid=3 [audio output] [src: pcm] kernel: pcm0: + <- nid=18 [audio selector] [src: mic] kernel: pcm0: | kernel: pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] kernel: pcm0: + <- nid=19 [audio selector] [src: line] kernel: pcm0: | kernel: pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] kernel: pcm0: kernel: pcm0: nid=6 [pin: Headphones (Grey Jack)] kernel: pcm0: | kernel: pcm0: + <- nid=14 [audio mixer] [src: pcm, speaker, line, mic] kernel: pcm0: | kernel: pcm0: + <- nid=13 [audio selector] [src: speaker] kernel: pcm0: | kernel: pcm0: + <- nid=16 [beep widget] [src: speaker] kernel: pcm0: + <- nid=17 [audio selector] [src: pcm] kernel: pcm0: | kernel: pcm0: + <- nid=3 [audio output] [src: pcm] kernel: pcm0: + <- nid=18 [audio selector] [src: mic] kernel: pcm0: | kernel: pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] kernel: pcm0: + <- nid=19 [audio selector] [src: line] kernel: pcm0: | kernel: pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] kernel: pcm0: kernel: pcm0: Record: kernel: pcm0: kernel: pcm0: nid=4 [audio input] kernel: pcm0: | kernel: pcm0: + <- nid=21 [audio selector] [src: line, mic] kernel: pcm0: | kernel: pcm0: + <- nid=12 [audio mixer] [src: mic] kernel: pcm0: | kernel: pcm0: + <- nid=30 [audio selector] [src: mic] kernel: pcm0: | kernel: pcm0: + <- nid=8 [pin: Mic (Grey Jack)] [src: mic] kernel: pcm0: + <- nid=9 [pin: Line-in (Blue Jack)] [src: line] kernel: pcm0: kernel: pcm0: +-------------------------+ kernel: pcm0: | DUMPING Volume Controls | kernel: pcm0: +-------------------------+ kernel: pcm0: kernel: pcm0: Master Volume (OSS: vol): -91/3dB kernel: pcm0: | kernel: pcm0: +- ctl 1 (nid 5 in ): -91/3dB (64 steps) + mute kernel: pcm0: +- ctl 3 (nid 6 in ): -91/3dB (64 steps) + mute kernel: pcm0: +- ctl 8 (nid 13 out): -45/0dB (16 steps) + mute kernel: pcm0: +- ctl 9 (nid 17 out): -34/12dB (32 steps) + mute kernel: pcm0: +- ctl 10 (nid 18 out): -34/12dB (32 steps) + mute kernel: pcm0: +- ctl 11 (nid 19 out): -34/12dB (32 steps) + mute kernel: pcm0: kernel: pcm0: PCM Volume (OSS: pcm): -34/12dB kernel: pcm0: | kernel: pcm0: +- ctl 9 (nid 17 out): -34/12dB (32 steps) + mute kernel: pcm0: kernel: pcm0: Microphone Volume (OSS: mic): 0/30dB kernel: pcm0: | kernel: pcm0: +- ctl 5 (nid 8 out): 0/30dB (4 steps) kernel: pcm0: +- ctl 10 (nid 18 out): -34/12dB (32 steps) + mute kernel: pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute kernel: pcm0: +- ctl 19 (nid 30 out): mute kernel: pcm0: kernel: pcm0: Line-in Volume (OSS: line): 0/30dB kernel: pcm0: | kernel: pcm0: +- ctl 7 (nid 9 out): 0/30dB (4 steps) kernel: pcm0: +- ctl 11 (nid 19 out): -34/12dB (32 steps) + mute kernel: pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute kernel: pcm0: kernel: pcm0: Speaker/Beep Volume (OSS: speaker): -45/0dB kernel: pcm0: | kernel: pcm0: +- ctl 8 (nid 13 out): -45/0dB (16 steps) + mute kernel: pcm0: kernel: pcm0: Recording Level (OSS: rec): 0/22dB kernel: pcm0: | kernel: pcm0: +- ctl 12 (nid 21 out): 0/22dB (16 steps) + mute kernel: pcm0: +- ctl 19 (nid 30 out): mute kernel: pcm0: kernel: pcm0: Input Monitoring Level (OSS: igain): -34/0dB kernel: pcm0: | kernel: pcm0: +- ctl 8 (nid 13 out): -45/0dB (16 steps) + mute kernel: pcm0: +- ctl 10 (nid 18 out): -34/12dB (32 steps) + mute kernel: pcm0: +- ctl 11 (nid 19 out): -34/12dB (32 steps) + mute kernel: pcm0: kernel: pcm0: OSS mixer initialization... kernel: hdaa0: Setting amplifier nid=5 index=0 out mute=0/0 vol=47/47 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=0/0 vol=15/15 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=6 index=0 out mute=0/0 vol=47/47 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=0/0 vol=15/15 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=24/24 kernel: hdaa0: Setting amplifier nid=9 index=0 in mute=0/0 vol=2/2 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=0/0 vol=25/25 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=0/0 vol=2/2 kernel: hdaa0: Setting amplifier nid=8 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=0/0 vol=13/13 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting selector nid=21 index=0 kernel: pcm0: Recsel (mic): nid 21 source 0 select kernel: hdaa0: Setting amplifier nid=8 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=1/1 vol=0/0 kernel: pcm0: Registering PCM channels... kernel: pcm0: clone manager: deadline=750ms flags=0x8000001e kernel: sndbuf_resize(): b=0xfffffe0006bbba00 0 -> 0xffffff80022bd000 [0 -> 65536 : 65536] kernel: sndbuf_resize(): b=0xfffffe0006bbb600 0 -> 0xffffff80022cd000 [0 -> 65536 : 65536] kernel: hdaa0: Setting amplifier nid=5 index=0 out mute=0/0 vol=54/54 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=6 index=0 out mute=0/0 vol=54/54 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=23/23 kernel: hdaa0: Setting amplifier nid=9 index=0 in mute=0/0 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=8 index=0 in mute=0/0 vol=2/2 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=0/0 vol=0/0 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=0/0 vol=13/13 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=0/0 vol=2/2 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=0/0 vol=0/0 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: sndbuf_resize(): b=0xfffffe0006bbba00 65536 [65536] NOCHANGE kernel: sndbuf_remalloc(): b=0xfffffe0006bbb800 0 -> 4096 [4096] kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: sndbuf_resize(): b=0xfffffe0006bbb600 65536 [65536] NOCHANGE kernel: sndbuf_remalloc(): b=0xfffffe0006bbb400 0 -> 4096 [4096] kernel: pcm0: chn_resizebuf(): PCMDIR_REC (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: pcm0: chn_resizebuf(): PCMDIR_REC (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: hdacc1: at cad 1 on hdac0 kernel: hdacc1: Root Node at nid=0: 1 subnodes 1-1 kernel: unknown: at nid 1 on hdacc1 (no driver attached) kernel: hdacc1: Power down FG nid=1 to the D3 state... kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=17 index=0 out mute=0/0 vol=24/24 kernel: hdaa0: Setting amplifier nid=9 index=0 in mute=0/0 vol=2/2 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=8 index=0 in mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=21 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=30 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=13 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=18 index=0 out mute=1/1 vol=0/0 kernel: hdaa0: Setting amplifier nid=19 index=0 out mute=1/1 vol=0/0 kernel: Starting background file system checks in 60 seconds. kernel: kernel: Mon Jul 9 23:45:12 BST 2012 ntpd[918]: synchronized to 217.115.155.125, stratum 2 ntpd[918]: time reset -1.291823 s login: login on ttyv1 as mexas kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) last message repeated 11 times /usr/sbin/cron[1026]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) login: login on ttyv2 as root login: ROOT LOGIN (root) ON ttyv2 login: ROOT LOGIN (root) ON ttyv2 kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) last message repeated 11 times /usr/sbin/cron[1031]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) last message repeated 11 times /usr/sbin/cron[1034]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) last message repeated 8 times /usr/sbin/cron[1037]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) /usr/sbin/cron[1040]: (root) CMD (/usr/libexec/atrun) /usr/sbin/cron[1042]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) ntpd[918]: synchronized to 91.198.174.204, stratum 2 /usr/sbin/cron[1044]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) /usr/sbin/cron[1047]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) .men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f .men.bris.ac.uk>, relay=mexas@localhost sendmail[1053]: q69MqAtd001053: to=freebsd-current@freebsd.org, delay=00:00:00, mailer=esmtp, pri=31758, dsn=4.4.3, stat=queued su: mexas to root on /dev/ttyv1 su: mexas to root on /dev/ttyv1 when xdm is started I get this in the logs: kernel: pcm0: chn_resizebuf(): PCMDIR_REC (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: sndbuf_remalloc(): b=0xfffffe0006bb6a00 0 -> 65536 [65536] kernel: pcm0: chn_resizebuf(): PCMDIR_REC (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3762 kernel: pcm0: chn_resizebuf(): PCMDIR_REC (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: pcm0: chn_resizebuf(): PCMDIR_REC (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3762 kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: sndbuf_remalloc(): b=0xfffffe0006bbb000 0 -> 65536 [65536] kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 kernel: pcm0: chn_start(): PCMDIR_PLAY (virtual) threshold i=2560 j=4 kernel: pcm0: chn_start(): VCHAN PARENT starting! (PCMDIR_PLAY/running) (ready=4096 force=1 i=1 j=0 intrtimeout=21 latency=21ms) kernel: hdac0: 1536Kbps of 46080Kbps bandwidth used kernel: pcm0: PCMDIR_PLAY: Stream setup fmt=00200010 (2.0) speed=48000 kernel: pcm0: PCMDIR_PLAY: Stream setup nid=3: fmt=0x0011, dfmt=0x0001, chan=0x0010, chan_count=0x01, stripe=0 kernel: pcm0: chn_trigger() pcm0:play:dsp0.p0: calling go=0x00000001 , prev=0x00000000 kernel: pcm0: chn_trigger() pcm0:virtual:dsp0.vp0: calling go=0x00000001 , prev=0x00000000 kernel: feed_root: (virtual) appending 1296 bytes (count=1884 l=588 feed=7) kernel: feed_root: (virtual) appending 1880 bytes (count=1880 l=0 feed=8) kernel: feed_root: (virtual) appending 1440 bytes (count=1440 l=0 feed=9) kernel: feed_root: (virtual) appending 444 bytes (count=444 l=0 feed=10) kernel: feed_root: (virtual) appending 1880 bytes (count=1880 l=0 feed=11) /usr/sbin/cron[1059]: (mexas) CMD (sysctl hw.acpi.battery.life >> /tmp/battery) kernel: pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead kernel: pcm0: chn_resizebuf(): PCMDIR_REC (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: pcm0: chn_resizebuf(): PCMDIR_REC (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3762 kernel: hdac0: Unexpected unsolicited response from address 0: 0000001f kernel: hdac0: Unexpected unsolicited response from address 0: 00000040 kernel: hdac0: Unexpected unsolicited response from address 0: 00400104 kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 0000000f kernel: hdac0: Unexpected unsolicited response from address 0: 410710f0 kernel: hdac0: Unexpected unsolicited response from address 0: 00000010 kernel: hdac0: Unexpected unsolicited response from address 0: 00000040 kernel: hdac0: Unexpected unsolicited response from address 0: 00400083 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 04a12020 kernel: hdac0: Unexpected unsolicited response from address 0: 00001727 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00400187 kernel: hdac0: Unexpected unsolicited response from address 0: 00000002 kernel: hdac0: Unexpected unsolicited response from address 0: 00000e03 kernel: hdac0: Unexpected unsolicited response from address 0: 0181302e kernel: hdac0: Unexpected unsolicited response from address 0: 00001737 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00400301 kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000002 kernel: hdac0: Unexpected unsolicited response from address 0: 4145f0f0 kernel: hdac0: Unexpected unsolicited response from address 0: 00000010 kernel: hdac0: Unexpected unsolicited response from address 0: 00000040 kernel: hdac0: Unexpected unsolicited response from address 0: 00300101 kernel: hdac0: Unexpected unsolicited response from address 0: 00000006 kernel: hdac0: Unexpected unsolicited response from address 0: 0e090c03 kernel: hdac0: Unexpected unsolicited response from address 0: 00001805 kernel: hdac0: Unexpected unsolicited response from address 0: 00200101 kernel: hdac0: Unexpected unsolicited response from address 0: 00000002 kernel: hdac0: Unexpected unsolicited response from address 0: 00001f1e kernel: hdac0: Unexpected unsolicited response from address 0: 0030010c kernel: hdac0: Unexpected unsolicited response from address 0: 00000002 kernel: hdac0: Unexpected unsolicited response from address 0: 00001610 kernel: hdac0: Unexpected unsolicited response from address 0: 800b0f0f kernel: hdac0: Unexpected unsolicited response from address 0: 00200101 kernel: hdac0: Unexpected unsolicited response from address 0: 00000008 kernel: hdac0: Unexpected unsolicited response from address 0: 1312110d kernel: hdac0: Unexpected unsolicited response from address 0: 1d1c1b1a kernel: hdac0: Unexpected unsolicited response from address 0: 00200100 kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 0000000b kernel: hdac0: Unexpected unsolicited response from address 0: 00700000 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000003 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000008 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000009 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 00500500 kernel: hdac0: Unexpected unsolicited response from address 0: 00000006 kernel: hdac0: Unexpected unsolicited response from address 0: 13900e0d kernel: hdac0: Unexpected unsolicited response from address 0: 00001d9a kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000008 kernel: hdac0: Unexpected unsolicited response from address 0: 0f0e090c kernel: hdac0: Unexpected unsolicited response from address 0: 17180519 kernel: hdac0: Unexpected unsolicited response from address 0: 80050f00 kernel: hdac0: Unexpected unsolicited response from address 0: 00400000 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 995711f0 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00400081 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 5993e0f0 kernel: hdac0: Unexpected unsolicited response from address 0: 00000027 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00400187 kernel: hdac0: Unexpected unsolicited response from address 0: 00000002 kernel: hdac0: Unexpected unsolicited response from address 0: 00000e03 kernel: hdac0: Unexpected unsolicited response from address 0: f0a79159 kernel: hdac0: Unexpected unsolicited response from address 0: 00001737 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00400001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 593310f0 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 00000020 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000005 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000017 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000018 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000019 kernel: hdac0: Unexpected unsolicited response from address 0: 80051f17 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000008 kernel: hdac0: Unexpected unsolicited response from address 0: 80000000 kernel: hdac0: Unexpected unsolicited response from address 0: 0030010d kernel: hdac0: Unexpected unsolicited response from address 0: 00000001 kernel: hdac0: Unexpected unsolicited response from address 0: 00000018 kernel: hdac0: Unexpected unsolicited response from address 0: 80000000 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 last message repeated 55 times kernel: hdac0: Unexpected unsolicited response from address 0: 0000fb48 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 0000f708 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 kernel: hdac0: Unexpected unsolicited response from address 0: 00005141 kernel: hdac0: Unexpected unsolicited response from address 0: 00000000 last message repeated 10 times kernel: pcm0: chn_trigger() pcm0:play:dsp0.p0: calling go=0xffffffff , prev=0x00000001 kernel: pcm0: chn_trigger() pcm0:virtual:dsp0.vp0: calling go=0xffffffff , prev=0x00000001 kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0 kernel: pcm0: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=3763 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 12:49:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7165C1065670 for ; Tue, 10 Jul 2012 12:49:20 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id D6D318FC1C for ; Tue, 10 Jul 2012 12:49:19 +0000 (UTC) Received: from vhoffman-macbooklocal.local (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q6ACnIFA064542 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 13:49:18 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4FFC24CD.7080400@unsane.co.uk> Date: Tue, 10 Jul 2012 13:49:17 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rick Macklem References: <1458419708.103582.1341796134892.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1458419708.103582.1341796134892.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Occassional "permission denied" in the middle of a large transfer over NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 12:49:20 -0000 On 09/07/2012 02:08, Rick Macklem wrote: > Vincent Hoffman: >> On 08/07/2012 00:26, Rick Macklem wrote: >>> Vincent Hoffman wrote: >>>> Hi Rick, >>>> >>>> I'm afraid this didnt make any real difference for me. >>>> Since I couldnt test it on the live system I tried it on a test vm. >>>> on the vm (nfs server) I set a looping mount/umount >>>> while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp >>>> ; >>>> done >>>> >>>> and on the client I set a loop of tars of large directorys to the >>>> nfs >>>> mount running under time to see how well it survived. Then >>>> replicated >>>> the test with the patch and without. >>>> >>> Just to confirm, you patched both the kernel and mountd and replaced >>> both >>> on the server? >>> >>> Also, I'm not sure how ZFS handles it's exports. I can't remember if >>> you've >>> tried an exported UFS volume. It might be something ZFS specific? >>> >>> rick >> Hi Rick, >> >> yes I patched both the kernel and mountd, rebuilt kernel and world (to >> be sure), added the -S flag to mountd in rc.conf and rebooted. >> This is a test VM running -CURRENT and is only exporting a ufs2 >> filesystem. >> (11:43:05 <~>) 0 $ cat /etc/exports >> /usr/local/export -maproot=root -alldirs XX.XX.XX.XX >> >> Client is a 8.3-RELEASE box but I see the same with linux clients. >> (I can confirm that it works fine when I am not running the >> mount/umount >> loop) >> > Oops, the patch I sent you worked for NFSv4 only. If you also apply the > attached patch, it seems to work for NFSv3 as well. > The patch is also at: > http://people.freebsd.org/~rmacklem/atomic-export2.patch > > You must also run the new/experimental server. (I can't remember if I > mentioned that before.) > > rick Hi Rick, Just wanted to report that this fixed the "permission denied" error for my (not terribly exhaustive) testing. I could transfer all 10G of data by tar to the nfs mount without issue. I'll try running that a couple more times to be sure but given it was bombing out in seconds before i'm happy :) Vince From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 13:45:25 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F56C106564A; Tue, 10 Jul 2012 13:45:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 64F1E8FC12; Tue, 10 Jul 2012 13:45:25 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6ADjOWH084442; Tue, 10 Jul 2012 06:45:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6ADjNtw084441; Tue, 10 Jul 2012 06:45:23 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2012 06:45:23 -0700 From: Steve Kargl To: Rainer Hurling Message-ID: <20120710134523.GA84396@troutmask.apl.washington.edu> References: <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFBF16D.2030007@gwdg.de> User-Agent: Mutt/1.4.2.3i Cc: David Schultz , freebsd-current@FreeBSD.ORG, Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 13:45:25 -0000 On Tue, Jul 10, 2012 at 11:10:05AM +0200, Rainer Hurling wrote: > > Do you think your version from > http://www.freebsd.org/cgi/query-pr.cgi?pr=152415 for expl() ld80 > version could be the one getting into head? Would you be willing to > commit it? That's a fairly early version of the ld80 expl(). bde and das reviewed the code and made several suggested changes. > As far as I understand from discussions on R mailing list > (r-devel@r-project.org), they plan to reduce the emulation and/or > workaround of long and complex math functions for FreeBSD and other > systems with their next releases of R devel. So we could really need > some progress with our C99 conform math functions ;-) I don't know R, and I don't understand what is meant by 'they plan to reduce the emulation and/or workaround of ... funtions'. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:02:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8AAC106566B for ; Tue, 10 Jul 2012 14:02:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 946BD8FC0C for ; Tue, 10 Jul 2012 14:02:38 +0000 (UTC) Received: by yhfs35 with SMTP id s35so6756202yhf.13 for ; Tue, 10 Jul 2012 07:02:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ko5e6AUeKjKkojfbkE25ccEUdfWO4n8LenytQuj9ABQ=; b=gSCISeLqC85jAzI4xjMT37XnocfytQPyC3iMWTgpGBsUwgVdT919hBRZaxNXOeYIUk orTWm59MYc7koRoy42dz/14vviCsimTOwFiX2OlUjb1V5eNJTPCzkplk/4x6peQKXhqz gw/CwUXzLBZFcnvp+iMd23c7juB5/It4i8stHQK3kj3DOf2lT7URSGEOLo0zhBzFiYHM YfHaIi9wOWWnnqgk2wIIdiDn04LEOx3jOWzVPmx4cN9YNdksWsxziRmu3o51KtjX4nSU qejSsd6UOSogafJnXbAhCyjatTFTOLBsmjTkqBvOWWll8YiJBPtfvVYVkxbTte/Pv/bY ozAw== Received: by 10.68.131.10 with SMTP id oi10mr69047778pbb.122.1341928957697; Tue, 10 Jul 2012 07:02:37 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id gj8sm29945745pbc.39.2012.07.10.07.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 07:02:37 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4FFBF16D.2030007@gwdg.de> Date: Tue, 10 Jul 2012 08:02:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> References: <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> To: Rainer Hurling X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlwItex5KIj01PLGklaV1a3ZDMpyIezCpNYK814+BFf6IYVv2/sxdH2HEpTivlruAuxHl1+ Cc: David Schultz , freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 14:02:39 -0000 On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > As far as I understand from discussions on R mailing list = (r-devel@r-project.org), they plan to reduce the emulation and/or = workaround of long and complex math functions for FreeBSD and other = systems with their next releases of R devel. So we could really need = some progress with our C99 conform math functions ;-) Not having R would be a bit pain in my backside. That's one of the = practical considerations that I was talking about. It is very real, and = if I have to, I'll commit the #define junk I railed against to get it = back. Please, let's get some progress. I have some time to help. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:03:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 166C91065693; Tue, 10 Jul 2012 14:03:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2D88FC1F; Tue, 10 Jul 2012 14:03: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 q6AE3Qwx076024; Tue, 10 Jul 2012 10:03:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AE3QCt076023; Tue, 10 Jul 2012 14:03:26 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 14:03:26 GMT Message-Id: <201207101403.q6AE3QCt076023@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:03:28 -0000 TB --- 2012-07-10 12:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 12:50:00 - 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 --- 2012-07-10 12:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-10 12:50:00 - cleaning the object tree TB --- 2012-07-10 12:57:42 - cvsupping the source tree TB --- 2012-07-10 12:57:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-10 12:58:31 - building world TB --- 2012-07-10 12:58:31 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 12:58:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 12:58:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 12:58:31 - SRCCONF=/dev/null TB --- 2012-07-10 12:58:31 - TARGET=arm TB --- 2012-07-10 12:58:31 - TARGET_ARCH=arm TB --- 2012-07-10 12:58:31 - TZ=UTC TB --- 2012-07-10 12:58:31 - __MAKE_CONF=/dev/null TB --- 2012-07-10 12:58:31 - cd /src TB --- 2012-07-10 12:58:31 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 12:58:32 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 13:59:19 UTC 2012 TB --- 2012-07-10 13:59:19 - cd /src/sys/arm/conf TB --- 2012-07-10 13:59:19 - /usr/sbin/config -m ATMEL TB --- 2012-07-10 13:59:19 - building ATMEL kernel TB --- 2012-07-10 13:59:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 13:59:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 13:59:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 13:59:19 - SRCCONF=/dev/null TB --- 2012-07-10 13:59:19 - TARGET=arm TB --- 2012-07-10 13:59:19 - TARGET_ARCH=arm TB --- 2012-07-10 13:59:19 - TZ=UTC TB --- 2012-07-10 13:59:19 - __MAKE_CONF=/dev/null TB --- 2012-07-10 13:59:19 - cd /src TB --- 2012-07-10 13:59:19 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Jul 10 13:59:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Jul 10 14:02:49 UTC 2012 TB --- 2012-07-10 14:02:49 - cd /src/sys/arm/conf TB --- 2012-07-10 14:02:49 - /usr/sbin/config -m AVILA TB --- 2012-07-10 14:02:49 - building AVILA kernel TB --- 2012-07-10 14:02:49 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 14:02:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 14:02:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 14:02:49 - SRCCONF=/dev/null TB --- 2012-07-10 14:02:49 - TARGET=arm TB --- 2012-07-10 14:02:49 - TARGET_ARCH=arm TB --- 2012-07-10 14:02:49 - TZ=UTC TB --- 2012-07-10 14:02:49 - __MAKE_CONF=/dev/null TB --- 2012-07-10 14:02:49 - cd /src TB --- 2012-07-10 14:02:49 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue Jul 10 14:02:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1628: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 14:03:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 14:03:26 - ERROR: failed to build AVILA kernel TB --- 2012-07-10 14:03:26 - 2635.97 user 600.19 system 4405.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:08:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 716F21065670 for ; Tue, 10 Jul 2012 14:08:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B92F8FC1D for ; Tue, 10 Jul 2012 14:08:44 +0000 (UTC) Received: by ghbz22 with SMTP id z22so6618ghb.13 for ; Tue, 10 Jul 2012 07:08:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=9GucgKH6ju2h0JjttrNBr0tp3ZUbvLSoZHVR0VDLpGc=; b=jCANNHFpC2hlJduODXAkNkMSxCgg/MXjptVb7ZH2Zx3ouS0zLnsPXdPiq8bCY9yiPU EHWd3rmjomfFOsB6OyuKvMDgtSg2xd7rf1WnPLdeZtAQE7G0TkyJTlxILjX3392D/zcR z7VYJip+o6ExuBpd1VRjC0IZbm5cu5KZjoTnDzPi4UxHVqNE+OBC3xMIXTGUJlzC2iiF hZOwg794qV0cinbnlRkE5jrqmViAi2lxsotatkNw9WByZOt2bL3uDkJqTG2jDZHqptyc wrq71eI0SwKncJwGpMM9hlyXlJVKeS2u9d43cq0CoL6tHHfsPbk8jY7NnIdP9Uq23MeR r5dw== Received: by 10.66.75.201 with SMTP id e9mr73865800paw.54.1341929323485; Tue, 10 Jul 2012 07:08:43 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id of4sm29937159pbb.51.2012.07.10.07.08.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 07:08:43 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120710134523.GA84396@troutmask.apl.washington.edu> Date: Tue, 10 Jul 2012 08:08:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <20120710134523.GA84396@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkAf+TeQ90YhsgDye/KVIHCQNm9FFx1aukoHRClDAPpXTM1DAt2JN0CfeP5KtyMaLcPvb7/ Cc: Peter Jeremy , David Schultz , freebsd-current@FreeBSD.ORG Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 14:08:44 -0000 On Jul 10, 2012, at 7:45 AM, Steve Kargl wrote: > On Tue, Jul 10, 2012 at 11:10:05AM +0200, Rainer Hurling wrote: >>=20 >> Do you think your version from=20 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D152415 for expl() ld80=20= >> version could be the one getting into head? Would you be willing to=20= >> commit it? >=20 > That's a fairly early version of the ld80 expl(). > bde and das reviewed the code and made several > suggested changes. Cool. Send them to me and I'll move them into the tree. >> As far as I understand from discussions on R mailing list=20 >> (r-devel@r-project.org), they plan to reduce the emulation and/or=20 >> workaround of long and complex math functions for FreeBSD and other=20= >> systems with their next releases of R devel. So we could really need=20= >> some progress with our C99 conform math functions ;-) >=20 > I don't know R, and I don't understand what is meant > by 'they plan to reduce the emulation and/or workaround > of ... funtions'. R is a totally awesome statistical and graphics packaging. It means = they are dropping support for freeBSD because we don't have these = functions. That totally sucks, and to prevent that, I'd be willing to = commit the #define nonsense. Unless somebody has something better they = could forward me for integration... Warner= From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:20:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FB9D106566C for ; Tue, 10 Jul 2012 14:20:19 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 4768C8FC22 for ; Tue, 10 Jul 2012 14:20:19 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.10]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6AEKBq7004809 for ; Tue, 10 Jul 2012 08:20:12 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Tue, 10 Jul 2012 21:20:09 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201207102120.10009.erichfreebsdlist@ovitrap.com> Subject: 'HAL_INT_RXHP' undeclared (first use in this function) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 14:20:19 -0000 Hi, I updated my source tree a few hours ago and get now error messages like the one above while compiling /usr/src/sys/dev/ath/if_ath.c 'HAL_INT_RXHP' and 'HAL_INT_RXLP' seem to be totally unknown. There is one comment regarding the first of them. Google does not much either: 'Your search - HAL_INT_RXHP - did not match any documents. ' Who knows more about the values to be used for them? Erich From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:28:49 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 044E4106567F for ; Tue, 10 Jul 2012 14:28:49 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id A90418FC1E for ; Tue, 10 Jul 2012 14:28:48 +0000 (UTC) Received: (qmail 30778 invoked by uid 0); 10 Jul 2012 10:25:36 -0400 Received: from unknown (HELO glenbarber.us) (75.146.225.65) by 0 with SMTP; 10 Jul 2012 10:25:36 -0400 Date: Tue, 10 Jul 2012 10:25:34 -0400 From: Glen Barber To: Erich Dollansky Message-ID: <20120710142534.GA1485@glenbarber.us> References: <201207102120.10009.erichfreebsdlist@ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201207102120.10009.erichfreebsdlist@ovitrap.com> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: adrian@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: 'HAL_INT_RXHP' undeclared (first use in this function) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 14:28:49 -0000 On Tue, Jul 10, 2012 at 09:20:09PM +0700, Erich Dollansky wrote: > Hi, > > I updated my source tree a few hours ago and get now error messages like the one above while compiling > > /usr/src/sys/dev/ath/if_ath.c > > 'HAL_INT_RXHP' and 'HAL_INT_RXLP' seem to be totally unknown. There is one comment regarding the first of them. > > Google does not much either: > > 'Your search - HAL_INT_RXHP - did not match any documents. ' > > Who knows more about the values to be used for them? > Looks like it was introduced here: http://svn.freebsd.org/changeset/base/238343 Glen From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:50:29 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD8AE106564A; Tue, 10 Jul 2012 14:50:29 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 709128FC0A; Tue, 10 Jul 2012 14:50:29 +0000 (UTC) Received: from p508c758e.dip.t-dialin.net ([80.140.117.142] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Soblf-0000yF-AD; Tue, 10 Jul 2012 16:50:23 +0200 Message-ID: <4FFC412B.4090202@gwdg.de> Date: Tue, 10 Jul 2012 16:50:19 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: Warner Losh References: <4FC3EBDA.2080502@missouri.edu> <20120528221731.GA76723@troutmask.apl.washington.edu> <4FC40449.3040602@missouri.edu> <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> In-Reply-To: <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: David Schultz , freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 14:50:29 -0000 On 10.07.2012 16:02 (UTC+2), Warner Losh wrote: > > On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: >> As far as I understand from discussions on R mailing list (r-devel@r-project.org), they plan to reduce the emulation and/or workaround of long and complex math functions for FreeBSD and other systems with their next releases of R devel. So we could really need some progress with our C99 conform math functions ;-) > > Not having R would be a bit pain in my backside. That's one of the practical considerations that I was talking about. It is very real, and if I have to, I'll commit the #define junk I railed against to get it back. Please, let's get some progress. I have some time to help. Yes, thank you Warner, that is also my problem. As I wrote some weeks ago (05/28/2012) when starting this thread, I am using FreeBSD as a scientific desktop because of its good scaling properties. For some years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and some more. If I would not be able to run upcoming versions of R on FreeBSD any more, that would be really, really hard :-( Rainer > Warner From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 14:52:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9451065672 for ; Tue, 10 Jul 2012 14:52:28 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E17CF8FC14 for ; Tue, 10 Jul 2012 14:52:27 +0000 (UTC) Received: by qcsg15 with SMTP id g15so74226qcs.13 for ; Tue, 10 Jul 2012 07:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zHnVvvXi0DUi5EFcrLuInmVz0jyicqFlkHvDuArdk1w=; b=zEY8d4u4bNOZvLqR0dppvSG1t5PzJo0GTIJsfoFd1MtnCxnjP6/nQ5KEz1AQVksjxn JW4/CHd1HQXBhvbbOX4RM9f1gji3mcftWovMBThN5ghCaOsHObgeyXMrAbrOe5AIEgfk bZUX70Bqfn4kcKQjs+ssxnEKGm/BJJ9Xa39nX1stx0kWkb6CEAbroRG6JjRog9XQ5toD U+10wOFLY1pi7y6bQAplB6mvcJfUYCZVi40HOVlLMPw8ND68TGIJ1NyekRLh2MRp9Zye XR6/DS2hLAGLYm36oEuYtVI772jcZ7lcc89SLO6fG/FpuQxA4V5ZrFT8F1pJ0XwKkl3i A3Hw== MIME-Version: 1.0 Received: by 10.224.189.137 with SMTP id de9mr21640094qab.7.1341931947078; Tue, 10 Jul 2012 07:52:27 -0700 (PDT) Received: by 10.229.39.12 with HTTP; Tue, 10 Jul 2012 07:52:26 -0700 (PDT) Date: Tue, 10 Jul 2012 10:52:26 -0400 Message-ID: From: Kim Culhan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 14:52:28 -0000 Updating -current to r238290 after make buildworld, installworld fails at: install -o root -g wheel -m 444 as.info.gz ld.info.gz binutils.info.gz /usr/share/info ===> gnu/usr.bin/cc (install) ===> gnu/usr.bin/cc/cc_tools (install) ===> gnu/usr.bin/cc/libiberty (install) ===> gnu/usr.bin/cc/libcpp (install) ===> gnu/usr.bin/cc/libdecnumber (install) ===> gnu/usr.bin/cc/cc_int (install) ===> gnu/usr.bin/cc/cc (install) install -s -o root -g wheel -m 555 gcc /usr/bin install: gcc: No such file or directory *** [_proginstall] Error code 71 Stop in /usr/src/gnu/usr.bin/cc/cc. *** [realinstall] Error code 1 Any help is greatly appreciated. thanks -kim From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:00:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 711C01065674 for ; Tue, 10 Jul 2012 15:00:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id DB6B18FC1E for ; Tue, 10 Jul 2012 15:00:47 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6AF0qJx026459; Tue, 10 Jul 2012 18:00:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6AF0eAW053565; Tue, 10 Jul 2012 18:00:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6AF0eE8053564; Tue, 10 Jul 2012 18:00:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 10 Jul 2012 18:00:40 +0300 From: Konstantin Belousov To: Kim Culhan Message-ID: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F3Ja72XjDYN1ox8a" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 15:00:48 -0000 --F3Ja72XjDYN1ox8a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 10:52:26AM -0400, Kim Culhan wrote: > Updating -current to r238290 after make buildworld, installworld fails at: >=20 > install -o root -g wheel -m 444 as.info.gz ld.info.gz > binutils.info.gz /usr/share/info > =3D=3D=3D> gnu/usr.bin/cc (install) > =3D=3D=3D> gnu/usr.bin/cc/cc_tools (install) > =3D=3D=3D> gnu/usr.bin/cc/libiberty (install) > =3D=3D=3D> gnu/usr.bin/cc/libcpp (install) > =3D=3D=3D> gnu/usr.bin/cc/libdecnumber (install) > =3D=3D=3D> gnu/usr.bin/cc/cc_int (install) > =3D=3D=3D> gnu/usr.bin/cc/cc (install) > install -s -o root -g wheel -m 555 gcc /usr/bin > install: gcc: No such file or directory > *** [_proginstall] Error code 71 >=20 > Stop in /usr/src/gnu/usr.bin/cc/cc. > *** [realinstall] Error code 1 >=20 > Any help is greatly appreciated. Are you installing to NFS ? What is the version of the kernel you run ? If installing to NFS, and you run a kernel before r237987, try to set sysctl debug.vn_io_fault_enable to 0. --F3Ja72XjDYN1ox8a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/8Q5gACgkQC3+MBN1Mb4j7DQCfQimli5biOBdSCu8QAFizIqo3 +s8An2HqN4KC0luNP68em28ENlxdHX3A =QGUA -----END PGP SIGNATURE----- --F3Ja72XjDYN1ox8a-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:11:23 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB8351065670 for ; Tue, 10 Jul 2012 15:11:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7665D8FC14 for ; Tue, 10 Jul 2012 15:11:23 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q6AFBG9N057004; Tue, 10 Jul 2012 11:11:16 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q6AFBF2h057003; Tue, 10 Jul 2012 11:11:15 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 10 Jul 2012 11:11:15 -0400 From: David Schultz To: Rainer Hurling Message-ID: <20120710151115.GA56950@zim.MIT.EDU> Mail-Followup-To: Rainer Hurling , Warner Losh , Steve Kargl , freebsd-current@FreeBSD.ORG, Peter Jeremy References: <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFC412B.4090202@gwdg.de> Cc: freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 15:11:23 -0000 On Tue, Jul 10, 2012, Rainer Hurling wrote: > On 10.07.2012 16:02 (UTC+2), Warner Losh wrote: > > > >On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > >>As far as I understand from discussions on R mailing list > >>(r-devel@r-project.org), they plan to reduce the emulation and/or > >>workaround of long and complex math functions for FreeBSD and other > >>systems with their next releases of R devel. So we could really need some > >>progress with our C99 conform math functions ;-) > > > >Not having R would be a bit pain in my backside. That's one of the > >practical considerations that I was talking about. It is very real, and > >if I have to, I'll commit the #define junk I railed against to get it > >back. Please, let's get some progress. I have some time to help. > > Yes, thank you Warner, that is also my problem. As I wrote some weeks > ago (05/28/2012) when starting this thread, I am using FreeBSD as a > scientific desktop because of its good scaling properties. For some > years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and > some more. > > If I would not be able to run upcoming versions of R on FreeBSD any > more, that would be really, really hard :-( Do you have a list of the essential functions here? There are 17 long double functions and some complex functions missing, but only a handful of those are of general interest. The reason I ask is that if R is just looking for a few missing functions that are already mostly implemented, then the best solution is probably to finish that work. But if it's expecting us to have something arcane like long double Bessel functions of the first kind, then we need to pursue a workaround in the short term. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:35:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51AFE106566C; Tue, 10 Jul 2012 15:35:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7928FC14; Tue, 10 Jul 2012 15:35: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 q6AFZIZo095227; Tue, 10 Jul 2012 11:35:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AFZIq7095218; Tue, 10 Jul 2012 15:35:18 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 15:35:18 GMT Message-Id: <201207101535.q6AFZIq7095218@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 15:35:19 -0000 TB --- 2012-07-10 12:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 12:50:00 - 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 --- 2012-07-10 12:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-10 12:50:00 - cleaning the object tree TB --- 2012-07-10 12:55:04 - cvsupping the source tree TB --- 2012-07-10 12:55:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-10 12:57:27 - building world TB --- 2012-07-10 12:57:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 12:57:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 12:57:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 12:57:27 - SRCCONF=/dev/null TB --- 2012-07-10 12:57:27 - TARGET=pc98 TB --- 2012-07-10 12:57:27 - TARGET_ARCH=i386 TB --- 2012-07-10 12:57:27 - TZ=UTC TB --- 2012-07-10 12:57:27 - __MAKE_CONF=/dev/null TB --- 2012-07-10 12:57:27 - cd /src TB --- 2012-07-10 12:57:27 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 12:57:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 15:27:29 UTC 2012 TB --- 2012-07-10 15:27:29 - generating LINT kernel config TB --- 2012-07-10 15:27:29 - cd /src/sys/pc98/conf TB --- 2012-07-10 15:27:29 - /usr/bin/make -B LINT TB --- 2012-07-10 15:27:29 - cd /src/sys/pc98/conf TB --- 2012-07-10 15:27:29 - /usr/sbin/config -m LINT TB --- 2012-07-10 15:27:30 - building LINT kernel TB --- 2012-07-10 15:27:30 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 15:27:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 15:27:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 15:27:30 - SRCCONF=/dev/null TB --- 2012-07-10 15:27:30 - TARGET=pc98 TB --- 2012-07-10 15:27:30 - TARGET_ARCH=i386 TB --- 2012-07-10 15:27:30 - TZ=UTC TB --- 2012-07-10 15:27:30 - __MAKE_CONF=/dev/null TB --- 2012-07-10 15:27:30 - cd /src TB --- 2012-07-10 15:27:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 15:27:30 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 15:35:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 15:35:18 - ERROR: failed to build LINT kernel TB --- 2012-07-10 15:35:18 - 6699.27 user 966.63 system 9917.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:36:44 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A59D1065677; Tue, 10 Jul 2012 15:36:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0923C8FC1E; Tue, 10 Jul 2012 15:36:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6AFahVf001096; Tue, 10 Jul 2012 11:36:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AFahRC001095; Tue, 10 Jul 2012 15:36:43 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 15:36:43 GMT Message-Id: <201207101536.q6AFahRC001095@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 15:36:44 -0000 TB --- 2012-07-10 12:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 12:50:00 - 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 --- 2012-07-10 12:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-10 12:50:00 - cleaning the object tree TB --- 2012-07-10 12:55:22 - cvsupping the source tree TB --- 2012-07-10 12:55:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-10 12:57:35 - building world TB --- 2012-07-10 12:57:35 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 12:57:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 12:57:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 12:57:35 - SRCCONF=/dev/null TB --- 2012-07-10 12:57:35 - TARGET=i386 TB --- 2012-07-10 12:57:35 - TARGET_ARCH=i386 TB --- 2012-07-10 12:57:35 - TZ=UTC TB --- 2012-07-10 12:57:35 - __MAKE_CONF=/dev/null TB --- 2012-07-10 12:57:35 - cd /src TB --- 2012-07-10 12:57:35 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 12:57:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 15:27:43 UTC 2012 TB --- 2012-07-10 15:27:43 - generating LINT kernel config TB --- 2012-07-10 15:27:43 - cd /src/sys/i386/conf TB --- 2012-07-10 15:27:43 - /usr/bin/make -B LINT TB --- 2012-07-10 15:27:43 - cd /src/sys/i386/conf TB --- 2012-07-10 15:27:43 - /usr/sbin/config -m LINT TB --- 2012-07-10 15:27:43 - building LINT kernel TB --- 2012-07-10 15:27:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 15:27:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 15:27:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 15:27:43 - SRCCONF=/dev/null TB --- 2012-07-10 15:27:43 - TARGET=i386 TB --- 2012-07-10 15:27:43 - TARGET_ARCH=i386 TB --- 2012-07-10 15:27:43 - TZ=UTC TB --- 2012-07-10 15:27:43 - __MAKE_CONF=/dev/null TB --- 2012-07-10 15:27:43 - cd /src TB --- 2012-07-10 15:27:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 15:27:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 15:36:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 15:36:43 - ERROR: failed to build LINT kernel TB --- 2012-07-10 15:36:43 - 6790.44 user 981.82 system 10002.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:40:42 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00B571065670 for ; Tue, 10 Jul 2012 15:40:42 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id AEBB58FC15 for ; Tue, 10 Jul 2012 15:40:41 +0000 (UTC) Received: by qabg1 with SMTP id g1so2453822qab.13 for ; Tue, 10 Jul 2012 08:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bg7k7KsAaCoqpyaDJU7aB4yTPiCQ8HHdsFV+xgOvI90=; b=UBvp/f3AzRCNA/V+++BBqLesvpI7Dst4iRIQuXpDl0IOnlXbNcNotQIG4gsjdNx0Iw ShSrXbvNVOukBJv0i83UNF4yqxXDvN56ehOigTP8TEzdRgdll7Ru0QJLmRP6c1+M7xHV CgHQWOi1LBVlziZsI4qX9CpUu9gQwKoqwrtVp2Nf0LNc3IhK+2qZDbyNFeH8BzgBpfPY IgddmTIJpgFffPJQ+UG3fQz47KJLaZAvc29VWhNlm8PHxBwhv9VX+23Y03TiOLEXDJhk US9IPoYfx3pjdFBCXcSfO0KCP6ACn6epzIn4pPO1B06VwbK0/a8Wd7wcv4KQrDbHzw6y e5SA== MIME-Version: 1.0 Received: by 10.224.222.147 with SMTP id ig19mr71393864qab.32.1341934841092; Tue, 10 Jul 2012 08:40:41 -0700 (PDT) Received: by 10.229.39.12 with HTTP; Tue, 10 Jul 2012 08:40:41 -0700 (PDT) In-Reply-To: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> References: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> Date: Tue, 10 Jul 2012 11:40:41 -0400 Message-ID: From: Kim Culhan To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 15:40:42 -0000 On Tue, Jul 10, 2012 at 11:00 AM, Konstantin Belousov wrote: > On Tue, Jul 10, 2012 at 10:52:26AM -0400, Kim Culhan wrote: >> Updating -current to r238290 after make buildworld, installworld fails at: >> >> install -o root -g wheel -m 444 as.info.gz ld.info.gz >> binutils.info.gz /usr/share/info >> ===> gnu/usr.bin/cc (install) >> ===> gnu/usr.bin/cc/cc_tools (install) >> ===> gnu/usr.bin/cc/libiberty (install) >> ===> gnu/usr.bin/cc/libcpp (install) >> ===> gnu/usr.bin/cc/libdecnumber (install) >> ===> gnu/usr.bin/cc/cc_int (install) >> ===> gnu/usr.bin/cc/cc (install) >> install -s -o root -g wheel -m 555 gcc /usr/bin >> install: gcc: No such file or directory >> *** [_proginstall] Error code 71 >> >> Stop in /usr/src/gnu/usr.bin/cc/cc. >> *** [realinstall] Error code 1 >> >> Any help is greatly appreciated. > Are you installing to NFS ? What is the version of the kernel you run ? > > If installing to NFS, and you run a kernel before r237987, try to set > sysctl debug.vn_io_fault_enable to 0. Not installing to NFS, present kernel is 236925. -kim From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 15:49:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 453FE106566C; Tue, 10 Jul 2012 15:49:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EF1988FC19; Tue, 10 Jul 2012 15:49: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 q6AFn4dn000250; Tue, 10 Jul 2012 11:49:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AFn4Uc000246; Tue, 10 Jul 2012 15:49:04 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 15:49:04 GMT Message-Id: <201207101549.q6AFn4Uc000246@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 15:49:05 -0000 TB --- 2012-07-10 14:03:26 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 14:03:26 - 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 --- 2012-07-10 14:03:26 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-10 14:03:26 - cleaning the object tree TB --- 2012-07-10 14:04:19 - cvsupping the source tree TB --- 2012-07-10 14:04:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-10 14:04:49 - building world TB --- 2012-07-10 14:04:49 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 14:04:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 14:04:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 14:04:49 - SRCCONF=/dev/null TB --- 2012-07-10 14:04:49 - TARGET=ia64 TB --- 2012-07-10 14:04:49 - TARGET_ARCH=ia64 TB --- 2012-07-10 14:04:49 - TZ=UTC TB --- 2012-07-10 14:04:49 - __MAKE_CONF=/dev/null TB --- 2012-07-10 14:04:49 - cd /src TB --- 2012-07-10 14:04:49 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 14:04:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 15:43:08 UTC 2012 TB --- 2012-07-10 15:43:08 - generating LINT kernel config TB --- 2012-07-10 15:43:08 - cd /src/sys/ia64/conf TB --- 2012-07-10 15:43:08 - /usr/bin/make -B LINT TB --- 2012-07-10 15:43:08 - cd /src/sys/ia64/conf TB --- 2012-07-10 15:43:08 - /usr/sbin/config -m LINT TB --- 2012-07-10 15:43:08 - building LINT kernel TB --- 2012-07-10 15:43:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 15:43:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 15:43:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 15:43:08 - SRCCONF=/dev/null TB --- 2012-07-10 15:43:08 - TARGET=ia64 TB --- 2012-07-10 15:43:08 - TARGET_ARCH=ia64 TB --- 2012-07-10 15:43:08 - TZ=UTC TB --- 2012-07-10 15:43:08 - __MAKE_CONF=/dev/null TB --- 2012-07-10 15:43:08 - cd /src TB --- 2012-07-10 15:43:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 15:43:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 15:49:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 15:49:04 - ERROR: failed to build LINT kernel TB --- 2012-07-10 15:49:04 - 4506.82 user 690.23 system 6337.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:11:38 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF0411065689; Tue, 10 Jul 2012 16:11:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id AEFDD8FC08; Tue, 10 Jul 2012 16:11: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 q6AGBbcj096421; Tue, 10 Jul 2012 12:11:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AGBbWn096378; Tue, 10 Jul 2012 16:11:37 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 16:11:37 GMT Message-Id: <201207101611.q6AGBbWn096378@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:11:38 -0000 TB --- 2012-07-10 12:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 12:50:00 - 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 --- 2012-07-10 12:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-10 12:50:00 - cleaning the object tree TB --- 2012-07-10 12:58:42 - cvsupping the source tree TB --- 2012-07-10 12:58:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-10 12:59:27 - building world TB --- 2012-07-10 12:59:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 12:59:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 12:59:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 12:59:27 - SRCCONF=/dev/null TB --- 2012-07-10 12:59:27 - TARGET=amd64 TB --- 2012-07-10 12:59:27 - TARGET_ARCH=amd64 TB --- 2012-07-10 12:59:27 - TZ=UTC TB --- 2012-07-10 12:59:27 - __MAKE_CONF=/dev/null TB --- 2012-07-10 12:59:27 - cd /src TB --- 2012-07-10 12:59:27 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 12:59:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 10 16:03:20 UTC 2012 TB --- 2012-07-10 16:03:20 - generating LINT kernel config TB --- 2012-07-10 16:03:20 - cd /src/sys/amd64/conf TB --- 2012-07-10 16:03:20 - /usr/bin/make -B LINT TB --- 2012-07-10 16:03:20 - cd /src/sys/amd64/conf TB --- 2012-07-10 16:03:20 - /usr/sbin/config -m LINT TB --- 2012-07-10 16:03:20 - building LINT kernel TB --- 2012-07-10 16:03:20 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 16:03:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 16:03:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 16:03:20 - SRCCONF=/dev/null TB --- 2012-07-10 16:03:20 - TARGET=amd64 TB --- 2012-07-10 16:03:20 - TARGET_ARCH=amd64 TB --- 2012-07-10 16:03:20 - TZ=UTC TB --- 2012-07-10 16:03:20 - __MAKE_CONF=/dev/null TB --- 2012-07-10 16:03:20 - cd /src TB --- 2012-07-10 16:03:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 16:03:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 16:11:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 16:11:37 - ERROR: failed to build LINT kernel TB --- 2012-07-10 16:11:37 - 8171.41 user 1285.15 system 12096.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:14:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBBD1065673 for ; Tue, 10 Jul 2012 16:14:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01FC68FC0C for ; Tue, 10 Jul 2012 16:14:25 +0000 (UTC) Received: by obbun3 with SMTP id un3so188332obb.13 for ; Tue, 10 Jul 2012 09:14:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=FZ/DHzmbhp+rgZUrnla1Hb/11d+q5Iec3MCMfP5u7XU=; b=C8APnaa7fVqichpPFbkH92dCo3ai7dn1ZfmIDiWbv9GCVUoLVYh20+0B9yO5XXfFwm vcy0FWXNYO19/+8ek0WwH0fUP7ZYU7JCX0X+VYAmvfAvhPmdfSG7UFpfzx+Uvmksw9nv 6eOLcDiNpPeKVVQu6B5zLcQXbeinLIEIlTGy/Pl+C5FHjtB8ZDi7AHlKA3i79Xrk4np0 iB/xhc6k/llk6LyduGLNYjWZmiNbFbc+B41YgVyY5Ob7ZbTs27AIXOTsderzGfxyGUh9 ZxK32ulfqC6zBh3hZNvddC8ldB/OapNRlWdEy/uRHpQUNpsBVPV5gecPmJDMpQwTEcQc vAew== Received: by 10.182.174.70 with SMTP id bq6mr41555115obc.78.1341936865384; Tue, 10 Jul 2012 09:14:25 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id fy8sm33165983obc.4.2012.07.10.09.14.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 09:14:24 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120710151115.GA56950@zim.MIT.EDU> Date: Tue, 10 Jul 2012 10:14:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7A095700-AA58-4DB1-B5D7-8F6B7934AC8B@bsdimp.com> References: <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> To: David Schultz X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQm4oivc0T4jJqP0g1KA38xLAKYaxTH/V+5cr7yghNfll4m1MJMqzBVdrgqB+54R78CXbSUH Cc: Peter Jeremy , freebsd-current@FreeBSD.ORG, Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 16:14:26 -0000 On Jul 10, 2012, at 9:11 AM, David Schultz wrote: > On Tue, Jul 10, 2012, Rainer Hurling wrote: >> On 10.07.2012 16:02 (UTC+2), Warner Losh wrote: >>>=20 >>> On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: >>>> As far as I understand from discussions on R mailing list=20 >>>> (r-devel@r-project.org), they plan to reduce the emulation and/or=20= >>>> workaround of long and complex math functions for FreeBSD and other=20= >>>> systems with their next releases of R devel. So we could really = need some=20 >>>> progress with our C99 conform math functions ;-) >>>=20 >>> Not having R would be a bit pain in my backside. That's one of the=20= >>> practical considerations that I was talking about. It is very real, = and=20 >>> if I have to, I'll commit the #define junk I railed against to get = it=20 >>> back. Please, let's get some progress. I have some time to help. >>=20 >> Yes, thank you Warner, that is also my problem. As I wrote some weeks=20= >> ago (05/28/2012) when starting this thread, I am using FreeBSD as a=20= >> scientific desktop because of its good scaling properties. For some=20= >> years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL = and=20 >> some more. >>=20 >> If I would not be able to run upcoming versions of R on FreeBSD any=20= >> more, that would be really, really hard :-( >=20 > Do you have a list of the essential functions here? There are 17 long > double functions and some complex functions missing, but only a > handful of those are of general interest. The reason I ask is that if > R is just looking for a few missing functions that are already mostly > implemented, then the best solution is probably to finish that work. > But if it's expecting us to have something arcane like long double > Bessel functions of the first kind, then we need to pursue a = workaround > in the short term. I'll get a list, but they are things like long long double exp and ln. = I don't think they were the Bessel functions. Warner From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:40:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D0E2106566B for ; Tue, 10 Jul 2012 16:40:06 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4DA8FC14 for ; Tue, 10 Jul 2012 16:40:06 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6AGdxnF004284; Tue, 10 Jul 2012 11:39:59 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4FFC5ADF.2010601@missouri.edu> Date: Tue, 10 Jul 2012 11:39:59 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> <4FFA52F8.2080700@missouri.edu> <20120709050238.GA54634@troutmask.apl.washington.edu> In-Reply-To: <20120709050238.GA54634@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 16:40:06 -0000 On 07/09/2012 12:02 AM, Steve Kargl wrote: > Yep. Another example is the use of upward recurion to compute > Bessel functions where the argument is larger than the order. > The algorithm is known to be unstable. By upward recursion, do you mean equation (1) in http://mathworld.wolfram.com/BesselFunction.html? So what do people use. Maybe something like http://en.wikipedia.org/wiki/Bessel_function#Asymptotic_forms (second set of equations), but finding some asymptotics with a few extra terms in them? From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:40:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E49A106564A; Tue, 10 Jul 2012 16:40:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E0C4B8FC17; Tue, 10 Jul 2012 16:40:34 +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 q6AGeY0m069716; Tue, 10 Jul 2012 12:40:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AGeYQF069715; Tue, 10 Jul 2012 16:40:34 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 16:40:34 GMT Message-Id: <201207101640.q6AGeYQF069715@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:40:35 -0000 TB --- 2012-07-10 15:35:18 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 15:35:18 - 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 --- 2012-07-10 15:35:18 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-10 15:35:18 - cleaning the object tree TB --- 2012-07-10 15:36:22 - cvsupping the source tree TB --- 2012-07-10 15:36:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-10 15:37:26 - building world TB --- 2012-07-10 15:37:26 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 15:37:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 15:37:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 15:37:26 - SRCCONF=/dev/null TB --- 2012-07-10 15:37:26 - TARGET=mips TB --- 2012-07-10 15:37:26 - TARGET_ARCH=mips TB --- 2012-07-10 15:37:26 - TZ=UTC TB --- 2012-07-10 15:37:26 - __MAKE_CONF=/dev/null TB --- 2012-07-10 15:37:26 - cd /src TB --- 2012-07-10 15:37:26 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 15:37:27 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 16:39:49 UTC 2012 TB --- 2012-07-10 16:39:49 - cd /src/sys/mips/conf TB --- 2012-07-10 16:39:49 - /usr/sbin/config -m ADM5120 TB --- 2012-07-10 16:39:49 - skipping ADM5120 kernel TB --- 2012-07-10 16:39:49 - cd /src/sys/mips/conf TB --- 2012-07-10 16:39:49 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-10 16:39:49 - skipping ALCHEMY kernel TB --- 2012-07-10 16:39:49 - cd /src/sys/mips/conf TB --- 2012-07-10 16:39:49 - /usr/sbin/config -m AP93 TB --- 2012-07-10 16:39:49 - building AP93 kernel TB --- 2012-07-10 16:39:49 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 16:39:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 16:39:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 16:39:49 - SRCCONF=/dev/null TB --- 2012-07-10 16:39:49 - TARGET=mips TB --- 2012-07-10 16:39:49 - TARGET_ARCH=mips TB --- 2012-07-10 16:39:49 - TZ=UTC TB --- 2012-07-10 16:39:49 - __MAKE_CONF=/dev/null TB --- 2012-07-10 16:39:49 - cd /src TB --- 2012-07-10 16:39:49 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Tue Jul 10 16:39:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1628: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 16:40:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 16:40:34 - ERROR: failed to build AP93 kernel TB --- 2012-07-10 16:40:34 - 2584.11 user 567.24 system 3915.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:50:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C421065675 for ; Tue, 10 Jul 2012 16:50:46 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 5F60C8FC1A for ; Tue, 10 Jul 2012 16:50:46 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6AGojGC094871; Tue, 10 Jul 2012 09:50:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6AGojVZ094870; Tue, 10 Jul 2012 09:50:45 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2012 09:50:45 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120710165045.GA94795@troutmask.apl.washington.edu> References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> <4FFA52F8.2080700@missouri.edu> <20120709050238.GA54634@troutmask.apl.washington.edu> <4FFC5ADF.2010601@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFC5ADF.2010601@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 16:50:46 -0000 On Tue, Jul 10, 2012 at 11:39:59AM -0500, Stephen Montgomery-Smith wrote: > On 07/09/2012 12:02 AM, Steve Kargl wrote: > > >Yep. Another example is the use of upward recurion to compute > >Bessel functions where the argument is larger than the order. > >The algorithm is known to be unstable. > > By upward recursion, do you mean equation (1) in > http://mathworld.wolfram.com/BesselFunction.html? Yes. > So what do people use. Maybe something like > http://en.wikipedia.org/wiki/Bessel_function#Asymptotic_forms (second > set of equations), but finding some asymptotics with a few extra terms > in them? They use downward recursion, which is known to be stable. NIST has revised Abramowitz and Stegun, and it is available on line. For Bessel function computations, look at http://dlmf.nist.gov/10.74 and more importantly example 1 under the following link http://dlmf.nist.gov/3.6#v -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 16:54:56 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B569C106564A; Tue, 10 Jul 2012 16:54:56 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 413C48FC14; Tue, 10 Jul 2012 16:54:56 +0000 (UTC) Received: from p508c758e.dip.t-dialin.net ([80.140.117.142] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Sodi9-00040k-O5; Tue, 10 Jul 2012 18:54:53 +0200 Message-ID: <4FFC5E5D.8000502@gwdg.de> Date: Tue, 10 Jul 2012 18:54:53 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Schultz References: <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> In-Reply-To: <20120710151115.GA56950@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 16:54:56 -0000 On 10.07.2012 17:11 (UTC+2), David Schultz wrote: > On Tue, Jul 10, 2012, Rainer Hurling wrote: >> On 10.07.2012 16:02 (UTC+2), Warner Losh wrote: >>> >>> On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: >>>> As far as I understand from discussions on R mailing list >>>> (r-devel@r-project.org), they plan to reduce the emulation and/or >>>> workaround of long and complex math functions for FreeBSD and other >>>> systems with their next releases of R devel. So we could really need some >>>> progress with our C99 conform math functions ;-) >>> >>> Not having R would be a bit pain in my backside. That's one of the >>> practical considerations that I was talking about. It is very real, and >>> if I have to, I'll commit the #define junk I railed against to get it >>> back. Please, let's get some progress. I have some time to help. >> >> Yes, thank you Warner, that is also my problem. As I wrote some weeks >> ago (05/28/2012) when starting this thread, I am using FreeBSD as a >> scientific desktop because of its good scaling properties. For some >> years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and >> some more. >> >> If I would not be able to run upcoming versions of R on FreeBSD any >> more, that would be really, really hard :-( > > Do you have a list of the essential functions here? There are 17 long > double functions and some complex functions missing, but only a > handful of those are of general interest. The reason I ask is that if > R is just looking for a few missing functions that are already mostly > implemented, then the best solution is probably to finish that work. > But if it's expecting us to have something arcane like long double > Bessel functions of the first kind, then we need to pursue a workaround > in the short term. > That is, what I found by grepping the sources of a recent R development version: expl: src/nmath/pnchisq.c log10l: src/extra/trio/trio.c log1pl: src/nmath/pnbeta.c logl: src/nmath/dnbeta.c src/nmath/pnbeta.c powl: src/extra/trio/triostr.c src/extra/trio/trio.c src/main/format.c In the R NEWS file I found the following three entries about C99 (complex) functions: NEWS:l2044 The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are now required. NEWS:l3032 The C99 double complex type is now required. The C99 complex trigonometric functions (such as csin) are not currently required (FreeBSD lacks most of them): substitutes are used if they are missing. NEWS:l3277 Complex arithmetic (notably z^n for complex z and integer n) gave incorrect results since R 2.10.0 on platforms without C99 complex support. This and some lesser issues in trigonometric functions have been corrected. Such platforms were rare (we know of Cygwin and FreeBSD). However, because of new compiler optimizations in the way complex arguments are handled, the same code was selected on x86_64 Linux with gcc 4.5.x at the default -O2 optimization (but not at -O). From the discussions on the R-devel mailing list we could expect, that there will be more complex (long, longlong) functions introduced in the near future. (But it is very likely that b.f. does know much more about this.) Rainer BTW: There seems to be a discrepancy about missing functions listed in http://wiki.freebsd.org/MissingMathStuff and in http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=227472&r2=236148&pathrev=236148. So the wiki is a bit outdated now? From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 17:22:03 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B4FD1065672; Tue, 10 Jul 2012 17:22:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 150028FC0A; Tue, 10 Jul 2012 17:22:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6AHM2eG094507; Tue, 10 Jul 2012 13:22:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AHM27e094494; Tue, 10 Jul 2012 17:22:02 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 17:22:02 GMT Message-Id: <201207101722.q6AHM27e094494@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:22:03 -0000 TB --- 2012-07-10 16:11:37 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 16:11:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 16:11:37 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 16:11:37 - cleaning the object tree TB --- 2012-07-10 16:13:24 - cvsupping the source tree TB --- 2012-07-10 16:13:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 16:14:29 - building world TB --- 2012-07-10 16:14:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 16:14:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 16:14:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 16:14:29 - SRCCONF=/dev/null TB --- 2012-07-10 16:14:29 - TARGET=sparc64 TB --- 2012-07-10 16:14:29 - TARGET_ARCH=sparc64 TB --- 2012-07-10 16:14:29 - TZ=UTC TB --- 2012-07-10 16:14:29 - __MAKE_CONF=/dev/null TB --- 2012-07-10 16:14:29 - cd /src TB --- 2012-07-10 16:14:29 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 16:14:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 17:17:16 UTC 2012 TB --- 2012-07-10 17:17:16 - generating LINT kernel config TB --- 2012-07-10 17:17:16 - cd /src/sys/sparc64/conf TB --- 2012-07-10 17:17:16 - /usr/bin/make -B LINT TB --- 2012-07-10 17:17:16 - cd /src/sys/sparc64/conf TB --- 2012-07-10 17:17:16 - /usr/sbin/config -m LINT TB --- 2012-07-10 17:17:16 - building LINT kernel TB --- 2012-07-10 17:17:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 17:17:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 17:17:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 17:17:16 - SRCCONF=/dev/null TB --- 2012-07-10 17:17:16 - TARGET=sparc64 TB --- 2012-07-10 17:17:16 - TARGET_ARCH=sparc64 TB --- 2012-07-10 17:17:16 - TZ=UTC TB --- 2012-07-10 17:17:16 - __MAKE_CONF=/dev/null TB --- 2012-07-10 17:17:16 - cd /src TB --- 2012-07-10 17:17:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 17:17:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 17:22:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 17:22:02 - ERROR: failed to build LINT kernel TB --- 2012-07-10 17:22:02 - 3149.62 user 578.56 system 4225.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 17:54:43 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1C52106564A; Tue, 10 Jul 2012 17:54:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9C59D8FC12; Tue, 10 Jul 2012 17:54:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6AHsgo6014863; Tue, 10 Jul 2012 13:54:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AHsgJ2014862; Tue, 10 Jul 2012 17:54:42 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 17:54:42 GMT Message-Id: <201207101754.q6AHsgJ2014862@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:54:43 -0000 TB --- 2012-07-10 15:36:43 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 15:36:43 - 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 --- 2012-07-10 15:36:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-10 15:36:43 - cleaning the object tree TB --- 2012-07-10 15:38:35 - cvsupping the source tree TB --- 2012-07-10 15:38:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-10 15:39:24 - building world TB --- 2012-07-10 15:39:24 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 15:39:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 15:39:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 15:39:24 - SRCCONF=/dev/null TB --- 2012-07-10 15:39:24 - TARGET=powerpc TB --- 2012-07-10 15:39:24 - TARGET_ARCH=powerpc TB --- 2012-07-10 15:39:24 - TZ=UTC TB --- 2012-07-10 15:39:24 - __MAKE_CONF=/dev/null TB --- 2012-07-10 15:39:24 - cd /src TB --- 2012-07-10 15:39:24 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 15:39:25 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 17:51:20 UTC 2012 TB --- 2012-07-10 17:51:20 - generating LINT kernel config TB --- 2012-07-10 17:51:20 - cd /src/sys/powerpc/conf TB --- 2012-07-10 17:51:20 - /usr/bin/make -B LINT TB --- 2012-07-10 17:51:20 - cd /src/sys/powerpc/conf TB --- 2012-07-10 17:51:20 - /usr/sbin/config -m LINT TB --- 2012-07-10 17:51:20 - building LINT kernel TB --- 2012-07-10 17:51:20 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 17:51:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 17:51:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 17:51:20 - SRCCONF=/dev/null TB --- 2012-07-10 17:51:20 - TARGET=powerpc TB --- 2012-07-10 17:51:20 - TARGET_ARCH=powerpc TB --- 2012-07-10 17:51:20 - TZ=UTC TB --- 2012-07-10 17:51:20 - __MAKE_CONF=/dev/null TB --- 2012-07-10 17:51:20 - cd /src TB --- 2012-07-10 17:51:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 17:51:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 17:54:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 17:54:42 - ERROR: failed to build LINT kernel TB --- 2012-07-10 17:54:42 - 6729.49 user 879.75 system 8279.13 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 18:11:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94F84106564A for ; Tue, 10 Jul 2012 18:11:39 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3E25E8FC0C for ; Tue, 10 Jul 2012 18:11:39 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6AIBcts028977; Tue, 10 Jul 2012 13:11:38 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4FFC705A.6070403@missouri.edu> Date: Tue, 10 Jul 2012 13:11:38 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Steve Kargl References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> <4FFA52F8.2080700@missouri.edu> <20120709050238.GA54634@troutmask.apl.washington.edu> <4FFC5ADF.2010601@missouri.edu> <20120710165045.GA94795@troutmask.apl.washington.edu> In-Reply-To: <20120710165045.GA94795@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 18:11:39 -0000 On 07/10/2012 11:50 AM, Steve Kargl wrote: > On Tue, Jul 10, 2012 at 11:39:59AM -0500, Stephen Montgomery-Smith wrote: >> On 07/09/2012 12:02 AM, Steve Kargl wrote: >> >>> Yep. Another example is the use of upward recurion to compute >>> Bessel functions where the argument is larger than the order. >>> The algorithm is known to be unstable. >> >> By upward recursion, do you mean equation (1) in >> http://mathworld.wolfram.com/BesselFunction.html? > > Yes. > >> So what do people use. Maybe something like >> http://en.wikipedia.org/wiki/Bessel_function#Asymptotic_forms (second >> set of equations), but finding some asymptotics with a few extra terms >> in them? > > They use downward recursion, which is known to be stable. > NIST has revised Abramowitz and Stegun, and it is available > on line. For Bessel function computations, look at > http://dlmf.nist.gov/10.74 > and more importantly example 1 under the following link > http://dlmf.nist.gov/3.6#v These algorithms are going to be subject to the same problems as using Taylor's series to evaluate exp(x) for x>0. The computation will require several floating point operations. Even if the method is not unstable, I would think getting a ULP of about 1 is next to impossible, that is, unless one performs all the computations in a higher precision, and then rounds at the end. Whereas as a scientist, having a bessel function computed to within 10 ULP would be just fine. I am looking at the man page of j0 for FreeBSD-8.3. It says in conforms to IEEE Std 1003.1-2001. Does that specify a certain ULP? I am searching around in this document, and I am finding nothing. Whereas the IEEE-754 document seems rather rigid, but on the other hand it doesn't specifically talk about math functions other than sqrt. From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 18:33:21 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70C3E106564A; Tue, 10 Jul 2012 18:33:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4260A8FC12; Tue, 10 Jul 2012 18:33:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6AIXKwq011895; Tue, 10 Jul 2012 14:33:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AIXKNa011894; Tue, 10 Jul 2012 18:33:20 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 18:33:20 GMT Message-Id: <201207101833.q6AIXKNa011894@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:33:21 -0000 TB --- 2012-07-10 15:49:04 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 15:49:04 - 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 --- 2012-07-10 15:49:04 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-10 15:49:04 - cleaning the object tree TB --- 2012-07-10 15:50:50 - cvsupping the source tree TB --- 2012-07-10 15:50:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-10 15:51:15 - building world TB --- 2012-07-10 15:51:15 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 15:51:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 15:51:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 15:51:15 - SRCCONF=/dev/null TB --- 2012-07-10 15:51:15 - TARGET=powerpc TB --- 2012-07-10 15:51:15 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 15:51:15 - TZ=UTC TB --- 2012-07-10 15:51:15 - __MAKE_CONF=/dev/null TB --- 2012-07-10 15:51:15 - cd /src TB --- 2012-07-10 15:51:15 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 15:51:16 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 10 18:29:54 UTC 2012 TB --- 2012-07-10 18:29:54 - generating LINT kernel config TB --- 2012-07-10 18:29:54 - cd /src/sys/powerpc/conf TB --- 2012-07-10 18:29:54 - /usr/bin/make -B LINT TB --- 2012-07-10 18:29:54 - cd /src/sys/powerpc/conf TB --- 2012-07-10 18:29:54 - /usr/sbin/config -m LINT TB --- 2012-07-10 18:29:54 - building LINT kernel TB --- 2012-07-10 18:29:54 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 18:29:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 18:29:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 18:29:54 - SRCCONF=/dev/null TB --- 2012-07-10 18:29:54 - TARGET=powerpc TB --- 2012-07-10 18:29:54 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 18:29:54 - TZ=UTC TB --- 2012-07-10 18:29:54 - __MAKE_CONF=/dev/null TB --- 2012-07-10 18:29:54 - cd /src TB --- 2012-07-10 18:29:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 18:29:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 18:33:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 18:33:20 - ERROR: failed to build LINT kernel TB --- 2012-07-10 18:33:20 - 8204.10 user 1121.45 system 9856.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 19:27:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB84D1065674 for ; Tue, 10 Jul 2012 19:27:28 +0000 (UTC) (envelope-from root@9du.org) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A802C8FC12 for ; Tue, 10 Jul 2012 19:27:28 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so833253pbb.13 for ; Tue, 10 Jul 2012 12:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type :x-gm-message-state; bh=yKewxY4NHZWCUKbgnSO0/BlSpq5qCeuy8IHnZ3tp4G0=; b=l3zERvTiArZKRNARNKKy++3NDLpm1qjMbMdGMZLa7J1pqe1dveYjqjux5V2Y9gNYgK g7GDCYbU4R4J6OrhYxMBr/AbnJb9K75LBwPWbsjguYq/My24+QG+u25Quldv8Y5yZ//3 A1KlgAMLwVpE7wOWNpzHO41OVE02g8704AVK8Rb2syNbTy8AcQ/EaOKnKZLT3rQB3IZg D5r3YC+sRAVZ8Mz62kkWh7UmVJUo21PjNmJMzigRKJOnHAYjr1wkJ1LFBCa4ZjeZPfW6 iWwyd8mVGnmFpvAG4Uk651E5hErcwqAmG4VGkFkYpkb9Btk92deTc9wDjUHeRJA4pSaz JY7A== Received: by 10.68.227.197 with SMTP id sc5mr72427410pbc.58.1341948447970; Tue, 10 Jul 2012 12:27:27 -0700 (PDT) Received: from YONG-BJHOME ([111.194.130.160]) by mx.google.com with ESMTPS id tj4sm100860pbc.33.2012.07.10.12.27.24 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 12:27:26 -0700 (PDT) Date: Wed, 11 Jul 2012 03:27:18 +0800 From: "root@9du.org" To: freebsd-current References: <20120710154057.BC83D1065708@hub.freebsd.org> X-Priority: 3 X-GUID: FCF936DE-45EA-42F1-B45A-FC6E4D28D00D X-Has-Attach: no X-Mailer: Foxmail 7.0.1.90[cn] Mime-Version: 1.0 Message-ID: <201207110327153069626@9du.org> X-Gm-Message-State: ALoCoQl+tSWnkvDPcMyLEOLcQI9X/4233024G29g6rPdEd785Tj2HByQWnxshFGdLu6HF0WWIlMn Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rizzo Subject: about netmap NETMAP_HW_RING with poll. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: root List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:27:28 -0000 aSBoYXZlIGEgdGVzdCB1c2UgcGt0LWdlbi5jIA0KIyBzdGFydCBwdGhyZWFkID4gMSANCm5ldG1h cCBhcyByZWNlaXZlciB3b3JrIG9uIE5FVE1BUF9IV19SSU5HICBtb2RlLg0KDQppZiBpIHN0b3Ag cmVjdiBwYWNrZXQuIHN5c3RlbSBkbWVzZyB3aWxsIHNob3cgDQppbnRlcnJ1cHQgc3Rvcm0gZGV0 ZWN0ZWQgb24gImlycTI4MToiOyB0aHJvdHRsaW5nIGludGVycnVwdCBzb3VyY2UNCmludGVycnVw dCBzdG9ybSBkZXRlY3RlZCBvbiAiaXJxMjgxOiI7IHRocm90dGxpbmcgaW50ZXJydXB0IHNvdXJj ZQ0KaW50ZXJydXB0IHN0b3JtIGRldGVjdGVkIG9uICJpcnEyODE6IjsgdGhyb3R0bGluZyBpbnRl cnJ1cHQgc291cmNlDQppbnRlcnJ1cHQgc3Rvcm0gZGV0ZWN0ZWQgb24gImlycTI4MToiOyB0aHJv dHRsaW5nIGludGVycnVwdCBzb3VyY2UNCmludGVycnVwdCBzdG9ybSBkZXRlY3RlZCBvbiAiaXJx MjgxOiI7IHRocm90dGxpbmcgaW50ZXJydXB0IHNvdXJjZQ0KLi4uLi4uDQoNCmkgdGhpbmsgdGhp cyBlcnJvciBtYXkgYmUgd2l0aCBwb2xsIG9yIDgyNTk5IGRldmljZT8NCg0KaWYgaSBub3QgdXNl IE5FVE1BUF9OV19SSU5HIHdpbGwgYmUgb2sh From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 19:53:54 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30B31065674; Tue, 10 Jul 2012 19:53:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A1B328FC0C; Tue, 10 Jul 2012 19:53:54 +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 q6AJrrug001597; Tue, 10 Jul 2012 15:53:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AJrrrc001596; Tue, 10 Jul 2012 19:53:53 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 19:53:53 GMT Message-Id: <201207101953.q6AJrrrc001596@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:53:55 -0000 TB --- 2012-07-10 18:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 18:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 18:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-10 18:40:01 - cleaning the object tree TB --- 2012-07-10 18:44:32 - cvsupping the source tree TB --- 2012-07-10 18:44:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-10 18:45:58 - building world TB --- 2012-07-10 18:45:58 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 18:45:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 18:45:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 18:45:58 - SRCCONF=/dev/null TB --- 2012-07-10 18:45:58 - TARGET=arm TB --- 2012-07-10 18:45:58 - TARGET_ARCH=arm TB --- 2012-07-10 18:45:58 - TZ=UTC TB --- 2012-07-10 18:45:58 - __MAKE_CONF=/dev/null TB --- 2012-07-10 18:45:58 - cd /src TB --- 2012-07-10 18:45:58 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 18:45:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 19:49:40 UTC 2012 TB --- 2012-07-10 19:49:40 - cd /src/sys/arm/conf TB --- 2012-07-10 19:49:40 - /usr/sbin/config -m ATMEL TB --- 2012-07-10 19:49:40 - building ATMEL kernel TB --- 2012-07-10 19:49:40 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 19:49:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 19:49:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 19:49:40 - SRCCONF=/dev/null TB --- 2012-07-10 19:49:40 - TARGET=arm TB --- 2012-07-10 19:49:40 - TARGET_ARCH=arm TB --- 2012-07-10 19:49:40 - TZ=UTC TB --- 2012-07-10 19:49:40 - __MAKE_CONF=/dev/null TB --- 2012-07-10 19:49:40 - cd /src TB --- 2012-07-10 19:49:40 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Jul 10 19:49:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Jul 10 19:53:13 UTC 2012 TB --- 2012-07-10 19:53:13 - cd /src/sys/arm/conf TB --- 2012-07-10 19:53:13 - /usr/sbin/config -m AVILA TB --- 2012-07-10 19:53:13 - building AVILA kernel TB --- 2012-07-10 19:53:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 19:53:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 19:53:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 19:53:13 - SRCCONF=/dev/null TB --- 2012-07-10 19:53:13 - TARGET=arm TB --- 2012-07-10 19:53:13 - TARGET_ARCH=arm TB --- 2012-07-10 19:53:13 - TZ=UTC TB --- 2012-07-10 19:53:13 - __MAKE_CONF=/dev/null TB --- 2012-07-10 19:53:13 - cd /src TB --- 2012-07-10 19:53:13 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue Jul 10 19:53:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_reinit_fifo': /src/sys/dev/ath/if_ath_rx_edma.c:193: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'bus_addr_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 19:53:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 19:53:53 - ERROR: failed to build AVILA kernel TB --- 2012-07-10 19:53:53 - 2642.90 user 595.48 system 4432.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 20:53:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8FF106566B for ; Tue, 10 Jul 2012 20:53:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 51CD48FC0C for ; Tue, 10 Jul 2012 20:53:12 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6AKrAEL095975; Tue, 10 Jul 2012 13:53:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6AKrAPv095974; Tue, 10 Jul 2012 13:53:10 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2012 13:53:10 -0700 From: Steve Kargl To: Stephen Montgomery-Smith Message-ID: <20120710205310.GA95746@troutmask.apl.washington.edu> References: <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <4FF9DA46.2010502@missouri.edu> <20120708235848.GB53462@troutmask.apl.washington.edu> <4FFA25EA.5090705@missouri.edu> <20120709020107.GA53977@troutmask.apl.washington.edu> <4FFA52F8.2080700@missouri.edu> <20120709050238.GA54634@troutmask.apl.washington.edu> <4FFC5ADF.2010601@missouri.edu> <20120710165045.GA94795@troutmask.apl.washington.edu> <4FFC705A.6070403@missouri.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFC705A.6070403@missouri.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 20:53:12 -0000 On Tue, Jul 10, 2012 at 01:11:38PM -0500, Stephen Montgomery-Smith wrote: > On 07/10/2012 11:50 AM, Steve Kargl wrote: > >On Tue, Jul 10, 2012 at 11:39:59AM -0500, Stephen Montgomery-Smith wrote: > >>On 07/09/2012 12:02 AM, Steve Kargl wrote: > >> > >>>Yep. Another example is the use of upward recurion to compute > >>>Bessel functions where the argument is larger than the order. > >>>The algorithm is known to be unstable. > >> > >>By upward recursion, do you mean equation (1) in > >>http://mathworld.wolfram.com/BesselFunction.html? > > > >Yes. > > > >>So what do people use. Maybe something like > >>http://en.wikipedia.org/wiki/Bessel_function#Asymptotic_forms (second > >>set of equations), but finding some asymptotics with a few extra terms > >>in them? > > > >They use downward recursion, which is known to be stable. > >NIST has revised Abramowitz and Stegun, and it is available > >on line. For Bessel function computations, look at > >http://dlmf.nist.gov/10.74 > >and more importantly example 1 under the following link > >http://dlmf.nist.gov/3.6#v > > These algorithms are going to be subject to the same problems as using > Taylor's series to evaluate exp(x) for x>0. The computation will > require several floating point operations. Even if the method is not > unstable, I would think getting a ULP of about 1 is next to impossible, > that is, unless one performs all the computations in a higher precision, > and then rounds at the end. Downward recurion is used for n > 1. j0(x) and j1(x) are computed using two different schemes. If x <= 2, then the ascending series can be summed (this only takes somewhere around 10 terms for double). Alternately, one can use a minimax polynomial for x in [0:2]. For x > 2, the Hankel expansions are used (see 10.17.3 at http://dlmf.nist.gov/10.17). The summations are approximated by minimax polynomials. See msun/src/s_j0.c. I've tested j0f() and know that one can get less than 1 ULP over various ranges of x. I also know that when is close to a zero of j0(x), then one has ULP on the order of 1000000. > Whereas as a scientist, having a bessel function computed to within 10 > ULP would be just fine. As someone who has spent a portion of career computing Bessel functions, I am disinclined to agree with your statement. > I am looking at the man page of j0 for FreeBSD-8.3. It says in conforms > to IEEE Std 1003.1-2001. Does that specify a certain ULP? I doubt that it would specify ULP for any function other than perhaps sqrt(). I don't have IEEE Std 1003.1-2001 handy, but I would guess that it simply statements the math funtion return an floating point approximation to its true value. > I am > searching around in this document, and I am finding nothing. Whereas > the IEEE-754 document seems rather rigid, but on the other hand it > doesn't specifically talk about math functions other than sqrt. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:30:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED36D1065674; Tue, 10 Jul 2012 21:30:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BBC698FC12; Tue, 10 Jul 2012 21:30: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 q6ALUFMh023573; Tue, 10 Jul 2012 17:30:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ALUF9s023560; Tue, 10 Jul 2012 21:30:15 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 21:30:15 GMT Message-Id: <201207102130.q6ALUF9s023560@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:30:17 -0000 TB --- 2012-07-10 18:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 18:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 18:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-10 18:40:01 - cleaning the object tree TB --- 2012-07-10 18:46:18 - cvsupping the source tree TB --- 2012-07-10 18:46:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-10 18:48:32 - building world TB --- 2012-07-10 18:48:32 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 18:48:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 18:48:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 18:48:32 - SRCCONF=/dev/null TB --- 2012-07-10 18:48:32 - TARGET=pc98 TB --- 2012-07-10 18:48:32 - TARGET_ARCH=i386 TB --- 2012-07-10 18:48:32 - TZ=UTC TB --- 2012-07-10 18:48:32 - __MAKE_CONF=/dev/null TB --- 2012-07-10 18:48:32 - cd /src TB --- 2012-07-10 18:48:32 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 18:48:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 21:22:31 UTC 2012 TB --- 2012-07-10 21:22:31 - generating LINT kernel config TB --- 2012-07-10 21:22:31 - cd /src/sys/pc98/conf TB --- 2012-07-10 21:22:31 - /usr/bin/make -B LINT TB --- 2012-07-10 21:22:31 - cd /src/sys/pc98/conf TB --- 2012-07-10 21:22:31 - /usr/sbin/config -m LINT TB --- 2012-07-10 21:22:31 - building LINT kernel TB --- 2012-07-10 21:22:31 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 21:22:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 21:22:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 21:22:31 - SRCCONF=/dev/null TB --- 2012-07-10 21:22:31 - TARGET=pc98 TB --- 2012-07-10 21:22:31 - TARGET_ARCH=i386 TB --- 2012-07-10 21:22:31 - TZ=UTC TB --- 2012-07-10 21:22:31 - __MAKE_CONF=/dev/null TB --- 2012-07-10 21:22:31 - cd /src TB --- 2012-07-10 21:22:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 21:22:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 21:30:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 21:30:15 - ERROR: failed to build LINT kernel TB --- 2012-07-10 21:30:15 - 6693.68 user 957.38 system 10214.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:30:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE1C81065690; Tue, 10 Jul 2012 21:30:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A522F8FC12; Tue, 10 Jul 2012 21:30:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6ALUt6X026709; Tue, 10 Jul 2012 17:30:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ALUtN7026708; Tue, 10 Jul 2012 21:30:55 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 21:30:55 GMT Message-Id: <201207102130.q6ALUtN7026708@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:30:56 -0000 TB --- 2012-07-10 18:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 18:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 18:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-10 18:40:01 - cleaning the object tree TB --- 2012-07-10 18:46:34 - cvsupping the source tree TB --- 2012-07-10 18:46:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-10 18:48:54 - building world TB --- 2012-07-10 18:48:54 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 18:48:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 18:48:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 18:48:54 - SRCCONF=/dev/null TB --- 2012-07-10 18:48:54 - TARGET=i386 TB --- 2012-07-10 18:48:54 - TARGET_ARCH=i386 TB --- 2012-07-10 18:48:54 - TZ=UTC TB --- 2012-07-10 18:48:54 - __MAKE_CONF=/dev/null TB --- 2012-07-10 18:48:54 - cd /src TB --- 2012-07-10 18:48:54 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 18:48:55 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 21:21:45 UTC 2012 TB --- 2012-07-10 21:21:45 - generating LINT kernel config TB --- 2012-07-10 21:21:45 - cd /src/sys/i386/conf TB --- 2012-07-10 21:21:45 - /usr/bin/make -B LINT TB --- 2012-07-10 21:21:46 - cd /src/sys/i386/conf TB --- 2012-07-10 21:21:46 - /usr/sbin/config -m LINT TB --- 2012-07-10 21:21:46 - building LINT kernel TB --- 2012-07-10 21:21:46 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 21:21:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 21:21:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 21:21:46 - SRCCONF=/dev/null TB --- 2012-07-10 21:21:46 - TARGET=i386 TB --- 2012-07-10 21:21:46 - TARGET_ARCH=i386 TB --- 2012-07-10 21:21:46 - TZ=UTC TB --- 2012-07-10 21:21:46 - __MAKE_CONF=/dev/null TB --- 2012-07-10 21:21:46 - cd /src TB --- 2012-07-10 21:21:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 21:21:46 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 21:30:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 21:30:55 - ERROR: failed to build LINT kernel TB --- 2012-07-10 21:30:55 - 6786.34 user 970.41 system 10254.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 21:42:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F833106566C; Tue, 10 Jul 2012 21:42:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F339B8FC14; Tue, 10 Jul 2012 21:42:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6ALgUBl008628; Tue, 10 Jul 2012 17:42:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ALgUSN008618; Tue, 10 Jul 2012 21:42:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 21:42:30 GMT Message-Id: <201207102142.q6ALgUSN008618@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 21:42:31 -0000 TB --- 2012-07-10 19:53:54 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 19:53:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 19:53:54 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-10 19:53:54 - cleaning the object tree TB --- 2012-07-10 19:54:46 - cvsupping the source tree TB --- 2012-07-10 19:54:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-10 19:55:16 - building world TB --- 2012-07-10 19:55:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 19:55:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 19:55:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 19:55:16 - SRCCONF=/dev/null TB --- 2012-07-10 19:55:16 - TARGET=ia64 TB --- 2012-07-10 19:55:16 - TARGET_ARCH=ia64 TB --- 2012-07-10 19:55:16 - TZ=UTC TB --- 2012-07-10 19:55:16 - __MAKE_CONF=/dev/null TB --- 2012-07-10 19:55:16 - cd /src TB --- 2012-07-10 19:55:16 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 19:55:17 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 21:36:17 UTC 2012 TB --- 2012-07-10 21:36:17 - generating LINT kernel config TB --- 2012-07-10 21:36:17 - cd /src/sys/ia64/conf TB --- 2012-07-10 21:36:17 - /usr/bin/make -B LINT TB --- 2012-07-10 21:36:17 - cd /src/sys/ia64/conf TB --- 2012-07-10 21:36:17 - /usr/sbin/config -m LINT TB --- 2012-07-10 21:36:17 - building LINT kernel TB --- 2012-07-10 21:36:17 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 21:36:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 21:36:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 21:36:17 - SRCCONF=/dev/null TB --- 2012-07-10 21:36:17 - TARGET=ia64 TB --- 2012-07-10 21:36:17 - TARGET_ARCH=ia64 TB --- 2012-07-10 21:36:17 - TZ=UTC TB --- 2012-07-10 21:36:17 - __MAKE_CONF=/dev/null TB --- 2012-07-10 21:36:17 - cd /src TB --- 2012-07-10 21:36:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 21:36:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 21:42:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 21:42:30 - ERROR: failed to build LINT kernel TB --- 2012-07-10 21:42:30 - 4499.45 user 694.83 system 6516.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:06:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD432106564A; Tue, 10 Jul 2012 22:06:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9E27B8FC08; Tue, 10 Jul 2012 22:06:51 +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 q6AM6peU016515; Tue, 10 Jul 2012 18:06:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AM6pKU016508; Tue, 10 Jul 2012 22:06:51 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 22:06:51 GMT Message-Id: <201207102206.q6AM6pKU016508@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 22:06:51 -0000 TB --- 2012-07-10 18:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 18:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 18:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-10 18:40:01 - cleaning the object tree TB --- 2012-07-10 18:49:28 - cvsupping the source tree TB --- 2012-07-10 18:49:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-10 18:50:16 - building world TB --- 2012-07-10 18:50:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 18:50:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 18:50:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 18:50:16 - SRCCONF=/dev/null TB --- 2012-07-10 18:50:16 - TARGET=amd64 TB --- 2012-07-10 18:50:16 - TARGET_ARCH=amd64 TB --- 2012-07-10 18:50:16 - TZ=UTC TB --- 2012-07-10 18:50:16 - __MAKE_CONF=/dev/null TB --- 2012-07-10 18:50:16 - cd /src TB --- 2012-07-10 18:50:16 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 18:50:17 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jul 10 21:58:45 UTC 2012 TB --- 2012-07-10 21:58:45 - generating LINT kernel config TB --- 2012-07-10 21:58:45 - cd /src/sys/amd64/conf TB --- 2012-07-10 21:58:45 - /usr/bin/make -B LINT TB --- 2012-07-10 21:58:45 - cd /src/sys/amd64/conf TB --- 2012-07-10 21:58:45 - /usr/sbin/config -m LINT TB --- 2012-07-10 21:58:45 - building LINT kernel TB --- 2012-07-10 21:58:45 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 21:58:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 21:58:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 21:58:45 - SRCCONF=/dev/null TB --- 2012-07-10 21:58:45 - TARGET=amd64 TB --- 2012-07-10 21:58:45 - TARGET_ARCH=amd64 TB --- 2012-07-10 21:58:45 - TZ=UTC TB --- 2012-07-10 21:58:45 - __MAKE_CONF=/dev/null TB --- 2012-07-10 21:58:45 - cd /src TB --- 2012-07-10 21:58:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 21:58:45 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 22:06:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 22:06:50 - ERROR: failed to build LINT kernel TB --- 2012-07-10 22:06:50 - 8170.57 user 1281.63 system 12409.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:08:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A42291065675 for ; Tue, 10 Jul 2012 22:08:52 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 513568FC0A for ; Tue, 10 Jul 2012 22:08:52 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Soibz-00068k-Cb; Tue, 10 Jul 2012 23:08:51 +0100 Received: from cpc1-aztw9-0-0-cust540.18-1.cable.virginmedia.com ([82.33.90.29] helo=mech-aslap239.men.bris.ac.uk) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Soiby-0004iq-Ty; Tue, 10 Jul 2012 23:08:51 +0100 Received: from mech-aslap239.men.bris.ac.uk (localhost [127.0.0.1]) by mech-aslap239.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6AM8olg001243; Tue, 10 Jul 2012 23:08:50 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-aslap239.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q6ALfc20001041; Tue, 10 Jul 2012 22:41:38 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-aslap239.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Tue, 10 Jul 2012 22:41:38 +0100 From: Anton Shterenlikht To: Garrett Cooper Message-ID: <20120710214138.GA1025@mech-aslap239.men.bris.ac.uk> Mail-Followup-To: Garrett Cooper , Steve Kargl , freebsd-current@freebsd.org References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> <20120709233857.GA12046@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.4.2.3i Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 22:08:52 -0000 On Mon, Jul 09, 2012 at 05:14:01PM -0700, Garrett Cooper wrote: > On Mon, Jul 9, 2012 at 4:38 PM, Steve Kargl > wrote: > > On Mon, Jul 09, 2012 at 11:52:10PM +0100, Anton Shterenlikht wrote: > >> I'm on amd64 r238259. > >> > >> I'm still not clear on the /usr/src/UPDATING > >> entry from 20110424 on replacing the ATA > >> drivers by CAM drivers. > >> > >> If I *do not* have device ata in the kernel, > >> I have neither /dev/cd* or /dev/acd*, > >> even though I have in the kernel: > >> > >> options ATA_CAM # Handle legacy controllers with CAM > >> options ATA_STATIC_ID # Static device numbering > >> device ada > >> device cd # CD > >> > > > > man 4 cam > > > > I suspect that you are missing 'device scbus' in > > your config file. > > device scbus # SCSI bus (required for ATA/SCSI) > > Probably. And as the fine print says... > > Note that to use CAM-based ATA kernel should include CAM devices > scbus, pass, da (or explicitly ada), cd and optionally others. I do have all this in the kernel, see below. Still if I don't have device ata, I get no cd: # ls /dev acpi console kbd0 stdin ttyve ad4 consolectl klog stdout ttyvf ad4s1 ctty kmem sysmouse ugen0.1 ad4s1a devctl log ttyv0 ugen0.2 ad4s1b devstat mdctl ttyv1 ugen1.1 ada0 dumpdev mem ttyv2 ugen2.1 ada0s1 fd midistat ttyv3 ugen3.1 ada0s1a fido mixer0 ttyv4 ugen4.1 ada0s1b geom.ctl null ttyv5 ugen5.1 apm io pass0 ttyv6 urandom apmctl ipauth pccard0.cis ttyv7 usb atkbd0 ipl pci ttyv8 usbctl audit iplookup psm0 ttyv9 xpt0 bpf ipnat ptmx ttyva zero bpf0 ipscan random ttyvb bpsm0 ipstate sndstat ttyvc cam ipsync stderr ttyvd # Here's the kernel config file: cpu HAMMER ident BUZI makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions MODULES_OVERRIDE= options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering options AUDIT # Security event auditing options CAPABILITIES # Capsicum capabilities options CAPABILITY_MODE # Capsicum capability mode options CD9660 # ISO 9660 Filesystem options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options COMPAT_LINUX32 options DDB # Support DDB. options DEADLKRES # Enable the deadlock resolver options FFS # Berkeley Fast Filesystem options GDB # Support remote GDB. options GEOM_LABEL # Provides labelization options GEOM_PART_GPT # GUID Partition Tables. options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's options IEEE80211_DEBUG # enable debug msgs options IEEE80211_SUPPORT_MESH # enable 802.11s draft support options INCLUDE_CONFIG_FILE # Include this file in kernel options INET # InterNETworking options INET6 # IPv6 communications protocols options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options IPFILTER options IPFILTER_DEFAULT_BLOCK options IPFILTER_LOG options KBD_INSTALL_CDEV # install a CDEV entry in /dev options KDB # Enable kernel debugger support. Always need this #options KDB_TRACE # Print a stack trace for a panic. #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks options KTRACE # ktrace(1) support options MAC # TrustedBSD MAC Framework options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options PREEMPTION # Enable kernel thread preemption options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options SC_PIXEL_MODE # add support for the raster text mode options SCHED_ULE # ULE scheduler options SCTP # Stream Control Transmission Protocol options SMP # Symmetric MultiProcessor Kernel options SOFTUPDATES # Enable FFS soft updates support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options USB_DEBUG # enable debug msgs options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions device acpi device ada device ahci # AHCI-compatible SATA controllers #device ata # Legacy ATA/SATA controllers device atkbd # AT keyboard device atkbdc # AT keyboard controller device bge # Broadcom BCM570xx Gigabit Ethernet device bpf # Berkeley packet filter device bwn # Broadcom BCM43xx wireless NICs. device cardbus # CardBus (32-bit) bus device cbb # cardbus (yenta) bridge device cd # CD device cpufreq device ctl # CAM Target Layer device da # Direct Access (disks) device ehci # EHCI PCI->USB interface (USB 2.0) device ether # Ethernet support device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module device gif # IPv6 and IPv4 tunneling device loop # Network loopback device md # Memory "disks" device miibus # MII bus support device ohci # OHCI PCI->USB interface device pass # Passthrough device (direct ATA/SCSI access) device pccard # PC Card (16-bit) bus device pci device psm # PS/2 mouse device pty # BSD-style compatibility pseudo ttys device random # Entropy device device sc # syscons is the default console driver, resembling an SCO console device scbus # SCSI bus (required for ATA/SCSI) device siba_bwn # required by bwn(4) device sound # Generic sound driver (required) device snd_hda # Intel High Definition Audio device tun # Packet tunnel. device uhci # UHCI PCI->USB interface device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device usb # USB Bus (required) device vga # VGA video card driver device vlan # 802.1Q VLAN support device wlan # 802.11 support device wlan_amrr # AMRR transmit rate control algorithm device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_wep # 802.11 WEP support device xhci # XHCI PCI->USB interface (USB 3.0) I must be missing something else. Many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:35:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5FA106564A for ; Tue, 10 Jul 2012 22:35:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 08FF08FC15 for ; Tue, 10 Jul 2012 22:35:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6AMZV0l096870; Tue, 10 Jul 2012 15:35:31 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6AMZVEI096869; Tue, 10 Jul 2012 15:35:31 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2012 15:35:31 -0700 From: Steve Kargl To: Garrett Cooper , freebsd-current@freebsd.org Message-ID: <20120710223531.GA96724@troutmask.apl.washington.edu> References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> <20120709233857.GA12046@troutmask.apl.washington.edu> <20120710214138.GA1025@mech-aslap239.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120710214138.GA1025@mech-aslap239.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 22:35:32 -0000 On Tue, Jul 10, 2012 at 10:41:38PM +0100, Anton Shterenlikht wrote: > On Mon, Jul 09, 2012 at 05:14:01PM -0700, Garrett Cooper wrote: > > On Mon, Jul 9, 2012 at 4:38 PM, Steve Kargl > > wrote: > > > On Mon, Jul 09, 2012 at 11:52:10PM +0100, Anton Shterenlikht wrote: > > >> I'm on amd64 r238259. > > >> > > >> I'm still not clear on the /usr/src/UPDATING > > >> entry from 20110424 on replacing the ATA > > >> drivers by CAM drivers. > > >> > > >> If I *do not* have device ata in the kernel, > > >> I have neither /dev/cd* or /dev/acd*, > > >> even though I have in the kernel: > > >> > > >> options ATA_CAM # Handle legacy controllers with CAM > > >> options ATA_STATIC_ID # Static device numbering > > >> device ada > > >> device cd # CD > > >> > > > > > > man 4 cam > > > > > > I suspect that you are missing 'device scbus' in > > > your config file. > > > > device scbus # SCSI bus (required for ATA/SCSI) > > > > Probably. And as the fine print says... > > > > Note that to use CAM-based ATA kernel should include CAM devices > > scbus, pass, da (or explicitly ada), cd and optionally others. > > I do have all this in the kernel, see below. > Still if I don't have device ata, I get no cd: > Well, then, leave 'device ata' in your config file. Groucho: Doctor, it hurts when I do this. yada yada -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 22:58:04 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FD3E106564A for ; Tue, 10 Jul 2012 22:58:04 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6CAB98FC0C for ; Tue, 10 Jul 2012 22:58:04 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q6AMw2HI059012; Tue, 10 Jul 2012 18:58:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q6AMw1nG059011; Tue, 10 Jul 2012 18:58:01 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 10 Jul 2012 18:58:01 -0400 From: David Schultz To: Rainer Hurling Message-ID: <20120710225801.GB58778@zim.MIT.EDU> Mail-Followup-To: Rainer Hurling , Warner Losh , Steve Kargl , Peter Jeremy , freebsd-current@FreeBSD.ORG References: <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFC5E5D.8000502@gwdg.de> Cc: freebsd-current@FreeBSD.ORG, Peter Jeremy , Steve Kargl , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 22:58:04 -0000 On Tue, Jul 10, 2012, Rainer Hurling wrote: > On 10.07.2012 17:11 (UTC+2), David Schultz wrote: > >On Tue, Jul 10, 2012, Rainer Hurling wrote: > >>On 10.07.2012 16:02 (UTC+2), Warner Losh wrote: > >>> > >>>On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > >>>>As far as I understand from discussions on R mailing list > >>>>(r-devel@r-project.org), they plan to reduce the emulation and/or > >>>>workaround of long and complex math functions for FreeBSD and other > >>>>systems with their next releases of R devel. So we could really need > >>>>some > >>>>progress with our C99 conform math functions ;-) > >>> > >>>Not having R would be a bit pain in my backside. That's one of the > >>>practical considerations that I was talking about. It is very real, and > >>>if I have to, I'll commit the #define junk I railed against to get it > >>>back. Please, let's get some progress. I have some time to help. > >> > >>Yes, thank you Warner, that is also my problem. As I wrote some weeks > >>ago (05/28/2012) when starting this thread, I am using FreeBSD as a > >>scientific desktop because of its good scaling properties. For some > >>years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and > >>some more. > >> > >>If I would not be able to run upcoming versions of R on FreeBSD any > >>more, that would be really, really hard :-( > > > >Do you have a list of the essential functions here? There are 17 long > >double functions and some complex functions missing, but only a > >handful of those are of general interest. The reason I ask is that if > >R is just looking for a few missing functions that are already mostly > >implemented, then the best solution is probably to finish that work. > >But if it's expecting us to have something arcane like long double > >Bessel functions of the first kind, then we need to pursue a workaround > >in the short term. > > > > That is, what I found by grepping the sources of a recent R development > version: > > expl: src/nmath/pnchisq.c > > logl: src/nmath/dnbeta.c > src/nmath/pnbeta.c Bruce has versions of these that could be committed with some cleanup. It's a matter of sorting through about 1200 emails from him and 3 source trees to find the most up-to-date patches, then cleaning them up and testing and committing them. I have no time right now, but I will do at least the first step as soon as I can, and try to get the patches to someone willing to do the final few steps. > log10l: src/extra/trio/trio.c > > log1pl: src/nmath/pnbeta.c If Bruce doesn't already have implementations of these, they are easy wrappers around logl() or some internal k_logl in Bruce's implementation. > powl: src/extra/trio/triostr.c > src/extra/trio/trio.c > src/main/format.c It's hard to do a good job on powl(), but the simple approach (exp(log(x)*y)) plus a few special cases may suffice for many uses. > NEWS:l2044 > The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are > now required. We have had them forever. > NEWS:l3032 > The C99 double complex type is now required. > The C99 complex trigonometric functions (such as csin) are not > currently required (FreeBSD lacks most of them): substitutes are > used if they are missing. We have these (but not the inverse trig functions). > NEWS:l3277 > Complex arithmetic (notably z^n for complex z and integer n) gave > incorrect results since R 2.10.0 on platforms without C99 complex > support. This and some lesser issues in trigonometric functions > have been corrected. > Such platforms were rare (we know of Cygwin and FreeBSD). > However, because of new compiler optimizations in the way complex > arguments are handled, the same code was selected on x86_64 Linux > with gcc 4.5.x at the default -O2 optimization (but not at -O). Not sure if this is relevant. > BTW: There seems to be a discrepancy about missing functions listed in > http://wiki.freebsd.org/MissingMathStuff and in > http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=227472&r2=236148&pathrev=236148. > So the wiki is a bit outdated now? My list: REAL FUNCTIONS (17): long double log2l(long double); long double logl(long double); long double log1pl(long double); long double acoshl(long double); long double asinhl(long double); long double atanhl(long double); long double log10l(long double); long double expl(long double); long double expm1l(long double); long double coshl(long double); long double sinhl(long double); long double tanhl(long double); long double erfcl(long double); long double erfl(long double); long double powl(long double, long double); long double lgammal(long double); long double tgammal(long double); COMPLEX FUNCTIONS (37): long double complex cexpl(long double complex); long double complex ccosl(long double complex); long double complex ccoshl(long double complex); long double complex csinl(long double complex); long double complex csinhl(long double complex); long double complex ctanl(long double complex); long double complex ctanhl(long double complex); float complex cacosf(float complex); float complex cacoshf(float complex); double complex cacos(double complex); double complex cacosh(double complex); long double complex cacosl(long double complex); long double complex cacoshl(long double complex); float complex casinf(float complex); float complex casinhf(float complex); double complex casin(double complex); double complex casinh(double complex); long double complex casinl(long double complex); long double complex casinhl(long double complex); float complex catanf(float complex); float complex catanhf(float complex); double complex catan(double complex); double complex catanh(double complex); long double complex catanl(long double complex); long double complex catanhl(long double complex); float complex clogf(float complex); double complex clog(double complex); long double complex clogl(long double complex); float complex cpowf(float complex, float complex); double complex cpow(double complex, double complex); long double complex cpowl(long double complex, long double complex); From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 23:00:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FFD4106564A; Tue, 10 Jul 2012 23:00:55 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45C9A8FC14; Tue, 10 Jul 2012 23:00:55 +0000 (UTC) Received: by obbun3 with SMTP id un3so751466obb.13 for ; Tue, 10 Jul 2012 16:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hs4je/W09wF0YGZ27rHwqJzjM2dw4dI1K0sVIMg4S5A=; b=M0fAEzcVgTlpR12dmdNXVE7T/xSMrcHRmeEtY2oVVipM6LrJtcScBW1ByT3gUJVSK/ jGVaVETLBke2LlmeamIck+bvcIjeEJaaky5gjbgeq7WVctFs/DkoDvEoNvo8ngMfAr9Z Rf8XCtAV8Bf+bxlIdY1ve6wlN4cz2YC9o6TQ1OMGsH3Hlsdusu4eWpOJVikMBJu04JY/ o0o6lTAHsirrQZGA9S71XbyHNS+70fj8x5KnQMtgc4V/8Oiwv7NXAnkVDqgfZ0R7A7bO jE1mIoSGYkSPeZJ0XsKToebF9YFcEF555FuYj3icJymbQKTk+B1FeINohNlYI/2kAVDR KhDw== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr8177141oba.39.1341961254737; Tue, 10 Jul 2012 16:00:54 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 16:00:54 -0700 (PDT) In-Reply-To: <20120710223531.GA96724@troutmask.apl.washington.edu> References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> <20120709233857.GA12046@troutmask.apl.washington.edu> <20120710214138.GA1025@mech-aslap239.men.bris.ac.uk> <20120710223531.GA96724@troutmask.apl.washington.edu> Date: Tue, 10 Jul 2012 16:00:54 -0700 Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 10 Jul 2012 23:00:55 -0000 On Tue, Jul 10, 2012 at 3:35 PM, Steve Kargl wrote: > On Tue, Jul 10, 2012 at 10:41:38PM +0100, Anton Shterenlikht wrote: ... >> I do have all this in the kernel, see below. >> Still if I don't have device ata, I get no cd: >> > > Well, then, leave 'device ata' in your config file. > > Groucho: Doctor, it hurts when I do this. > yada yada The UPDATING directions don't say this is required, so mav@ might want to know (CCed). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 23:24:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8849106564A; Tue, 10 Jul 2012 23:24:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A4B468FC14; Tue, 10 Jul 2012 23:24: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 q6ANO6Aj002952; Tue, 10 Jul 2012 19:24:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ANO6ov002949; Tue, 10 Jul 2012 23:24:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 23:24:06 GMT Message-Id: <201207102324.q6ANO6ov002949@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:24:08 -0000 TB --- 2012-07-10 22:06:51 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 22:06:51 - 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 --- 2012-07-10 22:06:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 22:06:51 - cleaning the object tree TB --- 2012-07-10 22:09:06 - cvsupping the source tree TB --- 2012-07-10 22:09:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 22:10:37 - building world TB --- 2012-07-10 22:10:37 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 22:10:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 22:10:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 22:10:37 - SRCCONF=/dev/null TB --- 2012-07-10 22:10:37 - TARGET=sparc64 TB --- 2012-07-10 22:10:37 - TARGET_ARCH=sparc64 TB --- 2012-07-10 22:10:37 - TZ=UTC TB --- 2012-07-10 22:10:37 - __MAKE_CONF=/dev/null TB --- 2012-07-10 22:10:37 - cd /src TB --- 2012-07-10 22:10:37 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 22:10:38 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 23:18:33 UTC 2012 TB --- 2012-07-10 23:18:33 - generating LINT kernel config TB --- 2012-07-10 23:18:33 - cd /src/sys/sparc64/conf TB --- 2012-07-10 23:18:33 - /usr/bin/make -B LINT TB --- 2012-07-10 23:18:33 - cd /src/sys/sparc64/conf TB --- 2012-07-10 23:18:33 - /usr/sbin/config -m LINT TB --- 2012-07-10 23:18:33 - building LINT kernel TB --- 2012-07-10 23:18:33 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 23:18:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 23:18:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 23:18:33 - SRCCONF=/dev/null TB --- 2012-07-10 23:18:33 - TARGET=sparc64 TB --- 2012-07-10 23:18:33 - TARGET_ARCH=sparc64 TB --- 2012-07-10 23:18:33 - TZ=UTC TB --- 2012-07-10 23:18:33 - __MAKE_CONF=/dev/null TB --- 2012-07-10 23:18:33 - cd /src TB --- 2012-07-10 23:18:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 23:18:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 23:24:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 23:24:06 - ERROR: failed to build LINT kernel TB --- 2012-07-10 23:24:06 - 3185.88 user 590.62 system 4635.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jul 10 23:56:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7998F1065672; Tue, 10 Jul 2012 23:56:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4A5C28FC0A; Tue, 10 Jul 2012 23:56:57 +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 q6ANuuBV050973; Tue, 10 Jul 2012 19:56:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ANuuK0050972; Tue, 10 Jul 2012 23:56:56 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 23:56:56 GMT Message-Id: <201207102356.q6ANuuK0050972@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:56:57 -0000 TB --- 2012-07-10 21:30:55 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 21:30:55 - 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 --- 2012-07-10 21:30:55 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-10 21:30:55 - cleaning the object tree TB --- 2012-07-10 21:34:07 - cvsupping the source tree TB --- 2012-07-10 21:34:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-10 21:35:29 - building world TB --- 2012-07-10 21:35:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 21:35:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 21:35:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 21:35:29 - SRCCONF=/dev/null TB --- 2012-07-10 21:35:29 - TARGET=powerpc TB --- 2012-07-10 21:35:29 - TARGET_ARCH=powerpc TB --- 2012-07-10 21:35:29 - TZ=UTC TB --- 2012-07-10 21:35:29 - __MAKE_CONF=/dev/null TB --- 2012-07-10 21:35:29 - cd /src TB --- 2012-07-10 21:35:29 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 21:35:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 23:53:40 UTC 2012 TB --- 2012-07-10 23:53:40 - generating LINT kernel config TB --- 2012-07-10 23:53:40 - cd /src/sys/powerpc/conf TB --- 2012-07-10 23:53:40 - /usr/bin/make -B LINT TB --- 2012-07-10 23:53:40 - cd /src/sys/powerpc/conf TB --- 2012-07-10 23:53:40 - /usr/sbin/config -m LINT TB --- 2012-07-10 23:53:40 - building LINT kernel TB --- 2012-07-10 23:53:40 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 23:53:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 23:53:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 23:53:40 - SRCCONF=/dev/null TB --- 2012-07-10 23:53:40 - TARGET=powerpc TB --- 2012-07-10 23:53:40 - TARGET_ARCH=powerpc TB --- 2012-07-10 23:53:40 - TZ=UTC TB --- 2012-07-10 23:53:40 - __MAKE_CONF=/dev/null TB --- 2012-07-10 23:53:40 - cd /src TB --- 2012-07-10 23:53:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 23:53:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 23:56:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 23:56:56 - ERROR: failed to build LINT kernel TB --- 2012-07-10 23:56:56 - 6787.34 user 905.23 system 8761.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:31:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FE85106564A; Wed, 11 Jul 2012 00:31:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8168FC15; Wed, 11 Jul 2012 00:31:56 +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 q6B0Vt4V045662; Tue, 10 Jul 2012 20:31:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B0Vtgq045661; Wed, 11 Jul 2012 00:31:55 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 00:31:55 GMT Message-Id: <201207110031.q6B0Vtgq045661@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 00:31:56 -0000 TB --- 2012-07-10 21:42:30 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 21:42:30 - 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 --- 2012-07-10 21:42:30 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-10 21:42:30 - cleaning the object tree TB --- 2012-07-10 21:44:44 - cvsupping the source tree TB --- 2012-07-10 21:44:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-10 21:45:38 - building world TB --- 2012-07-10 21:45:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 21:45:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 21:45:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 21:45:38 - SRCCONF=/dev/null TB --- 2012-07-10 21:45:38 - TARGET=powerpc TB --- 2012-07-10 21:45:38 - TARGET_ARCH=powerpc64 TB --- 2012-07-10 21:45:38 - TZ=UTC TB --- 2012-07-10 21:45:38 - __MAKE_CONF=/dev/null TB --- 2012-07-10 21:45:38 - cd /src TB --- 2012-07-10 21:45:38 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 21:45:39 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 11 00:28:30 UTC 2012 TB --- 2012-07-11 00:28:30 - generating LINT kernel config TB --- 2012-07-11 00:28:30 - cd /src/sys/powerpc/conf TB --- 2012-07-11 00:28:30 - /usr/bin/make -B LINT TB --- 2012-07-11 00:28:30 - cd /src/sys/powerpc/conf TB --- 2012-07-11 00:28:30 - /usr/sbin/config -m LINT TB --- 2012-07-11 00:28:30 - building LINT kernel TB --- 2012-07-11 00:28:30 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 00:28:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 00:28:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 00:28:30 - SRCCONF=/dev/null TB --- 2012-07-11 00:28:30 - TARGET=powerpc TB --- 2012-07-11 00:28:30 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 00:28:30 - TZ=UTC TB --- 2012-07-11 00:28:30 - __MAKE_CONF=/dev/null TB --- 2012-07-11 00:28:30 - cd /src TB --- 2012-07-11 00:28:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 00:28:30 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 00:31:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 00:31:55 - ERROR: failed to build LINT kernel TB --- 2012-07-11 00:31:55 - 8271.30 user 1136.98 system 10164.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 00:55:16 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6210D1065673 for ; Wed, 11 Jul 2012 00:55:16 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id E02AE8FC0C for ; Wed, 11 Jul 2012 00:55:15 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6B0tCRM063851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Jul 2012 10:55:13 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6B0t6cC089446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2012 10:55:06 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6B0t6bh089445 for freebsd-current@FreeBSD.ORG; Wed, 11 Jul 2012 10:55:06 +1000 (EST) (envelope-from peter) Date: Wed, 11 Jul 2012 10:55:06 +1000 From: Peter Jeremy To: freebsd-current@FreeBSD.ORG Message-ID: <20120711005506.GA88249@server.rulingia.com> References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20120710225801.GB58778@zim.MIT.EDU> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 00:55:16 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-08 19:01:07 -0700, Steve Kargl wrote: >Well, on the most popular hardware (that being i386/amd64), >ld80 will use hardware fp instruction while ld128 must be >done completely in software. The speed difference is >significant. AFAIK, of the architectures that FreeBSD supports, only sparc64 defines ld128 in the architecture and I don't believe there are any SPARC chip implementations that implement ld128 math in hardware. For that matter, I don't believe anything except x86 provides full IEEE FP support in hardware - most architectures require software assistance for subnormals and some corner cases. If your application happens to hit those cases often, performance will also suffer. On 2012-Jul-08 20:05:04 -0700, Steve Kargl wrote: >AFAIK, neither gcc in base nor clang would be c99 complaint >even if all of the c99 math functions were available. That sort of argument can easily get circular. Lets get the C99 bits of libm out of the way and then we can have another bikeshed about the shortcomings of the compiler(s). On 2012-Jul-08 19:56:52 -0400, David Schultz wrote: >Yes, Bruce has ld128 versions, and clusteradm very kindly got us a >sparc64 machine to test on. That was about the time I ran out of time >to keep working on it. If someone wants to pick it up, that would be >great. I have access to a couple of SPARC systems as well and would be willing to help work on the missing bits. On 2012-Jul-10 18:58:01 -0400, David Schultz wrote: >On Tue, Jul 10, 2012, Rainer Hurling wrote: >> powl: src/extra/trio/triostr.c >> src/extra/trio/trio.c >> src/main/format.c > >It's hard to do a good job on powl(), but the simple approach >(exp(log(x)*y)) plus a few special cases may suffice for many uses. A simplistic exp(log(x)*y) throws away 15 bits of precision (size of the FP exponent field). cephes has a powl() that appears to do better or, alternatively, it shouldn't be too difficult to extend the approach used by __ieee754_pow() using long doubles. >> BTW: There seems to be a discrepancy about missing functions listed in >> http://wiki.freebsd.org/MissingMathStuff and in >> http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=3D227472&r2= =3D236148&pathrev=3D236148. >> So the wiki is a bit outdated now? >My list: [elided] I was thinking that a wiki page would be a good spot to co-ordinate the work (as well as making it clear what is still to be done). The existing page needs some TLC to be useful. --=20 Peter Jeremy --zhXaljGHf11kAtnf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/8zuoACgkQ/opHv/APuId9gQCgn0BumQyzCOMJTf/GoUu4PAxr fkcAn0iSSglTkje2VSlYwOFc5caV2v9f =TGxS -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:22:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E3A106566B for ; Wed, 11 Jul 2012 01:22:47 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BEA88FC0A for ; Wed, 11 Jul 2012 01:22:47 +0000 (UTC) Received: by obbun3 with SMTP id un3so944553obb.13 for ; Tue, 10 Jul 2012 18:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KPFCnwgNCNRwkqGzZvSD5vdmfzrxWWLYdCcDLtrJgas=; b=GZVawuh48b+K4CUa1TfpdjFSyy1sPr5zotORC2DLqjaiX+FPVJvpr9pu7HQIU5Jh2W jZh8Ut9dpIpUbzHWTeihIEZAcoZjvgo2p77TLgNCWmT3CLaKclzIZlir20ccLmpvFyWn Wh4+tyn1RJmFc6m+hhtiqVyqZKGbI1bH97zZcUXWYIqLen65wV4FQkCj9fV6Y2spPpwq dj70Q5115J+RpzFKR3udT1qJ8MW0DK0zK+VvVm37N3VgA6yfyQw89zHkkKc8WeUaP136 xUmVXNs11gSh3pcoM2tWy4WqAti/sk8+2w5xAawbfdJVHVq7NCchH7rHv3h9ulbu3qDS 8j+A== MIME-Version: 1.0 Received: by 10.182.157.84 with SMTP id wk20mr37800321obb.57.1341969766801; Tue, 10 Jul 2012 18:22:46 -0700 (PDT) Received: by 10.182.75.135 with HTTP; Tue, 10 Jul 2012 18:22:46 -0700 (PDT) In-Reply-To: References: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> Date: Tue, 10 Jul 2012 21:22:46 -0400 Message-ID: From: Kim Culhan To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 01:22:47 -0000 On Tue, Jul 10, 2012 at 11:40 AM, Kim Culhan wrote: > On Tue, Jul 10, 2012 at 11:00 AM, Konstantin Belousov > wrote: >> On Tue, Jul 10, 2012 at 10:52:26AM -0400, Kim Culhan wrote: >>> Updating -current to r238290 after make buildworld, installworld fails at: >>> >>> install -o root -g wheel -m 444 as.info.gz ld.info.gz >>> binutils.info.gz /usr/share/info >>> ===> gnu/usr.bin/cc (install) >>> ===> gnu/usr.bin/cc/cc_tools (install) >>> ===> gnu/usr.bin/cc/libiberty (install) >>> ===> gnu/usr.bin/cc/libcpp (install) >>> ===> gnu/usr.bin/cc/libdecnumber (install) >>> ===> gnu/usr.bin/cc/cc_int (install) >>> ===> gnu/usr.bin/cc/cc (install) >>> install -s -o root -g wheel -m 555 gcc /usr/bin >>> install: gcc: No such file or directory >>> *** [_proginstall] Error code 71 >>> >>> Stop in /usr/src/gnu/usr.bin/cc/cc. >>> *** [realinstall] Error code 1 >>> >>> Any help is greatly appreciated. >> Are you installing to NFS ? What is the version of the kernel you run ? >> >> If installing to NFS, and you run a kernel before r237987, try to set >> sysctl debug.vn_io_fault_enable to 0. > > Not installing to NFS, present kernel is 236925. Ran another buildworld and on this run gcc was produced in /usr/obj/usr/src/gnu/usr.bin/cc/cc and installworld worked fine. Thanks -kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:38:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39C24106564A; Wed, 11 Jul 2012 01:38:26 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7FE88FC16; Wed, 11 Jul 2012 01:38:25 +0000 (UTC) Received: by obbun3 with SMTP id un3so965768obb.13 for ; Tue, 10 Jul 2012 18:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4jE385TFoZZBRJmpiABalwnsatAV7CzfPkxyn/YJXeg=; b=ZrJ656hSjJKwkc5ger4GMwce/6+UNCPQJ/ej0nt6PxEnAuNPy8195qTu2uXgPItgA2 FW5Bn3xSg9hZGlKXxB/sP2wlBPhIG1cVZ7/d/VakB1b7LQG6kOShd8SrBx3yw1yn8AqS ExIFJPp/Y9sfx9N5gaNUofgvKimvjSOgVtP1OV5Ccaw9g9ts+3dBlhyBjjJqy6cRdbHG YnC9Pr/1+NHVcIaDlEQ4FXAqaTyJGKvgA+8eZy64qpUMHN8//wzXwrI7tfVdo+sVJnxY eUtI3yoxqIv9dEX7NGD4WhPLw0BIID5x28IB5Y6d24B8k9bCJXEUXILiRHd4n6eXroOY iihw== MIME-Version: 1.0 Received: by 10.60.6.73 with SMTP id y9mr48279853oey.17.1341970705522; Tue, 10 Jul 2012 18:38:25 -0700 (PDT) Received: by 10.60.61.38 with HTTP; Tue, 10 Jul 2012 18:38:25 -0700 (PDT) In-Reply-To: <20120709131957.GI1552@albert.catwhisker.org> References: <20120709131957.GI1552@albert.catwhisker.org> Date: Tue, 10 Jul 2012 20:38:25 -0500 Message-ID: From: Brandon Gooch To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 01:38:26 -0000 On Mon, Jul 9, 2012 at 8:19 AM, David Wolfskill wrote: > Just finished updating from r238227 to r238290 on the "head" slice of my > laptop, and was unable to make use of the wlan(4) NIC; I captured the > following via cut/paste from ttyv0: > > ... > Setting hostname: localhost. > Starting dhclient. > em0: no link .............. giving up > /etc/rc.d/dhclient: WARNING: failed to start dhclient > Starting wpa_supplicant. > ioctl[SIOCG80211, op 98, len 32]: Invalid argument > /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant > Starting dhclient. > dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT > dhclient: Setting hostname from localhost to null string > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT > dhclient: reason was PREINIT; no action taken > dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 > wlan0: not found > exiting. > /etc/rc.d/dhclient: WARNING: failed to start dhclient > Starting Network: lo0 em0 iwn0 fwe0 fwip0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > em0: flags=8843 metric 0 mtu 1500 > options=4219b _MAGIC,VLAN_HWTSO> > ether 00:24:e8:9c:11:0f > nd6 options=29 > media: Ethernet autoselect > status: no carrier > iwn0: flags=8802 metric 0 mtu 2290 > ether 00:21:6a:26:34:c0 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > fwe0: flags=8802 metric 0 mtu 1500 > options=8 > ether 4a:4f:c0:37:06:01 > nd6 options=29 > ch 1 dma -1 > fwip0: flags=8802 metric 0 mtu 1500 > lladdr 4a.4f.c0.0.10.37.6.1.a.2.ff.fe.0.0.0.0 > nd6 options=29 > Starting devd. > ifconfig: create: bad value > Starting wpa_supplicant. > ioctl[SIOCG80211, op 98, len 32]: Invalid argument > /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant > Starting dhclient. > dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT > dhclient: Leaving hostname set to > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT > dhclient: reason was PREINIT; no action taken > dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 > wlan0: not found > exiting. > /etc/rc.d/dhclient: WARNING: failed to start dhclient > Starting Network: iwn0. > iwn0: flags=8802 metric 0 mtu 2290 > ether 00:21:6a:26:34:c0 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > ifconfig: create: bad value > Starting wpa_supplicant. > ioctl[SIOCG80211, op 98, len 32]: Invalid argument > /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant > .... > > Yesterday, I had updated to: > > FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #614 238227M: Sun Jul 8 06:47:51 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > and things seemed OK -- I was certainly able to use the NIC. :-} > > uname output from this morning: > > FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #615 238290M: Mon Jul 9 05:39:15 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > > > I glanced through the list of commits to head in that range, but > didn't note anything glaringly obvious (yet). > > I hadn't tried a wired NIC on the laptop; I can, if there's anything > likely to be of value in doing so. > > I've attached a copy of the associated dmesg.boot. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. Same thing here, and I tracked it down to r238279: http://svnweb.freebsd.org/base?view=revision&revision=238279 Not yet sure why though, looking info it... -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:50:58 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 076B81065674 for ; Wed, 11 Jul 2012 01:50:58 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C19CD8FC14 for ; Wed, 11 Jul 2012 01:50:57 +0000 (UTC) Received: by obbun3 with SMTP id un3so982417obb.13 for ; Tue, 10 Jul 2012 18:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6frKmk1eJLhQInvBw22OkmCgjrWNyDYHX1fixGpnwWo=; b=IqpNDOlBfX/e78C4O+EH2mI3rCUJt+peHijp3+E98A0RA1A1iCzUYjvON/YRoi97Ky rodz5CDwacDUtlJPFGWJ8PjPBU7/LVRQZPR8pNq3ydNZHrosuwqRbDDGM/Y2f0lW3Dq0 TnZKDFxO8tU8df35nbvpM8C1ZcESUCMZejADaFSkM3xJH/x6wNWSJE/r2e/chgPmYQYa H6AD9M2qbmRulQZeFik1vZ2H/8Gf0FDzLwO57XjcXUHNkX+/VxLpizYfP04P9BJTwtNH Q+1CqyVhx7Ei7fCpwqXKjL//a6Qo60pewJz5rKjnXRhj936jY7tl56lgCdLlTgJgfbfP zGeQ== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr8592752oba.39.1341971457226; Tue, 10 Jul 2012 18:50:57 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 18:50:57 -0700 (PDT) In-Reply-To: References: <20120709131957.GI1552@albert.catwhisker.org> Date: Tue, 10 Jul 2012 18:50:57 -0700 Message-ID: From: Garrett Cooper To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 01:50:58 -0000 On Tue, Jul 10, 2012 at 6:38 PM, Brandon Gooch wrote: ... > Same thing here, and I tracked it down to r238279: > > http://svnweb.freebsd.org/base?view=revision&revision=238279 > > Not yet sure why though, looking info it... What does `ifconfig -l` say :)? -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:52:56 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 697EC106564A for ; Wed, 11 Jul 2012 01:52:56 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4078FC1F for ; Wed, 11 Jul 2012 01:52:56 +0000 (UTC) Received: by obbun3 with SMTP id un3so984897obb.13 for ; Tue, 10 Jul 2012 18:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ACpzflhbxaJIqH0qdMtFQ56fsinZtziEJVOg4r+XXzs=; b=S8q7HjxH2wOFiaozXiO2dgi8oDv3wsqu8lFULmQIQ1lLhPNUVa9hSkP7x6HItLsozf 27qHKBDsMkT9JYGaWLvk7wOhTy9U3VQFZMOnEbyUdLz0r3IJU0IdBMD095wILMHzx7Zs R153cdKkzvUr+rOmnyEjrmt1fgmANUO+xxZrR2oCflFYfbW/Vji6VwjsLAxOTh6mHtJs G3DHvO14lXrR19twrClVRspdI/vUW8i2aLpbLGm6w/0+n0fPEqDJBjCuD7yUL3F/2jwo VIqeJ/UBM/jjj+lLs2LPCmGwvUXb1MXbl2Qj2gyDh8Z8hiphm+6zfqLJpSm3nz24hGDE /x0A== MIME-Version: 1.0 Received: by 10.60.20.74 with SMTP id l10mr49207865oee.19.1341971575753; Tue, 10 Jul 2012 18:52:55 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 18:52:55 -0700 (PDT) In-Reply-To: References: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> Date: Tue, 10 Jul 2012 18:52:55 -0700 Message-ID: From: Garrett Cooper To: Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 01:52:56 -0000 On Tue, Jul 10, 2012 at 6:22 PM, Kim Culhan wrote: ... > Ran another buildworld and on this run gcc was produced in > /usr/obj/usr/src/gnu/usr.bin/cc/cc > and installworld worked fine. I would be curious (if it happened again) if you updated your source tree but not your objdir, or see whether or not there was some clock skew at hand. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 01:56:49 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D5331065672; Wed, 11 Jul 2012 01:56:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7AC8FC16; Wed, 11 Jul 2012 01:56:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6B1umks035481; Tue, 10 Jul 2012 21:56:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B1umw0035480; Wed, 11 Jul 2012 01:56:48 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 01:56:48 GMT Message-Id: <201207110156.q6B1umw0035480@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 01:56:49 -0000 TB --- 2012-07-11 00:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 00:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 00:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-11 00:40:01 - cleaning the object tree TB --- 2012-07-11 00:44:45 - cvsupping the source tree TB --- 2012-07-11 00:44:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-11 00:46:43 - building world TB --- 2012-07-11 00:46:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 00:46:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 00:46:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 00:46:43 - SRCCONF=/dev/null TB --- 2012-07-11 00:46:43 - TARGET=arm TB --- 2012-07-11 00:46:43 - TARGET_ARCH=arm TB --- 2012-07-11 00:46:43 - TZ=UTC TB --- 2012-07-11 00:46:43 - __MAKE_CONF=/dev/null TB --- 2012-07-11 00:46:43 - cd /src TB --- 2012-07-11 00:46:43 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 00:46:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 01:52:38 UTC 2012 TB --- 2012-07-11 01:52:38 - cd /src/sys/arm/conf TB --- 2012-07-11 01:52:38 - /usr/sbin/config -m ATMEL TB --- 2012-07-11 01:52:38 - building ATMEL kernel TB --- 2012-07-11 01:52:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 01:52:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 01:52:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 01:52:38 - SRCCONF=/dev/null TB --- 2012-07-11 01:52:38 - TARGET=arm TB --- 2012-07-11 01:52:38 - TARGET_ARCH=arm TB --- 2012-07-11 01:52:38 - TZ=UTC TB --- 2012-07-11 01:52:38 - __MAKE_CONF=/dev/null TB --- 2012-07-11 01:52:38 - cd /src TB --- 2012-07-11 01:52:38 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Jul 11 01:52:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Wed Jul 11 01:56:08 UTC 2012 TB --- 2012-07-11 01:56:08 - cd /src/sys/arm/conf TB --- 2012-07-11 01:56:08 - /usr/sbin/config -m AVILA TB --- 2012-07-11 01:56:08 - building AVILA kernel TB --- 2012-07-11 01:56:08 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 01:56:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 01:56:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 01:56:08 - SRCCONF=/dev/null TB --- 2012-07-11 01:56:08 - TARGET=arm TB --- 2012-07-11 01:56:08 - TARGET_ARCH=arm TB --- 2012-07-11 01:56:08 - TZ=UTC TB --- 2012-07-11 01:56:08 - __MAKE_CONF=/dev/null TB --- 2012-07-11 01:56:08 - cd /src TB --- 2012-07-11 01:56:08 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Jul 11 01:56:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_reinit_fifo': /src/sys/dev/ath/if_ath_rx_edma.c:193: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'bus_addr_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 01:56:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 01:56:48 - ERROR: failed to build AVILA kernel TB --- 2012-07-11 01:56:48 - 2642.52 user 594.66 system 4607.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:02:54 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DC81106564A for ; Wed, 11 Jul 2012 02:02:54 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 32CD28FC15 for ; Wed, 11 Jul 2012 02:02:52 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q6B22LSK039022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 11:02:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q6B22Fnr091124; Wed, 11 Jul 2012 11:02:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 11 Jul 2012 11:02:03 +0900 (JST) Message-Id: <20120711.110203.744611964086256554.hrs@allbsd.org> To: david@catwhisker.org From: Hiroki Sato In-Reply-To: <20120709131957.GI1552@albert.catwhisker.org> References: <20120709131957.GI1552@albert.catwhisker.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jul_11_11_02_03_2012_204)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 11 Jul 2012 11:02:35 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, QENCPTR1, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, 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 Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:02:54 -0000 ----Security_Multipart(Wed_Jul_11_11_02_03_2012_204)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Wolfskill wrote in <20120709131957.GI1552@albert.catwhisker.org>: da> Just finished updating from r238227 to r238290 on the "head" slice of my da> laptop, and was unable to make use of the wlan(4) NIC; I captured the da> following via cut/paste from ttyv0: (snip) da> da> I glanced through the list of commits to head in that range, but da> didn't note anything glaringly obvious (yet). da> da> I hadn't tried a wired NIC on the laptop; I can, if there's anything da> likely to be of value in doing so. Gr, it may be due to my change of r238279. I am investigating it. -- Hiroki ----Security_Multipart(Wed_Jul_11_11_02_03_2012_204)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/83psACgkQTyzT2CeTzy1YsgCgqFCtrH4ScXgCYlOpwPMAdB2u maAAoKVLApub5nM3MD6InOmFHOVDJS9+ =81P6 -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jul_11_11_02_03_2012_204)---- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:06:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFDC9106566B; Wed, 11 Jul 2012 02:06:10 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB1F8FC14; Wed, 11 Jul 2012 02:06:10 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6B269Ka002290; Tue, 10 Jul 2012 19:06:09 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6B269wu002289; Tue, 10 Jul 2012 19:06:09 -0700 (PDT) (envelope-from david) Date: Tue, 10 Jul 2012 19:06:09 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20120711020609.GB1898@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Garrett Cooper , Brandon Gooch , current@freebsd.org References: <20120709131957.GI1552@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:06:10 -0000 --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 06:50:57PM -0700, Garrett Cooper wrote: > On Tue, Jul 10, 2012 at 6:38 PM, Brandon Gooch > wrote: >=20 > ... >=20 > > Same thing here, and I tracked it down to r238279: > > > > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D238279 > > > > Not yet sure why though, looking info it... >=20 > What does `ifconfig -l` say :)? g1-228(10.0-C)[1] uname -a FreeBSD g1-228.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #615 238290= M: Mon Jul 9 05:39:15 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 g1-228(10.0-C)[2] ifconfig -l em0 iwn0 fwe0 fwip0 lo0 wlan0 g1-228(10.0-C)[3]=20 (I'm connected via the em0 NIC at the moment.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/835AACgkQmprOCmdXAD2lpwCcCU8qYilww5uIZaImCqI5lb1/ BSsAn33v6Udcrrr77edpXxMr06ghI4m5 =wogq -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:10:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD48F106566B for ; Wed, 11 Jul 2012 02:10:09 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 998BD8FC12 for ; Wed, 11 Jul 2012 02:10:09 +0000 (UTC) Received: by obbun3 with SMTP id un3so1007988obb.13 for ; Tue, 10 Jul 2012 19:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qdYPLI/gCibMrO70AwSLp028N8jXZfW17kngKqPrrzc=; b=r7KXZZk7ee6LUYANBuxxz05mIK84V5m8uo98e/IYC4DEJ7t0xdK+qJtyFtqkxD3FiE EoywhD++NKb1980GZcYNC6VqnCwOUscNFJ1SkpALAsB2/QFlp8bzejsojh3CK1LnNIjj mDkdBfcqY/viBCVEbqtXNcTvceq738XOp6ayhtD5QadeLUMSl2YJSFj+bh2X6cctlWde bmTzBW1yaL3B6E9UjEaW6lYyYGSF5rPtdnSshXY5khXFTEZRGae88F9hriGTUmDXetHm wgcrZT2gOO0bR7Rv6y7rjN7Ewivwe+kCdv+iw70etVeDRU1T0V7+guH3gCHUI/caAn5W l57w== MIME-Version: 1.0 Received: by 10.182.174.6 with SMTP id bo6mr42819308obc.65.1341972609278; Tue, 10 Jul 2012 19:10:09 -0700 (PDT) Received: by 10.182.75.135 with HTTP; Tue, 10 Jul 2012 19:10:09 -0700 (PDT) In-Reply-To: References: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> Date: Tue, 10 Jul 2012 22:10:09 -0400 Message-ID: From: Kim Culhan To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:10:10 -0000 On Tue, Jul 10, 2012 at 9:52 PM, Garrett Cooper wrote: > On Tue, Jul 10, 2012 at 6:22 PM, Kim Culhan wrote: > > ... > >> Ran another buildworld and on this run gcc was produced in >> /usr/obj/usr/src/gnu/usr.bin/cc/cc >> and installworld worked fine. > > I would be curious (if it happened again) if you updated your source > tree but not your objdir, or see whether or not there was some clock > skew at hand. Yes the objdir was unchanged from the the previous run which was ~30 days ago. Should probably have rm -r'd /usr/obj before the first run today. -kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:15:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCD62106566B for ; Wed, 11 Jul 2012 02:15:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEF88FC0C for ; Wed, 11 Jul 2012 02:15:28 +0000 (UTC) Received: by ggnm2 with SMTP id m2so820102ggn.13 for ; Tue, 10 Jul 2012 19:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uQFRvzTi0LSZnD8zpUenbm0Yb4YgwUCWIYuNxyz1LXg=; b=VhmIF+ft3YNVM+scCHAg1kCK76Kd2ol1PWkZSZIxnvZEdRdxyvU/jVzqqFxEgcCy/8 UAYcbqh1/SqQQ7RQqHhFFLJup2E2F/BYLXDc54auYglCYM74N+HRn4as1NryVv9wWjF8 XAw/x/w63w17KgEcKU2cRl4K7g0v2sYEZgmCcsN0LDjbwlwVRggrxQMvAOjwofIBKWgz 1I/gtHVBVHNE67YnQFKwty961Ha5bTytNfpsrVPfUPuh0IGIPu3Iwf4Tyat72lTWdFKX jwAtILyNt8s4Dud1b8VgcXe8binfX16jpbi+G8x/wpId1qdVZRy7jAQ7OkVNcAZFLCCJ Is4A== MIME-Version: 1.0 Received: by 10.60.3.194 with SMTP id e2mr48819498oee.1.1341972921780; Tue, 10 Jul 2012 19:15:21 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 19:15:21 -0700 (PDT) In-Reply-To: <20120711020609.GB1898@albert.catwhisker.org> References: <20120709131957.GI1552@albert.catwhisker.org> <20120711020609.GB1898@albert.catwhisker.org> Date: Tue, 10 Jul 2012 19:15:21 -0700 Message-ID: From: Garrett Cooper To: David Wolfskill , Garrett Cooper , Brandon Gooch , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:15:28 -0000 On Tue, Jul 10, 2012 at 7:06 PM, David Wolfskill wrote: > On Tue, Jul 10, 2012 at 06:50:57PM -0700, Garrett Cooper wrote: >> On Tue, Jul 10, 2012 at 6:38 PM, Brandon Gooch >> wrote: >> >> ... >> >> > Same thing here, and I tracked it down to r238279: >> > >> > http://svnweb.freebsd.org/base?view=revision&revision=238279 >> > >> > Not yet sure why though, looking info it... >> >> What does `ifconfig -l` say :)? > > g1-228(10.0-C)[1] uname -a > FreeBSD g1-228.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #615 238290M: Mon Jul 9 05:39:15 PDT 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 > g1-228(10.0-C)[2] ifconfig -l > em0 iwn0 fwe0 fwip0 lo0 wlan0 > g1-228(10.0-C)[3] > > (I'm connected via the em0 NIC at the moment.) Curious. I was wondering about this because there's some logic in network.subr that parses ifconfig -l output -- thinking that the fallout might have been there. I would be curious next to see what devd is trying to execute. As a fun next test, try adding the following line to devd.conf (look for "dhclient") and restart devd: nomatch "bus" "uhub[0-9]+"; Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:19:22 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53014106566C for ; Wed, 11 Jul 2012 02:19:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12E758FC19 for ; Wed, 11 Jul 2012 02:19:22 +0000 (UTC) Received: by obbun3 with SMTP id un3so1020561obb.13 for ; Tue, 10 Jul 2012 19:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BOvW1LC17hkDxajTe2R0p3h/1WmapsX3tUQHovFxqtg=; b=rDb0LtYIvbzfyWr+aJ4IASMK3zA9uitgHFUXyQ35bX4eUppvAR/Fx2znyBDxKRZ2Pn WUJ164/rGGEcy5K+fwKz6XAodjj/F3D6a6hhMGHQVKRZVpiLzfkJa/o2OHJmlygBME3P /NQvlKMaxFOWy9avsHOHpw1dTqUtwqdTmiyFgSMz+uIaV6hE5cggKdtsv7bhKIHKWd0x +s+SAFa5Uerm3dUkF//t5acqAmd7NV9TDhhJJAosEqAsk+ccf14h5kt4qG7z7fNclfH5 E1a7Oe/KG2qslxzgRnjpQGx5W228UJTwaeB9v/HKEKMhGFD4lOZhNQ30eYIJFTOVd29P T+xg== MIME-Version: 1.0 Received: by 10.182.2.233 with SMTP id 9mr42710737obx.11.1341973161621; Tue, 10 Jul 2012 19:19:21 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 19:19:21 -0700 (PDT) In-Reply-To: References: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> Date: Tue, 10 Jul 2012 19:19:21 -0700 Message-ID: From: Garrett Cooper To: Kim Culhan Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:19:22 -0000 On Tue, Jul 10, 2012 at 7:10 PM, Kim Culhan wrote: > On Tue, Jul 10, 2012 at 9:52 PM, Garrett Cooper wrote: >> On Tue, Jul 10, 2012 at 6:22 PM, Kim Culhan wrote: >> >> ... >> >>> Ran another buildworld and on this run gcc was produced in >>> /usr/obj/usr/src/gnu/usr.bin/cc/cc >>> and installworld worked fine. >> >> I would be curious (if it happened again) if you updated your source >> tree but not your objdir, or see whether or not there was some clock >> skew at hand. > > Yes the objdir was unchanged from the the previous run which was ~30 days ago. > > Should probably have rm -r'd /usr/obj before the first run today. Indeed. Changing source directories and not cleaning out your objdir is certain to bring pain in certain cases because of dependency order `violations` if you using -DNO_CLEAN, -DKERNFAST, etc (sys/boot definitely hates it when things are in an inconsistent state, as does include/). `Hacks` or modifications to sources might be required to get things to work if you patch things on the fly as well [1]. Cheers, -Garrett 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/160646 From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:26:05 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16327106566C for ; Wed, 11 Jul 2012 02:26:05 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id BE8788FC12 for ; Wed, 11 Jul 2012 02:26:04 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6B2Q4LO002557; Tue, 10 Jul 2012 19:26:04 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6B2Q4WK002556; Tue, 10 Jul 2012 19:26:04 -0700 (PDT) (envelope-from david) Date: Tue, 10 Jul 2012 19:26:04 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20120711022604.GC1898@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Garrett Cooper , Brandon Gooch , current@freebsd.org References: <20120709131957.GI1552@albert.catwhisker.org> <20120711020609.GB1898@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfjH4zxOES6UT95V" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:26:05 -0000 --kfjH4zxOES6UT95V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 07:15:21PM -0700, Garrett Cooper wrote: > ... > Curious. I was wondering about this because there's some logic in > network.subr that parses ifconfig -l output -- thinking that the > fallout might have been there. > I would be curious next to see what devd is trying to execute. >=20 > As a fun next test, try adding the following line to devd.conf (look > for "dhclient") and restart devd: >=20 > nomatch "bus" "uhub[0-9]+"; > .... Well, devd wasn't particularly happy about that: g1-228(10.0-C)[7] sudo service devd restart Stopping devd. Waiting for PIDS: 1736. Starting devd. devd: Cannot parse /etc/devd.conf at line 55 /etc/rc.d/devd: WARNING: failed to start devd g1-228(10.0-C)[8] cat -n devd.conf | grep -wC 3 55 52 notify 0 { 53 match "system" "IFNET"; 54 match "type" "LINK_UP"; 55 nomatch "bus" "uhub[0-9]+"; 56 media-type "ethernet"; 57 action "/etc/rc.d/dhclient quietstart $subsystem"; 58 }; g1-228(10.0-C)[9]=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --kfjH4zxOES6UT95V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/85DwACgkQmprOCmdXAD0UcQCbBanu1AG9s1f88jlETOyESeIQ PI4An1vOPupzCfDDGivnrFSdCvt+KSJf =XCcS -----END PGP SIGNATURE----- --kfjH4zxOES6UT95V-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:36:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC889106564A for ; Wed, 11 Jul 2012 02:36:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 937508FC0A for ; Wed, 11 Jul 2012 02:36:10 +0000 (UTC) Received: by ghbz22 with SMTP id z22so826663ghb.13 for ; Tue, 10 Jul 2012 19:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=A91DMZiUn4VzV75j82GEh7AAO/i0mp49TTTu0Dks++k=; b=ZpDPwWhKtPTCThrxmD+qdjiO70GVktPO6d+a3sHAoqKtPhztEEJEjW5t/ZlXmc6LID nzOceDOmb0PGbTuDB+AJzF9paA56exWxSX3gtRAR8WTkSjRV0H5UMjpjFXIGIOpE59Yp QgQrxstCK0LuX0pnBBn9j3Dv/7wYvmFm3n8MYFXa+hz8atPFp4OwGiiuXgoNjvl2M1D8 QjU/fXRw1Nd/UkZDCy08gCn0oR/x/zpCwfJIA1T9YsrDY0RQCHbXKuly6pGv5Ugg0vVU mPZQwUia4G/qPosRzrS2Bu8y/bQdBd9iIWA2v1VPHq2wm9WKM9IEwYFIHMHJ75h/H+hg cceQ== MIME-Version: 1.0 Received: by 10.60.20.74 with SMTP id l10mr49310651oee.19.1341974169995; Tue, 10 Jul 2012 19:36:09 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 19:36:09 -0700 (PDT) In-Reply-To: <20120711022604.GC1898@albert.catwhisker.org> References: <20120709131957.GI1552@albert.catwhisker.org> <20120711020609.GB1898@albert.catwhisker.org> <20120711022604.GC1898@albert.catwhisker.org> Date: Tue, 10 Jul 2012 19:36:09 -0700 Message-ID: From: Garrett Cooper To: David Wolfskill , Garrett Cooper , Brandon Gooch , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:36:11 -0000 On Tue, Jul 10, 2012 at 7:26 PM, David Wolfskill wrote: > On Tue, Jul 10, 2012 at 07:15:21PM -0700, Garrett Cooper wrote: >> ... >> Curious. I was wondering about this because there's some logic in >> network.subr that parses ifconfig -l output -- thinking that the >> fallout might have been there. >> I would be curious next to see what devd is trying to execute. >> >> As a fun next test, try adding the following line to devd.conf (look >> for "dhclient") and restart devd: >> >> nomatch "bus" "uhub[0-9]+"; >> .... > > Well, devd wasn't particularly happy about that: > > g1-228(10.0-C)[7] sudo service devd restart > Stopping devd. > Waiting for PIDS: 1736. > Starting devd. > devd: Cannot parse /etc/devd.conf at line 55 > /etc/rc.d/devd: WARNING: failed to start devd > g1-228(10.0-C)[8] cat -n devd.conf | grep -wC 3 55 > 52 notify 0 { > 53 match "system" "IFNET"; > 54 match "type" "LINK_UP"; > 55 nomatch "bus" "uhub[0-9]+"; > 56 media-type "ethernet"; > 57 action "/etc/rc.d/dhclient quietstart $subsystem"; > 58 }; > g1-228(10.0-C)[9] My bad -- I misread the manpage. This will work better probably: notify 0 { match "system" "IFNET"; match "type" "LINK_UP"; media-type "802.11"; match "device" "wlan[0-9]+"; action "/etc/rc.d/dhclient quietstart $subsystem"; }; Kind of funny why things are setup that way anyhow for wireless post-8.x... All else fails, you sh -x the rc.d script at boot or add rc_debug="YES" to rc.conf and see what's getting passed along... Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 02:59:58 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94B95106564A for ; Wed, 11 Jul 2012 02:59:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAFA8FC0C for ; Wed, 11 Jul 2012 02:59:58 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6B2xwDf002797; Tue, 10 Jul 2012 19:59:58 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6B2xwHQ002796; Tue, 10 Jul 2012 19:59:58 -0700 (PDT) (envelope-from david) Date: Tue, 10 Jul 2012 19:59:58 -0700 From: David Wolfskill To: Garrett Cooper Message-ID: <20120711025958.GE1898@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Garrett Cooper , current@freebsd.org References: <20120709131957.GI1552@albert.catwhisker.org> <20120711020609.GB1898@albert.catwhisker.org> <20120711022604.GC1898@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2NLGdgz3UMHa/lqP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 02:59:58 -0000 --2NLGdgz3UMHa/lqP Content-Type: multipart/mixed; boundary="WlEyl6ow+jlIgNUh" Content-Disposition: inline --WlEyl6ow+jlIgNUh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2012 at 07:36:09PM -0700, Garrett Cooper wrote: > .. > > Well, devd wasn't particularly happy about that: > ... > My bad -- I misread the manpage. >=20 > This will work better probably: >=20 > notify 0 { > match "system" "IFNET"; > match "type" "LINK_UP"; > media-type "802.11"; > match "device" "wlan[0-9]+"; > action "/etc/rc.d/dhclient quietstart $subsystem"; > }; OK; didn't get a whine from that: devd.conf: 327 lines, 9863 characters. g1-228(10.0-C)[10] rcsdiff -u !$ rcsdiff -u devd.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: RCS/devd.conf,v retrieving revision 1.1 diff -u -r1.1 devd.conf --- devd.conf 2012/07/11 02:20:46 1.1 +++ devd.conf 2012/07/11 02:45:04 @@ -73,6 +73,7 @@ match "system" "IFNET"; match "type" "LINK_UP"; media-type "802.11"; + match "device" "wlan[0-9]+"; action "/etc/rc.d/dhclient quietstart $subsystem"; }; =20 g1-228(10.0-C)[11] sudo service devd restart devd not running? Starting devd. g1-228(10.0-C)[12]=20 > Kind of funny why things are setup that way anyhow for wireless post-=3D 8.x... > All else fails, you sh -x the rc.d script at boot or add > rc_debug=3D"YES" to rc.conf and see what's getting passed along... Well, the "wifi" LED isn't lit on the machine (which it is -- at least blinking -- if it's even trying to associate). So I suspect that the devd.conf stuff is a bit moot at this point. I've attached a typescript from "sh -x /etc/rc.d/netif restart". (And then I need to flip back to my stable/8 slice in order to maintain domestic tranquility -- don't ask. :-}) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --WlEyl6ow+jlIgNUh Content-Type: application/octet-stream Content-Disposition: attachment; filename="netif.gz" Content-Transfer-Encoding: base64 H4sICA/q/E8AA25ldGlmAO19fXPbRpL3v1eu8neYvcuVko1FkZQsy9wwd4qtZLUrS34seZ2t JMuCgKGEFQkgAKiX3brv/sw7ZgYvJCASoqR2KjbR89YzmP7NdM9049SN/ShFSerEKfZQGKCz GUZ/mU1Qr4t6bwevu4PeW9Tv9vovXr6IwzD934veZr+/N9jCqYv+CyWXaPMW0Yet2O14WwFO /TGKMavw5csX36KOSk1m5zGlDFB/Z3eb/sK3URin6NO70cfD95TwC9r8F9rYQL/Rh1HsjmiZ 0SR0POwN/35wSsmnfz99d3Y03ErO/WAruUvcdJKRR8fDDT0FbQYbWuqXXLHD98OtWRJvUarv ccq7D++HG6Qbv7C+Zanotz+h9BIHBm1zFvwJjX3WysdT0jqlRwnavLlhNO0ZbUas62gzRP/0 vSFN/gthoFvU24E2eGRUb8L4So1g4EzxUBDpMxvtkTv1JHHEx58lhZGVEkY0wZ2EAZ7xNPZ7 NMvoXngTaCn0kb+vNHZGbjidOoGXDDdEHVkZ1mNSzh8Hww32kOCU9OzaiUfheRJOcIqRH13v jnDgnE/Eb8dN/WsnxSNnMhn5QYrjsePihBafhK4zQSNSno0R+XeoFac0D5/PLtCG2cYAfaVl +zqceN+gze8FsaS5rwN88w3yE1Lj2CfdYeyzahNV73BD557lwNeEwQ2NOiL1UD7/s6qx/2Rl C0rNG5Dk0h+nqF/csmRzNE0uhv+Zb8NIr34/UYzHOK56BVmOylfAs2WvYLFhzs0RXo094pyq RlzrsZki+lo4diKnOXZaSr5SI2tutByPirIbBmP/AmlCKsaRyi4SQ34tBhaNyGDwB0QrRZRv Ntq2pDOAFM8cJcfOJMEiKeZwQSpzZpM0oaBL+eAZxVs6DWex6wcXxVk3NNSx0/iLGrF6hscn 4tEPxmH2xHCH9CCRaB27yeUsZXiS+lMcztLhW4Z32Iknd6MJneWef+17OB7+eHh0QID67OAD K+pMbpy7ZDQOY5fkwRGmmMNbSm6caOxPsHh0oqmYLBnBK6CMJw7hjE8Gzzs3c1ACf2tD3n3v XHXbw9eqPtExRtIrvJp4t2QamJVKIkHI83PSRZM6Db0ZEcvISS9FJVF4g2OLdUHT20qn0XSc DPc/n52Ix8T/Fx72u9MsVRTYZNySSaYXoNJGC2z3p1mqUSAKoxl7OVR8ZDF3gp2ATlxzKNjM 5q9+FvHllJHUtoC9MrbTYBN6lOCIIKmQfDboI/o2Se9kETZt9YcOq5EV+Rdh1Rigiyg9J1sT i6uLc48A6CwNnTR13EuKpTI/TSHvzyeYqpNkxjTF0yhNhtsqhTR+5fkxmxiMiCe+qoG/EkZK Y98kCBkyXh5LoIx5mLan+KVkOrFl5k2MHEw2DhPUf72LNhO0031L/hWISTsc35ApNAtSWcU4 ca9Gd+bgCJrOwLnjXl3EpCCZVCRVlrbIhPeJczfcZdJKIIeMenoX0e4F42Rw/OMpIphOf54c vadPyfScPJx++AHRTZ0zIQ8fTz6d7R+h4IYW+PLj6Ua2idAr5IxehknK4I4zSR99W+gEkYk+ mx2cwDj0Ey+cOn7A6hAifelOfBykBJ/Di9iZit2fJBtZSgZIpkvguQvcyzgMwlliJ4lXTYpR SGNjt93NJbhOTOZILDK8puk3kUN2flE08V1H55XKEePXzFBQRAhuUpCkhIuPl5mq8G3sx/iG bjbMqSOpXHaHUh4l3chDX+Xw8/Ffj0++HBsJv898nNo1TsKLC7IIFZD9sU3U34wiuiFnKp/A XyeZX8Pe236n2yH/b/V3zP7404jgrk/awl6vMEkv39vd6u8V5QpZBd3CJIsBs/z0LsGxjh4q hfwf3pQlpvEsIWqaTSaj5uHgzh63ICQJVBZJPb3t15u97bevdnZeE82uv/uK/PUG9Xa2t1+R v3bM+gInLZkINEXtR202aKKxws6m0zsyDGZdfjSiPMVOcIHJxIyTtChh4mT0K2zVQAiGkPDF homKnzhX08iT2XR2/CjBrs0LJWXSwZ6VUJD+eBZyUJJKMqpiFHtoGNHkgTRG8thsCKrZGCEb qfGMLpGC0XGHPRoZzJZyb5GT7DYILUs0miAEvRH79frRNAzsFijJboHQskQBVe8l50luKJL8 MGSZdQYia69FnjX+yQjJF0kSzCqjsdD+SYpZI5EYu1JKIv/zWUI2P2S6XWwxcpZuV08lMks1 ACyNSOZbe5GWVJMbutrY7DAa/YtsP8yM9K8I49ik+mOxqRU7RzcakRUYB4kfBkm2g7sgk5fs 9fyAWyNotiuMI2fiX6vVlxK9OIxoS0R3k6/MnQpyjMkeCbupnkBrtujSEpEptkO6G+IbTGpI 0FOE5hZFUZ5K1oo8cYzdPJEWN8eREPILLaHKRLI1x4otSiDTX46DKMxmRORE7qWjis0IdA/p 3kzuVpzIAorkLqGzw9rYSGqeJ5GiZ9KXe7pQWS1wUr4mRs8yyF3mzRe0+Q7tdvmui+CuVR0n mTOc0bJEfdbS7VcOGykpzxCjZxnoPOWyy57P+T8aHNNMM98bkrJ6sUs63mx3TqXTrpSlsu32 LPKIQiNHnCcnd9OJH1xZb4On3Th+avSAEkb0pQ7ZikN/ZYm0Baqr3jixZ5TSE8i2YCLX6Ssc E40wTF6P6HJvrwl2qljp/HN8i92tK88trELMjE2uWbAsjjclw1XSiJlotcETWb7ISZIbzyuu xEy0KhGJLOPYmheUYC7kstSYFbhIEqsEo+izLb65DK08nGRkcmJbCjlJDJfD9vxkmkQOYcXK qdENcI6i0J7ngka6xO0ZG3/Us0p5+4jYPI1nDG9ISifyPT1jtosY30YMjZPk0kYRSikAC0JW yday4+WWnJLRpykqh15JbmwoIc8EocpE2WcHbXXo8zRIqT7LgQwx7Y1r+SSxM3UiRE3dBkU1 TH6rtoR4kf2A2O2bcEPojkvAnyQTKcBShSXkovnLtdjCJI0uezJDm6QLAeJbZqZ9W4MiaGJu MaPgDXauRoJO4OCSsEz0r5SswFpDMWZNeWwXrAMFTTyfjSOilGKl78SRy60S1rxWZEMAImaZ sznNyFZmCrC5rIyYf9siRc9kN30Xcei1xR8zLaiYaCwp4+R6p+wFuef2asNpVgV0Yc5n5FTD subnli9OMupLWX+s6gSxYJ3jKXomMTvOdZpufCS0bOET6VRadA7yzZe0rZKrWmDbRzLtuB1P r1RO/SgDLkqnsIU2x5xIV2tK82J/nHIO/RLpzOjGkBLyXZTY2mJGtjMXTgffllet7ttxbgJk 9Hx2uaoVlJBJhskoCab2KxE0QyfWbEHSGkxF0HdHZEUaRQ5RiOWel5MDr5DMasj2XOl0VJRw QebNjWMpGyyHLd+cZu7yOFFLFrP2dwZzRdVM7Xos9XyaVTk16pQq5W0hx4Re1FpGNlapWOhS mcFX7r4SevaBWRm5gpF1IkqLElL7SIEQomtXtUIeSUvy8dJNsGtvnDlNF7rzyQynZENxucUT lQQmXk5P8LjAkrkyGSrBI1SVSC2UET8gCs9D704lUFSz6OfppW9PZkEr5o8nKv5EXvJXMpQC L7JQGpsjY3owPCKbmOJ9YkG6VKI2iNaHiFK4UZKPnkETLSsI8GTYK8lDiqs8zHA/Y/xdur4l wkT7pPv4QqI8olJGb0YlaqZM4BZdptmeT12i/GD3MlTT8Xp3VKHcVh3t6lUUYQRLKJJwllAi NCTFjTBRWwJlVBWnlYQF904X/d0iPNgtXO95ip7JFOGsB9pOVtSaJqFpz2UUu21O0zfncep4 17lsjJbT9aeFHZoW9kiDpsif7nqekVVnNEk1W8OI9HLH8by4NDGaYGFJyaXtkvlElNjugP7X K8mSTByah/xRgzomU/GSnTT7t/rbpM2RzXGUmdMFudBsuKub9HZpH9xUmf2F+qslEMk6D5Ns SqmEKJz4ZArJk0GybTsPqeYrzkLxHWEp29LFjgJWmhMrZCZPVGgvZKo7i5NQLYxuHGTVjAkW 7t32ds3HHeNxT0LbxAmuqMwSgeVvwblWskQ24glZM4IwkPPU7L5Itzf1lMYOOaQ8Cxrdrg+3 PHy9FSXTrpagTx9GIj2Nje0VwQDSR4wD07Cpka/OPaOa1OEV2EcyCQ68qeMzo6b8ba0nkkq2 bZktk60pIoVu6MycceiydURTMIvakRvEI5RMNwmLaPOc7Ax/3+5ON4x8yex86tujbaeWV4Y2 T947eBoGH8mIn0QpM2DuUylU5hizPSLG5+wQr6RFlW60+fsMz3AR+9MkGrHEsvqyDGYnkkhW uu8WVRzj85lPEM+Z+E6i1gJn5vm2xiZoBTo3S9Cy6LPGjTNDveCZkfLVULJK9pLUyK5XObG3 K5NC7WPClY+JtQsOEnuv5F5ekVUpSF0nKk8QKwKr0puRrTW+VgDEnqUN0I2d5FKKvRvG2BoO kkqvreTGRNKLBkak0Yy/z0Iihxab2L0asQRlVGdP2ZGHk9HG4zyR16CTyd6UmgwIrlsL+7mb 9ItI7OYgURRc0gDr/V1y7UfWCcLED2a3FjRcxztWdyaYQFU6tV+GIv+sTg48vn8kCxgBuFms mpF0ermFXuwQFqYtsnEjJKQtv4RqPYpMW9HVxYZe2XZfVCdr2+7n2xo5dKNmN7hFqXYzlGY0 MOJXWTyqbpl5iQbubMls+SKEs3mFOK9XZGs+4iM1wdfYAmk7dbjJNgjcfDKahqm6BYupYhDd ycNL/qQnKGEgO/WCZCoZo+Rfw353Zy9HD2bTIaOSBesaJ2IjF88iBQgyAaeXhGWco0ejlIiR uis1xcmFJW03TupeetpJCB+BjGyqzdfUQkZ3LswEZt5PY6l8XyNvrimCVpyIQ4qnshajZnYL UtWuJfDrfDJFmHnJRi2Mp05ANmvuLclyQ3o8/PPhT3/OpUaz0TjGv5OCxwdslMlUCKd3BcVU il3kmh6dhZo2JcZvdkHW8Rvb4OCxsz2PnmyYGwQtias2N9wIa598KLpAonfsMsfUv80xEEZk g2Ipyf/MbTsYhdrPJxM8MTY/LGXiJ/JNsGf6IuRFIH4XQjbHk0NqAx3NAv/Wj/iFGmYoNfII 1OOleVvGvXKu7MtLmslIXEQd3okbtmYyk3V2ddMXSfz+kZZXEIYD/cLaQLQbG9fYOAcdg8aw PrvBKFcjfUUxNqGFu9XM0t7vvOHbC+3QQMoc2RYnI/8m6A7pz25GI8DJaQxvrDtElnYgDpRH rIrhxpeP++j9n9993Mgl9soS8bQ7pFS+SBXcqJL32RpdS9okOtImqSoyMldeQ5IHu67rxPag caKJR+qumnEQWHBL1LzPaRKzV3bpO55DNrTXZIt4bjwF2tNGbvkW9TkR3T0UEvv9MrKwvSid Q9AnPtmEJ2WFDC3FLOHE4s7i5jvksW26kWt0mabRSJjb8obrPMU0RxdecCy+tyixsOI24603 HXkxGVKyYgfXvuc7JlUaMEjiPCkf5C+pFks+T8s8W9jFPOHrkcYzeYXbuvXqbRmXvfm19dH1 UHdvYOM8kpdBRBZ6Nf2rsrv/vETmBCDKEPA3y/Db8zw3TZznnGCxp93ZL2ev4E59xp51uT7H p3HLP+NT2JZmAR9o5q6inJLY+ON0FgsDTUxN7xdDLTl/yZ57DvREdn6DlU/4Dfk+hWHG6CVd tmPfw5KH4VfSPCg0DF46l03oKcbT6ArfkaLU7YYxyjx7ZKe4AwUq9sehzPmqGvKTOvbIJ6ni 8+dfKOLIdZINg2zgt1wy7yOpnIOC6hp7lA3rgCEGhWzvyNZUZWePG4xOb2roCfSZpgS+izM6 faJUdtVGUekTpTKjeEZmj4qeWAmcTcER6Zfkgf5kjdIfrB36g1etfiWlY6aPECfyMfzD0BxO at0ncI5lHvI+q7PIJDuXZIEsJXoWNidMGmukrIxIJhSrE/TtkDnzlchIH+iYkilvkPkzSyEr opnECWK82fxDsjz7KQoUDKlycKFSJuvzyARXsDkSks7ryzZPZBs9Iyu9NzrHZEuOdQQQzjjc p4WBAermWrZqccYE64oqQQwL7KqM3yYUSR+8IhySaQBCmUDlZy0gUFMEysayGH4KEUJhk4SU +bnngon0TNWRhNEKYITTbQzRXVrnoYmR97c6qCEFsjlk2DXMxwvJmxf6KdoweBfGCe5xacDK ANHsA5TPzoc9T8/5BOueu0oKSO1hQJS3YGR1xA3DK9JJqsMjejxF+zYLXIIlV4jk5f6ilJK9 iH+pesRLYMl63XqtRfOb0ukpa6GjMD2fQdRAyXnif9PzGvEcopHPXiA7yBHwI7LLA0yhpKJN Jjmq9HCDaK2I6s5ofIPpX37UJc12mQbNb8+SBqRyREr5Y4T5gZAYL9IQffHs9bPsSiG+wClL MfOTYSF5xyJrMBSphKQPKGWLjcwFZkfVVEIZq7Lywx+RMNrLaomEkGFPxT8jN3NCpVoP4qsI SmZj8g9vZ5u8Aoz6VJz5z23x/qgHjGCLVTbc6KBNtIW+5S2mnJcOGmkMkKlB/opJsx59K9Qw S2cZq4SkqQpJlmGH/aJHESO+TM3kizr88ZSnmkEDaAZRAT2bl0OqMSqZ2mzM1GYlU5v3YWqr MVNblUxt3Yepbxsz9W0lU982YYp7oGeTm7cgFHZxOZdvg1Qmtntis1nfCLD6N776t26W2vy/ DdW0tFBJuVUmKxP96QANGRD8ZsIJTdHBgGJHLTSwCthwIJMtPGAQZQMCI7aGCIqzEkhg3NTD BFVlY1CQNbB3q6rTuFWc1QMGg7NGyLA4Z/XQweCsETwszlk9iDA4a4QRczlbHUzQFnScyLYR mjZmYgQbolKQYMk6UtANRi2ksArYSCGTLaRg+xgbKRixNaRQnJUgBeOmHlKoKhsjhayBvV1V ncat4qweUhicNUKKxTmrhxQGZ42QYnHO6iGFwVkjpJjL2eqQgrZQEynYEFUjBctjwoUf1cUL s0QeMER6DjGo0pOHDEptETMkc6WgQfmpixqy0nvAhqhCzDRZoc5yxl5d6NDZa4gdddirix86 ew0BpA57dUFEZ68hisxnb5VAQpqojSR0oBaAEp5TBxRSpBacmPltMBGpFpQotjQgobTWYESy VQIilJd6ECIrbAwgogL2gmVlGaOSqXrAoTPVCDYWY6oeXOhMNQKLxZiqBxI6U40gopqp1YED aaAmNNDB0YGBmi3pk44B6oLQwihgl7BxQKVbSMDoOSzg1NbQIGOuBA84P/UQIau0MSaoKti7 zSrUWc7Yq4cNJnuN0KEee/VQwmSvEU7UY68eXpjsNUKMRdhbHW6wJnTkkJf1TPwwrvCZOMKH beEthn5SojLSsnPyaqczo0ULSRQuz2Z3xzx4WoAtz/FYiBDBGT0Ak7/DK3WaJE67jC0SRUZ3 fCEyyBWCULh3o7k/csb4lrCUUHdXbXoKYCVQKuhW2GN6ftcRSVkVhLhbXIlM4SeY7CL6GDtk eHC+2LXgMuAp9t00dibJriQa1bCgart8gK6zBSA72rN7QEt3ZOmOYoI1VNlGFlF5Thb9/XPP xfAmyG1n6f8Ju6zB+ntEzxLDiceIiit9qScpw39wFmgUOFl7bmdNq5brqm9Vso7vrKvqEHOz 7PxaXBRklz2Zn6YxsDyVbDMYEFUNirbZkOMimump4c2q5Dg4EkEiqaeiPLxm+2bmXmU1RC8z knSxWZjQMiLIJPonok84Sey3y8sMs/psDUbjheP1PfYs/WzP0gcNBjSYB9dgcpO7ZDOi5Zuz H9FyFqoyxqU2Y8HQ5H/MpFHBTA7+SE4LkEWJMtinaM9yZDqIvLWTVcIycA4GRUiQbdu4c6eN c4AGgAaPGg0KJ/ji6olWqNS2IfLkccGQS9HWeYydq0Ukk8dhAPEE8XzK4lk+yytW7VqCahRo LK25Tb1utdRLy55exDhCG1yTYVnJaG/8GmwgpnZJLW24gcgfnmsw6IleTjBpqb+H/oH4H54+ xntdkue/6ZvM8u3uoMQNI0z0ge7ta/QP1hbX/XjlCL18od7UP7I3hYzK843LC9G3UbxI5gHa 6Pzx1695hl+//qW7+dbZHA9+++Ov3/z6TYfHmRSK7YaqRfGlGpDM6sOptZqpNKo32RarqF8L DVpFVxcsX7/3ouJaIyDKVI9CYWW66kutOHkFXgMGU39nRUrUd62Qqb3XUd7vZW9RzVS1MN/a Umhs2WlmbLFxrsjWUgoWC2EFEbk3nS75r0dtaFMnuSLTcDzusj8NIaC6zlIJmVdMEwwhF7/9 +u/eq+1f/+/XDpGNf5MfBtEQFi4rWRM1hEXjy8PUbbOOtBTqatocqFLVCicNqGqwF4S94Ly9 4NqqavM3f1TuqTE2qbTnUhjQjboj1/di/jcrrQt0xCy9IwmqI/bVEUoPWCXRJLyh/1z6F5f0 XxaIycSTmhZh2QEwCAOuPC1csed2qWYps2mgUmwOlhkLrcFKnM2bLT3tt7kPV9hTsHMQh7Aj dfR6Ezlw/w3AAsBiRWDxwPffmIzT0FAg5CDkIORPTMiD0Cm6TmLxWLBhEFYGYa8T+UwBzsIC ZNdYdKuI/ET6SO07SjYj4ju4+mYkixXG4lz4NFaYecGGMehe+tTqRMaTvMnwzuwnaYFn4H+P rmlYP/GbhfijN80kK70CSOJxAEE9ATB6UmCkT+tiJOI5qmGI5ynWRzIREyUtwboGwQLBenqC dT1XsK4XEKzreYJ1rQlWmarPrltTPrmt8VndtFW30MUeRlw3NwIJWdfNRZp53VxFEXqi180r BzS7A2gHYFr46ncWp6bs6ne+6tyEFFke3fjllWXmOkH6bfS4NJrVSGZdNKAVKwBRrXRGIarV k4pqpUSixgmdLFIa3YrlmKtGG3dEbBlsy7cBxA/Er3XxW6lvgxVdrpnoWbY1ED4QvqckfIuZ jssuKZcJYFmAx/kiOPdwec0uec7TcnaaaTn2+6q6cyny1L5z+abf6b3p9Dr9/p5x15HfdkTn ceh49IOrMmf/9Wv6f+P7mE3bq7ir2bzKpdzj1Jpf4ConW1JybN/zNqesVJtdC9zmNKfjfW9z 2qriym9zwmoJq+VDaooruc1JtcW2bnOyyfjwtzmVQariNqfYiLdymxNwBXDlAXbhq7rNWbj5 vudtTnPnUHKb08wEH2EAsACwWPYmpAIqVvsRBv1GJwg6CDoI+lMTdHGr0xZWi8+yjYP8mqq3 JT8ujLILEqfkV+QHF0imkRn+xfFTShqHMfp4+P50gF73X3O50DYhwuonGjeRQb8qKjIYVpdG V0WzlqyroqrZqquixuDd66ooba6Fq6KAcoBybaPcMq+KFis7VVdF6Zi0cFUUBAsEq23BWuZV 0QrBqnVVVH2cDW7nwe08gDGAsXpnLnA7D8QPxK9d8YPbeSB8IHxwO6/wdp7yfDI/mmy5PslE 0/cp+2Ly83Z+yn1vemHvJ+0DvGXuTwWV5zQsmefRjWFexeIf3K7WsfQPeJtK1kLf8G5BzYIP ecOHvBfnrJ0PeS9f96It3U/5UtLeivYFUglSuR5SuVKVjDa1BIlsRykDmQSZXB+ZXLGmVl8y n6gjVW2NKffKqlypZKYFfalYWrUj1HwPHo6btV14rIG4rw9PTtVZuRMP4Dfg93rg96o9e5i2 05ZrD5+cD+/bk5laKpx75J6xFe8eABwAnPUAnNW5/BTvExfw+TH2QYU7jBJfHyvXfB+A3A6u 3ESreQEsZJ8F0yzgx3PAj1U4ByykYRa4AIH8g/yD/D8T+ReeQTkRttksiJ1qRnyXGS3Z1h15 ZBbDONPMlUdrzfLlyZqucuYx+3svbx7WYAvuPABWAFZrAVbL9PGxMYpSu0pghZ+PIiqwURTW B/aUhxutmEVEAgYMgLFFugVHIhBpEOm1EOlleheVGCzK3IvMVb7Uz4jxzs2rcBcO7sIB4AHg 3Qfw4C4cSCVI5dpJJdyFA5kEmVw/mVzru3DKbWl8gzWVwHJbkomm2xKlgttSYA1dHbclWbLC bamg8pyqJvM8ujHMq2psTs1R1dSo5VS1bEZqqw+vslVVTXFYsgAxluotQKrKxguQrIGhhDbz VILirN4CZHDWaAFanLN6C5DBWaMFaHHO6i1ABmeNFqC5nK1eVaMt3U9VU9LeiqoGUglSuR5S uVJVjTa1BIlsR1UDmQSZXB+ZXLGqVl8yn6jbUm2NKffKqtyWZCbDTcn2YVqy2xLHzdpuS9ZA 3NdtKafqrNxtCfAb8Hs98HvVbktM22nLbYlPzod3W8pMLRVuS3LP2IrbEgAOAM56AM7q3JaK 94nN3JasHUaJ25KVa77bQm4HV26i1dwWFrLPgmkW8OM54Mcq3BYW0jAL3JZA/kH+Qf6fifwL t6WcCNtslm8whM1JZrRkW3cZkFkM40wztyWtNcttKWu6ym3J7O+93JZYgy24LQFYAVitBVgt 022pRLup+jYRG5kWfIpA3kDe1kLelulTVCVvtT9ZxG9b0iq53RMuqcElNQA7ALv7gB1cUgOp BKlcO6mES2ogkyCT6yeTa31JTfMn8iNNJ8g5FIlU26OIkMGlKLBHr55PkSha6VSUr75AYROZ Ht04FmlsdGLNVdnkyBXobGpiGusQq7VlrU0yWboYUabqrkay0nssR6IKgWDZJMySMvbqLkk6 ew3XpDrs1V2XdPYaLkx12Ku7OOnsNVyd5rPXhipHmrqvLidxoCVlDoQVhHVthXXFGh5paxmC 2paOB6IKorrWorpyxa+2wD5Z96S62lf+rVU7KIlcbX5YSSBqAxclczDu76NkK00tOCkBtgO2 ry22r95ziepN7bkuscm6Dr5LypxT6bwkNpoteS8BEgESrS0SrdKlqXBz2dSnydySlDo1mdkW 8WqwN34VFmLDr2Eh8zBYhgFbni22rMbdYRGVtdDfCaABoAGg4blDg3KFsoU7x+kCzlAipy32 pjuUyGTagpo6RGUt5jyiVPPVLlFGv+/pE0WbbMUpCsAMwGxdwWy5nlLFSlO1qxQdn1Z8pUAM QQzXVQyX60BVIYb38KDi/HMjLNzL03sN9/IADgEO4V4e7F1AWJ+hsMK9PBBVENVHI6rrfS9P eWSpTzoXemRlH482PLK0z0M/b48sa/TqeGSpohUeWUXV5zQ/lenRjWNe8+MTa47ml41cTvPT Jqa2PIlaW9X8MiZLVijOVL0VKqu08QqlqmCgoU/CLCljr94KZbLXaIWqx169Fcpkr9EKVY+9 eiuUyV6jFWoR9lav+bGm7qf5ZTjQiuYHwgrCusbCulLNj7W1DEFtR/MDUQVRXXNRXbHm10Bg n6hHVn3tK//WqjyyVK60/JtRMvOANJjieOy4WMxSLyRDE4QpYkPLKl6u75bA3tq+W/aw3dd3 K69erdx3C1YBWAXWeBVYte8W17Da8t0Sk/Xhfbc0w0+F75bakrbiuwVIBEi0xki0Ot+tkm1o M98te0tS4rtlZ5vvoJHfIlbYkjUHjQUNyWBDBmx5ttiyCgeNHKp8+biP3v/53UfWhFJxJVWH GMYZ83eI3Y63RRBjlMyiaOK7TpAi/bDTSqI6WjwLAj+4+B/0NVNw0Rbp4RYhWtVssRo6ke99 01EAxRoWLmSAUIBQgFCAUCZCCYeyvKjn+C6z1GW4RoBm4mML0RSxEstkrk4piim/NcWQjTW6 35rNtWlTNN3S9AottzSt9iq3NGv07uWWxptk2UA9BIB8rgCpC8B93dLK9MEqtzQ+Pi24pYEY ghiurxgu0y2tUgzv7ZbGe8GtzHBFUe81XFEEUARQhCuKsIMBYX2GwgpXFEFUQVQfjaiu9xVF NiZ6njnqiBgGWuo0DaPIDy6yliUFHeP0JoyvBtWVdUizdYvQxri2khAdIZ0m/PJcUf+4MZf5 wilLKqn85Qvy1wCNJw4Znb3uzt53RycnH3/Yf/fXV58+Hx8fHv/06sPno7PDd/unZ9+jKU5j 3yXqyjSdod7u9t7OyxfyomAY0ZsxyXC3S/5sf/fp53ennz+8OuP/8KfR4ce/7QoS+/19Vjzw dlUV/d53Hw8+/Xjy6cPx5/ev9j+fnYyODo//enTybv/o+4J+kAF6+YL8pfrhdvvf/fDpZP89 ZfvVyf67s8O/Hbw6Pfzw8ejg5/IOve528/3Z6ffenlvd+dvR/vHow9ln/uPPX872f/qJDpV4 5FlPT3ZefTk5Gn3Y/+nwncp5eqJ1GqeXOEbd7qC/M8B7g7fuoNcbdMclo/JWH5XDH98fnu7/ cHRQMECy9BR7vjNAB7QVet/JmaVhgieYLDhf97rdcyfBZz+j78azyWTTm0UTfPv9N1lpMqXS WTJA9MrTNS4YdjonX76gf6uB3zMGft6A9/tvu0WD0RvsOoP+7mB7Z+B2lzwYhwcHB4iw2en1 0Bc/JqORJMUjlP0uGJQgRK4Txz6OCwaGfySR/q0G5q0xMB8/nXw4PH3XcEbufSfnX24q7TiD nTEZtMH2m0F3d9DtLWv03EvUQ97UQZu9wg4zL2T2T8O5YHZ1MmH39naczs6443Y73U6v29l+ 09nt9DpOp98Zjztj3Ony/+7bx1x3xLpV54a1h89nF2jj7BKjcTiZhDcUxVWxBN3gGLMSvMpZ jL0B/8jGiAO0tAZ12aauyCAUzwJqVorCJHWnXiXOG795MXql0gk8xBaKXLskA1kfhyqRLfMB X4R49cmlP06F0c4d4ds0dvRrnowzvnpri/TGKLzGREo8LNsffiVqJbnDi9iZ8tK5bMJ4aDyN rvAdKeqRNhmj/CAyxvwhdunW2Z2EAZ5F/F96/rchOI58VQ35SQZQPcWhGzhTXLQ3YMPAq/8t l8h7SKrm8111jD3KZnmaMSTupefHWXb2uMHocRimegJ9pimB7+KMTp8odZZgrRr6RKkXcTiL MjJ7VPTESuBsCo5IvyQP9CdrlP5g7dAfvGr1q3A3ZewPaYc5kY/hH4ZFg0k0GZXMX6JOYe+4 OL9IJM9Wm3QwyQv+imWjP+kAkNmpEfkTo3N5Ugn8UQwMocsB423KaugoyJLaMJiZfzPklhXM dmwx/n1G1h9vdI7HIQEHJXti6z62BdkYZ6sOZ0yQJl8FUv4UZeggufNCP0UbJvsbGrCZKDJA NP8AFeTn41+QYJBYF6YetVhrN4tk5wi2RGiA+iwXFeTRLNK6JbTi0YQ62YizdhN8WJL4LTrw jgGCwNwxdo0qffRP+nBBFHeTHGEcs/EjzRDFPsYUKTRWuOOPJGZXFNi010wBbAuv2RULqlmm IYBtiMvNAJSbekYAWWFjE4CogGlGsrKMUclUPdVfZ6qR4r8YU/UUfp2pRur+YkzVU/N1phop +dVM5czmcnrXMJvLIsVmc9IQy1Gg2nPxUzDyB513TQKZAt2iCHLlqFwGGT/1hFBV2VgKZQ1s /FR1GreKs3qSaHDWSBQX56yeOBqcNZLHxTmrJ5MGZ42Eci5nq5dL2tI9BZMZtVoUTK6clwsm 46du/DZ8T8GUNYgAX7hrc6s4qxu6Dd9TMBfnrG7UNnxPwVycs3qCaXDWMF7bHM5WL5i0pXsL ph22eOWSCbEVG0koxFZsI7biasWVxiy+n7zSo6IWpZUdHpXLKuWmnqTKChvLqaiADZ2sLGNU MlVPPnWmGknnYkzVk0qdqUYyuRhT9WRRZ6qRJFYztXoZJA01kUDdmqZMtzx+AY91atrk3DC8 wh63XY3Gjk/NdESC6O1XNo6sPUrRDWOqIjFcLN2oXa+3yC5L6TQKwig7k8iYSu8izM7IOVf8 b3r8JZ5D6TFEM0oTm8g+NEM/CNOXKj3cKDq9JkMt7HShKE/zE4SSVo5FfRjN/PZlWGmeMP0X KUM2dlr2udVefwXrHFjnHtA6Vw80qzwSSQM6WOZ8ESXBPMWgAzRkC8xvJpDQFB0MlIFlUTSw CthwoMwiJh4wcJpnLlwtIoCxEIyF62YsXB5M0BYW/SquwAg2RKUgwZJ1pFAWn0WRwiqQ/8QT LkIKtoOZZ79cLVKA9RKsl+tmvVweUtAWaiIFG6JqpGB5TLgwv2sHn9sGuyrYVR/errpMIFnk IzU2ktCBWgBKtA9lCkCRhrNF4cTMb4OJtHiZUKLYKjf5rhZGwOALBt8HNPguDxxIAzWhgQ6O DgzUbEmfLEto1Sd1dcvsaH52OShFGWz+TNtvJROe4904vuKD2p/lbxp9QZhypbHZgCnrA10i zfw8lxohFYJpFsla9PBL9KKtP+6o7IXxObOiWWxOxFynR2GUFsUM15ix35gWHKoSi3Xszm7P AoIDggOCPy4EZ640+HfUE/xqSbSQgQVlvqHrGDWmgE37E4e0dEeW7igmWEOVbXCIXCCLEXeP dvwOJ0HIfd2Zv6CT4pEzmVjHjbKrzmSGh19V5Ra9ZRmPT+iDuMeftTaobA75CUpwitIQHZ90 9DVdWyH+oC0RxogW4b0deqfGUjEvao+2XpgxexZYMlqI1wPrBqwbD3nVY+lReOhVjwVj8Nx/ EbFFt63APSC1ILWtS+1Kw/EUbvsayV878XhAAkECH0QCVxxlp5kcyrXUjudNx5F73fJvrZQb ZER/wRQD0ADQ8IhMMbriLT5XAkIOQg5C/pSEXHxqxBZUi8eyr7I9ho8DN7K8qmaqWphvd82b XdkX8XJnZBTC4uxzw3JmqK9Z5k7GyrHxnsAIihEA4/MExhJNKGPZUH0YGvX6b1gsu97WHlKf lpUf0OZCXu972zlguO+3ti1wWP2XtgEjACMe8tBhJd/PJo219vVsOsQP/+lspZrxD2cXfTd7 Erb31WxAFUCVBzDJrupb2IX7j0W/hL2Ot1u6qo6CELjMCl1b5RHfi8oXyn0tSmR5dONijFF+ 06jzUrVrLBhb2DUCvgO+z8P3td01zpNM66wQxBPE8wmKZ/ksr3kwXiqo9un46nQ8dRfmMkxS 32PbvCqFT9P1hKjyLyvw4uifiD7hJLEHbr66BpfYADCeMGC0e4nNiF5vnDAxIMi0H8d1cZSO 4tTxrrXtOk+bpSGDlyplRztiLzqTy5qbcyIX3WoNaIoRp9vnYkQL6Ygk9kFgAiUugb0Um5xS Dy+Wrn82WP+SN+KlGHxyjwD+hQ3mneZLVoVio+4FWOClf3wcYAtg64nAlj6tiwHrZoGPefM8 xXalTA5FSUuwrkGwQLCenmBdzxWs6wUE63qeYF1rgmVsAcruyTCXbco0Vy2elZlTebLLtV64 rBsBQS2XdZFmuqyraKC6y7rIWeCyrrKXuaybEUnruKxbcRHnxDpd1PsQIqQmECG1IVMQIbWt CKlP1Vm9Es8fqeM4nb6643iG72R6eH7inE9w9nnOjGTd/WKAygbWLFWE4E1dzwuKVqwApuv5 AotAC67nsBLASvCQX7Jbuus5/ZLdQ7ieSyhoxWoPUgtS27rUrtRqb23k6rueK/lrx8MCJBAk 8EEkcMWu583k8Beyimqu59zPvNyeIjoHlhTAAcCBR2ZJKfA1B0EHQQdBf2qCLvzNbWG1+Cw7 O2M7AiJBdjAaOtA8GE1yF7gAIAAgACAAIAJAtAMLig6XcRiEs2REUGLi4yAL9aAOKopy6QcU fz84pU8FJxRFJbWTCVLQOJpgrLKT6tjteFuqhHYofkp/+sEFkolE6kjCgIwDmvjBFeqQP+gi TNnTyxcy24DXKx83MT0p2bwMwyt6ZHRNI8+jGz+9JKw4SRigj58ODo8Pz/QKTnHKWqaXjumH VNE4Dqd8xCmJdiiYTSaE25hkq2j61k/rtSxSbpxEpv6J9lfciE6dKxzo2Q9IA5TR0ma/FrV8 wxumKfTiQTpL6CugM+vTwf/7fHB6hkj1VOZI1/qvX3e0/1EUkley+4Zn33/3Vz4avTf9To8G ASAz7TycBR4tKoi9Tr+/hzY3SXcCfEMvNgRoZ7vf7ZLpQCa9l3B4Vbc0H0Mwla6qodjRbyd/ mcJy9JNAosU2wfYVCuULh6f1AyiYrd/XFc5azFfvawMLOizoD3l0thJXONJYawEU6BA/fAAF pS6Ue+TgaXsBFABVAFUe4GBhVQEUcNF5wpMPoFBvXyVuFucL5W4WiyyPblzg5hQANQD1EoB6 TW5OwRUoEL/nKH7tX4GqK3pw+wmE7wkL30PcfqoSwRohtpfl0G+oCct26BeVW8jSgkM/IAog StuIskyH/mI7R5VDPx2TFhz6QbBAsNoWrGU69FcIVnOHfso4P9IA0xuY3gDTANPA9AZbChC/ NRY/ML2B8IHwgemtcJOfxafybwJtK28FqJKJZoQqSs2HqJJ5C2JUZQXKglSZXNSKUsUqrwpT ZdW9aKgSq5i945fJltdE1lUN8RixNb8JxVkJ4jFu6kGeqrIx5ska2FxV1WncKs7q4Z7BWSPg W5yzeuBncNYI/RbnrB4CGpw1gsC5nK3OmYK20EqokkdnuHik0avYBF5C+CoOsovEr+I5mwWw KipbtTSY1qCFVocW7EGwRMASsW5LxPKNRLSlBwltpUCiFesSCDMI83oI80pNTsUbv2Zi2Y7l CQQTBHN9BHPF5qiG4lkYCKvCYiP6B7YagAiAiCdhqymIjwXyD/IP8v9M5F9EvcmJsM1mwYdX qv1ftdrWOaRIruOG76t6SVpQETaNiqOKcPSqGVbE4uC+cUVsBF19YBFAUUDRdUPR1UQboa21 Fm6EDfTDxxvJdm/lAUekaaeViCMANwA36wE3qwtDUrx1e/JxSOpuxoQ7REGxnD+EzPPoxgYO wQHGAcafwyE4nGaDVIJUfvtwp9m1JRIOskEmn5tMPshB9prFNDEVjmUHNZG125DTQlgTgBqA mrWAmmXGOrEhhVK7SqpFvBNF1KSO0XThXa3wKRbKpI/zU0/8skoby5+qwhw9g+WMvXoyaLLX SAjrsVdPEE32GkliPfbqSaPJXiNxXIQ9JpF5MSiWSz1ftXTqOVlbBRbPLMtwg+bx8DWHrY1C WeVZ6AILkgqS+kwl1RaC8vWT55q/hvJ8JTKqbWhl+dtIjtIAMbH9pbv59jf21x+/Mg5LjTUW 6RLOxF9u4U3XwFkaEonO3smi99TsErbRPBtG86Ya59E2A3Bqa3fVAHMAc9YXc1ZygS0HOF8+ 7ue/37YhqfqZaJeDjAyzYEm+FWchUwiMQAua2OuRFlTuglALWpGyWAs2CNUJtsCrr4q2UAWK VY61AI0AjQCNTxsaISzD4wnLwCf1EuIyCCheJDCDyNosMkNh4cpVxLyWsuBC0sLFFFhNYDV5 FKvJ8m+rsKYeJGZDBh+tXHMBGQcZX2MZX+ndlxIzXkNpbecKDMgryOuay+uK78U0ldrCCA9V ViLRRbAPAXoAejwr+5BuNmFm7djteFsEMUbJLIomvusEKTLs6af0wQ8ukJmJTHc/dNPJL6eH J+9+2uv2e71XKIzQ271XaIIDtN3/bYAOA8K47yHCyGyKqedhWZsD9GX/0/Hh8U8DNHZ8auJI Q8mHkZH1TZ0ZimgWgHWAdYB1gHUm1omwF3lRz/Fddr2YGUCI7AmJT+4CFxAHEAcQBxBniYij HV9RhLmMwyCcJSOCNBMf8x2PeWxVlEs/rvr7wSl9KjivKiqpnVORgp2KbaIqUbxBlMlEVuXP AS8tHzcxPR3bvAzDK3pMeB1ekY3ejZ9ekgadJAzQx08Hh8eHZ3oFR9i5prVfhkkaOFMseb3o bfb7ex3XSW8u/eQKx52QQq98fwPEtqfoa7o/3T/8cf/9+0/fFO1IS1m99dN6nIqUGyeRqX8i MwKJKB6pc4UDPfsBaYB2rLTZr0Ut3/CGaQq96pLOEvpi2OgPSAMpGoezwHv5AvMKO/ouO2uu dH+tz7NsZz3Hy+bxBH/KC6MRcCBDEi38Ewe84vhPYuWtGQDK5uK+EaBy6//qQ0DBHgD2AI9i D7CauFCsudYCQ/HhfvjIUJpWUh4aSoBRS7GhAIcAh9YYh1YXMCqnkQj/qaceMar+Dk7EjCoq mAsapTI9uvGBC3oA8gDyDwLya3NBD27agbCCsK7fTbv6ggqX7EBUQVQf7JLdmkWfslSXZYef UtUXRtcAAw5g0LPFIF0A7huVqsxio8Wk4pScGF6DGIIYPmcxvJ4rhtcLiOH1fDG81sRwoVXf DtnYgqhCyEYI2bg4ZysM2bhMqSz5/sVCQmluvw2jeHg13GAXN/C0yzrCz2fhKxIlxwHwFQlA P0A/+IoE7ElAKh+nVMJXJEAmQSbXTybX+isSWdzI8Q3WdAIrbKRMNKNGUqq8GJ4FjZR5C2JG ZgXKQkaaXNSKGMkqrwoYadW9aLgvq5itOMhky18t66oGhIzYmrea4qwEBhk39WBQVdkYBmUN bK6q6jRuFWf1YNDgrBEMLs5ZPRg0OGsEg4tzVg8GDc4aweBczlbnmEZbaCV016MzgDzSOJBs Ai8hDCQH2UWiQPKczYJAFpWtWhpMm9JCq0MLNiVYImCJWLclYvk2JdrSg4R6VCDRiikKhBmE eT2EeaWmqOKNXzOxbMceBYIJgrk+grlie1RD8SwM3lhhsRH9A1sNQARAxJOw1ejWABFeDOQf 5B/k/5nIv4galhNhm80yx/5SJ3+ttnWO0JTruOHer16SFp+JTaPi8EwcvWpGZ7I4uG9wJhtB Vx+bCVAUUHTdUHQ1YZhoa61FYWID/fBBmLLdW3kMJmnaaSUEE8ANwM16wM3qoi0Vb92efLCl upsx4VhRUCznWCHzPLqxgUNwgHGA8edwCA6n2SCVIJXfPtxpdm2JhINskMnnJpMPcpC9ZgGS TIVj2fGRZO025LQQHQmgBqBmLaBmmYGQSowpVXGQ2Mi0EFsF5A3kbS3kbZmxVarkrXbAo3xI FdYJfuIC5j8w/wHyAfLdB/nA/AdSCVK5dlIJ5j+QSZDJ9ZPJtTb/6XFV/EhTCnKBVUSqHVmF kItCq4jchbFVVJHy4CoGKzWjq9Dqq8OrmLUv7klvlstrECI9d2tfddjAREpt8d6+ZK4UEyk/ dUFRVnoPVBRVCEGSFeosZ+zVRUadvYbQWIe9uvCos9cQH+uwVxcjdfYaguR89lZ5mZ80AZFX nlTkFTqNlxJ6hYHvYrFXWNamwVcKCleuG7bpaaGloxXjE6wfsH48gvVjFRYp0tQDhWWR8NGS KQtkHGR8bWV8xfatws1iQ2lty8wF8gryutbyunLbVzOpLQniUm4XEl0EixCgB6DHE7cIFcZ3 AWgAaABoeO7QoEK/2MKd4/TpBn+xu245HMs3ZYR/8e0jOS3+ix81CQBjcnH/CDAWvrYRAgYw FjD2EWDsquLCkOZaDAxDh3sdIsOoXV9VaBhhR2opNgzgEODQ2uLQKgPGFO74nkHEmLo7OOU0 ki9Y4DUiMj268YHTewB5APkHAfm1Ob2HY3gQVhDW9TuGry+ocAIPogqi+mAn8GsXfcZQXZYf fkZUn8OiVgLQAAYBBq0rBi03Kk2xxaY6LA0dn1bi0oAYghiuqxguN1hNhRguK1oN7ww/DALz o95rMD8CNgI2gvkRNjIgrM9QWMH8CKIKovpoRHW9zY+FFkS6Ze/40W7Hc7yRusiVTDCOeCnt JxtUvZFSTUaMIM1/SkPh+MFFxrSkoGOc3oTx1aCsGhoVYfHMtAGu3LDoO9OEX4ktGo5uNhwq SgKp9uUL8tcAMePncK+78/a7zx9fHZ2cfPxh/91fX336fHx8ePzTqw+fj84O3+2fnn2PpjiN fZcoONN0hnq723s7L18g8SeM6J23ZLjbJX+2v/v087vTzx9enfF/+NPo8OPfdgWJ/f4+K84V r8GgJ6bNBJO32N9Ddo4x3uuSXP9NRyXLubuDEjeMsO+h7u1rqxCp502nS/7rIXnDr3s7HnfZ Hy1v4O2qXvR73308+PTjyacPx5/fv9r/fHYyOjo8/uvRybv9o+8LRpO8oJcvyF9qNPd2tulo /vDpZP89HTw1nKeHHz4eHfxcPqyvu938qO70e2/PrUH929H+8ejD2Wf+489fzvZ/+om2IB55 1tOTnVdfTo5GH/Z/Onyncp6eaEOP00sco2530N8Z4L3BW3fQ6w26Y3sQ3/Q7vTedXqdP3oo+ jnwk0XkcOp7rJCpn//Vr+n/ZAL/VB/jwx/eHp/s/HB0UjLUsPcWe7wzQAeWWMuTM0jDBE0wW 3K973e65k+Czn9F349lksunNogm+/f6brDSRkXSWDBCLToIL3iAVr5cv6N/ZO+z2v8te4LwX 1++/7RYNam+w6wz6u4PtnYHbXfJgHB4cHCDCZqfXQ1/8mIxGkhSPUPa7YFCCELlOHPs4LhgY HvOM/q0G5q0xMB8/nXw4PH3XcGbvfSfncW5K7jiDnTEZtMH2m0F3d9DtLWv03EvUQ97UQZu9 wg6zhY7903AumF2dTNj94h2nszPuuAyJup3tN51dIk1Op98ZjztjzBCK/HffPqrAPGeXGI3D ySS8ocuJFojnBseYvPIU8f7OYuwNkFzlxjygW+x2vC0/GvsTUoyvJQX032c+6TVO7gK3oPh5 7HsXmO5ttRVpxJckaS7rsl1vkcUsngXU7haFSepOvcqVzSxXXn+zOuMwTP/3ordJcG9AO4f+ C/3j/X/8B771ydbhxSkLi4e8kDQTBuhshtFfZhPU66Le28Hr7oAAYL/b67/4/8UaDivZeAMA --WlEyl6ow+jlIgNUh-- --2NLGdgz3UMHa/lqP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/87C0ACgkQmprOCmdXAD1QmACffYAAYgTbRAFD28/8JR7yzd6V WgkAn3a70wPw0iXLcljZZL27tUsAnD5O =ogtc -----END PGP SIGNATURE----- --2NLGdgz3UMHa/lqP-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:02:44 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BC08106566B for ; Wed, 11 Jul 2012 03:02:44 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4498FC0C for ; Wed, 11 Jul 2012 03:02:42 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q6B32I9g053299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 12:02:30 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q6B32Gqt091602; Wed, 11 Jul 2012 12:02:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 11 Jul 2012 12:01:01 +0900 (JST) Message-Id: <20120711.120101.584031014276205300.hrs@allbsd.org> To: david@catwhisker.org From: Hiroki Sato In-Reply-To: <20120711.110203.744611964086256554.hrs@allbsd.org> References: <20120709131957.GI1552@albert.catwhisker.org> <20120711.110203.744611964086256554.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Jul_11_12_01_01_2012_055)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Wed, 11 Jul 2012 12:02:30 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, 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 Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 03:02:44 -0000 ----Security_Multipart(Wed_Jul_11_12_01_01_2012_055)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20120711.110203.744611964086256554.hrs@allbsd.org>: hr> David Wolfskill wrote hr> in <20120709131957.GI1552@albert.catwhisker.org>: hr> hr> da> Just finished updating from r238227 to r238290 on the "head" slice of my hr> da> laptop, and was unable to make use of the wlan(4) NIC; I captured the hr> da> following via cut/paste from ttyv0: hr> (snip) hr> da> hr> da> I glanced through the list of commits to head in that range, but hr> da> didn't note anything glaringly obvious (yet). hr> da> hr> da> I hadn't tried a wired NIC on the laptop; I can, if there's anything hr> da> likely to be of value in doing so. hr> hr> Gr, it may be due to my change of r238279. I am investigating it. Committed a fix as r238361. Please try it. -- Hiroki ----Security_Multipart(Wed_Jul_11_12_01_01_2012_055)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/87G0ACgkQTyzT2CeTzy353QCfVieABW3ApJtE1zQWgaYHrAr0 gQIAn31vBTNeDFs9H4iUABX7q9Coralb =QFu+ -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Jul_11_12_01_01_2012_055)---- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:11:52 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE5F6106564A; Wed, 11 Jul 2012 03:11:52 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9671F8FC08; Wed, 11 Jul 2012 03:11:52 +0000 (UTC) Received: by obbun3 with SMTP id un3so1088219obb.13 for ; Tue, 10 Jul 2012 20:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tA5MqsarazyMp60wCwRzrp2grel7oSTZ5q0Q1OjxkvI=; b=0STeRgH89TdIOksCQ7ghxcWtE4PLGkedfwRSbSfkYdzhq9hx3qYoZsFilD4TmkTljY jWhEy/G9rwakJz6PVzHVlaYzllYEXLN8wY1ZlH7t9UxxCwNozGo9mpB35ZZ6cQ6MD+P3 QNEknnBoqFdSFrL9gMVldPaNeLgMDT4kZaAna5UuWZngW2ZvnXSE86K2Su42JpoNUayC 4pYz2sB/R2pxYIgdqIjFKo5p63ZQFarKOsUp9+DaRBqPKYjSm2K2lkrPvzGhN8vm+ybM naP24q+eurHSJmlm/P+z8X1NSEG23siHQwNAJ3Eqa5F88UHTU/fd0sNe20axWM0JVnvy zCqg== MIME-Version: 1.0 Received: by 10.60.18.114 with SMTP id v18mr48649977oed.34.1341976311962; Tue, 10 Jul 2012 20:11:51 -0700 (PDT) Received: by 10.60.61.38 with HTTP; Tue, 10 Jul 2012 20:11:51 -0700 (PDT) In-Reply-To: <20120711.110203.744611964086256554.hrs@allbsd.org> References: <20120709131957.GI1552@albert.catwhisker.org> <20120711.110203.744611964086256554.hrs@allbsd.org> Date: Tue, 10 Jul 2012 22:11:51 -0500 Message-ID: From: Brandon Gooch To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 03:11:53 -0000 On Tue, Jul 10, 2012 at 9:02 PM, Hiroki Sato wrote: > David Wolfskill wrote > in <20120709131957.GI1552@albert.catwhisker.org>: > > da> Just finished updating from r238227 to r238290 on the "head" slice of my > da> laptop, and was unable to make use of the wlan(4) NIC; I captured the > da> following via cut/paste from ttyv0: > (snip) > da> > da> I glanced through the list of commits to head in that range, but > da> didn't note anything glaringly obvious (yet). > da> > da> I hadn't tried a wired NIC on the laptop; I can, if there's anything > da> likely to be of value in doing so. > > Gr, it may be due to my change of r238279. I am investigating it. > > -- Hiroki The issue with wpa_supplicant failing is due to the wlan0 interface being cloned from one of the new usbus/usbpf devices instead of the actual wireless network device: brandon@m6500[/home/brandon] $ ifconfig -v wlan0 wlan0: flags=1 metric 0 mtu 0 nd6 options=29 groups: usbus How this might be happening is strange to me, how can the system be confused as to which interface to clone from? Off-by-one error somewhere? -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:20:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58BCC106566B; Wed, 11 Jul 2012 03:20:39 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 103ED8FC08; Wed, 11 Jul 2012 03:20:39 +0000 (UTC) Received: by obbun3 with SMTP id un3so1100095obb.13 for ; Tue, 10 Jul 2012 20:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4W0FuIkQ1XE2aNNPv6LJ8UUJ7DLtu2ZAfBNDOYtXonE=; b=f3OKOO7/GraDA6iaBr975T5AUX/xzgTaLMkIfPf66xb3ZAjd8a/L82Od4hw0VXgsIh IQf9DP2fhDG7mvsv03HTkr8Jt93wfVbLxsN65oUfOnVFn7y+0ZxGbwWee/ExjxNtubDA 61dFCWWcsG78vmhj0UAUxxhDBayUq19gI6ML2QWMq7Up6kwNftPbR7qcTDPiOpMZ+88/ qp62Zzb9w5HDZhvcKqa2JX1vkdoyE6rfYU3hTS2uLiK8o90KYdZD77Dj7zOq4fThlHI9 Qbi5nINCpTIeXWVL0GF5xid8dCKMpgw38LnRuAtBImNR3t64ApRLzmQQpn7zar1J+JAg cYfg== MIME-Version: 1.0 Received: by 10.182.2.233 with SMTP id 9mr42854395obx.11.1341976838530; Tue, 10 Jul 2012 20:20:38 -0700 (PDT) Received: by 10.76.84.7 with HTTP; Tue, 10 Jul 2012 20:20:38 -0700 (PDT) In-Reply-To: References: <20120709131957.GI1552@albert.catwhisker.org> <20120711.110203.744611964086256554.hrs@allbsd.org> Date: Tue, 10 Jul 2012 20:20:38 -0700 Message-ID: From: Garrett Cooper To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 03:20:39 -0000 On Tue, Jul 10, 2012 at 8:11 PM, Brandon Gooch wrote: > On Tue, Jul 10, 2012 at 9:02 PM, Hiroki Sato wrote: >> David Wolfskill wrote >> in <20120709131957.GI1552@albert.catwhisker.org>: >> >> da> Just finished updating from r238227 to r238290 on the "head" slice of my >> da> laptop, and was unable to make use of the wlan(4) NIC; I captured the >> da> following via cut/paste from ttyv0: >> (snip) >> da> >> da> I glanced through the list of commits to head in that range, but >> da> didn't note anything glaringly obvious (yet). >> da> >> da> I hadn't tried a wired NIC on the laptop; I can, if there's anything >> da> likely to be of value in doing so. >> >> Gr, it may be due to my change of r238279. I am investigating it. >> >> -- Hiroki > > The issue with wpa_supplicant failing is due to the wlan0 interface > being cloned from one of the new usbus/usbpf devices instead of the > actual wireless network device: > > brandon@m6500[/home/brandon] > $ ifconfig -v wlan0 > wlan0: flags=1 metric 0 mtu 0 > nd6 options=29 > groups: usbus > > How this might be happening is strange to me, how can the system be > confused as to which interface to clone from? Off-by-one error > somewhere? Hiroki just fixed it a little while ago. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:31:53 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DAE41065670; Wed, 11 Jul 2012 03:31:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0318FC14; Wed, 11 Jul 2012 03:31:53 +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 q6B3VqGM057188; Tue, 10 Jul 2012 23:31:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B3Vq6N057179; Wed, 11 Jul 2012 03:31:52 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 03:31:52 GMT Message-Id: <201207110331.q6B3Vq6N057179@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 03:31:53 -0000 TB --- 2012-07-11 00:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 00:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 00:40:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-11 00:40:01 - cleaning the object tree TB --- 2012-07-11 00:47:53 - cvsupping the source tree TB --- 2012-07-11 00:47:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-11 00:50:28 - building world TB --- 2012-07-11 00:50:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 00:50:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 00:50:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 00:50:28 - SRCCONF=/dev/null TB --- 2012-07-11 00:50:28 - TARGET=pc98 TB --- 2012-07-11 00:50:28 - TARGET_ARCH=i386 TB --- 2012-07-11 00:50:28 - TZ=UTC TB --- 2012-07-11 00:50:28 - __MAKE_CONF=/dev/null TB --- 2012-07-11 00:50:28 - cd /src TB --- 2012-07-11 00:50:28 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 00:50:29 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 03:23:14 UTC 2012 TB --- 2012-07-11 03:23:14 - generating LINT kernel config TB --- 2012-07-11 03:23:14 - cd /src/sys/pc98/conf TB --- 2012-07-11 03:23:14 - /usr/bin/make -B LINT TB --- 2012-07-11 03:23:14 - cd /src/sys/pc98/conf TB --- 2012-07-11 03:23:14 - /usr/sbin/config -m LINT TB --- 2012-07-11 03:23:14 - building LINT kernel TB --- 2012-07-11 03:23:14 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 03:23:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 03:23:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 03:23:14 - SRCCONF=/dev/null TB --- 2012-07-11 03:23:14 - TARGET=pc98 TB --- 2012-07-11 03:23:14 - TARGET_ARCH=i386 TB --- 2012-07-11 03:23:14 - TZ=UTC TB --- 2012-07-11 03:23:14 - __MAKE_CONF=/dev/null TB --- 2012-07-11 03:23:14 - cd /src TB --- 2012-07-11 03:23:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 03:23:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 03:31:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 03:31:52 - ERROR: failed to build LINT kernel TB --- 2012-07-11 03:31:52 - 6687.12 user 955.62 system 10311.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:33:10 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27951106566B; Wed, 11 Jul 2012 03:33:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E98868FC19; Wed, 11 Jul 2012 03:33:09 +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 q6B3X93X063288; Tue, 10 Jul 2012 23:33:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B3X4ZN063054; Wed, 11 Jul 2012 03:33:04 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 03:33:04 GMT Message-Id: <201207110333.q6B3X4ZN063054@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 03:33:10 -0000 TB --- 2012-07-11 00:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 00:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 00:40:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-11 00:40:01 - cleaning the object tree TB --- 2012-07-11 00:48:20 - cvsupping the source tree TB --- 2012-07-11 00:48:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-11 00:50:57 - building world TB --- 2012-07-11 00:50:57 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 00:50:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 00:50:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 00:50:57 - SRCCONF=/dev/null TB --- 2012-07-11 00:50:57 - TARGET=i386 TB --- 2012-07-11 00:50:57 - TARGET_ARCH=i386 TB --- 2012-07-11 00:50:57 - TZ=UTC TB --- 2012-07-11 00:50:57 - __MAKE_CONF=/dev/null TB --- 2012-07-11 00:50:57 - cd /src TB --- 2012-07-11 00:50:57 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 00:50:58 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 03:23:14 UTC 2012 TB --- 2012-07-11 03:23:14 - generating LINT kernel config TB --- 2012-07-11 03:23:14 - cd /src/sys/i386/conf TB --- 2012-07-11 03:23:14 - /usr/bin/make -B LINT TB --- 2012-07-11 03:23:14 - cd /src/sys/i386/conf TB --- 2012-07-11 03:23:14 - /usr/sbin/config -m LINT TB --- 2012-07-11 03:23:14 - building LINT kernel TB --- 2012-07-11 03:23:14 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 03:23:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 03:23:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 03:23:14 - SRCCONF=/dev/null TB --- 2012-07-11 03:23:14 - TARGET=i386 TB --- 2012-07-11 03:23:14 - TARGET_ARCH=i386 TB --- 2012-07-11 03:23:14 - TZ=UTC TB --- 2012-07-11 03:23:14 - __MAKE_CONF=/dev/null TB --- 2012-07-11 03:23:14 - cd /src TB --- 2012-07-11 03:23:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 03:23:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 03:33:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 03:33:04 - ERROR: failed to build LINT kernel TB --- 2012-07-11 03:33:04 - 6785.16 user 969.80 system 10383.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:34:48 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A387E106566B; Wed, 11 Jul 2012 03:34:48 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 585248FC1E; Wed, 11 Jul 2012 03:34:48 +0000 (UTC) Received: by obbun3 with SMTP id un3so1118064obb.13 for ; Tue, 10 Jul 2012 20:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZYZPoMWV9i2kqefwYv4sa7rdfzafiH+yL0rFp2ugljM=; b=J6xjGNK/wnmc1jqfrPwHaQOzUg565zRG/Hmu1zGhyYMF/Y7obNBrc8pO7aynpin5D6 nP/KSb0dTpHoKzcn68XgXbGAHeRlMGhjqQt5Z6zhYta2i+zsWEEl0cP44qhBuYgpK8SH JZ8BO8uSRR5x3SxuJWzoU9SydCMvibc1cwNOYqKIYIHgkltsNt4qrzD4VDR3bTyjHpn1 YCgWQK/epFJ2FQuDHCcxmBiuc0Ho0y2QfQIp5oStgrx37VSn7g04jvatsMxciNAehsXm 4JWUFO5e8khhv9XVPAnRxfBr/epjATyONhR22+7ykFBvfEW0AyHxIItfl4tHtvxRq084 dCbg== MIME-Version: 1.0 Received: by 10.182.78.228 with SMTP id e4mr40359793obx.77.1341977687822; Tue, 10 Jul 2012 20:34:47 -0700 (PDT) Received: by 10.60.61.38 with HTTP; Tue, 10 Jul 2012 20:34:47 -0700 (PDT) In-Reply-To: References: <20120709131957.GI1552@albert.catwhisker.org> <20120711.110203.744611964086256554.hrs@allbsd.org> Date: Tue, 10 Jul 2012 22:34:47 -0500 Message-ID: From: Brandon Gooch To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 03:34:49 -0000 On Tue, Jul 10, 2012 at 10:20 PM, Garrett Cooper wrote: > On Tue, Jul 10, 2012 at 8:11 PM, Brandon Gooch > wrote: >> On Tue, Jul 10, 2012 at 9:02 PM, Hiroki Sato wrote: >>> David Wolfskill wrote >>> in <20120709131957.GI1552@albert.catwhisker.org>: >>> >>> da> Just finished updating from r238227 to r238290 on the "head" slice of my >>> da> laptop, and was unable to make use of the wlan(4) NIC; I captured the >>> da> following via cut/paste from ttyv0: >>> (snip) >>> da> >>> da> I glanced through the list of commits to head in that range, but >>> da> didn't note anything glaringly obvious (yet). >>> da> >>> da> I hadn't tried a wired NIC on the laptop; I can, if there's anything >>> da> likely to be of value in doing so. >>> >>> Gr, it may be due to my change of r238279. I am investigating it. >>> >>> -- Hiroki >> >> The issue with wpa_supplicant failing is due to the wlan0 interface >> being cloned from one of the new usbus/usbpf devices instead of the >> actual wireless network device: >> >> brandon@m6500[/home/brandon] >> $ ifconfig -v wlan0 >> wlan0: flags=1 metric 0 mtu 0 >> nd6 options=29 >> groups: usbus >> >> How this might be happening is strange to me, how can the system be >> confused as to which interface to clone from? Off-by-one error >> somewhere? > > Hiroki just fixed it a little while ago. > -Garrett Thanks for the heads up, I kept dropping offline to debug, then when I had something to report, I find that a fix had been committed -- now that's service! Thanks Hiroki! -Brandon From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:41:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 928DF1065672 for ; Wed, 11 Jul 2012 03:41:23 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm1-vm3.bullet.mail.ne1.yahoo.com (nm1-vm3.bullet.mail.ne1.yahoo.com [98.138.91.131]) by mx1.freebsd.org (Postfix) with SMTP id 4339E8FC15 for ; Wed, 11 Jul 2012 03:41:23 +0000 (UTC) Received: from [98.138.90.52] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jul 2012 03:41:16 -0000 Received: from [98.138.84.43] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jul 2012 03:41:16 -0000 Received: from [127.0.0.1] by smtp111.mail.ne1.yahoo.com with NNFMP; 11 Jul 2012 03:41:16 -0000 X-Yahoo-Newman-Id: 896110.9807.bm@smtp111.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6xAeQBUVM1k7TLGb.GiywUa6.4ZPdnmwpEdQDn02C9blPxH J8zfrHoxENGUc6RJ_9k1NIhp4LBM7O7e9a63vpCzUkpYOTe98TFT2pPHgD1e Rt829eGYqBXT1kWJKNNF6l4nOrsziWTCdAiIA_fd_VR7S7M.cxINZKvPZkL3 v7uzEJYuSnvv91qbSrom.akxswy.LSt1qVXu2DZiJdkrsM7rC_x6mdcdsRbV kGYYigcef83TNy2q9LdI0mYySxjRymx7NybdsR6V0syDqAVk95gMnU_8NdzZ nldhpChrR4LowgTrEsxKVZzJfPxbrUmRb4O8zrzuaMe2jjrCYJnZpwoxkjtN b1QktYes6G18t23uvQyM5gTp045OUTqCJnsHozNory6hUJYng4FiWayV5_HX VbzFW6EQHGNkADodvlBqvX.5pOwpNK02vyY7XsX9rZ_JikA.zuDpyJt3c0uh 8XG8.wHvrfyryohkYJ1sOjGi9o2SHyENpNNXfO3GlFv_EWEu70AeEKSxiEHY 25oCw1wd74Kqk X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.101] (pfg@200.118.157.7 with plain) by smtp111.mail.ne1.yahoo.com with SMTP; 10 Jul 2012 20:41:16 -0700 PDT Message-ID: <4FFCF5F8.6060104@FreeBSD.org> Date: Tue, 10 Jul 2012 22:41:44 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120618 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [CFT] Add -Wbounded to gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 03:41:23 -0000 Hello; I have a patch from OpenBSD that adds -Wbounded to gcc: http://people.freebsd.org/~pfg/patches/patch-gcc-bounded Unfortunately it breaks world, or at least binutils, at this time: _________ ... cc1: warnings being treated as errors peigen.c: In function '_bfd_pei_swap_aux_in': peigen.c:241: warning: array size (14) smaller than bound length (18) peigen.c:241: warning: array size (14) smaller than bound length (18) peigen.c: In function '_bfd_pei_swap_aux_out': peigen.c:314: warning: array size (14) smaller than bound length (18) peigen.c:314: warning: array size (14) smaller than bound length (18) *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. ___________ OpenBSD has a fix but before attempting to clean this, and whatever else would break, I can't help but ask: is it worth it? best regards, Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 03:43:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4A9B1065670; Wed, 11 Jul 2012 03:43:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 753138FC0C; Wed, 11 Jul 2012 03:43:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6B3hYcX047882; Tue, 10 Jul 2012 23:43:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B3hYYM047874; Wed, 11 Jul 2012 03:43:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 03:43:34 GMT Message-Id: <201207110343.q6B3hYYM047874@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 03:43:35 -0000 TB --- 2012-07-11 01:56:48 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 01:56:48 - 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 --- 2012-07-11 01:56:48 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-11 01:56:48 - cleaning the object tree TB --- 2012-07-11 01:57:35 - cvsupping the source tree TB --- 2012-07-11 01:57:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-11 01:58:03 - building world TB --- 2012-07-11 01:58:03 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 01:58:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 01:58:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 01:58:03 - SRCCONF=/dev/null TB --- 2012-07-11 01:58:03 - TARGET=ia64 TB --- 2012-07-11 01:58:03 - TARGET_ARCH=ia64 TB --- 2012-07-11 01:58:03 - TZ=UTC TB --- 2012-07-11 01:58:03 - __MAKE_CONF=/dev/null TB --- 2012-07-11 01:58:03 - cd /src TB --- 2012-07-11 01:58:03 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 01:58:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 03:37:40 UTC 2012 TB --- 2012-07-11 03:37:40 - generating LINT kernel config TB --- 2012-07-11 03:37:40 - cd /src/sys/ia64/conf TB --- 2012-07-11 03:37:40 - /usr/bin/make -B LINT TB --- 2012-07-11 03:37:40 - cd /src/sys/ia64/conf TB --- 2012-07-11 03:37:40 - /usr/sbin/config -m LINT TB --- 2012-07-11 03:37:40 - building LINT kernel TB --- 2012-07-11 03:37:40 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 03:37:40 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 03:37:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 03:37:40 - SRCCONF=/dev/null TB --- 2012-07-11 03:37:40 - TARGET=ia64 TB --- 2012-07-11 03:37:40 - TARGET_ARCH=ia64 TB --- 2012-07-11 03:37:40 - TZ=UTC TB --- 2012-07-11 03:37:40 - __MAKE_CONF=/dev/null TB --- 2012-07-11 03:37:40 - cd /src TB --- 2012-07-11 03:37:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 03:37:40 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 03:43:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 03:43:34 - ERROR: failed to build LINT kernel TB --- 2012-07-11 03:43:34 - 4505.49 user 687.84 system 6406.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 04:07:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19CA1106564A; Wed, 11 Jul 2012 04:07:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DBEBB8FC08; Wed, 11 Jul 2012 04:07: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 q6B47k2V066594; Wed, 11 Jul 2012 00:07:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B47kd6066579; Wed, 11 Jul 2012 04:07:46 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 04:07:46 GMT Message-Id: <201207110407.q6B47kd6066579@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 04:07:47 -0000 TB --- 2012-07-11 00:40:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 00:40:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 00:40:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-11 00:40:01 - cleaning the object tree TB --- 2012-07-11 00:51:51 - cvsupping the source tree TB --- 2012-07-11 00:51:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-11 00:52:51 - building world TB --- 2012-07-11 00:52:51 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 00:52:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 00:52:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 00:52:51 - SRCCONF=/dev/null TB --- 2012-07-11 00:52:51 - TARGET=amd64 TB --- 2012-07-11 00:52:51 - TARGET_ARCH=amd64 TB --- 2012-07-11 00:52:51 - TZ=UTC TB --- 2012-07-11 00:52:51 - __MAKE_CONF=/dev/null TB --- 2012-07-11 00:52:51 - cd /src TB --- 2012-07-11 00:52:51 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 00:52:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 11 04:00:10 UTC 2012 TB --- 2012-07-11 04:00:10 - generating LINT kernel config TB --- 2012-07-11 04:00:10 - cd /src/sys/amd64/conf TB --- 2012-07-11 04:00:10 - /usr/bin/make -B LINT TB --- 2012-07-11 04:00:10 - cd /src/sys/amd64/conf TB --- 2012-07-11 04:00:10 - /usr/sbin/config -m LINT TB --- 2012-07-11 04:00:11 - building LINT kernel TB --- 2012-07-11 04:00:11 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 04:00:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 04:00:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 04:00:11 - SRCCONF=/dev/null TB --- 2012-07-11 04:00:11 - TARGET=amd64 TB --- 2012-07-11 04:00:11 - TARGET_ARCH=amd64 TB --- 2012-07-11 04:00:11 - TZ=UTC TB --- 2012-07-11 04:00:11 - __MAKE_CONF=/dev/null TB --- 2012-07-11 04:00:11 - cd /src TB --- 2012-07-11 04:00:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 04:00:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 04:07:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 04:07:46 - ERROR: failed to build LINT kernel TB --- 2012-07-11 04:07:46 - 8170.88 user 1279.30 system 12465.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 04:11:02 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C038D106564A; Wed, 11 Jul 2012 04:11:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 767998FC1B; Wed, 11 Jul 2012 04:11:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6B4B28s003524; Tue, 10 Jul 2012 21:11:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6B4B2e8003523; Tue, 10 Jul 2012 21:11:02 -0700 (PDT) (envelope-from david) Date: Tue, 10 Jul 2012 21:11:01 -0700 From: David Wolfskill To: Hiroki Sato Message-ID: <20120711041101.GF1898@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Hiroki Sato , current@FreeBSD.org References: <20120709131957.GI1552@albert.catwhisker.org> <20120711.110203.744611964086256554.hrs@allbsd.org> <20120711.120101.584031014276205300.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YrlhzR9YrZtruaFS" Content-Disposition: inline In-Reply-To: <20120711.120101.584031014276205300.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: "ifconfig create" breaks between r238227 - r238290? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 04:11:02 -0000 --YrlhzR9YrZtruaFS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2012 at 12:01:01PM +0900, Hiroki Sato wrote: > ... > hr> Gr, it may be due to my change of r238279. I am investigating it. >=20 > Committed a fix as r238361. Please try it. And we have a winner! Thank you! :-) [Sorry for the delay; I had already updated my sources to r238345 early this morning. But that wouldn't build the kernel, so I needed to also apply r238349 & r238350, But it did finally work.] Ref.: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #616 238345= M: Tue Jul 10 20:31:44 PDT 2012 root@g1-228.catwhisker.org:/usr/obj/usr= /src/sys/CANARY i386 and=20 g1-227(10.0-C)[1] ifconfig wlan0 wlan0: flags=3D8843 metric 0 mtu 15= 00 ether 00:21:6a:26:34:c0 inet 172.17.1.227 netmask 0xffff0000 broadcast 172.17.255.255=20 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11g status: associated ssid lmdhw-net channel 11 (2462 MHz 11g) bssid 08:10:75:08:8c:1c country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 15 bmiss 10 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL g1-227(10.0-C)[2]=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --YrlhzR9YrZtruaFS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/8/NQACgkQmprOCmdXAD2y9ACdF38p86G8RxGNmf5FHg7XFO0R YWAAn3+XToLyZ8wjhXESDk19rSlM9qix =T/TG -----END PGP SIGNATURE----- --YrlhzR9YrZtruaFS-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 04:16:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DE59106566C; Wed, 11 Jul 2012 04:16:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCEC8FC08; Wed, 11 Jul 2012 04:16:41 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6B4GYtx003707; Tue, 10 Jul 2012 21:16:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6B4GYZ9003706; Tue, 10 Jul 2012 21:16:34 -0700 (PDT) (envelope-from sgk) Date: Tue, 10 Jul 2012 21:16:34 -0700 From: Steve Kargl To: Pedro Giffuni Message-ID: <20120711041634.GA3697@troutmask.apl.washington.edu> References: <4FFCF5F8.6060104@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFCF5F8.6060104@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: [CFT] Add -Wbounded to gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 04:16:41 -0000 On Tue, Jul 10, 2012 at 10:41:44PM -0500, Pedro Giffuni wrote: > > I have a patch from OpenBSD that adds -Wbounded to gcc: > > http://people.freebsd.org/~pfg/patches/patch-gcc-bounded > > Unfortunately it breaks world, or at least binutils, at this time: > > _________ > ... > cc1: warnings being treated as errors > peigen.c: In function '_bfd_pei_swap_aux_in': > peigen.c:241: warning: array size (14) smaller than bound length (18) > peigen.c:241: warning: array size (14) smaller than bound length (18) > peigen.c: In function '_bfd_pei_swap_aux_out': > peigen.c:314: warning: array size (14) smaller than bound length (18) > peigen.c:314: warning: array size (14) smaller than bound length (18) > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/binutils/libbfd. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/binutils. > ___________ > > OpenBSD has a fix but before attempting to clean this, and whatever > else would break, I can't help but ask: is it worth it? > IMHO, no. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 05:23:51 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B1021065670; Wed, 11 Jul 2012 05:23:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 25F858FC17; Wed, 11 Jul 2012 05:23:51 +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 q6B5Nib4047017; Wed, 11 Jul 2012 01:23:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B5NiJD047004; Wed, 11 Jul 2012 05:23:44 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 05:23:44 GMT Message-Id: <201207110523.q6B5NiJD047004@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 05:23:51 -0000 TB --- 2012-07-11 04:07:46 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 04: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 --- 2012-07-11 04:07:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-11 04:07:46 - cleaning the object tree TB --- 2012-07-11 04:09:28 - cvsupping the source tree TB --- 2012-07-11 04:09:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-11 04:10:38 - building world TB --- 2012-07-11 04:10:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 04:10:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 04:10:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 04:10:38 - SRCCONF=/dev/null TB --- 2012-07-11 04:10:38 - TARGET=sparc64 TB --- 2012-07-11 04:10:38 - TARGET_ARCH=sparc64 TB --- 2012-07-11 04:10:38 - TZ=UTC TB --- 2012-07-11 04:10:38 - __MAKE_CONF=/dev/null TB --- 2012-07-11 04:10:38 - cd /src TB --- 2012-07-11 04:10:38 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 04:10:39 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 05:18:29 UTC 2012 TB --- 2012-07-11 05:18:29 - generating LINT kernel config TB --- 2012-07-11 05:18:29 - cd /src/sys/sparc64/conf TB --- 2012-07-11 05:18:29 - /usr/bin/make -B LINT TB --- 2012-07-11 05:18:29 - cd /src/sys/sparc64/conf TB --- 2012-07-11 05:18:29 - /usr/sbin/config -m LINT TB --- 2012-07-11 05:18:29 - building LINT kernel TB --- 2012-07-11 05:18:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 05:18:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 05:18:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 05:18:29 - SRCCONF=/dev/null TB --- 2012-07-11 05:18:29 - TARGET=sparc64 TB --- 2012-07-11 05:18:29 - TARGET_ARCH=sparc64 TB --- 2012-07-11 05:18:29 - TZ=UTC TB --- 2012-07-11 05:18:29 - __MAKE_CONF=/dev/null TB --- 2012-07-11 05:18:29 - cd /src TB --- 2012-07-11 05:18:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 05:18:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 05:23:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 05:23:44 - ERROR: failed to build LINT kernel TB --- 2012-07-11 05:23:44 - 3187.68 user 589.09 system 4557.54 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 05:54:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C9FB106566C; Wed, 11 Jul 2012 05:54:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 34A4F8FC0A; Wed, 11 Jul 2012 05:54:56 +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 q6B5st8B082732; Wed, 11 Jul 2012 01:54:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B5strC082727; Wed, 11 Jul 2012 05:54:55 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 05:54:55 GMT Message-Id: <201207110554.q6B5strC082727@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 05:54:56 -0000 TB --- 2012-07-11 03:33:09 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 03:33: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 --- 2012-07-11 03:33:09 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-11 03:33:09 - cleaning the object tree TB --- 2012-07-11 03:34:41 - cvsupping the source tree TB --- 2012-07-11 03:34:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-11 03:35:32 - building world TB --- 2012-07-11 03:35:32 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 03:35:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 03:35:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 03:35:32 - SRCCONF=/dev/null TB --- 2012-07-11 03:35:32 - TARGET=powerpc TB --- 2012-07-11 03:35:32 - TARGET_ARCH=powerpc TB --- 2012-07-11 03:35:32 - TZ=UTC TB --- 2012-07-11 03:35:32 - __MAKE_CONF=/dev/null TB --- 2012-07-11 03:35:32 - cd /src TB --- 2012-07-11 03:35:32 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 03:35:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 05:51:24 UTC 2012 TB --- 2012-07-11 05:51:24 - generating LINT kernel config TB --- 2012-07-11 05:51:24 - cd /src/sys/powerpc/conf TB --- 2012-07-11 05:51:24 - /usr/bin/make -B LINT TB --- 2012-07-11 05:51:24 - cd /src/sys/powerpc/conf TB --- 2012-07-11 05:51:24 - /usr/sbin/config -m LINT TB --- 2012-07-11 05:51:24 - building LINT kernel TB --- 2012-07-11 05:51:24 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 05:51:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 05:51:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 05:51:24 - SRCCONF=/dev/null TB --- 2012-07-11 05:51:24 - TARGET=powerpc TB --- 2012-07-11 05:51:24 - TARGET_ARCH=powerpc TB --- 2012-07-11 05:51:24 - TZ=UTC TB --- 2012-07-11 05:51:24 - __MAKE_CONF=/dev/null TB --- 2012-07-11 05:51:24 - cd /src TB --- 2012-07-11 05:51:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 05:51:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 05:54:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 05:54:55 - ERROR: failed to build LINT kernel TB --- 2012-07-11 05:54:55 - 6789.82 user 904.02 system 8505.89 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 06:31:24 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C495106566C; Wed, 11 Jul 2012 06:31:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 65B0C8FC18; Wed, 11 Jul 2012 06:31: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 q6B6VNV8079465; Wed, 11 Jul 2012 02:31:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B6VNHV079464; Wed, 11 Jul 2012 06:31:23 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 06:31:23 GMT Message-Id: <201207110631.q6B6VNHV079464@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 06:31:24 -0000 TB --- 2012-07-11 03:43:35 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 03:43:35 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 03:43:35 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-11 03:43:35 - cleaning the object tree TB --- 2012-07-11 03:45:20 - cvsupping the source tree TB --- 2012-07-11 03:45:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-11 03:45:51 - building world TB --- 2012-07-11 03:45:51 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 03:45:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 03:45:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 03:45:51 - SRCCONF=/dev/null TB --- 2012-07-11 03:45:51 - TARGET=powerpc TB --- 2012-07-11 03:45:51 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 03:45:51 - TZ=UTC TB --- 2012-07-11 03:45:51 - __MAKE_CONF=/dev/null TB --- 2012-07-11 03:45:51 - cd /src TB --- 2012-07-11 03:45:51 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 03:45:52 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 11 06:27:55 UTC 2012 TB --- 2012-07-11 06:27:55 - generating LINT kernel config TB --- 2012-07-11 06:27:55 - cd /src/sys/powerpc/conf TB --- 2012-07-11 06:27:55 - /usr/bin/make -B LINT TB --- 2012-07-11 06:27:55 - cd /src/sys/powerpc/conf TB --- 2012-07-11 06:27:55 - /usr/sbin/config -m LINT TB --- 2012-07-11 06:27:55 - building LINT kernel TB --- 2012-07-11 06:27:55 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 06:27:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 06:27:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 06:27:55 - SRCCONF=/dev/null TB --- 2012-07-11 06:27:55 - TARGET=powerpc TB --- 2012-07-11 06:27:55 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 06:27:55 - TZ=UTC TB --- 2012-07-11 06:27:55 - __MAKE_CONF=/dev/null TB --- 2012-07-11 06:27:55 - cd /src TB --- 2012-07-11 06:27:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 06:27:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 06:31:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 06:31:23 - ERROR: failed to build LINT kernel TB --- 2012-07-11 06:31:23 - 8272.30 user 1142.11 system 10068.31 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 07:39:01 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACBC7106566B; Wed, 11 Jul 2012 07:39:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 62AE88FC15; Wed, 11 Jul 2012 07:39:01 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 45DB15C37; Wed, 11 Jul 2012 09:39:00 +0200 (CEST) Message-ID: <4FFD2D94.9040805@FreeBSD.org> Date: Wed, 11 Jul 2012 09:39:00 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: Pedro Giffuni References: <4FFCF5F8.6060104@FreeBSD.org> In-Reply-To: <4FFCF5F8.6060104@FreeBSD.org> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] Add -Wbounded to gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 07:39:01 -0000 On 2012-07-11 05:41, Pedro Giffuni wrote: > I have a patch from OpenBSD that adds -Wbounded to gcc: > > http://people.freebsd.org/~pfg/patches/patch-gcc-bounded > > Unfortunately it breaks world, or at least binutils, at this time: > > _________ > ... > cc1: warnings being treated as errors > peigen.c: In function '_bfd_pei_swap_aux_in': > peigen.c:241: warning: array size (14) smaller than bound length (18) > peigen.c:241: warning: array size (14) smaller than bound length (18) > peigen.c: In function '_bfd_pei_swap_aux_out': > peigen.c:314: warning: array size (14) smaller than bound length (18) > peigen.c:314: warning: array size (14) smaller than bound length (18) > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/binutils/libbfd. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/binutils. > ___________ > > OpenBSD has a fix but before attempting to clean this, and whatever > else would break, I can't help but ask: is it worth it? Does it catch any really interesting bound overruns? If the number of false positives is very large, then it generally isn't worth the pain. Or the option should be turned off by default, and only enabled for WARNS=some_arbitrary_high_number. That said, fixing binutils (and particularly libbfd, which is what you are seeing here) is rather hopeless, it should be compiled with a low WARNS= setting anyway. :) From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 08:02:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E3161065672; Wed, 11 Jul 2012 08:02:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DE5C98FC1E; Wed, 11 Jul 2012 08:02:39 +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 q6B82deH069617; Wed, 11 Jul 2012 04:02:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B82d2r069616; Wed, 11 Jul 2012 08:02:39 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 08:02:39 GMT Message-Id: <201207110802.q6B82d2r069616@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 08:02:40 -0000 TB --- 2012-07-11 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 06:40:00 - 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 --- 2012-07-11 06:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-11 06:40:00 - cleaning the object tree TB --- 2012-07-11 06:45:06 - cvsupping the source tree TB --- 2012-07-11 06:45:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-11 06:46:53 - building world TB --- 2012-07-11 06:46:53 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 06:46:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 06:46:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 06:46:53 - SRCCONF=/dev/null TB --- 2012-07-11 06:46:53 - TARGET=arm TB --- 2012-07-11 06:46:53 - TARGET_ARCH=arm TB --- 2012-07-11 06:46:53 - TZ=UTC TB --- 2012-07-11 06:46:53 - __MAKE_CONF=/dev/null TB --- 2012-07-11 06:46:53 - cd /src TB --- 2012-07-11 06:46:53 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 06:46:54 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 07:58:28 UTC 2012 TB --- 2012-07-11 07:58:28 - cd /src/sys/arm/conf TB --- 2012-07-11 07:58:28 - /usr/sbin/config -m ATMEL TB --- 2012-07-11 07:58:28 - building ATMEL kernel TB --- 2012-07-11 07:58:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 07:58:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 07:58:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 07:58:28 - SRCCONF=/dev/null TB --- 2012-07-11 07:58:28 - TARGET=arm TB --- 2012-07-11 07:58:28 - TARGET_ARCH=arm TB --- 2012-07-11 07:58:28 - TZ=UTC TB --- 2012-07-11 07:58:28 - __MAKE_CONF=/dev/null TB --- 2012-07-11 07:58:28 - cd /src TB --- 2012-07-11 07:58:28 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Jul 11 07:58:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Wed Jul 11 08:02:00 UTC 2012 TB --- 2012-07-11 08:02:00 - cd /src/sys/arm/conf TB --- 2012-07-11 08:02:00 - /usr/sbin/config -m AVILA TB --- 2012-07-11 08:02:00 - building AVILA kernel TB --- 2012-07-11 08:02:00 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 08:02:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 08:02:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 08:02:00 - SRCCONF=/dev/null TB --- 2012-07-11 08:02:00 - TARGET=arm TB --- 2012-07-11 08:02:00 - TARGET_ARCH=arm TB --- 2012-07-11 08:02:00 - TZ=UTC TB --- 2012-07-11 08:02:00 - __MAKE_CONF=/dev/null TB --- 2012-07-11 08:02:00 - cd /src TB --- 2012-07-11 08:02:00 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Jul 11 08:02:00 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_reinit_fifo': /src/sys/dev/ath/if_ath_rx_edma.c:193: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'bus_addr_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 08:02:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 08:02:38 - ERROR: failed to build AVILA kernel TB --- 2012-07-11 08:02:38 - 2643.38 user 591.77 system 4958.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 08:03:12 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61B9B1065688 for ; Wed, 11 Jul 2012 08:03:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DDE288FC0A for ; Wed, 11 Jul 2012 08:03:11 +0000 (UTC) Received: by weyx56 with SMTP id x56so691068wey.13 for ; Wed, 11 Jul 2012 01:03:10 -0700 (PDT) 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=z9hDXMd337TFNekRcurOq6RYK/FJM1xP59cGBtPZpew=; b=rddFylxqvfxuBneGcF/B4am5pvv2dZs061iWK1FyhV9Tz/RI7Zfdmc+g9eMOb8l0bt ATH4/9jfO7CTxfo1xd9HdlvBTnuc77/x/YFsa8t2d/2/459xAAFIJ8KGmMfQe1K2J7ZO XZ8O56Cx5COhknjstu3b3G4+MAkEueXEszDPg3lsBZBO2jRg//lO2u3DJvqphdidxbFD cZxafvJRMreR8ym79vQSNP1ZV5sCcIvPG4CxvesvannYVx2shV8dqoGd9Lwjs9cX5G1G EO5aHYDARpRS28aSRJsL1E/5h8j1n63ok6VuWj0HcYcTBvVsRDki2iTkQl24kKHcEyeP qvvQ== Received: by 10.216.116.73 with SMTP id f51mr691387weh.50.1341993790881; Wed, 11 Jul 2012 01:03:10 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id b7sm3231775wiz.9.2012.07.11.01.03.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 01:03:10 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FFD3338.7030500@FreeBSD.org> Date: Wed, 11 Jul 2012 11:03:04 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Anton Shterenlikht References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> <20120709233857.GA12046@troutmask.apl.washington.edu> <20120710214138.GA1025@mech-aslap239.men.bris.ac.uk> <20120710223531.GA96724@troutmask.apl.washington.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-current@freebsd.org, Steve Kargl Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 08:03:12 -0000 On 11.07.2012 02:00, Garrett Cooper wrote: > On Tue, Jul 10, 2012 at 3:35 PM, Steve Kargl > wrote: >> On Tue, Jul 10, 2012 at 10:41:38PM +0100, Anton Shterenlikht wrote: >>> I do have all this in the kernel, see below. >>> Still if I don't have device ata, I get no cd: >>> >> >> Well, then, leave 'device ata' in your config file. >> >> Groucho: Doctor, it hurts when I do this. >> yada yada > > The UPDATING directions don't say this is required, so mav@ might > want to know (CCed). The UPDATING record tells nothing about removing `device ata`. `options ATA_CAM` only trims it from full ATA infrastructure to a CAM driver for legacy ATA controllers not supported by the new, more advanced drivers ahci(4), mvs(4) and siis(4). ata(4) man page was updated respectively. It is not mandatory any more. You would be free to remove `device ata` from your kernel if you had no such hardware, but obviously you have it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 08:51:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76B24106566C; Wed, 11 Jul 2012 08:51:45 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 224298FC0C; Wed, 11 Jul 2012 08:51:45 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Sose8-0000ss-7T; Wed, 11 Jul 2012 09:51:44 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Sose7-0003vu-Sk; Wed, 11 Jul 2012 09:51:43 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6B8pheI062590; Wed, 11 Jul 2012 09:51:43 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q6B8phd6062589; Wed, 11 Jul 2012 09:51:43 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Wed, 11 Jul 2012 09:51:43 +0100 From: Anton Shterenlikht To: Alexander Motin Message-ID: <20120711085143.GA62552@mech-cluster241.men.bris.ac.uk> Mail-Followup-To: Alexander Motin , Anton Shterenlikht , Garrett Cooper , Steve Kargl , freebsd-current@freebsd.org References: <20120709225210.GA1021@mech-aslap239.men.bris.ac.uk> <20120709233857.GA12046@troutmask.apl.washington.edu> <20120710214138.GA1025@mech-aslap239.men.bris.ac.uk> <20120710223531.GA96724@troutmask.apl.washington.edu> <4FFD3338.7030500@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFD3338.7030500@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Garrett Cooper , freebsd-current@freebsd.org, Anton Shterenlikht , Steve Kargl Subject: Re: ada,ata and cd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 08:51:45 -0000 On Wed, Jul 11, 2012 at 11:03:04AM +0300, Alexander Motin wrote: > On 11.07.2012 02:00, Garrett Cooper wrote: > >On Tue, Jul 10, 2012 at 3:35 PM, Steve Kargl > > wrote: > >>On Tue, Jul 10, 2012 at 10:41:38PM +0100, Anton Shterenlikht wrote: > >>>I do have all this in the kernel, see below. > >>>Still if I don't have device ata, I get no cd: > >>> > >> > >>Well, then, leave 'device ata' in your config file. > >> > >>Groucho: Doctor, it hurts when I do this. > >>yada yada > > > > The UPDATING directions don't say this is required, so mav@ might > >want to know (CCed). > > The UPDATING record tells nothing about removing `device ata`. `options > ATA_CAM` only trims it from full ATA infrastructure to a CAM driver for > legacy ATA controllers not supported by the new, more advanced drivers > ahci(4), mvs(4) and siis(4). ata(4) man page was updated respectively. > It is not mandatory any more. You would be free to remove `device ata` > from your kernel if you had no such hardware, but obviously you have it. Thank you for the clarification. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 09:38:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A21106564A; Wed, 11 Jul 2012 09:38:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 506E08FC0C; Wed, 11 Jul 2012 09:38:20 +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 q6B9cI8i090556; Wed, 11 Jul 2012 05:38:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B9cI5D090543; Wed, 11 Jul 2012 09:38:18 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 09:38:18 GMT Message-Id: <201207110938.q6B9cI5D090543@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 09:38:20 -0000 TB --- 2012-07-11 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 06:40:00 - 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 --- 2012-07-11 06:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-11 06:40:00 - cleaning the object tree TB --- 2012-07-11 06:47:54 - cvsupping the source tree TB --- 2012-07-11 06:47:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-11 06:50:18 - building world TB --- 2012-07-11 06:50:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 06:50:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 06:50:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 06:50:18 - SRCCONF=/dev/null TB --- 2012-07-11 06:50:18 - TARGET=pc98 TB --- 2012-07-11 06:50:18 - TARGET_ARCH=i386 TB --- 2012-07-11 06:50:18 - TZ=UTC TB --- 2012-07-11 06:50:18 - __MAKE_CONF=/dev/null TB --- 2012-07-11 06:50:18 - cd /src TB --- 2012-07-11 06:50:18 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 06:50:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 09:30:25 UTC 2012 TB --- 2012-07-11 09:30:25 - generating LINT kernel config TB --- 2012-07-11 09:30:25 - cd /src/sys/pc98/conf TB --- 2012-07-11 09:30:25 - /usr/bin/make -B LINT TB --- 2012-07-11 09:30:25 - cd /src/sys/pc98/conf TB --- 2012-07-11 09:30:25 - /usr/sbin/config -m LINT TB --- 2012-07-11 09:30:25 - building LINT kernel TB --- 2012-07-11 09:30:25 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 09:30:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 09:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 09:30:25 - SRCCONF=/dev/null TB --- 2012-07-11 09:30:25 - TARGET=pc98 TB --- 2012-07-11 09:30:25 - TARGET_ARCH=i386 TB --- 2012-07-11 09:30:25 - TZ=UTC TB --- 2012-07-11 09:30:25 - __MAKE_CONF=/dev/null TB --- 2012-07-11 09:30:25 - cd /src TB --- 2012-07-11 09:30:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 09:30:25 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 09:38:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 09:38:18 - ERROR: failed to build LINT kernel TB --- 2012-07-11 09:38:18 - 6689.15 user 946.82 system 10698.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 09:38:22 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C24E4106566C; Wed, 11 Jul 2012 09:38:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8DF368FC12; Wed, 11 Jul 2012 09:38:22 +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 q6B9cMZH090768; Wed, 11 Jul 2012 05:38:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B9cMov090763; Wed, 11 Jul 2012 09:38:22 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 09:38:22 GMT Message-Id: <201207110938.q6B9cMov090763@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 09:38:22 -0000 TB --- 2012-07-11 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 06:40:00 - 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 --- 2012-07-11 06:40:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-11 06:40:00 - cleaning the object tree TB --- 2012-07-11 06:48:10 - cvsupping the source tree TB --- 2012-07-11 06:48:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-11 06:50:45 - building world TB --- 2012-07-11 06:50:45 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 06:50:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 06:50:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 06:50:45 - SRCCONF=/dev/null TB --- 2012-07-11 06:50:45 - TARGET=i386 TB --- 2012-07-11 06:50:45 - TARGET_ARCH=i386 TB --- 2012-07-11 06:50:45 - TZ=UTC TB --- 2012-07-11 06:50:45 - __MAKE_CONF=/dev/null TB --- 2012-07-11 06:50:45 - cd /src TB --- 2012-07-11 06:50:45 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 06:50:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 09:29:08 UTC 2012 TB --- 2012-07-11 09:29:08 - generating LINT kernel config TB --- 2012-07-11 09:29:08 - cd /src/sys/i386/conf TB --- 2012-07-11 09:29:08 - /usr/bin/make -B LINT TB --- 2012-07-11 09:29:08 - cd /src/sys/i386/conf TB --- 2012-07-11 09:29:08 - /usr/sbin/config -m LINT TB --- 2012-07-11 09:29:09 - building LINT kernel TB --- 2012-07-11 09:29:09 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 09:29:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 09:29:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 09:29:09 - SRCCONF=/dev/null TB --- 2012-07-11 09:29:09 - TARGET=i386 TB --- 2012-07-11 09:29:09 - TARGET_ARCH=i386 TB --- 2012-07-11 09:29:09 - TZ=UTC TB --- 2012-07-11 09:29:09 - __MAKE_CONF=/dev/null TB --- 2012-07-11 09:29:09 - cd /src TB --- 2012-07-11 09:29:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 09:29:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 09:38:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 09:38:22 - ERROR: failed to build LINT kernel TB --- 2012-07-11 09:38:22 - 6777.28 user 964.24 system 10701.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 09:51:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36BD4106566B; Wed, 11 Jul 2012 09:51:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 075908FC14; Wed, 11 Jul 2012 09:51:25 +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 q6B9pPAF086430; Wed, 11 Jul 2012 05:51:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B9pPS9086413; Wed, 11 Jul 2012 09:51:25 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 09:51:25 GMT Message-Id: <201207110951.q6B9pPS9086413@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 09:51:26 -0000 TB --- 2012-07-11 08:02:39 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 08:02:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 08:02:39 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-11 08:02:39 - cleaning the object tree TB --- 2012-07-11 08:03:24 - cvsupping the source tree TB --- 2012-07-11 08:03:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-11 08:03:50 - building world TB --- 2012-07-11 08:03:50 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 08:03:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 08:03:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 08:03:50 - SRCCONF=/dev/null TB --- 2012-07-11 08:03:50 - TARGET=ia64 TB --- 2012-07-11 08:03:50 - TARGET_ARCH=ia64 TB --- 2012-07-11 08:03:50 - TZ=UTC TB --- 2012-07-11 08:03:50 - __MAKE_CONF=/dev/null TB --- 2012-07-11 08:03:50 - cd /src TB --- 2012-07-11 08:03:50 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 08:03:51 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 09:45:05 UTC 2012 TB --- 2012-07-11 09:45:05 - generating LINT kernel config TB --- 2012-07-11 09:45:05 - cd /src/sys/ia64/conf TB --- 2012-07-11 09:45:05 - /usr/bin/make -B LINT TB --- 2012-07-11 09:45:05 - cd /src/sys/ia64/conf TB --- 2012-07-11 09:45:05 - /usr/sbin/config -m LINT TB --- 2012-07-11 09:45:05 - building LINT kernel TB --- 2012-07-11 09:45:05 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 09:45:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 09:45:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 09:45:05 - SRCCONF=/dev/null TB --- 2012-07-11 09:45:05 - TARGET=ia64 TB --- 2012-07-11 09:45:05 - TARGET_ARCH=ia64 TB --- 2012-07-11 09:45:05 - TZ=UTC TB --- 2012-07-11 09:45:05 - __MAKE_CONF=/dev/null TB --- 2012-07-11 09:45:05 - cd /src TB --- 2012-07-11 09:45:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 09:45:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 09:51:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 09:51:25 - ERROR: failed to build LINT kernel TB --- 2012-07-11 09:51:25 - 4496.71 user 690.73 system 6526.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 10:15:06 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E5E2106564A; Wed, 11 Jul 2012 10:15:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E9F1B8FC08; Wed, 11 Jul 2012 10:15:05 +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 q6BAF5ra099148; Wed, 11 Jul 2012 06:15:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BAF5WW099133; Wed, 11 Jul 2012 10:15:05 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 10:15:05 GMT Message-Id: <201207111015.q6BAF5WW099133@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 10:15:06 -0000 TB --- 2012-07-11 06:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 06:40:00 - 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 --- 2012-07-11 06:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-11 06:40:00 - cleaning the object tree TB --- 2012-07-11 06:51:26 - cvsupping the source tree TB --- 2012-07-11 06:51:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-11 06:52:20 - building world TB --- 2012-07-11 06:52:20 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 06:52:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 06:52:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 06:52:20 - SRCCONF=/dev/null TB --- 2012-07-11 06:52:20 - TARGET=amd64 TB --- 2012-07-11 06:52:20 - TARGET_ARCH=amd64 TB --- 2012-07-11 06:52:20 - TZ=UTC TB --- 2012-07-11 06:52:20 - __MAKE_CONF=/dev/null TB --- 2012-07-11 06:52:20 - cd /src TB --- 2012-07-11 06:52:20 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 06:52:21 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 11 10:07:15 UTC 2012 TB --- 2012-07-11 10:07:15 - generating LINT kernel config TB --- 2012-07-11 10:07:15 - cd /src/sys/amd64/conf TB --- 2012-07-11 10:07:15 - /usr/bin/make -B LINT TB --- 2012-07-11 10:07:15 - cd /src/sys/amd64/conf TB --- 2012-07-11 10:07:15 - /usr/sbin/config -m LINT TB --- 2012-07-11 10:07:15 - building LINT kernel TB --- 2012-07-11 10:07:15 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 10:07:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 10:07:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 10:07:15 - SRCCONF=/dev/null TB --- 2012-07-11 10:07:15 - TARGET=amd64 TB --- 2012-07-11 10:07:15 - TARGET_ARCH=amd64 TB --- 2012-07-11 10:07:15 - TZ=UTC TB --- 2012-07-11 10:07:15 - __MAKE_CONF=/dev/null TB --- 2012-07-11 10:07:15 - cd /src TB --- 2012-07-11 10:07:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 10:07:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 10:15:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 10:15:05 - ERROR: failed to build LINT kernel TB --- 2012-07-11 10:15:05 - 8167.55 user 1275.77 system 12904.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 11:30:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A29651065670; Wed, 11 Jul 2012 11:30:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4CC8FC0C; Wed, 11 Jul 2012 11:30:56 +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 q6BBUtux080061; Wed, 11 Jul 2012 07:30:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BBUtiu080060; Wed, 11 Jul 2012 11:30:55 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 11:30:55 GMT Message-Id: <201207111130.q6BBUtiu080060@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:30:56 -0000 TB --- 2012-07-11 10:15:05 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 10:15:05 - 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 --- 2012-07-11 10:15:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-11 10:15:05 - cleaning the object tree TB --- 2012-07-11 10:16:34 - cvsupping the source tree TB --- 2012-07-11 10:16:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-11 10:17:43 - building world TB --- 2012-07-11 10:17:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 10:17:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 10:17:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 10:17:43 - SRCCONF=/dev/null TB --- 2012-07-11 10:17:43 - TARGET=sparc64 TB --- 2012-07-11 10:17:43 - TARGET_ARCH=sparc64 TB --- 2012-07-11 10:17:43 - TZ=UTC TB --- 2012-07-11 10:17:43 - __MAKE_CONF=/dev/null TB --- 2012-07-11 10:17:43 - cd /src TB --- 2012-07-11 10:17:43 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 10:17:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 11:25:53 UTC 2012 TB --- 2012-07-11 11:25:53 - generating LINT kernel config TB --- 2012-07-11 11:25:53 - cd /src/sys/sparc64/conf TB --- 2012-07-11 11:25:53 - /usr/bin/make -B LINT TB --- 2012-07-11 11:25:53 - cd /src/sys/sparc64/conf TB --- 2012-07-11 11:25:53 - /usr/sbin/config -m LINT TB --- 2012-07-11 11:25:53 - building LINT kernel TB --- 2012-07-11 11:25:53 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 11:25:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 11:25:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 11:25:53 - SRCCONF=/dev/null TB --- 2012-07-11 11:25:53 - TARGET=sparc64 TB --- 2012-07-11 11:25:53 - TARGET_ARCH=sparc64 TB --- 2012-07-11 11:25:53 - TZ=UTC TB --- 2012-07-11 11:25:53 - __MAKE_CONF=/dev/null TB --- 2012-07-11 11:25:53 - cd /src TB --- 2012-07-11 11:25:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 11:25:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 11:30:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 11:30:55 - ERROR: failed to build LINT kernel TB --- 2012-07-11 11:30:55 - 3185.70 user 589.66 system 4549.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 12:01:58 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39896106566B; Wed, 11 Jul 2012 12:01:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 099998FC26; Wed, 11 Jul 2012 12:01:57 +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 q6BC1vRm016756; Wed, 11 Jul 2012 08:01:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BC1v9U016755; Wed, 11 Jul 2012 12:01:57 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 12:01:57 GMT Message-Id: <201207111201.q6BC1v9U016755@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:01:58 -0000 TB --- 2012-07-11 09:38:22 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 09:38:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 09:38:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-11 09:38:22 - cleaning the object tree TB --- 2012-07-11 09:41:04 - cvsupping the source tree TB --- 2012-07-11 09:41:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-11 09:42:10 - building world TB --- 2012-07-11 09:42:10 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 09:42:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 09:42:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 09:42:10 - SRCCONF=/dev/null TB --- 2012-07-11 09:42:10 - TARGET=powerpc TB --- 2012-07-11 09:42:10 - TARGET_ARCH=powerpc TB --- 2012-07-11 09:42:10 - TZ=UTC TB --- 2012-07-11 09:42:10 - __MAKE_CONF=/dev/null TB --- 2012-07-11 09:42:10 - cd /src TB --- 2012-07-11 09:42:10 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 09:42:11 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 11:58:26 UTC 2012 TB --- 2012-07-11 11:58:26 - generating LINT kernel config TB --- 2012-07-11 11:58:26 - cd /src/sys/powerpc/conf TB --- 2012-07-11 11:58:26 - /usr/bin/make -B LINT TB --- 2012-07-11 11:58:26 - cd /src/sys/powerpc/conf TB --- 2012-07-11 11:58:26 - /usr/sbin/config -m LINT TB --- 2012-07-11 11:58:26 - building LINT kernel TB --- 2012-07-11 11:58:26 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 11:58:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 11:58:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 11:58:26 - SRCCONF=/dev/null TB --- 2012-07-11 11:58:26 - TARGET=powerpc TB --- 2012-07-11 11:58:26 - TARGET_ARCH=powerpc TB --- 2012-07-11 11:58:26 - TZ=UTC TB --- 2012-07-11 11:58:26 - __MAKE_CONF=/dev/null TB --- 2012-07-11 11:58:26 - cd /src TB --- 2012-07-11 11:58:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 11:58:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 12:01:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 12:01:57 - ERROR: failed to build LINT kernel TB --- 2012-07-11 12:01:57 - 6788.95 user 906.38 system 8615.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 12:39:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A213A106566B; Wed, 11 Jul 2012 12:39:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6923B8FC08; Wed, 11 Jul 2012 12:39: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 q6BCdIJH013719; Wed, 11 Jul 2012 08:39:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BCdIu3013718; Wed, 11 Jul 2012 12:39:18 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 12:39:18 GMT Message-Id: <201207111239.q6BCdIu3013718@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:39:19 -0000 TB --- 2012-07-11 09:51:25 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 09:51:25 - 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 --- 2012-07-11 09:51:25 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-11 09:51:25 - cleaning the object tree TB --- 2012-07-11 09:53:09 - cvsupping the source tree TB --- 2012-07-11 09:53:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-11 09:53:35 - building world TB --- 2012-07-11 09:53:35 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 09:53:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 09:53:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 09:53:35 - SRCCONF=/dev/null TB --- 2012-07-11 09:53:35 - TARGET=powerpc TB --- 2012-07-11 09:53:35 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 09:53:35 - TZ=UTC TB --- 2012-07-11 09:53:35 - __MAKE_CONF=/dev/null TB --- 2012-07-11 09:53:35 - cd /src TB --- 2012-07-11 09:53:35 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 09:53:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 11 12:35:49 UTC 2012 TB --- 2012-07-11 12:35:49 - generating LINT kernel config TB --- 2012-07-11 12:35:49 - cd /src/sys/powerpc/conf TB --- 2012-07-11 12:35:49 - /usr/bin/make -B LINT TB --- 2012-07-11 12:35:50 - cd /src/sys/powerpc/conf TB --- 2012-07-11 12:35:50 - /usr/sbin/config -m LINT TB --- 2012-07-11 12:35:50 - building LINT kernel TB --- 2012-07-11 12:35:50 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 12:35:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 12:35:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 12:35:50 - SRCCONF=/dev/null TB --- 2012-07-11 12:35:50 - TARGET=powerpc TB --- 2012-07-11 12:35:50 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 12:35:50 - TZ=UTC TB --- 2012-07-11 12:35:50 - __MAKE_CONF=/dev/null TB --- 2012-07-11 12:35:50 - cd /src TB --- 2012-07-11 12:35:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 12:35:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 12:39:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 12:39:18 - ERROR: failed to build LINT kernel TB --- 2012-07-11 12:39:18 - 8270.41 user 1137.05 system 10072.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 13:54:36 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 891331065673; Wed, 11 Jul 2012 13:54:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDB68FC14; Wed, 11 Jul 2012 13:54:36 +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 q6BDsYZi003460; Wed, 11 Jul 2012 09:54:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BDsYmE003453; Wed, 11 Jul 2012 13:54:34 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 13:54:34 GMT Message-Id: <201207111354.q6BDsYmE003453@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 13:54:36 -0000 TB --- 2012-07-11 12:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 12:40:00 - 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 --- 2012-07-11 12:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-11 12:40:00 - cleaning the object tree TB --- 2012-07-11 12:44:21 - cvsupping the source tree TB --- 2012-07-11 12:44:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-11 12:46:13 - building world TB --- 2012-07-11 12:46:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 12:46:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 12:46:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 12:46:13 - SRCCONF=/dev/null TB --- 2012-07-11 12:46:13 - TARGET=arm TB --- 2012-07-11 12:46:13 - TARGET_ARCH=arm TB --- 2012-07-11 12:46:13 - TZ=UTC TB --- 2012-07-11 12:46:13 - __MAKE_CONF=/dev/null TB --- 2012-07-11 12:46:13 - cd /src TB --- 2012-07-11 12:46:13 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 12:46:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 13:50:18 UTC 2012 TB --- 2012-07-11 13:50:18 - cd /src/sys/arm/conf TB --- 2012-07-11 13:50:18 - /usr/sbin/config -m ATMEL TB --- 2012-07-11 13:50:18 - building ATMEL kernel TB --- 2012-07-11 13:50:18 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 13:50:18 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 13:50:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 13:50:18 - SRCCONF=/dev/null TB --- 2012-07-11 13:50:18 - TARGET=arm TB --- 2012-07-11 13:50:18 - TARGET_ARCH=arm TB --- 2012-07-11 13:50:18 - TZ=UTC TB --- 2012-07-11 13:50:18 - __MAKE_CONF=/dev/null TB --- 2012-07-11 13:50:18 - cd /src TB --- 2012-07-11 13:50:18 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Jul 11 13:50:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Wed Jul 11 13:53:50 UTC 2012 TB --- 2012-07-11 13:53:50 - cd /src/sys/arm/conf TB --- 2012-07-11 13:53:50 - /usr/sbin/config -m AVILA TB --- 2012-07-11 13:53:50 - building AVILA kernel TB --- 2012-07-11 13:53:50 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 13:53:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 13:53:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 13:53:50 - SRCCONF=/dev/null TB --- 2012-07-11 13:53:50 - TARGET=arm TB --- 2012-07-11 13:53:50 - TARGET_ARCH=arm TB --- 2012-07-11 13:53:50 - TZ=UTC TB --- 2012-07-11 13:53:50 - __MAKE_CONF=/dev/null TB --- 2012-07-11 13:53:50 - cd /src TB --- 2012-07-11 13:53:50 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Jul 11 13:53:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_reinit_fifo': /src/sys/dev/ath/if_ath_rx_edma.c:193: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'bus_addr_t' [-Wformat] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 13:54:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 13:54:29 - ERROR: failed to build AVILA kernel TB --- 2012-07-11 13:54:29 - 2642.48 user 594.33 system 4469.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 14:00:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C020A1065674; Wed, 11 Jul 2012 14:00:57 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [202.12.127.65]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC1B8FC15; Wed, 11 Jul 2012 14:00:57 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (not verified)) (Authenticated sender: imb@protected-networks.net) by sarah.protected-networks.net (Postfix) with ESMTPSA id 52A0B60FA; Wed, 11 Jul 2012 10:00:50 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=cjUYnfpwJukC3GHk9idMN/TQp8hWv79RyNyM7YhbbHkNAtxyDZwU8V5DIm3glVrkk clXrBtpOfcCDJRdyg6heqNKGEmrltwD24BNtMkDbRTiSDhx/XbdSb4SwBx+Mlxg Message-ID: <4FFD8710.5010408@protected-networks.net> Date: Wed, 11 Jul 2012 10:00:48 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:13.0) Gecko/20120619 Thunderbird/13.0.1 MIME-Version: 1.0 References: <20120607203753.2466c63a.miwi@FreeBSD.org> <4fd44f39.06db440a.4ccb.ffffe4e1SMTPIN_ADDED@mx.google.com> <4fd465a3.46e8440a.7470.0336SMTPIN_ADDED@mx.google.com> In-Reply-To: X-Enigmail-Version: 1.4.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-current , x11@freebsd.org Subject: Re: [CFT] Xorg 7.7 ready for testing! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 14:00:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/12 15:46, Alexander Yerenkow wrote: > I'm created unofficial pkg repo for patched xorg tree. > I'm still experimenting with it, but I already have built all required > packages for CURRENT i386. Just a couple of quick notes on this since I rebuilt the whole thing yesterday from the SVN repository at https://trillian.chruetertee.ch/svn/ports/trunk .. 1) On my x86 Core Duo, the updated x11/libXxf86dga Makefile contains more -Werror compilation flags causing it to fail with .. ===> Building for libXxf86dga-1.1.3 Making all in src make all-am CC XF86DGA.lo XF86DGA.c: In function 'XF86cleanup': XF86DGA.c:651: warning: function might be possible candidate for attribute 'noreturn' CC XF86DGA2.lo XF86DGA2.c: In function 'DGAMapPhysical': XF86DGA2.c:931: error: cast from pointer to integer of different size *** [XF86DGA2.lo] Error code 1 Stop in /usr/ports/x11/libXxf86dga/work/libXxf86dga-1.1.3/src. *** [all] Error code 1 2) The (port) version number on x11-drivers/xf86-input-keyboard is the same (1.6.1) which means that 'portupgrade -a' won't catch it. This leaves you with a keyboard driver with a version mismatch to the new server - one that won't load. A recompile of this driver is required. Having resolved than these locally, my ~6 year old laptop now has all the associated eye-candy with the new X-server; compositing, blurring and all :-) Thanks! imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/9hw8ACgkQQv9rrgRC1JLEswCaA0UWCKbGb9GKTicuzbR+y9UB 9LoAoI1oXv3HBFDB2Ykzl8qLuU/Mz+hn =iB5N -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 16:12:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8FB5106564A for ; Wed, 11 Jul 2012 16:12:10 +0000 (UTC) (envelope-from pfg@freebsd.org) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by mx1.freebsd.org (Postfix) with SMTP id 64F708FC20 for ; Wed, 11 Jul 2012 16:12:10 +0000 (UTC) Received: from [72.30.22.93] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jul 2012 16:12:04 -0000 Received: from [72.30.22.37] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 11 Jul 2012 16:12:04 -0000 Received: from [127.0.0.1] by omp1067.mail.sp2.yahoo.com with NNFMP; 11 Jul 2012 16:12:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 645331.75573.bm@omp1067.mail.sp2.yahoo.com Received: (qmail 29539 invoked by uid 60001); 11 Jul 2012 16:12:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1342023124; bh=sutiuycF91SLhNOTRgwE5ZIOuY1W5rJV6iS4zlpBYJk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H/ecaLKBWUQi3i7KfqDO0rJ1U99TNdwDnk5V38yg0HIuVRatr7KsNqQGYXNVr/Il/770LXiuKpa+YoKaZ2gDqx7wpAdrpmk6McrLoq6sXkODjy1MBloYLZyYSXFTR8Jr2wvvDBHcSU5vC/It7PcQsO/+CxRAsXAws42T4j9fT4U= X-YMail-OSG: oZqX580VM1lywIKmOS5pZHYAw5.SwJVtIIzNwQ.YzhJBYH7 oJWyMbecjlAJn7SXccJ3SpTDG6ALTyTGPQCnhcgG_1Z_TfJKOGz9yWRDJHjK kpzKoiTZVGOlnkHKNRwnwoUbaaCGfM6CzXxWtImN_sh6PVJrRqsVJqnwNYEo sDkBig1_sEe6egDjMe.TILQ7U7EDPl5feSg.NjIR1c2RudGIDcTufuLGJsqc n9pmn15ZD3EP5tIvqAPW2Gtk9QDJw4ZEfMFLFwfVyFWuJrXM4Gvy5ukwTUw7 7HuJXDoIYQB_AAM1I5kkgbu1cvRPIKdlwEKAmjA5RLGJ77KMRBJjoOsPwu4v 9o1gQGUG_MumBbsmAfM2Rcz.wE_iti5deD01p.F7lLOgJ93kom1s4WOv__8r 32d19ykU6ViuBxCBW1ucgnBcH4zVzKafYRjCnLEpAwtD0K7sUTcNctgTQ18L mTDSa Received: from [200.118.157.7] by web113519.mail.gq1.yahoo.com via HTTP; Wed, 11 Jul 2012 09:12:03 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.120.356233 Message-ID: <1342023123.27181.YahooMailClassic@web113519.mail.gq1.yahoo.com> Date: Wed, 11 Jul 2012 09:12:03 -0700 (PDT) From: Pedro Giffuni To: Dimitry Andric In-Reply-To: <4FFD2D94.9040805@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] Add -Wbounded to gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfg@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:12:10 -0000 =0A--- Mer 11/7/12, Dimitry Andric ha scritto:=0A...=0A> = =0A> Does it catch any really interesting bound overruns?=0A> =0A=0ANah .. = I arrived to the conclusion that it's not=0Areally worth it :).=0A=0A> If t= he number of false positives is very large, then it=0A> generally isn't=0A>= worth the pain.=A0 Or the option should be turned off by=0A> default, and = only=0A> enabled for WARNS=3Dsome_arbitrary_high_number.=0A> =0A=0AIt is ni= ce to have but I don't think we should turn it on=0Afor any level. I will h= ave to look at how to do that.=0A=0AThanks,=0A=0APedro.=0A From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 16:43:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D99E0106564A for ; Wed, 11 Jul 2012 16:43:47 +0000 (UTC) (envelope-from w8hdkim@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFA18FC0A for ; Wed, 11 Jul 2012 16:43:47 +0000 (UTC) Received: by qaat11 with SMTP id t11so1169694qaa.13 for ; Wed, 11 Jul 2012 09:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ngdvQHJkhOFDF5iVtMGYvOhbp3z0+1+B/mBuXczyDd0=; b=QNCUGhIzynJvfOOVkfisfpvEpO8nwbs0f8zjNRpFatzucvJuaSVdYFydJJ4TGYPvci NMwI61pah/tsFsnj48roI+beuShAenXncjw5jDWueUi5vzzL883/KbeMhKjhm58Y/yQy 1LHiVLE3dszxnAjvFAAylk3Ts9e0HJCgKADZvitw2josQykFucSqlPLCkuXnbub+UkSC zBXyGrzWE0ZBzI5uNH4dadpXELdneBGuIsQVReUyW6FFV+BdRuGPPwtaRGBdgT3XeF+i 3BcrQ5zA/eff4VvZHdNsGJbYicWJ16+GhblJExO3Q59MtR11A/ycsOqMr8wnX9MgyF5v e0nA== MIME-Version: 1.0 Received: by 10.224.105.203 with SMTP id u11mr88137860qao.41.1342025021528; Wed, 11 Jul 2012 09:43:41 -0700 (PDT) Received: by 10.229.39.12 with HTTP; Wed, 11 Jul 2012 09:43:41 -0700 (PDT) In-Reply-To: References: <20120710150040.GE2338@deviant.kiev.zoral.com.ua> Date: Wed, 11 Jul 2012 12:43:41 -0400 Message-ID: From: Kim Culhan To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , freebsd-current@freebsd.org Subject: Re: FreeBSD-current r238290 installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 16:43:47 -0000 On Tue, Jul 10, 2012 at 10:19 PM, Garrett Cooper wrote: > On Tue, Jul 10, 2012 at 7:10 PM, Kim Culhan wrote: >> On Tue, Jul 10, 2012 at 9:52 PM, Garrett Cooper wrote: >>> On Tue, Jul 10, 2012 at 6:22 PM, Kim Culhan wrote: >>> >>> ... >>> >>>> Ran another buildworld and on this run gcc was produced in >>>> /usr/obj/usr/src/gnu/usr.bin/cc/cc >>>> and installworld worked fine. >>> >>> I would be curious (if it happened again) if you updated your source >>> tree but not your objdir, or see whether or not there was some clock >>> skew at hand. >> >> Yes the objdir was unchanged from the the previous run which was ~30 days ago. >> >> Should probably have rm -r'd /usr/obj before the first run today. > > Indeed. Changing source directories and not cleaning out your > objdir is certain to bring pain in certain cases because of dependency > order `violations` if you using -DNO_CLEAN, -DKERNFAST, etc (sys/boot > definitely hates it when things are in an inconsistent state, as does > include/). `Hacks` or modifications to sources might be required to > get things to work if you patch things on the fly as well [1]. > Cheers, > -Garrett > > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/160646 Very good, thanks for the info, running another buildworld now. -kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 19:46:40 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5A3106566C; Wed, 11 Jul 2012 19:46:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4698B8FC12; Wed, 11 Jul 2012 19:46:40 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2774369pbb.13 for ; Wed, 11 Jul 2012 12:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M2LQtJCTXXtMh/hOLu8m1OZo7i7u7+33B+Zhye1zNEs=; b=RsrUmRvcMj70bk5epGU1cCOKl3v7FdfqKRn7EmM4k/j/04tECl2wFI6KIcpYT4VlzE m0UbESbFkWHTiXSKzov7aM6Gi2sxN8+WpCsM/G4k+2JsvaqUjhkwdbGGnXy49NcTVdCk BZLaVnwePN3Gkh/XRSfrRB2eRvu8WFjNOgPE+JlhPjNio2arBciQjMQYahWbFISzXRuK nfW6DbNzRLu01rlswzO5gAsbvQkB7ICVDct5fm3stxQFI3tpQ9USyznL/RS+kFAWl7z9 UKMqbQRgAHezIxToVUpp5yubk2FmgBatcQLlwwSeMKEI99fBn4n3FfQXclJ1GfWXSmdQ GnQg== MIME-Version: 1.0 Received: by 10.68.222.163 with SMTP id qn3mr81056287pbc.135.1342036000122; Wed, 11 Jul 2012 12:46:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.195.102 with HTTP; Wed, 11 Jul 2012 12:46:40 -0700 (PDT) In-Reply-To: <201207110257.q6B2vXeW018145@svn.freebsd.org> References: <201207110257.q6B2vXeW018145@svn.freebsd.org> Date: Wed, 11 Jul 2012 12:46:40 -0700 X-Google-Sender-Auth: sIBpp74Jfg0kgJUSnC3eJ0oWqSw Message-ID: From: Adrian Chadd To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, current@freebsd.org Subject: Re: svn commit: r238361 - head/sys/dev/usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 19:46:40 -0000 Hi, What was the original commit which broke wlan name matching? I can't see how a commit to usb_pf.c would "fix" this. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 19:53:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15D691065672; Wed, 11 Jul 2012 19:53:42 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D7A0C8FC1E; Wed, 11 Jul 2012 19:53:41 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q6BJrfGK007318; Wed, 11 Jul 2012 12:53:41 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q6BJrflY007317; Wed, 11 Jul 2012 12:53:41 -0700 (PDT) (envelope-from david) Date: Wed, 11 Jul 2012 12:53:41 -0700 From: David Wolfskill To: Adrian Chadd Message-ID: <20120711195341.GK3599@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Adrian Chadd , Hiroki Sato , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, current@freebsd.org References: <201207110257.q6B2vXeW018145@svn.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YIleam+9adpUeYf+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, current@freebsd.org Subject: Re: svn commit: r238361 - head/sys/dev/usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 19:53:42 -0000 --YIleam+9adpUeYf+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2012 at 12:46:40PM -0700, Adrian Chadd wrote: > Hi, >=20 > What was the original commit which broke wlan name matching? >=20 > I can't see how a commit to usb_pf.c would "fix" this. > ... r238279 Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --YIleam+9adpUeYf+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/92cUACgkQmprOCmdXAD0pBwCfWs27KE/UsCDfbj2h2zdDzpHt 1tUAn1kn+aWmhtM0+ooueqbMG+Aj5GF8 =Y33G -----END PGP SIGNATURE----- --YIleam+9adpUeYf+-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 20:28:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE661065670; Wed, 11 Jul 2012 20:28:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6D93D8FC14; Wed, 11 Jul 2012 20:28:09 +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 q6BKS8Sb010901; Wed, 11 Jul 2012 16:28:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BKS83q010900; Wed, 11 Jul 2012 20:28:08 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 20:28:08 GMT Message-Id: <201207112028.q6BKS83q010900@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:28:09 -0000 TB --- 2012-07-11 19:18:06 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 19:18:06 - 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 --- 2012-07-11 19:18:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-11 19:18:06 - cleaning the object tree TB --- 2012-07-11 19:19:35 - cvsupping the source tree TB --- 2012-07-11 19:19:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-11 19:20:19 - building world TB --- 2012-07-11 19:20:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 19:20:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 19:20:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 19:20:19 - SRCCONF=/dev/null TB --- 2012-07-11 19:20:19 - TARGET=sparc64 TB --- 2012-07-11 19:20:19 - TARGET_ARCH=sparc64 TB --- 2012-07-11 19:20:19 - TZ=UTC TB --- 2012-07-11 19:20:19 - __MAKE_CONF=/dev/null TB --- 2012-07-11 19:20:19 - cd /src TB --- 2012-07-11 19:20:19 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 19:20:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 20:18:23 UTC 2012 TB --- 2012-07-11 20:18:23 - generating LINT kernel config TB --- 2012-07-11 20:18:23 - cd /src/sys/sparc64/conf TB --- 2012-07-11 20:18:23 - /usr/bin/make -B LINT TB --- 2012-07-11 20:18:23 - cd /src/sys/sparc64/conf TB --- 2012-07-11 20:18:23 - /usr/sbin/config -m LINT TB --- 2012-07-11 20:18:23 - building LINT kernel TB --- 2012-07-11 20:18:23 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 20:18:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 20:18:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 20:18:23 - SRCCONF=/dev/null TB --- 2012-07-11 20:18:23 - TARGET=sparc64 TB --- 2012-07-11 20:18:23 - TARGET_ARCH=sparc64 TB --- 2012-07-11 20:18:23 - TZ=UTC TB --- 2012-07-11 20:18:23 - __MAKE_CONF=/dev/null TB --- 2012-07-11 20:18:23 - cd /src TB --- 2012-07-11 20:18:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 20:18:23 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_devstat.c cc1: warnings being treated as errors /src/sys/kern/subr_devstat.c: In function 'devstat_start_transaction_bio': /src/sys/kern/subr_devstat.c:295: warning: implicit declaration of function 'DTRACE_DEVSTAT_BIO_START' /src/sys/kern/subr_devstat.c:295: warning: nested extern declaration of 'DTRACE_DEVSTAT_BIO_START' [-Wnested-externs] /src/sys/kern/subr_devstat.c: In function 'devstat_end_transaction_bio': /src/sys/kern/subr_devstat.c:390: warning: implicit declaration of function 'DTRACE_DEVSTAT_BIO_DONE' /src/sys/kern/subr_devstat.c:390: warning: nested extern declaration of 'DTRACE_DEVSTAT_BIO_DONE' [-Wnested-externs] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 20:28:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 20:28:08 - ERROR: failed to build LINT kernel TB --- 2012-07-11 20:28:08 - 3436.29 user 557.12 system 4201.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:09:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA31B106564A; Wed, 11 Jul 2012 21:09:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B96B88FC12; Wed, 11 Jul 2012 21:09:39 +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 q6BL9dxX011666; Wed, 11 Jul 2012 17:09:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BL9dhk011665; Wed, 11 Jul 2012 21:09:39 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 21:09:39 GMT Message-Id: <201207112109.q6BL9dhk011665@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 21:09:40 -0000 TB --- 2012-07-11 18:22:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 18:22: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 --- 2012-07-11 18:22:59 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-11 18:23:00 - cleaning the object tree TB --- 2012-07-11 18:25:00 - cvsupping the source tree TB --- 2012-07-11 18:25:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-11 18:26:00 - building world TB --- 2012-07-11 18:26:00 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 18:26:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 18:26:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 18:26:00 - SRCCONF=/dev/null TB --- 2012-07-11 18:26:00 - TARGET=powerpc TB --- 2012-07-11 18:26:00 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 18:26:00 - TZ=UTC TB --- 2012-07-11 18:26:00 - __MAKE_CONF=/dev/null TB --- 2012-07-11 18:26:00 - cd /src TB --- 2012-07-11 18:26:00 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 18:26:01 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 11 21:02:01 UTC 2012 TB --- 2012-07-11 21:02:01 - generating LINT kernel config TB --- 2012-07-11 21:02:01 - cd /src/sys/powerpc/conf TB --- 2012-07-11 21:02:01 - /usr/bin/make -B LINT TB --- 2012-07-11 21:02:01 - cd /src/sys/powerpc/conf TB --- 2012-07-11 21:02:01 - /usr/sbin/config -m LINT TB --- 2012-07-11 21:02:01 - building LINT kernel TB --- 2012-07-11 21:02:01 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 21:02:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 21:02:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 21:02:01 - SRCCONF=/dev/null TB --- 2012-07-11 21:02:01 - TARGET=powerpc TB --- 2012-07-11 21:02:01 - TARGET_ARCH=powerpc64 TB --- 2012-07-11 21:02:01 - TZ=UTC TB --- 2012-07-11 21:02:01 - __MAKE_CONF=/dev/null TB --- 2012-07-11 21:02:01 - cd /src TB --- 2012-07-11 21:02:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 21:02:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_devstat.c cc1: warnings being treated as errors /src/sys/kern/subr_devstat.c: In function 'devstat_start_transaction_bio': /src/sys/kern/subr_devstat.c:295: warning: implicit declaration of function 'DTRACE_DEVSTAT_BIO_START' /src/sys/kern/subr_devstat.c:295: warning: nested extern declaration of 'DTRACE_DEVSTAT_BIO_START' [-Wnested-externs] /src/sys/kern/subr_devstat.c: In function 'devstat_end_transaction_bio': /src/sys/kern/subr_devstat.c:390: warning: implicit declaration of function 'DTRACE_DEVSTAT_BIO_DONE' /src/sys/kern/subr_devstat.c:390: warning: nested extern declaration of 'DTRACE_DEVSTAT_BIO_DONE' [-Wnested-externs] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 21:09:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 21:09:39 - ERROR: failed to build LINT kernel TB --- 2012-07-11 21:09:39 - 8391.79 user 1107.96 system 9999.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:20:17 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD621065674; Wed, 11 Jul 2012 21:20:17 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 43D578FC15; Wed, 11 Jul 2012 21:20:17 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 91F362AA4F2; Wed, 11 Jul 2012 15:20:16 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 53F411DAF2; Wed, 11 Jul 2012 16:20:09 -0500 (EST) Date: Wed, 11 Jul 2012 16:20:09 -0500 From: Diane Bruce To: Warner Losh Message-ID: <20120711212009.GA15542@night.db.net> References: <20120528233035.GA77157@troutmask.apl.washington.edu> <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: Peter Jeremy , David Schultz , freebsd-current@FreeBSD.ORG, Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 21:20:17 -0000 On Tue, Jul 10, 2012 at 08:02:33AM -0600, Warner Losh wrote: > > On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > > Not having R would be a bit pain in my backside. That's one of the practical considerations that I was talking about. It is very real, and if I have to, I'll commit the #define junk I railed against to get it back. Please, let's get some progress. I have some time to help. > Not having complex functions is a PITA for software defined radio programs... I submitted this PR in frustration. I know, I meant to close it already. >Number: 147599 >Category: kern >Synopsis: [libm] [patch] Import netbsd complex functions into our libm > Warner Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db Nowadays tar can compress using yesterdays latest technologies! From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:43:51 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1CEA1065672; Wed, 11 Jul 2012 21:43:50 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id C7C538FC15; Wed, 11 Jul 2012 21:43:50 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6BLhkwI009898; Wed, 11 Jul 2012 14:43:46 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6BLhkvE009897; Wed, 11 Jul 2012 14:43:46 -0700 (PDT) (envelope-from sgk) Date: Wed, 11 Jul 2012 14:43:46 -0700 From: Steve Kargl To: Diane Bruce Message-ID: <20120711214346.GA9877@troutmask.apl.washington.edu> References: <4FC40DEA.8030703@missouri.edu> <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <20120711212009.GA15542@night.db.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120711212009.GA15542@night.db.net> User-Agent: Mutt/1.4.2.3i Cc: Peter Jeremy , David Schultz , freebsd-current@FreeBSD.ORG, Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 21:43:51 -0000 On Wed, Jul 11, 2012 at 04:20:09PM -0500, Diane Bruce wrote: > On Tue, Jul 10, 2012 at 08:02:33AM -0600, Warner Losh wrote: > > > > On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > > > > Not having R would be a bit pain in my backside. That's one of the practical considerations that I was talking about. It is very real, and if I have to, I'll commit the #define junk I railed against to get it back. Please, let's get some progress. I have some time to help. > > > > Not having complex functions is a PITA for software defined radio programs... > > I submitted this PR in frustration. I know, I meant to close it already. > > >Number: 147599 > >Category: kern > >Synopsis: [libm] [patch] Import netbsd complex functions into our libm > You submitted on June 6th, 2010. I commented on why the patch should be avoided on June 15th, 2010. I see no follow-ups from you that give the details on how you went about testing and fixing the code? -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 21:54:22 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42614106566C; Wed, 11 Jul 2012 21:54:22 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB5E8FC16; Wed, 11 Jul 2012 21:54:22 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 532DF2AA5D5; Wed, 11 Jul 2012 15:54:21 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 1646A1DAF2; Wed, 11 Jul 2012 16:54:14 -0500 (EST) Date: Wed, 11 Jul 2012 16:54:14 -0500 From: Diane Bruce To: Steve Kargl Message-ID: <20120711215414.GA16350@night.db.net> References: <20120529000756.GA77386@troutmask.apl.washington.edu> <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <20120711212009.GA15542@night.db.net> <20120711214346.GA9877@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120711214346.GA9877@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: Diane Bruce , freebsd-current@FreeBSD.ORG, David Schultz , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 21:54:22 -0000 On Wed, Jul 11, 2012 at 02:43:46PM -0700, Steve Kargl wrote: > On Wed, Jul 11, 2012 at 04:20:09PM -0500, Diane Bruce wrote: > > On Tue, Jul 10, 2012 at 08:02:33AM -0600, Warner Losh wrote: > > > > > > On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > > > ... > > You submitted on June 6th, 2010. I commented on why > the patch should be avoided on June 15th, 2010. I see > no follow-ups from you that give the details on how > you went about testing and fixing the code? Steve, I misunderstood. Someone told me you and Bruce had some code which made this PR unnecessary, I did mean to close the PR as this is what I had heard. If that is not true I'd be happy to help you guys in any way I can. And my apologies, I should have verfied directly with you rather than listening to hearsay. > > -- > Steve Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db Nowadays tar can compress using yesterdays latest technologies! From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:16:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4762E10656B9; Wed, 11 Jul 2012 22:16:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB57B8FC08; Wed, 11 Jul 2012 22:15:59 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2968446pbb.13 for ; Wed, 11 Jul 2012 15:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=2zJnKa7+mrPuwUwRiAzeb2DIvN63YMb+zpsBLeYZAwQ=; b=qAXMxSpmItzINMQVV33cbLXuLdhCvDqaGvd5NHGtoJw3+h9vDX28yjzdIRbO6TYKbh 26M4xq9eenM/OhxPCfxY+FWfL5OrRNLrmBEPfyXvW8peqJwcyprPpXvjjbzOpPONceb+ b02NcjWSkyd73MB7FLKxERMNuKV9YKV9vL/IvpyUFgADa5CJ1NG7tORAqDgy7vumCuk8 X7u4gGvPftaHQEIif3igSBntupOZoSPFeqNJ52jXXU5Vjju2zOXAeF/KyJb74yKz5xoK IwvqJp6Z+onJrDHCWyaMTZlqZLGFxADNhA/R1ilJqqwIW61W0423NtZUIEwSUfSEHXl5 /dew== MIME-Version: 1.0 Received: by 10.68.201.9 with SMTP id jw9mr81292849pbc.28.1342044959711; Wed, 11 Jul 2012 15:15:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.195.102 with HTTP; Wed, 11 Jul 2012 15:15:59 -0700 (PDT) In-Reply-To: <20120711195341.GK3599@albert.catwhisker.org> References: <201207110257.q6B2vXeW018145@svn.freebsd.org> <20120711195341.GK3599@albert.catwhisker.org> Date: Wed, 11 Jul 2012 15:15:59 -0700 X-Google-Sender-Auth: z6Z4KkGGoUO3dmKwFDeAaI5rCNE Message-ID: From: Adrian Chadd To: David Wolfskill , Adrian Chadd , Hiroki Sato , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: svn commit: r238361 - head/sys/dev/usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 22:16:00 -0000 Again, that just touched usb. So, how'd that affect non-USB wifi cloning? Adiran From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:32:49 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E15106566C; Wed, 11 Jul 2012 22:32:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2644D8FC0C; Wed, 11 Jul 2012 22:32:49 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6BMWmt4010113; Wed, 11 Jul 2012 15:32:48 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6BMWlJk010112; Wed, 11 Jul 2012 15:32:47 -0700 (PDT) (envelope-from sgk) Date: Wed, 11 Jul 2012 15:32:47 -0700 From: Steve Kargl To: Diane Bruce Message-ID: <20120711223247.GA9964@troutmask.apl.washington.edu> References: <4FC43C8F.5090509@missouri.edu> <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <20120711212009.GA15542@night.db.net> <20120711214346.GA9877@troutmask.apl.washington.edu> <20120711215414.GA16350@night.db.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120711215414.GA16350@night.db.net> User-Agent: Mutt/1.4.2.3i Cc: Peter Jeremy , David Schultz , freebsd-current@FreeBSD.ORG, Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 22:32:49 -0000 On Wed, Jul 11, 2012 at 04:54:14PM -0500, Diane Bruce wrote: > On Wed, Jul 11, 2012 at 02:43:46PM -0700, Steve Kargl wrote: > > On Wed, Jul 11, 2012 at 04:20:09PM -0500, Diane Bruce wrote: > > > On Tue, Jul 10, 2012 at 08:02:33AM -0600, Warner Losh wrote: > > > > > > > > On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote: > > > > > ... > > > > You submitted on June 6th, 2010. I commented on why > > the patch should be avoided on June 15th, 2010. I see > > no follow-ups from you that give the details on how > > you went about testing and fixing the code? > > Steve, I misunderstood. Someone told me you and Bruce had some code which > made this PR unnecessary, I did mean to close the PR as this is what I had > heard. If that is not true I'd be happy to help you guys in any way I can. > > And my apologies, I should have verfied directly with you rather than > listening to hearsay. I know an approach to implementing many of the missing functions. The problem is that over the last 2 years or so I have had very little time to work on coding nor am I paid to work on such code. When I do find some free time, I look at what is missing and start to put together a new function. At the moment, it seems that it takes 3+ years to get a new function written, tested, and committed. Given that it seems that only das@, bde@, and I work on libm, I suspect it will be completed by the time I retire. At one time I had hoped others would step up to help write the missing function, but most people seem to push the "easy button" and want to grab either cephes or netlib's libm. There are technical issues with this approach that I won't rehash again. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jul 11 22:44:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9F471065670 for ; Wed, 11 Jul 2012 22:44:57 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 78CE08FC16 for ; Wed, 11 Jul 2012 22:44:57 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3004957pbb.13 for ; Wed, 11 Jul 2012 15:44:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=qbfCTV6dbN8UnqvrR5PykniwBVg3o2Z1lMeuUokwF2s=; b=DwpEBsaHN4/UNcLKRo2b8ybz1C+RHtyU1eILGii41IIJRlce0nqzqTOGbOgFc8otFu awbcPnqbVF5Sl62vEJzq2su3mCFq1mDLE1v1KCG7APS85uWcFabRJtvjA6F9enRuQs0q D0BW6MqH4cIEVTTXPKRHhVPKBzq+OPIxc94f0gV2SE3rF1T7Hw5wT8HireA5uo3a4gUJ 71cJ7EwEflYUhJeZRD7RDDX3fmmBn3ue633LytIqCca+F2KzM6R01TReildVQSVVBtS7 uqa7jQ/NIKVSuXxwYntjmcAqcJkcnP4noGSmf9QCV/eNZptCyxHQEYkqMj5xD/4JXMN/ Sknw== MIME-Version: 1.0 Received: by 10.68.240.73 with SMTP id vy9mr81201045pbc.102.1342046697258; Wed, 11 Jul 2012 15:44:57 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.20.71 with HTTP; Wed, 11 Jul 2012 15:44:57 -0700 (PDT) In-Reply-To: References: <201207110257.q6B2vXeW018145@svn.freebsd.org> <20120711195341.GK3599@albert.catwhisker.org> Date: Thu, 12 Jul 2012 10:44:57 +1200 X-Google-Sender-Auth: d6fBxc-ixwnJQu7VPfezUCaz6Nc Message-ID: From: Andrew Thompson To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlhYiLxU/1KahRsqmF/IzRUtI0ygxLsKdUVLTKc/uPAElKfGy8IUpoMS7ZlHSK4HdyKLlcu Cc: src-committers@freebsd.org, current@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r238361 - head/sys/dev/usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 11 Jul 2012 22:44:57 -0000 On 12 July 2012 10:15, Adrian Chadd wrote: > Again, that just touched usb. So, how'd that affect non-USB wifi cloning? I guess cloning is first match wins and usb was incorrectly matching wlan* Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 03:47:52 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C48106566B; Thu, 12 Jul 2012 03:47:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6158FC0A; Thu, 12 Jul 2012 03:47:51 +0000 (UTC) Received: by lbon10 with SMTP id n10so3307323lbo.13 for ; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ykhiy4BXcrqg714iHPrnFmeaf2/wIiragN6AFheEyV0=; b=l4vLuz8Kl4iBK4NMEn+ZryNvZ5cJMmAeah7WRf9oVxVqofUyxnJHrgGxJeixY02a3o Pi1xb3DfElMay7DrKrb/dIsBjlDBLNAlkaTVfwGKLHz6AnFMoqfYVohEYzVMXRQGAWL0 +yDrzZrydLtOo7SwSlW2gyk6X1JGhQkqnXV5copY7Ae9Y8ILs4Zy6T0Awc4NTQKa3Jv3 27DzZYA6N2FtKCRpsfD4FI4o1dOjJvWzCod2sJ3NiZHg6Reebkh6g1FMXdG4HCeVqlR0 BPQK3/5P+4l3pVEy0yGwaLQ4fkyQVjCfWKhDE2zQvUF82aG85xa13wFrsInCgug48EkY cSjw== MIME-Version: 1.0 Received: by 10.152.132.40 with SMTP id or8mr51802446lab.24.1342064870717; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Wed, 11 Jul 2012 20:47:50 -0700 (PDT) In-Reply-To: References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> Date: Wed, 11 Jul 2012 23:47:50 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 03:47:52 -0000 Hi, On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >> >> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >> >>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh wrote: >>>> >>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>>> >>>>> Hi, >>>>> >>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh wrote: >>>>>> >>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports more >>>>>>> than one interface, and one of its child has need to use more than = one >>>>>>> interface, each interfaces cannot register, concurrently, its own >>>>>>> ivar. While I try to always have a single child per >>>>>>> interface/resource, I need to keep some compatibility with the old = way >>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>>> userland). So, it would have been nice if ivar had been per-interfa= ce, >>>>>>> not global and unique to one device. >>>>>> >>>>>> There's one pointer for the ivars. The bus code gets to determine w= hat the ivar looks like, because the interface is totally private to the bu= s. So long as it returns the right thing for any key that's presented, it = doesn't matter quite how things are done. >>>>>> >>>>>> So I'm not sure I understand what you are saying here. >>>>>> >>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, needs t= o >>>>> use both interfaces. There is no generic way for dev0 to export >>>>> independent ivars for both interface. For now, I restricted the >>>>> function of the second interface not to need ivar, but that's kind of >>>>> hackish. >>>> >>>> Only if the IVARs for interface A and interface B have overlapping val= ues. If the Ivar keys don't overlap, then there's no problems at all. Cer= tainly less hackish than not using them at all. Since dev0 knows the layou= t of the ivar that it set on its child, this presents no problems at all. = It would return the values from A from the right part of the ivar, and thos= e from B in the right part. Apart from the coordination of Ivar numbers, a= s I outlined in my last post, there's no issue here. >>>> >>> I think we should not be talking about the same API here. I have no >>> idea what you mean by "the key to value translation", nor "Ivar >>> numbers". What I refer to is that device_set_ivars() / >>> device_get_ivars() acts on a single instance variables from `struct >>> device': `ivars'. In that case, I do not really see how to set that >>> specific field to two distinct values for each interfaces. >> >> We are talking about the ivar interface. You are just misunderstanding = how it is used. >> > yes I indeed did... silly, silly me :-) > Actually, no. I wasn't that silly, neither was I misunderstanding anything beside how *you* wanted it to be used, which is, I sorry to say, unacceptable. The last thing I want is to pollute an interface with a single-purpose, hand-crafted, bus. I was to just throw away all that ivar stuff and go into hinted child configuration for now, waiting for FDT... but of course, I figured out after a few hours that hinted child attachment requires `bus_hinted_child' to be set in the parent, as does bus_enumerate_hinted_children() / bus_generic_attach() to explicitly pollute my code. All this stuff should be done implicitly to support N:1 interfaces/client relationship. N *independent* interfaces being provided by a single driver; of course, I'm not even going back to require those interface being provided by multiple drivers, it is already a dead end. I am not even sure any driver in the tree provides more than one interface.= .. For whatever reason, I am more and more thinking that this all new-bus[0] stuff is *way* overkill, static, bloated at will, and missing critical features; a huge PITA to use, for the intended purpose. /me pissed. - Arnaud [0]: damn, why is it even called "newbus", this stuff is 14 years old. It really belongs to a museum, not production code... From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 03:51:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EC3D106566C; Thu, 12 Jul 2012 03:51:07 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 978B88FC0C; Thu, 12 Jul 2012 03:51:06 +0000 (UTC) Received: by lbon10 with SMTP id n10so3310776lbo.13 for ; Wed, 11 Jul 2012 20:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ld4EQ0vVtcIYE4PJWTr+vZeGtinJ1zcOqM1qyRqgms8=; b=QUChQv8D1lKm9y/Si+SacNnAMbw2Fnbfjgr8B54Esm69Ks2bBE9sOgKTU7lel2WWB0 Lu+6J2kC1K9qkTCpMN6GcX16m71AXqOTedkyZy/8un4madZIl1dRV+/xzvJIsnGpCGUQ fvflu2O/rxQh3d05pPRwwLMPchgGi8JnavnuwhQa6ZUwlvAJB/chcu22hbJK0nCz0HGk ZIhS4HDvOB/h6tb4IM0M+HZIFoysK+JdvZz9Yh21xUrFk5xLueDbgFbYWiDplaLCj9tm IsbdxCSxRN76tU1b1+gTwQav6uexxyHS3pR/XMOew+OpoIWNPmwj9/3F4nvA14APAXv2 bJYA== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr51660627lab.20.1342065065417; Wed, 11 Jul 2012 20:51:05 -0700 (PDT) Received: by 10.114.13.68 with HTTP; Wed, 11 Jul 2012 20:51:05 -0700 (PDT) In-Reply-To: <201207091127.30289.jhb@freebsd.org> References: <08E43D4E-EBB0-4469-9FC0-4E05C1D68DE4@bsdimp.com> <201207091127.30289.jhb@freebsd.org> Date: Wed, 11 Jul 2012 23:51:05 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Warner Losh Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 03:51:07 -0000 Hi, On Mon, Jul 9, 2012 at 11:27 AM, John Baldwin wrote: > Also, I think we should do this in general. We already have one example (e.g. > ACPI IVARs start at 100 so that things like the ACPI PCI bus driver can > provide both ACPI and PCI IVARs to child devices). I think we should assign > each bus it's own IVAR range. It would make it easier to determine if a > specific IVAR is event supported. Certainly I think ISA and PCI at a minimum > should be changed to start at, say, 200 and 300. > What's the point doing that ? Let's just resign to the conclusion that FreeBSD devices' subsystem provides no dynamic way for a client device to deals with multiple bus driver. Instead all possible combination have to be harcoded and hand-crafted, when at all possible, to look like they're coming from a single bus... But again, newbus is 14 years old... - Arnaud From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 05:20:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D55106564A for ; Thu, 12 Jul 2012 05:20:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C40178FC19 for ; Thu, 12 Jul 2012 05:20:12 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2320608ggn.13 for ; Wed, 11 Jul 2012 22:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gQj15LefXJAW00EkiFPzDQ1KcGKgEl1c2SqZv3ONKC4=; b=jBk+luVI0Gd5ozIx5Ww5CTYYTdjo/m49HFLzAfE5XVRW2h2vHW9smregBeocFOeBQ+ 9Oi57w3Yj2FOoMIzjVr3IknMHiPmrN8L+VFY2CnJa7GiVnzUgFzfU8n5x5n6Ae+AZnaL nl9jM7js37Fh/SpZvpLNnxodH7G0Ot3BZGFHLYDdh9NyJep2O4PaNPhWZ2NFkhOAX8Fx k9ZbReQNdpb+ZwCK1KHm4wJXIBjmWh/noq95JqdBNjVMJmZ99azgRkOvZ+eCr603DaFZ KSFnUJU4njoh97DWD1dMbcXBqDoHvv+4hmxXjhxjAusYHw81GVKeUzpLOLLJi6O44kRf CIWA== Received: by 10.66.83.33 with SMTP id n1mr87325444pay.7.1342070411875; Wed, 11 Jul 2012 22:20:11 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id se9sm3120525pbc.25.2012.07.11.22.20.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 22:20:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 11 Jul 2012 23:20:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl9NaGXV+EGrQCtv09EaLgGrz5uHYrOL7TkkwUFud+RYHlzg/X+6wGtbchBjl2TcTAdV0j1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 05:20:13 -0000 On Jul 11, 2012, at 9:47 PM, Arnaud Lacombe wrote: > Hi, >=20 > On Mon, Jul 9, 2012 at 1:17 AM, Arnaud Lacombe = wrote: >> Hi, >>=20 >> On Mon, Jul 9, 2012 at 12:37 AM, Warner Losh wrote: >>>=20 >>> On Jul 8, 2012, at 9:46 PM, Arnaud Lacombe wrote: >>>=20 >>>> On Sun, Jul 8, 2012 at 11:31 PM, Warner Losh = wrote: >>>>>=20 >>>>> On Jul 8, 2012, at 9:26 PM, Arnaud Lacombe wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> On Sun, Jul 8, 2012 at 10:07 PM, Warner Losh = wrote: >>>>>>>=20 >>>>>>> On Jul 8, 2012, at 7:22 PM, Arnaud Lacombe wrote: >>>>>>>> Ok, yet another Newbus' limitation. Assuming a device exports = more >>>>>>>> than one interface, and one of its child has need to use more = than one >>>>>>>> interface, each interfaces cannot register, concurrently, its = own >>>>>>>> ivar. While I try to always have a single child per >>>>>>>> interface/resource, I need to keep some compatibility with the = old way >>>>>>>> of doing thing (POLA wrt. drivers I cannot/will not convert and >>>>>>>> userland). So, it would have been nice if ivar had been = per-interface, >>>>>>>> not global and unique to one device. >>>>>>>=20 >>>>>>> There's one pointer for the ivars. The bus code gets to = determine what the ivar looks like, because the interface is totally = private to the bus. So long as it returns the right thing for any key = that's presented, it doesn't matter quite how things are done. >>>>>>>=20 >>>>>>> So I'm not sure I understand what you are saying here. >>>>>>>=20 >>>>>> dev0 implements two interfaces: A and B. dev1, child of dev0, = needs to >>>>>> use both interfaces. There is no generic way for dev0 to export >>>>>> independent ivars for both interface. For now, I restricted the >>>>>> function of the second interface not to need ivar, but that's = kind of >>>>>> hackish. >>>>>=20 >>>>> Only if the IVARs for interface A and interface B have overlapping = values. If the Ivar keys don't overlap, then there's no problems at = all. Certainly less hackish than not using them at all. Since dev0 = knows the layout of the ivar that it set on its child, this presents no = problems at all. It would return the values from A from the right part = of the ivar, and those from B in the right part. Apart from the = coordination of Ivar numbers, as I outlined in my last post, there's no = issue here. >>>>>=20 >>>> I think we should not be talking about the same API here. I have no >>>> idea what you mean by "the key to value translation", nor "Ivar >>>> numbers". What I refer to is that device_set_ivars() / >>>> device_get_ivars() acts on a single instance variables from `struct >>>> device': `ivars'. In that case, I do not really see how to set that >>>> specific field to two distinct values for each interfaces. >>>=20 >>> We are talking about the ivar interface. You are just = misunderstanding how it is used. >>>=20 >> yes I indeed did... silly, silly me :-) >>=20 > Actually, no. I wasn't that silly, neither was I misunderstanding > anything beside how *you* wanted it to be used, which is, I sorry to > say, unacceptable. The last thing I want is to pollute an interface > with a single-purpose, hand-crafted, bus. I was to just throw away all > that ivar stuff and go into hinted child configuration for now, > waiting for FDT... but of course, I figured out after a few hours that > hinted child attachment requires `bus_hinted_child' to be set in the > parent, as does bus_enumerate_hinted_children() / bus_generic_attach() > to explicitly pollute my code. All this stuff should be done > implicitly to support N:1 interfaces/client relationship. N > *independent* interfaces being provided by a single driver; of course, > I'm not even going back to require those interface being provided by > multiple drivers, it is already a dead end. >=20 > I am not even sure any driver in the tree provides more than one = interface... >=20 > For whatever reason, I am more and more thinking that this all > new-bus[0] stuff is *way* overkill, static, bloated at will, and > missing critical features; a huge PITA to use, for the intended > purpose. >=20 > /me pissed. >=20 > - Arnaud >=20 > [0]: damn, why is it even called "newbus", this stuff is 14 years old. > It really belongs to a museum, not production code... I'm sorry you feel that way. Honestly, though, I think you'll be more pissed when you find out that = the N:1 interface that you want is being done in the wrong domain. But = I've been wrong before and look forward to seeing your replacement. acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI = interfaces. Warner= From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 06:43:42 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1A2F106566B; Thu, 12 Jul 2012 06:43:42 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 845838FC0A; Thu, 12 Jul 2012 06:43:41 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q6C6hIr8051633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 15:43:31 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q6C6hFbj007308; Thu, 12 Jul 2012 15:43:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 12 Jul 2012 15:43:09 +0900 (JST) Message-Id: <20120712.154309.1565855047300110662.hrs@allbsd.org> To: thompsa@FreeBSD.org From: Hiroki Sato In-Reply-To: References: <20120711195341.GK3599@albert.catwhisker.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jul_12_15_43_09_2012_012)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Thu, 12 Jul 2012 15:43:33 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, 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: adrian@FreeBSD.org, src-committers@FreeBSD.org, current@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r238361 - head/sys/dev/usb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 06:43:42 -0000 ----Security_Multipart(Thu_Jul_12_15_43_09_2012_012)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Thompson wrote in : th> On 12 July 2012 10:15, Adrian Chadd wrote: th> > Again, that just touched usb. So, how'd that affect non-USB wifi cloning? th> th> I guess cloning is first match wins and usb was incorrectly matching wlan* Yes, a greedier ifname matching rule can unintentionally win regardless of the interface type. -- Hiroki ----Security_Multipart(Thu_Jul_12_15_43_09_2012_012)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/+cf0ACgkQTyzT2CeTzy2LDwCgozmSWQ9KbUr/eh78FBazNZRt d4oAn0jGZuXDJn2kAGqYzdPPSSPHIz3G =PXUn -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jul_12_15_43_09_2012_012)---- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 07:01:40 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3BFA1065670; Thu, 12 Jul 2012 07:01:40 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6FF8FC12; Thu, 12 Jul 2012 07:01:40 +0000 (UTC) Received: by weyx56 with SMTP id x56so1877601wey.13 for ; Thu, 12 Jul 2012 00:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hg1ixnKhpS5GFnhza6la6hVviiJFKEM77Pbl6oNpOEc=; b=X70qm9UGDLuxesowOKAi2+G6UFBgNiK+CLf4Lnwz2kmsk+wkdLtDVcKmWqbX11RmCO y1F8iXlJ8+2Jgr2ZhrjTX2aB7+aBEbuf4bxZYg7bVrryENtBFKAY2nW6QQjVpMIOZkps cB3JfWsxStroNJWQeL1aos744ykfMyXUj6eL0dcidX7vAU300DroVxxXo66Ugo3QEki1 VNUSsnzuWixVS3aMFZFFdoT1gquw7yZnxZ2CogoqDCXfrxm3BeV7aDrloTEI8fSee3s+ TCFmhKUY/URGZe7ERrr2GZ1ho8OZGuk0aDz1omNrGS9zXApVAOeWjfjRutFYAonj7ZmB 4i2w== MIME-Version: 1.0 Received: by 10.216.29.10 with SMTP id h10mr2475824wea.126.1342076497225; Thu, 12 Jul 2012 00:01:37 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Thu, 12 Jul 2012 00:01:36 -0700 (PDT) In-Reply-To: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> Date: Thu, 12 Jul 2012 03:01:36 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 07:01:40 -0000 Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > I'm sorry you feel that way. > > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > > acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces. > Does it ? From the definition of `acpi_pcib_acpi_methods', I can only see a single pcib(4) interface being exported. Moreover, I do not seem to be able to find any clue that would led any ACPI devices to attach on acpi_pcib_acpi(4), neither to find how could acpi_get_flags() ends up in acpi_pcib_read_ivar() ? Thks, - Arnaud From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 07:19:37 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C1E0E106564A; Thu, 12 Jul 2012 07:19:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9127B8FC0A; Thu, 12 Jul 2012 07:19: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 q6C7JUuF094456; Thu, 12 Jul 2012 03:19:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6C7JUWX094455; Thu, 12 Jul 2012 07:19:30 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jul 2012 07:19:30 GMT Message-Id: <201207120719.q6C7JUWX094455@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 07:19:37 -0000 TB --- 2012-07-12 06:10:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-12 06:10:00 - 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 --- 2012-07-12 06:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-12 06:10:00 - cleaning the object tree TB --- 2012-07-12 06:10:00 - cvsupping the source tree TB --- 2012-07-12 06:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-12 06:11:04 - building world TB --- 2012-07-12 06:11:04 - CROSS_BUILD_TESTING=YES TB --- 2012-07-12 06:11:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-12 06:11:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-12 06:11:04 - SRCCONF=/dev/null TB --- 2012-07-12 06:11:04 - TARGET=arm TB --- 2012-07-12 06:11:04 - TARGET_ARCH=arm TB --- 2012-07-12 06:11:04 - TZ=UTC TB --- 2012-07-12 06:11:04 - __MAKE_CONF=/dev/null TB --- 2012-07-12 06:11:04 - cd /src TB --- 2012-07-12 06:11:04 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 12 06:11:05 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 12 07:16:04 UTC 2012 TB --- 2012-07-12 07:16:04 - cd /src/sys/arm/conf TB --- 2012-07-12 07:16:04 - /usr/sbin/config -m ATMEL TB --- 2012-07-12 07:16:04 - building ATMEL kernel TB --- 2012-07-12 07:16:04 - CROSS_BUILD_TESTING=YES TB --- 2012-07-12 07:16:04 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-12 07:16:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-12 07:16:04 - SRCCONF=/dev/null TB --- 2012-07-12 07:16:04 - TARGET=arm TB --- 2012-07-12 07:16:04 - TARGET_ARCH=arm TB --- 2012-07-12 07:16:04 - TZ=UTC TB --- 2012-07-12 07:16:04 - __MAKE_CONF=/dev/null TB --- 2012-07-12 07:16:04 - cd /src TB --- 2012-07-12 07:16:04 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Thu Jul 12 07:16:04 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/uart_bus_at91usart.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/uart_cpu_at91rm9200usart.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/uart_dev_at91usart.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91soc.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91rm9200.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91sam9260.c cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/arm/at91/at91sam9g20.c /src/sys/arm/at91/at91sam9g20.c:253: error: unknown field 'soc_childpren' specified in initializer *** Error code 1 Stop in /obj/arm.arm/src/sys/ATMEL. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-12 07:19:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-12 07:19:30 - ERROR: failed to build ATMEL kernel TB --- 2012-07-12 07:19:30 - 2607.46 user 583.59 system 4170.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 10:01:14 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D2D6106566C; Thu, 12 Jul 2012 10:01:14 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 637F38FC15; Thu, 12 Jul 2012 10:01:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6CA1EFs094741; Thu, 12 Jul 2012 10:01:14 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6CA1EpA094740; Thu, 12 Jul 2012 10:01:14 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Thu, 12 Jul 2012 10:01:10 +0000 From: Baptiste Daroussin To: ports-announce@FreeBSD.org, ports@FreeBSD.org, current@FreeBSD.org Message-ID: <20120712100110.GA34228@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 10:01:14 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On behalf of the pkgng team I'm really pleased to announce pkg 1.0 RC1 (aka pkgng) Only bug fixes will be accepted in the RC phase. What is pkg ----------- pkg is a new package manager for FreeBSD. It is designed as a replacement for the pkg_* tools, and as a full featured binary package manager. It provides a library that does all the work, and a frontend to be used by users The ports tree is already able to transparently switch to pkgng by default by adding WITH_PKGNG=yes to your make.conf It provides a pkg2ng tool to help converting from an old installation to a new one. Test repositories are available on http://pkgbeta.freebsd.org/ (I try to update them as fast as I can) It will live forever in the ports tree (with a binary bootstrap in 9 and 10) Why pkg? -------- pkg_* tools have become hardly maintainable over the time, it lacks lots of features most of people are expecting from a package manager: - binary upgrade - ability to search information about remote packages - real reverse dependency tracking - tracking leaves - many more. Third party tools ----------------- Tools supporting natively pkgng - ports-mgmt/portupgrade-devel (soon the main portupgrade will support) - ports-mgmt/pkg_cutleaves - ports-mgmt/poudriere - ports-mgmt/portdowngrade - ports-mgmt/tinderbox-devel (support can be improved) Tools supporting pkgng via a patch (I hope it will be reviewed/integrated soon) - ports-mgmt/portmaster (https://github.com/pkgng/pkgng/blob/master/ports/patch-portmaster-pkgng) Tools being worked on (or I heard people are interested) : - salt support (in version 0.10) http://salt.readthedocs.org/en/v0.10.0/ref/modules/all/salt.modules.freebsdpkg.html - cfengine support - puppet support: (https://github.com/xaque208/puppet-pkgng) - ruby bindings: (https://github.com/baloo/libpkg-ruby/) - PackageKit Links ----- - http://wiki.freebsd.org/PkgPrimer - http://wiki.freebsd.org/pkgng Please report bugs in the github issue tracker: - http://github.com/pkgng/pkgng Schedule -------- The plan is to switch the ports tree to pkgng on CURRENT by default on July 25th No dates are planned yet for other branches. Note that there will be a NO_PKGNG knob for some time (undefined yet) for people not will to switch on July 25th Please also note that some ports won't work with pkgng right now, because pkgng is more strict than pkg_install on purpose. The major one is: nvidia drivers, because pkgng does not allow to overwrite a file owned by another package, and we will not accept any hacks for that in pkgng. Road to next version -------------------- The road to the next version is already open and lots of work will happen, list of ideas: - remote repositories will be able to display update messages - optionnal remote files repository to be able to search which packages to install if you want a known binary - real solver, - better support for multi repository - provides/requires support - stabilisation of the library API - reduce as much as possible scripting in packages to allow cross installation - many more :D regards, Bapt --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/+oGYACgkQ8kTtMUmk6EyZ0QCfep1QFS5xZsBizeWQ7tj0jdxW +7IAnRfF0bv/W3+A6387XCxKrRBvDiky =TO0o -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 10:12:19 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8BF8106566C; Thu, 12 Jul 2012 10:12:19 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB2218FC17; Thu, 12 Jul 2012 10:12:15 +0000 (UTC) Received: by bkcje9 with SMTP id je9so2057444bkc.13 for ; Thu, 12 Jul 2012 03:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DOoZ8o2vVAETP1Iw9aq9iRkgLm+RP0HGodyB46t+1Ek=; b=TOl/tdWvNoS/y0peG0mF62q9dd0Z5sK0l1CGixlIybeNOSfm7tTA/SOdgit7P7/MYz lDzEyemP+OrBF1nduYx0jo2OLMX1qViKeg9fioemKL/uqg89a5TUFcwKn5hcixRlXLbd qo1o5yG/IeS+BJgC/HGJQOCm70fR6e+45933Jjq+COqxX3JT0eDIj0eCIsdVKntVOGUv RQUGSyW9zZy9dwm3izewAIjU7zw0sMNluoj1LjWXvbph6XFCSU3Ng3A4wM+eijjlvcdc KnHbbadCJ7TlyyPA7RfL6c+y+GUCNw8Xs+iimSKIa2VudofA0hedqJtnC27ourN5z4Lp hOaw== Received: by 10.204.156.17 with SMTP id u17mr6213804bkw.52.1342087934730; Thu, 12 Jul 2012 03:12:14 -0700 (PDT) MIME-Version: 1.0 Sender: villa.alberto@gmail.com Received: by 10.204.200.209 with HTTP; Thu, 12 Jul 2012 03:11:53 -0700 (PDT) In-Reply-To: <20120712100110.GA34228@ithaqua.etoilebsd.net> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> From: Alberto Villa Date: Thu, 12 Jul 2012 12:11:53 +0200 X-Google-Sender-Auth: D59DY8uuPqJF8L-GBpjHDEaMGH8 Message-ID: To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: ports@freebsd.org, ports-announce@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 10:12:19 -0000 On Thu, Jul 12, 2012 at 12:01 PM, Baptiste Daroussin wrote: > Third party tools > ----------------- > > Tools supporting natively pkgng > - ports-mgmt/portupgrade-devel (soon the main portupgrade will support) > - ports-mgmt/pkg_cutleaves > - ports-mgmt/poudriere > - ports-mgmt/portdowngrade > - ports-mgmt/tinderbox-devel (support can be improved) Also: - ports-mgmt/portbuilder. -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 12:35:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 290541065670; Thu, 12 Jul 2012 12:35:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C0BE88FC18; Thu, 12 Jul 2012 12:35:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 06565B93A; Thu, 12 Jul 2012 08:35:05 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 12 Jul 2012 08:01:25 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207120801.25810.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 08:35:05 -0400 (EDT) Cc: FreeBSD Hackers , Warner Losh , Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 12:35:06 -0000 On Thursday, July 12, 2012 3:01:36 am Arnaud Lacombe wrote: > Hi, > > On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > > I'm sorry you feel that way. > > > > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > > > > acpi_pcib_acpi.c, btw, implements both PCIB interfaces and ACPI interfaces. > > > Does it ? From the definition of `acpi_pcib_acpi_methods', I can only > see a single pcib(4) interface being exported. Moreover, I do not seem > to be able to find any clue that would led any ACPI devices to attach > on acpi_pcib_acpi(4), neither to find how could acpi_get_flags() ends > up in acpi_pcib_read_ivar() ? acpi_get_handle() is certainly supported. Relevant code snippets: sys/dev/acpica/acpivar.h: /* * Note that the low ivar values are reserved to provide * interface compatibility with ISA drivers which can also * attach to ACPI. */ #define ACPI_IVAR_HANDLE 0x100 #define ACPI_IVAR_UNUSED 0x101 /* Unused/reserved. */ #define ACPI_IVAR_PRIVATE 0x102 #define ACPI_IVAR_FLAGS 0x103 /* * Accessor functions for our ivars. Default value for BUS_READ_IVAR is * (type) 0. The accessor functions don't check return values. */ #define __ACPI_BUS_ACCESSOR(varp, var, ivarp, ivar, type) \ \ static __inline type varp ## _get_ ## var(device_t dev) \ { \ uintptr_t v = 0; \ BUS_READ_IVAR(device_get_parent(dev), dev, \ ivarp ## _IVAR_ ## ivar, &v); \ return ((type) v); \ } \ \ static __inline void varp ## _set_ ## var(device_t dev, type t) \ { \ uintptr_t v = (uintptr_t) t; \ BUS_WRITE_IVAR(device_get_parent(dev), dev, \ ivarp ## _IVAR_ ## ivar, v); \ } __ACPI_BUS_ACCESSOR(acpi, handle, ACPI, HANDLE, ACPI_HANDLE) __ACPI_BUS_ACCESSOR(acpi, private, ACPI, PRIVATE, void *) __ACPI_BUS_ACCESSOR(acpi, flags, ACPI, FLAGS, int) sys/dev/acpica/acpi_pcib_acpi.c: /* * Support for standard PCI bridge ivars. */ static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_hpcib_softc *sc = device_get_softc(dev); switch (which) { case PCIB_IVAR_DOMAIN: *result = sc->ap_segment; return (0); case PCIB_IVAR_BUS: *result = sc->ap_bus; return (0); case ACPI_IVAR_HANDLE: *result = (uintptr_t)sc->ap_handle; return (0); case ACPI_IVAR_FLAGS: *result = (uintptr_t)sc->ap_flags; return (0); } return (ENOENT); } sys/dev/acpica/acpi_pcib_pci.c: static int acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_pcib_softc *sc = device_get_softc(dev); switch (which) { case ACPI_IVAR_HANDLE: *result = (uintptr_t)sc->ap_handle; return (0); } return (pcib_read_ivar(dev, child, which, result)); } This is used by the ACPI PCI bus driver to detect buses that are enumerated via ACPI and to then provide the ACPI_IVAR_HANDLE for all such PCI devices. Note that ACPI PCI uses its own ivars structure (acpi_pci_devinfo) that extends the base PCI ivars to add ACPI handle and flags. sys/dev/acpi/acpi_pci.c: struct acpi_pci_devinfo { struct pci_devinfo ap_dinfo; ACPI_HANDLE ap_handle; int ap_flags; }; ... static int acpi_pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct acpi_pci_devinfo *dinfo; dinfo = device_get_ivars(child); switch (which) { case ACPI_IVAR_HANDLE: *result = (uintptr_t)dinfo->ap_handle; return (0); case ACPI_IVAR_FLAGS: *result = (uintptr_t)dinfo->ap_flags; return (0); } return (pci_read_ivar(dev, child, which, result)); } ... static int acpi_pci_attach(device_t dev) { ... /* * First, PCI devices are added as in the normal PCI bus driver. * Afterwards, the ACPI namespace under the bridge driver is * walked to save ACPI handles to all the devices that appear in * the ACPI namespace as immediate descendants of the bridge. * * XXX: Sometimes PCI devices show up in the ACPI namespace that * pci_add_children() doesn't find. We currently just ignore * these devices. */ pci_add_children(dev, domain, busno, sizeof(struct acpi_pci_devinfo)); AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, acpi_pci_save_handle, NULL, dev, NULL); ... } The main use of this feature is to get PCI interrupt routing to work correctly for ACPI bridges (i.e. using ACPI's _PRT method to route interrupts for all ACPI-enumerated bridges). The first way this is accomplished is by having each ACPI PCI bridge driver export it's own handle as the handle for it's child. This allows the ACPI PCI bus driver to detect a bus that is enumerated via ACPI and export ACPI handle ivars for each PCI device: sys/dev/acpica/acpi_pci.c: static int acpi_pci_probe(device_t dev) { if (acpi_get_handle(dev) == NULL) return (ENXIO); device_set_desc(dev, "ACPI PCI bus"); return (0); } (Note: it is calling acpi_get_handle() on a pcib device!) Secondly, to handle PCI-PCI bridges the ACPI PCI-PCI bridge driver checks for a valid ACPI handle on each PCI-PCI bridge device and returns a higher priority to claim that bridge (rather than the generic PCI-PCI bridge driver). Note again that it is calling acpi_get_handle() on a PCI device: sys/dev/acpica/acpi_pcib_pci.c: static int acpi_pcib_pci_probe(device_t dev) { if (pci_get_class(dev) != PCIC_BRIDGE || pci_get_subclass(dev) != PCIS_BRIDGE_PCI || acpi_disabled("pci")) return (ENXIO); if (acpi_get_handle(dev) == NULL) return (ENXIO); if (pci_cfgregopen() == 0) return (ENXIO); device_set_desc(dev, "ACPI PCI-PCI bridge"); return (-1000); } New-bus is certainly not the only way to organize a device hierarchy and is not perfect, but in your case I suggest you tone down your language until you have enough information to develop an informed opinion. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 13:21:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78FA9106564A for ; Thu, 12 Jul 2012 13:21:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id DAAE08FC0C for ; Thu, 12 Jul 2012 13:21:03 +0000 (UTC) Received: by ggnm2 with SMTP id m2so2740386ggn.13 for ; Thu, 12 Jul 2012 06:21:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Bg654VVqjMWN+VjKSmVNGjVxSOY4jJKrne9NDuPlQ/Y=; b=PWRROd3tJgNkZBkt8Yf+qsUJJMWeu5EO0TblR43HFePmBeao8cyZKj+uItR3aA11rI VXUIPXNCFsnFjEwToWBKkaHl00HXijOW9ZNkFfMBAyTl5sn33WiULe5N1w/FTBdOZDZS Q2E0mIO8txjksHANngEdBnaXbCUeVH8mk7Br1yQ88dKsBm7r/VVobOUYAsB9berntSNF LxnT7kEfyUEna+Yqli1q1p9+MrcFUBFo4vzIRRaZzKGN6BOQdqXDg4Jf3Gn1R6bVYnNN Id+OgiN0DJZSWQNVqnncDBS0zxJBo79w9ovLtFAiRnIwT1dup5N/ehPW8zj1KtvdlfMH dMBw== Received: by 10.68.227.198 with SMTP id sc6mr5423759pbc.138.1342099262621; Thu, 12 Jul 2012 06:21:02 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id gh9sm3865763pbc.20.2012.07.12.06.21.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 06:21:01 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201207120801.25810.jhb@freebsd.org> Date: Thu, 12 Jul 2012 07:20:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <40098958-831C-49AE-8A7A-BE0B8EE15C34@bsdimp.com> References: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> <201207120801.25810.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkZnHaTV7hK1eQ+4IVgBnJ4oZqD2mV2e0kCUWCfHjBtAIbivj1H+wy7EKuh40GEzEEPy7ku Cc: FreeBSD Hackers , freebsd-current@freebsd.org, Arnaud Lacombe Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 13:21:04 -0000 On Jul 12, 2012, at 6:01 AM, John Baldwin wrote: > New-bus is certainly not the only way to organize a device hierarchy = and is=20 > not perfect, but in your case I suggest you tone down your language = until you=20 > have enough information to develop an informed opinion. It is also not the only way to represent relationships between objects, = or to export services to the rest of the kernel. =46rom earlier = descriptions, it seems like some of these relationships aren't very = newbus-y. =46rom what I know about FDT, many of them are 'this device's = interrupt pin is tied to GPIO 12 on controller 3' which isn't a = parent/child relationship, but rather some kind of interrupt cookie = you'll need to implement bus_setup_intr. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 14:40:28 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68127106564A; Thu, 12 Jul 2012 14:40:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8858FC14; Thu, 12 Jul 2012 14:40:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 99467B94E; Thu, 12 Jul 2012 10:40:27 -0400 (EDT) From: John Baldwin To: current@freebsd.org Date: Thu, 12 Jul 2012 10:40:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201207121040.27116.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 10:40:27 -0400 (EDT) Cc: Peter Jeremy , scottl@freebsd.org Subject: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 14:40:28 -0000 I have a need to allocate static DMA memory via bus_dmamem_alloc() that is also WC (for a PCI-e device so it can use "nosnoop" transactions). This is similar to what the nvidia driver needs, but in my case it is much cleaner to allocate the memory via bus dma since the existing code I am extending all uses busdma. I have a patch to implement this on 8.x for amd64 that I can port to HEAD if folks don't object. What I would really like to do is add a new paramter to bus_dmamem_alloc() to specify the memory attribute to use, but I am hesitant to break that API. Instead, I added a new flag similar to the existing BUS_DMA_NOCACHE used to allocate UC memory. While doing this, I ran into an old bug, which is that if you were to call bus_dmamem_alloc() with BUS_DMA_NOCACHE but a tag that otherwise fell through to using malloc() instead of contigmalloc(), bus_dmamem_alloc() would actually change the state of the entire page. This seems wrong. Instead, I think that any request for a non-default memory attribute should always use contigmalloc(). In fact, even better is to call kmem_alloc_contig() directly rather than using contigmalloc(). However, if you change this, then bus_dmamem_free() won't always DTRT as it doesn't have enough state to know if a small allocation should be free'd via free() or contigfree() (the latter would be required if it used a non-default memory attribute). The fix I used for this was to create a new dummy dmamap that is returned by bus_dmamem_alloc if it uses contigmalloc(). bus_dmamem_free() then checks the passed in map pointer to decide which type of free to perform. Once this is fixed, the actual WC support is rather trivial as it merely consists of passing a different argument to kmem_alloc_contig(). Oh, and using kmem_alloc_contig() instead of the pmap_change_attr() hack is required if you want to be able to export the same pages to userland via mmap (e.g. using an OBJT_SG object). :) Peter, this is somewhat orthognal (but related) to your bus_dma patch which is what prompted me to post this. Patch for 8 is below. Porting it to HEAD should be fairly trivial and direct. Index: amd64/amd64/busdma_machdep.c =================================================================== --- amd64/amd64/busdma_machdep.c (revision 225604) +++ amd64/amd64/busdma_machdep.c (working copy) @@ -42,6 +42,8 @@ #include #include +#include +#include #include #include @@ -125,7 +127,7 @@ static STAILQ_HEAD(, bus_dmamap) bounce_map_waitinglist; static STAILQ_HEAD(, bus_dmamap) bounce_map_callbacklist; -static struct bus_dmamap nobounce_dmamap; +static struct bus_dmamap nobounce_dmamap, contig_dmamap; static void init_bounce_pages(void *dummy); static int alloc_bounce_zone(bus_dma_tag_t dmat); @@ -455,7 +457,7 @@ int bus_dmamap_destroy(bus_dma_tag_t dmat, bus_dmamap_t map) { - if (map != NULL && map != &nobounce_dmamap) { + if (map != NULL && map != &nobounce_dmamap && map != &contig_dmamap) { if (STAILQ_FIRST(&map->bpages) != NULL) { CTR3(KTR_BUSDMA, "%s: tag %p error %d", __func__, dmat, EBUSY); @@ -480,6 +482,7 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags, bus_dmamap_t *mapp) { + vm_memattr_t attr; int mflags; if (flags & BUS_DMA_NOWAIT) @@ -502,6 +505,12 @@ } if (flags & BUS_DMA_ZERO) mflags |= M_ZERO; + if (flags & BUS_DMA_WRITE_COMBINING) + attr = VM_MEMATTR_WRITE_COMBINING; + else if (flags & BUS_DMA_NOCACHE) + attr = VM_MEMATTR_UNCACHEABLE; + else + attr = VM_MEMATTR_DEFAULT; /* * XXX: @@ -513,7 +522,8 @@ */ if ((dmat->maxsize <= PAGE_SIZE) && (dmat->alignment < dmat->maxsize) && - dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) { + dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem) && + attr == VM_MEMATTR_DEFAULT) { *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); } else { /* @@ -522,9 +532,10 @@ * multi-seg allocations yet though. * XXX Certain AGP hardware does. */ - *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags, - 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul, - dmat->boundary); + *vaddr = (void *)kmem_alloc_contig(kernel_map, dmat->maxsize, + mflags, 0ul, dmat->lowaddr, dmat->alignment ? + dmat->alignment : 1ul, dmat->boundary, attr); + *mapp = &contig_dmamap; } if (*vaddr == NULL) { CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", @@ -533,9 +544,6 @@ } else if ((uintptr_t)*vaddr & (dmat->alignment - 1)) { printf("bus_dmamem_alloc failed to align memory properly.\n"); } - if (flags & BUS_DMA_NOCACHE) - pmap_change_attr((vm_offset_t)*vaddr, dmat->maxsize, - PAT_UNCACHEABLE); CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", __func__, dmat, dmat->flags, 0); return (0); @@ -550,18 +558,15 @@ { /* * dmamem does not need to be bounced, so the map should be - * NULL + * NULL if malloc() was used and contig_dmamap if + * contigmalloc() was used. */ - if (map != NULL) + if (!(map == NULL || map == &contig_dmamap)) panic("bus_dmamem_free: Invalid map freed\n"); - pmap_change_attr((vm_offset_t)vaddr, dmat->maxsize, PAT_WRITE_BACK); - if ((dmat->maxsize <= PAGE_SIZE) && - (dmat->alignment < dmat->maxsize) && - dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) + if (map == NULL) free(vaddr, M_DEVBUF); - else { - contigfree(vaddr, dmat->maxsize, M_DEVBUF); - } + else + kmem_free(kernel_map, (vm_offset_t)vaddr, dmat->maxsize); CTR3(KTR_BUSDMA, "%s: tag %p flags 0x%x", __func__, dmat, dmat->flags); } @@ -588,7 +593,7 @@ bus_addr_t paddr; int seg; - if (map == NULL) + if (map == NULL || map == &contig_dmamap) map = &nobounce_dmamap; if ((map != &nobounce_dmamap && map->pagesneeded == 0) @@ -1119,7 +1124,7 @@ struct bounce_page *bpage; KASSERT(dmat->bounce_zone != NULL, ("no bounce zone in dma tag")); - KASSERT(map != NULL && map != &nobounce_dmamap, + KASSERT(map != NULL && map != &nobounce_dmamap && map != &contig_dmamap, ("add_bounce_page: bad map %p", map)); bz = dmat->bounce_zone; Index: sys/bus_dma.h =================================================================== --- sys/bus_dma.h (revision 225604) +++ sys/bus_dma.h (working copy) @@ -101,6 +101,7 @@ */ #define BUS_DMA_NOWRITE 0x100 #define BUS_DMA_NOCACHE 0x200 +#define BUS_DMA_WRITE_COMBINING 0x400 /* * The following flag is a DMA tag hint that the page offset of the -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 15:02:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 685DA1065674 for ; Thu, 12 Jul 2012 15:02:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC6C8FC0C for ; Thu, 12 Jul 2012 15:02:17 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta01.emeryville.ca.mail.comcast.net with comcast id ZSyV1j0050QkzPwA1T2BrB; Thu, 12 Jul 2012 15:02:11 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta02.emeryville.ca.mail.comcast.net with comcast id ZT291j00h4NgCEG8NT2AaC; Thu, 12 Jul 2012 15:02:11 +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 q6CF27E5015681; Thu, 12 Jul 2012 09:02:07 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201207121040.27116.jhb@freebsd.org> References: <201207121040.27116.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jul 2012 09:02:07 -0600 Message-ID: <1342105327.1123.66.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: scottl@freebsd.org, Peter Jeremy , current@freebsd.org Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 15:02:17 -0000 On Thu, 2012-07-12 at 10:40 -0400, John Baldwin wrote: > I have a need to allocate static DMA memory via bus_dmamem_alloc() that is > also WC (for a PCI-e device so it can use "nosnoop" transactions). This is > similar to what the nvidia driver needs, but in my case it is much cleaner to > allocate the memory via bus dma since the existing code I am extending all > uses busdma. > > I have a patch to implement this on 8.x for amd64 that I can port to HEAD if > folks don't object. What I would really like to do is add a new paramter to > bus_dmamem_alloc() to specify the memory attribute to use, but I am hesitant > to break that API. Instead, I added a new flag similar to the existing > BUS_DMA_NOCACHE used to allocate UC memory. > > While doing this, I ran into an old bug, which is that if you were to call > bus_dmamem_alloc() with BUS_DMA_NOCACHE but a tag that otherwise fell through > to using malloc() instead of contigmalloc(), bus_dmamem_alloc() would actually > change the state of the entire page. This seems wrong. Instead, I think that > any request for a non-default memory attribute should always use > contigmalloc(). The problem I have with this (already, even before your proposed changes) is that contigmalloc() is only able to allocate pages. In the ARM world we have a need to allocate BUS_DMA_COHERENT memory (same effect as BUS_DMA_NOCACHE; we should consolidate these names) that is aligned to a 32-byte boundary (cacheline-aligned) but usually the buffer is far smaller than a page, often smaller than 1k, and sometimes we need lots of them (allocating 128 pages for ethernet buffers, with only half of each page used, is unreasonably expensive on a platform with only 64mb to begin with). I keep thinking what's needed is a busdma allocation helper routine, something MI that can be used by the various MD busdma implementations, that can manage a pool of pages that are flagged as uncachable and can subdivide those pages to provide small blocks of memory that fit various alignment and boundary restrictions. To be clear, I'm not objecting to your proposed changes, I'm more just musing that similar problems exist in non-x86 architectures and maybe an MI solution is possible (or at least the groundwork could be laid)? > In fact, even better is to call kmem_alloc_contig() directly > rather than using contigmalloc(). However, if you change this, then > bus_dmamem_free() won't always DTRT as it doesn't have enough state to know if > a small allocation should be free'd via free() or contigfree() (the latter > would be required if it used a non-default memory attribute). The fix I used > for this was to create a new dummy dmamap that is returned by bus_dmamem_alloc > if it uses contigmalloc(). bus_dmamem_free() then checks the passed in map > pointer to decide which type of free to perform. Once this is fixed, the > actual WC support is rather trivial as it merely consists of passing a > different argument to kmem_alloc_contig(). > > Oh, and using kmem_alloc_contig() instead of the pmap_change_attr() hack is > required if you want to be able to export the same pages to userland via > mmap (e.g. using an OBJT_SG object). :) > > Peter, this is somewhat orthognal (but related) to your bus_dma patch which is > what prompted me to post this. > > Patch for 8 is below. Porting it to HEAD should be fairly trivial and direct. > [patch removed] > -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 15:36:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 968E01065676; Thu, 12 Jul 2012 15:36:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 529F58FC1D; Thu, 12 Jul 2012 15:36:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9BD23B960; Thu, 12 Jul 2012 11:36:17 -0400 (EDT) From: John Baldwin To: Ian Lepore Date: Thu, 12 Jul 2012 11:36:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201207121040.27116.jhb@freebsd.org> <1342105327.1123.66.camel@revolution.hippie.lan> In-Reply-To: <1342105327.1123.66.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207121136.08387.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 11:36:17 -0400 (EDT) Cc: scottl@freebsd.org, Peter Jeremy , current@freebsd.org Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 15:36:18 -0000 On Thursday, July 12, 2012 11:02:07 am Ian Lepore wrote: > On Thu, 2012-07-12 at 10:40 -0400, John Baldwin wrote: > > I have a need to allocate static DMA memory via bus_dmamem_alloc() that is > > also WC (for a PCI-e device so it can use "nosnoop" transactions). This is > > similar to what the nvidia driver needs, but in my case it is much cleaner to > > allocate the memory via bus dma since the existing code I am extending all > > uses busdma. > > > > I have a patch to implement this on 8.x for amd64 that I can port to HEAD if > > folks don't object. What I would really like to do is add a new paramter to > > bus_dmamem_alloc() to specify the memory attribute to use, but I am hesitant > > to break that API. Instead, I added a new flag similar to the existing > > BUS_DMA_NOCACHE used to allocate UC memory. > > > > While doing this, I ran into an old bug, which is that if you were to call > > bus_dmamem_alloc() with BUS_DMA_NOCACHE but a tag that otherwise fell through > > to using malloc() instead of contigmalloc(), bus_dmamem_alloc() would actually > > change the state of the entire page. This seems wrong. Instead, I think that > > any request for a non-default memory attribute should always use > > contigmalloc(). > > The problem I have with this (already, even before your proposed > changes) is that contigmalloc() is only able to allocate pages. In the > ARM world we have a need to allocate BUS_DMA_COHERENT memory (same > effect as BUS_DMA_NOCACHE; we should consolidate these names) that is > aligned to a 32-byte boundary (cacheline-aligned) but usually the buffer > is far smaller than a page, often smaller than 1k, and sometimes we need > lots of them (allocating 128 pages for ethernet buffers, with only half > of each page used, is unreasonably expensive on a platform with only > 64mb to begin with). > > I keep thinking what's needed is a busdma allocation helper routine, > something MI that can be used by the various MD busdma implementations, > that can manage a pool of pages that are flagged as uncachable and can > subdivide those pages to provide small blocks of memory that fit various > alignment and boundary restrictions. > > To be clear, I'm not objecting to your proposed changes, I'm more just > musing that similar problems exist in non-x86 architectures and maybe an > MI solution is possible (or at least the groundwork could be laid)? The traditional argument I've heard against this is that the relevant driver should allocate a big block and manage suballocations on its own rather than pushing that work into bus_dma. How are you allocating Ethernet buffers btw? Are you not using mbuf clusters to receive packets, but allocate mbufs in your RX interrupt handler and copying data out of static buffers into the mbufs to send up the stack? Also, I do not think BUS_DMA_COHERENT and BUS_DMA_NOCACHE are quite the same. I see UC as a way to implement COHERENT semantics, but it also seems to me that a COHERENT mapping can't use bounce pages either. OTOH, NOCACHE (and my new flag), are specifically requesting a certain mapping behavior not necessarily to avoid bus_dmamap_sync() operations, but due to a hardware requirement (e.g. the WC mapping is to enable use of "nosnoop" PCI-e transactions). That is, I interpret COHERENT as meaning "this map doesn't require bus_dmamap_sync(), do whatever it takes to make that true", where as NOCACHE and WC have other meanings (though in practice NOCACHE and WC both imply COHERENT). For example, on x86 with caches that snoop DMA transactions, COHERENT doesn't require NOCACHE at all, it simply requires avoiding the use of bounce pages. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 15:40:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A47761065672 for ; Thu, 12 Jul 2012 15:40:37 +0000 (UTC) (envelope-from nil@mad.dog.cx) Received: from msv5.zenno.net (msv5.zenno.net [125.53.25.155]) by mx1.freebsd.org (Postfix) with SMTP id 1F21B8FC08 for ; Thu, 12 Jul 2012 15:40:37 +0000 (UTC) Received: (qmail 78912 invoked from network); 13 Jul 2012 00:33:54 +0900 Received: from unknown (HELO lenovo-b0c22c0d) (nil@mad.dog.cx@110.66.100.43) by msv5.zenno.net with SMTP; 13 Jul 2012 00:33:54 +0900 Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2012 00:33:21 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "HIROSHI OOTA" Message-ID: User-Agent: Opera Mail/12.00 (Win32) Subject: [CFT] ng_nptv6 (IPv6-to-IPv6 Network Prefix Translation) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 15:40:37 -0000 Hi, all I have created a netgraph node which performs a IPv6-to-IPv6 Network Prefix Translation(RFC6296). It works with ipfw(ng_ipfw). a sample configuration is follows. 1 setup netgraph ngctl mkpeer ipfw: nptv6 1000 inbound ngctl name ipfw:1000 nptv6 ngctl connect ipfw: nptv6: 2000 outbound ngctl msg nptv6: setconfig { inner=fd00:1234:1234::/48 outer=2001:db8::/32 } or use rcng script(ng_nptv6.sh) which is included in archive. 2 setup ipfw # inbound ipfw 1000 allow ip6 from any to 2001:db8::/64 in ipfw 1010 netgraph 1000 ip6 from any to 2001:db8::/32 in ipfw 1090 allow ip6 from any to any in # outbound ipfw 2000 allow ip6 from 2001:db8::/64 to any out ipfw 2010 netgraph 2000 ip6 from 2001:db8::/32 to any out ipfw 2090 allow ip6 from any to any in You can download from http://hp.vector.co.jp/authors/VA052357/ng_nptv6-0.0.tar.xz Comments and tests results are welcome! -- HIROSHI OOTA From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 16:38:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27062106566C; Thu, 12 Jul 2012 16:38:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F236E8FC0A; Thu, 12 Jul 2012 16:37:59 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 91ACC46B0A; Thu, 12 Jul 2012 12:37:59 -0400 (EDT) Date: Thu, 12 Jul 2012 17:37:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ian Lepore In-Reply-To: <1342105327.1123.66.camel@revolution.hippie.lan> Message-ID: References: <201207121040.27116.jhb@freebsd.org> <1342105327.1123.66.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , scottl@freebsd.org, current@freebsd.org Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 16:38:00 -0000 On Thu, 12 Jul 2012, Ian Lepore wrote: > To be clear, I'm not objecting to your proposed changes, I'm more just > musing that similar problems exist in non-x86 architectures and maybe an MI > solution is possible (or at least the groundwork could be laid)? I was likewise going to comment that there are known defficiencies in handling page table attributes on non-x86 -- for example, they are ignored on MIPS. I encountered this when trying to add memory mapping support for a device driver and discovered that all entries were being installed cached instead of the requested uncached. I have local patches that propagate the same non-solution used by FreeBSD/MIPS within the kernel to the d_mmap interface -- namely, if you try to export something that isn't memory, then it knows it has to be uncached. I plan to commit these fixes to the MIPS TLB code pretty soon, but have been preoccupied with other things for the last few months. However, some heavier lifting is required to add attribute support, and it's quite desirable to do so. Robert From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 16:37:20 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70ED2106566B for ; Thu, 12 Jul 2012 16:37:20 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by mx1.freebsd.org (Postfix) with SMTP id 43F378FC1F for ; Thu, 12 Jul 2012 16:37:20 +0000 (UTC) Received: from [98.139.91.63] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jul 2012 16:37:14 -0000 Received: from [98.139.91.12] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jul 2012 16:37:14 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 12 Jul 2012 16:37:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 230355.65709.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 17167 invoked by uid 60001); 12 Jul 2012 16:37:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1342111033; bh=SWGQOvvnlC4DMGqAOEytp9L27viTQHQqeUJYAj1PHak=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4RCpwAkbajQPAPACSevSeonYFPLpW2jAlAGwj9WjJNH+MVymXhQ5dMve1VaHkp250VyJ7iQrTaudVyOontncWyty60+tsqoi/lojR2t+1jEfzC/o5QlNAM/SwU9Aj/hfAax8o5O6dOnPPHCpGDatITP60bBwV2zkiqBqeY4OBEM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DyPOJZuwa7E59cHIpReIvU8Lpl7e70X1FEaM9t1rIS3fJc6hWlYorbwzNml4bfJFU6vHe1hC4XTVHuU7Tfozs9Rk82Yu9Y0Nj2XDF2fCndufwFB/p6eIenK8tmKZKOo1OOlZWW9QhvOwq1katpJfrxELzReZB4AHqHt4mpwWXM4=; X-YMail-OSG: kYfG7pQVM1kZ_v4uPxzSB0GChF5GV5RRbbznV8p4LJsW6.a dUQXX7i0MrbOnzVUpjaXK5v1X_SwSmNHXqijuO8qWxw2g_UOs3NlgR0LKUgS kNVpeqNhDWdzLjgDG7RGGEhka_XlDmRwlQ2e3ErS7XXQOxdxSX64.r4vlUDT gT3pCO2bnz54IUGvb7kHiuy5.nBvMq3.BvbyTPOeLMdVTCYUgbmNsAq_gUKR D0DY.GDMYVEKUAx2YzNMdLIuAXKTyemrE3J4fQE1Q1K6wX5o19NkKdICoeUa Iu.WSP11rEru8H.g.bE.j120m0kaqERSnILyOwN2Onmz9npEJiskE_dakwPh 0uYtz55XxdSls3G662M8mJlmeUlksVbOzKnwJHDVXSbtdtLcpK0GY0rl350k NAIstjrBVjMnpERojSURXLOZAZVC0l8Amz3TY3jq3Kiz0y7CwfH213fw6RL_ SkTvboWQ5NmQ- Received: from [69.53.237.66] by web45716.mail.sp1.yahoo.com via HTTP; Thu, 12 Jul 2012 09:37:13 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <201207121040.27116.jhb@freebsd.org> Message-ID: <1342111033.198.YahooMailNeo@web45716.mail.sp1.yahoo.com> Date: Thu, 12 Jul 2012 09:37:13 -0700 (PDT) From: Scott Long To: John Baldwin , "current@freebsd.org" In-Reply-To: <201207121040.27116.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 12 Jul 2012 16:40:00 +0000 Cc: Peter Jeremy Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scott Long List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:37:20 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: John Baldwin =0A> To: current@freebsd.org=0A> Cc: scottl@freebsd.org; Peter Jeremy= =0A> Sent: Thursday, July 12, 2012 7:40 AM=0A> Subject= : Adding support for WC (write-combining) memory to bus_dma=0A> =0A> I have= a need to allocate static DMA memory via bus_dmamem_alloc() that is =0A> a= lso WC (for a PCI-e device so it can use "nosnoop" transactions).=A0 =0A> T= his is =0A> similar to what the nvidia driver needs, but in my case it is m= uch cleaner to =0A> allocate the memory via bus dma since the existing code= I am extending all =0A> uses busdma.=0A> =0A> I have a patch to implement = this on 8.x for amd64 that I can port to HEAD if =0A> folks don't object.= =A0 What I would really like to do is add a new paramter to =0A> =0A> bus_d= mamem_alloc() to specify the memory attribute to use, but I am hesitant =0A= > to break that API.=A0 Instead, I added a new flag similar to the existing= =0A> BUS_DMA_NOCACHE used to allocate UC memory.=0A>=A0=0A=0APlease don't = add new parameters. =A0Now that I'm carefully documenting the=0Aevolution o= f the=A0APIs, it's becoming glaringly apparent how sloppy we are=0Awith API= design and=A0interface compatibility. =A0I'm just as guilty of it as anyon= e,=0Abut I'd really like to=A0see less instances of call signature changes = in existing=0Afunctions; they make=A0driver maintenance tedious and are har= d to effectively=0Adocument. =A0Some options I can think of:=0A=0A1. =A0cre= ate bus_dmamem_alloc_attr(). =A0I don't really like leafy API growth like= =0Athis either,=A0but=A0it's not a horrible solution.=0A2. =A0There are exi= sting placeholder flags, BUS_DMA_BUS[1234] that could be=0Aaliased and repu= rposed to hold 4 bits of attribute information for this function.=0AThe 3 a= nd 4 variants are already in use, but I haven't looked closely to see=0Athe= ir scope.=0A3. =A0Reserve the top 16 bits of the flags for attribute inform= ation.=0A4. =A0Move the attribute information into the tag and create new s= etter/getter=0Aaccessors for attribute information. =A0This would probably = be the cleanest,=0Athough it breaks the existing sloppiness of allowing dif= ferent pseudo-attributes=0Afor different allocations under the same tag. = =A0I've wanted to break down the=0Aexisting bus_dma_tag_create() into finer= -grained setter/getters for a while in=0Aany case.=0A5. =A0Move the attribu= te information into the map and force everyone to start=0Acreating maps for= static memory allocations. =A0This would actually add some=0Amissing unifo= rmity to the API and might actually be cleaner that option 4.=0A=0A> While = doing this, I ran into an old bug, which is that if you were to call =0A> b= us_dmamem_alloc() with BUS_DMA_NOCACHE but a tag that otherwise fell throug= h =0A> to using malloc() instead of contigmalloc(), bus_dmamem_alloc() woul= d actually=0A> change the state of the entire page.=A0 This seems wrong.=A0= Instead, I think that =0A> any request for a non-default memory attribute = should always use =0A> contigmalloc().=A0 In fact, even better is to call k= mem_alloc_contig() directly=0A> rather than using contigmalloc().=A0 Howeve= r, if you change this, then =0A> bus_dmamem_free() won't always DTRT as it = doesn't have enough state to =0A> know if=0A> a small allocation should be = free'd via free() or contigfree() (the latter =0A> would be required if it = used a non-default memory attribute).=A0 The fix I used =0A> for this was t= o create a new dummy dmamap that is returned by bus_dmamem_alloc =0A> if it= uses contigmalloc().=A0 bus_dmamem_free() then checks the passed in map = =0A> pointer to decide which type of free to perform.=A0 Once this is fixed= , the =0A> actual WC support is rather trivial as it merely consists of pas= sing a =0A> different argument to kmem_alloc_contig().=0A=0AYup, this is a = problem, and I like your fix; this kind of state is exactly what=0Abelongs = in the map.=0A=0A> =0A> Oh, and using kmem_alloc_contig() instead of the pm= ap_change_attr() hack is=0A> required if you want to be able to export the = same pages to userland via=0A> mmap (e.g. using an OBJT_SG object). :)=0A> = =0A> Peter, this is somewhat orthognal (but related) to your bus_dma patch = which is=0A> what prompted me to post this.=0A> =0A> Patch for 8 is below.= =A0 Porting it to HEAD should be fairly trivial and direct.=0A> =0A> Index:= amd64/amd64/busdma_machdep.c=0A=0AThanks,=0AScott=0A From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 18:04:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC0FB106566B; Thu, 12 Jul 2012 18:04:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 89E288FC08; Thu, 12 Jul 2012 18:04:58 +0000 (UTC) Message-ID: <4FFF11CA.60004@FreeBSD.org> Date: Thu, 12 Jul 2012 14:04:58 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , freebsd-security@FreeBSD.org Subject: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 18:04:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL 1.0.1c will be merged to head today. There will be several important changes to note. - - Several crypto/engine modules will be added or enabled by default to closely match OpenSSL default, e.g., Camellia (crypto), SEED (crypto), CHIL (engine), GOST (engine), etc. - - MD2 will be removed because a) it is disabled by default and b) we removed it from libmd. - - Optimized amd64 asm files will be added and enabled by default. - - Optimized i386 asm files will be updated and new files will be added. - - opensslconf.h for amd64 and i386 will be merged. Unfortunately, library versions will be bumped, i.e., libcrypto.so.6 -> libcrypto.so.7 libssl.so.6 -> libssl.so.7 Therefore, all binaries depending on these need to be recompiled. Also, you may have to merge your /etc/ssl/openssl.conf changes. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk//EckACgkQmlay1b9qnVN0PQCgwtUHNK7iEdKpTi3TmWD5W4UK smUAnAxcPa+OtZQe4HKifeaVm+ybdRIH =T9Oc -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 18:11:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAC2D106564A for ; Thu, 12 Jul 2012 18:11:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 73CD58FC0C for ; Thu, 12 Jul 2012 18:11:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BE5A8B91A; Thu, 12 Jul 2012 14:11:12 -0400 (EDT) From: John Baldwin To: Scott Long Date: Thu, 12 Jul 2012 13:51:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201207121040.27116.jhb@freebsd.org> <1342111033.198.YahooMailNeo@web45716.mail.sp1.yahoo.com> In-Reply-To: <1342111033.198.YahooMailNeo@web45716.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207121351.20951.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 12 Jul 2012 14:11:12 -0400 (EDT) Cc: Peter Jeremy , "current@freebsd.org" Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 18:11:13 -0000 On Thursday, July 12, 2012 12:37:13 pm Scott Long wrote: > > ----- Original Message ----- > > From: John Baldwin > > To: current@freebsd.org > > Cc: scottl@freebsd.org; Peter Jeremy > > Sent: Thursday, July 12, 2012 7:40 AM > > Subject: Adding support for WC (write-combining) memory to bus_dma > > > > I have a need to allocate static DMA memory via bus_dmamem_alloc() that is > > also WC (for a PCI-e device so it can use "nosnoop" transactions). > > This is > > similar to what the nvidia driver needs, but in my case it is much cleaner to > > allocate the memory via bus dma since the existing code I am extending all > > uses busdma. > > > > I have a patch to implement this on 8.x for amd64 that I can port to HEAD if > > folks don't object. What I would really like to do is add a new paramter to > > > > bus_dmamem_alloc() to specify the memory attribute to use, but I am hesitant > > to break that API. Instead, I added a new flag similar to the existing > > BUS_DMA_NOCACHE used to allocate UC memory. > > > > Please don't add new parameters. Now that I'm carefully documenting the > evolution of the APIs, it's becoming glaringly apparent how sloppy we are > with API design and interface compatibility. I'm just as guilty of it as anyone, > but I'd really like to see less instances of call signature changes in existing > functions; they make driver maintenance tedious and are hard to effectively > document. Some options I can think of: > > 1. create bus_dmamem_alloc_attr(). I don't really like leafy API growth like > this either, but it's not a horrible solution. I would actually not oppose this either. In this particular case it is a bit useful as I think the user shouldn't have to explicitly state a default if they don't need a non-standard attribute. Side-band comment: if I were going to change the API of bus_dmamem_alloc(), my biggest request would be a bus_dmamem_alloc_size() that takes the size to allocate as a parameter rather than pulling the size out of the tag. I always think of a tag as describing a DMA engine's capabilities and restrictions, whereas the size of, say, a descriptor ring is often a software-configurable knob (e.g. hw.igb.nrxd) and thus the allocation size isn't really a property of the DMA engine. I also find this to be the least intuitive behavior in the bus DMA API. But that is an entirely different ball of wax. > 2. There are existing placeholder flags, BUS_DMA_BUS[1234] that could be > aliased and repurposed to hold 4 bits of attribute information for this function. > The 3 and 4 variants are already in use, but I haven't looked closely to see > their scope. Humm, I could do that. In practice WC is only really applicable on x86. Also, to be honest, I doubt anyone will ever use special attributes besides UC and WC for DMA on x86. That is the main reason why I just added a new flag and didn't try to add a generic scheme for specifying the memory attribute. I could easily just move BUS_DMA_WRITE_COMBINING into x86's and have it use one of the free placeholder flags. That is probably the simplest short term solution. > 3. Reserve the top 16 bits of the flags for attribute information. > 4. Move the attribute information into the tag and create new setter/getter > accessors for attribute information. This would probably be the cleanest, > though it breaks the existing sloppiness of allowing different pseudo-attributes > for different allocations under the same tag. I've wanted to break down the > existing bus_dma_tag_create() into finer-grained setter/getters for a while in > any case. > 5. Move the attribute information into the map and force everyone to start > creating maps for static memory allocations. This would actually add some > missing uniformity to the API and might actually be cleaner that option 4. > > > While doing this, I ran into an old bug, which is that if you were to call > > bus_dmamem_alloc() with BUS_DMA_NOCACHE but a tag that otherwise fell through > > to using malloc() instead of contigmalloc(), bus_dmamem_alloc() would actually > > change the state of the entire page. This seems wrong. Instead, I think that > > any request for a non-default memory attribute should always use > > contigmalloc(). In fact, even better is to call kmem_alloc_contig() directly > > rather than using contigmalloc(). However, if you change this, then > > bus_dmamem_free() won't always DTRT as it doesn't have enough state to > > know if > > a small allocation should be free'd via free() or contigfree() (the latter > > would be required if it used a non-default memory attribute). The fix I used > > for this was to create a new dummy dmamap that is returned by bus_dmamem_alloc > > if it uses contigmalloc(). bus_dmamem_free() then checks the passed in map > > pointer to decide which type of free to perform. Once this is fixed, the > > actual WC support is rather trivial as it merely consists of passing a > > different argument to kmem_alloc_contig(). > > Yup, this is a problem, and I like your fix; this kind of state is exactly what > belongs in the map. Why don't I break out the fix first as a separate patch. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 18:30:05 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C15CE1065670; Thu, 12 Jul 2012 18:30:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2598F8FC19; Thu, 12 Jul 2012 18:30:05 +0000 (UTC) Message-ID: <4FFF17AC.6080907@FreeBSD.org> Date: Thu, 12 Jul 2012 14:30:04 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FFF11CA.60004@FreeBSD.org> In-Reply-To: <4FFF11CA.60004@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , freebsd-security@freebsd.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 18:30:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-12 14:04:58 -0400, Jung-uk Kim wrote: > - Several crypto/engine modules will be added or enabled by default > to closely match OpenSSL default, e.g., Camellia (crypto), SEED > (crypto), CHIL (engine), GOST (engine), etc. Actually, CHIL is already enabled. My bad. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk//F6wACgkQmlay1b9qnVMnhQCghxsNSDCr3sbM+6PEenB4nTh2 3/YAoJ5EiSCzQhTKBJQ4bbWd0mVGZqbk =hYlB -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 18:48:45 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 28CFC1065672; Thu, 12 Jul 2012 18:48:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 23D3D14F644; Thu, 12 Jul 2012 18:48:42 +0000 (UTC) Message-ID: <4FFF1C09.2020408@FreeBSD.org> Date: Thu, 12 Jul 2012 11:48:41 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Baptiste Daroussin References: <20120712100110.GA34228@ithaqua.etoilebsd.net> In-Reply-To: <20120712100110.GA34228@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, ports-announce@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 18:48:45 -0000 I do not mean this e-mail to be in any way critical. I was told after the new OPTIONS framework discussion that I should have asked questions before the change, so I'm asking these questions now; in a genuine attempt to get information. On 07/12/2012 03:01 AM, Baptiste Daroussin wrote: In the time that you have been working on this project I have asked numerous times for you(pl.) to answer the following questions: 1. What are the goals for pkg? 2. Why can't the existing tools fulfill those goals? 3. How does pkg fulfill them? You've put some of this in the various places where pkg is documented, but I don't see any thorough treatment of these questions. You have some of it below, which I'd like to see expanded on if you would be so kind. :) > Why pkg? > -------- > pkg_* tools have become hardly maintainable over the time, I agree on this point, but the right solution (as some of us have been saying for years) is to move the pkg_* tools into the ports tree. You are correctly handling that by keeping pkg in the ports tree, I'm simply pointing out that this isn't a reason we need to switch to pkg. > it lacks lots of features most of people are expecting from a package manager: > - binary upgrade I'm not sure what you mean by this. We have the ability to create binary packages now. > - ability to search information about remote packages This is a good feature, certainly. However there is no reason we can't create a tool to do this, or add the functionality to an existing tool. > - real reverse dependency tracking > - tracking leaves Can you expand on what these 2 mean? What I'm looking for is compelling motivation to make this overwhelming change to the ports infrastructure. > Schedule > -------- > > The plan is to switch the ports tree to pkgng on CURRENT by default on July 25th > No dates are planned yet for other branches. Can you describe how this is going to be done? I assume with an OSVERSION knob in bsd.port.mk? > Note that there will be a NO_PKGNG knob for some time (undefined yet) for people > not will to switch on July 25th > > Please also note that some ports won't work with pkgng right now, because pkgng > is more strict than pkg_install on purpose. > The major one is: nvidia drivers, because pkgng does not allow to overwrite a file > owned by another package, and we will not accept any hacks for that in pkgng. IMO it would be a very large mistake to switch the default in any branch until the problem with the nvidia drivers is sorted out. We have a lot of users (myself included) who use this port, and by switching the default there's going to be 1 of 2 outcomes for those users. Either they will opt-out, which means you won't get the level of testing you're looking for; or you'll break their existing ports installation. Neither outcome is desirable. Doug From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 17:18:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9D19106564A; Thu, 12 Jul 2012 17:18:27 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0B98FC0C; Thu, 12 Jul 2012 17:18:27 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q6CHIP94085032; Thu, 12 Jul 2012 13:18:26 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id q6CHIPXG085031; Thu, 12 Jul 2012 13:18:25 -0400 (EDT) (envelope-from wollman) Date: Thu, 12 Jul 2012 13:18:25 -0400 (EDT) From: Garrett Wollman Message-Id: <201207121718.q6CHIPXG085031@hergotha.csail.mit.edu> To: bapt@freebsd.org X-Newsgroups: In-Reply-To: <20120712100110.GA34228@ithaqua.etoilebsd.net> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 12 Jul 2012 13:18:26 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Thu, 12 Jul 2012 19:51:45 +0000 Cc: current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 17:18:27 -0000 In article <20120712100110.GA34228@ithaqua.etoilebsd.net>, bapt@freebsd.org writes: > - puppet support: (https://github.com/xaque208/puppet-pkgng) I've actually already written one of these; it may be good to merge. Would whoever is working on this please raise your hand? -GAWollman -- Garrett A. Wollman | What intellectual phenomenon can be older, or more oft wollman@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:29:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5867F106566B; Thu, 12 Jul 2012 20:29:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E8CB98FC0C; Thu, 12 Jul 2012 20:28:59 +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 q6CKSxKH036702; Thu, 12 Jul 2012 16:28:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6CKSw2v036689; Thu, 12 Jul 2012 20:28:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jul 2012 20:28:58 GMT Message-Id: <201207122028.q6CKSw2v036689@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:29:00 -0000 TB --- 2012-07-12 20:13:29 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-12 20:13:29 - 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 --- 2012-07-12 20:13:29 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-12 20:13:29 - cleaning the object tree TB --- 2012-07-12 20:13:29 - cvsupping the source tree TB --- 2012-07-12 20:13:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-12 20:15:27 - building world TB --- 2012-07-12 20:15:27 - CROSS_BUILD_TESTING=YES TB --- 2012-07-12 20:15:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-12 20:15:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-12 20:15:27 - SRCCONF=/dev/null TB --- 2012-07-12 20:15:27 - TARGET=powerpc TB --- 2012-07-12 20:15:27 - TARGET_ARCH=powerpc TB --- 2012-07-12 20:15:27 - TZ=UTC TB --- 2012-07-12 20:15:27 - __MAKE_CONF=/dev/null TB --- 2012-07-12 20:15:27 - cd /src TB --- 2012-07-12 20:15:27 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 12 20:15:28 UTC 2012 >>> 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 [...] ===> sbin/sysctl (installincludes) ===> sbin/tunefs (installincludes) ===> sbin/umount (installincludes) ===> secure (includes) cd /src/secure; /usr/bin/make buildincludes; /usr/bin/make installincludes ===> secure/lib (buildincludes) ===> secure/lib/libcrypto (buildincludes) make: don't know how to make tmdiff.h. Stop *** Error code 2 Stop in /src/secure/lib. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-12 20:28:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-12 20:28:58 - ERROR: failed to build world TB --- 2012-07-12 20:28:58 - 632.52 user 79.98 system 929.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:45:30 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0DD41065798; Thu, 12 Jul 2012 20:45:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6CD8FC0A; Thu, 12 Jul 2012 20:45:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6CKjTJs015934; Thu, 12 Jul 2012 16:45:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6CKjTHJ015929; Thu, 12 Jul 2012 20:45:29 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jul 2012 20:45:29 GMT Message-Id: <201207122045.q6CKjTHJ015929@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:45:30 -0000 TB --- 2012-07-12 20:28:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-12 20:28: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 --- 2012-07-12 20:28:59 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-12 20:28:59 - cleaning the object tree TB --- 2012-07-12 20:28:59 - cvsupping the source tree TB --- 2012-07-12 20:28:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-12 20:30:34 - building world TB --- 2012-07-12 20:30:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-12 20:30:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-12 20:30:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-12 20:30:34 - SRCCONF=/dev/null TB --- 2012-07-12 20:30:34 - TARGET=powerpc TB --- 2012-07-12 20:30:34 - TARGET_ARCH=powerpc64 TB --- 2012-07-12 20:30:34 - TZ=UTC TB --- 2012-07-12 20:30:34 - __MAKE_CONF=/dev/null TB --- 2012-07-12 20:30:34 - cd /src TB --- 2012-07-12 20:30:34 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 12 20:30:35 UTC 2012 >>> 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 [...] ===> sbin/sysctl (installincludes) ===> sbin/tunefs (installincludes) ===> sbin/umount (installincludes) ===> secure (includes) cd /src/secure; /usr/bin/make buildincludes; /usr/bin/make installincludes ===> secure/lib (buildincludes) ===> secure/lib/libcrypto (buildincludes) make: don't know how to make tmdiff.h. Stop *** Error code 2 Stop in /src/secure/lib. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-12 20:45:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-12 20:45:29 - ERROR: failed to build world TB --- 2012-07-12 20:45:29 - 654.77 user 83.49 system 990.57 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 20:53:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E64106564A; Thu, 12 Jul 2012 20:53:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1EDCD8FC12; Thu, 12 Jul 2012 20:53:47 +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 q6CKrkrs073943; Thu, 12 Jul 2012 16:53:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6CKrkT1073942; Thu, 12 Jul 2012 20:53:46 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jul 2012 20:53:46 GMT Message-Id: <201207122053.q6CKrkT1073942@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:53:47 -0000 TB --- 2012-07-12 20:43:02 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-12 20:43:02 - 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 --- 2012-07-12 20:43:02 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-12 20:43:02 - cleaning the object tree TB --- 2012-07-12 20:43:02 - cvsupping the source tree TB --- 2012-07-12 20:43:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-12 20:44:43 - building world TB --- 2012-07-12 20:44:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-12 20:44:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-12 20:44:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-12 20:44:43 - SRCCONF=/dev/null TB --- 2012-07-12 20:44:43 - TARGET=sparc64 TB --- 2012-07-12 20:44:43 - TARGET_ARCH=sparc64 TB --- 2012-07-12 20:44:43 - TZ=UTC TB --- 2012-07-12 20:44:43 - __MAKE_CONF=/dev/null TB --- 2012-07-12 20:44:43 - cd /src TB --- 2012-07-12 20:44:43 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 12 20:44:44 UTC 2012 >>> 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 [...] ===> sbin/sysctl (installincludes) ===> sbin/tunefs (installincludes) ===> sbin/umount (installincludes) ===> secure (includes) cd /src/secure; /usr/bin/make buildincludes; /usr/bin/make installincludes ===> secure/lib (buildincludes) ===> secure/lib/libcrypto (buildincludes) make: don't know how to make tmdiff.h. Stop *** Error code 2 Stop in /src/secure/lib. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-12 20:53:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-12 20:53:46 - ERROR: failed to build world TB --- 2012-07-12 20:53:46 - 411.92 user 59.38 system 643.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 21:11:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 923FF1065670; Thu, 12 Jul 2012 21:11:16 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2C43A8FC14; Thu, 12 Jul 2012 21:11:16 +0000 (UTC) Received: by obbun3 with SMTP id un3so4668612obb.13 for ; Thu, 12 Jul 2012 14:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h/wR7C2SSPEZ8Ku2Ap2XDiTDm8EX9AkziiEIKrUKH8A=; b=o9fkWnoMM0pr7tApk4TWYXdi733ZKhSupuYjuLFe9q9ZxxZMXCXknRfvv/C3/+lFGN FbkPtsxSmmDTg1zADsD4YnLiGSE2hVMD+2cqOqwOMx/JYAYjpgKYurskN8tTo3k1NF35 BXSjUAzkwUuSbgF4idmjFfFyZVhT/4MYfUhrBDzslLhDW8IM/diCA9JeulZ4v1JIrHoY xmOiqPChGoHs8io42IYzH4QQxFD3/e+d7Q24oyJ2qNsxRbv+qWHinQZnchPNIkycT3rc YQpECpywqxftR1Vn/wnxpaY17oWjtyvRuw0H9eeXmBn7RM4ySXktxH5Jxzmub50bWwLR HRZA== MIME-Version: 1.0 Received: by 10.182.225.100 with SMTP id rj4mr51539119obc.64.1342127475734; Thu, 12 Jul 2012 14:11:15 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.182.3.3 with HTTP; Thu, 12 Jul 2012 14:11:15 -0700 (PDT) In-Reply-To: <4FFF1C09.2020408@FreeBSD.org> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> Date: Thu, 12 Jul 2012 14:11:15 -0700 X-Google-Sender-Auth: KLxC_wqKFiQKxNkifR3WA4XVyH8 Message-ID: From: Craig Rodrigues To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, Baptiste Daroussin , current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 21:11:16 -0000 On Thu, Jul 12, 2012 at 11:48 AM, Doug Barton wrote: > 1. What are the goals for pkg? > 2. Why can't the existing tools fulfill those goals? > 3. How does pkg fulfill them? > > Hi, You might want to view Baptiste's pkgng presentation at BSDCan: http://www.youtube.com/watch?v=4Hxq7AHZ27I For me, that presentation clarified the goals and motivation of the pkgng project. After viewing that presentation, for me it put into perspective some of the other pkgng information at http://wiki.freebsd.org/pkgng/ . -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 21:16:42 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id C1C731065672; Thu, 12 Jul 2012 21:16:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0853914E832; Thu, 12 Jul 2012 21:16:42 +0000 (UTC) Message-ID: <4FFF3EB9.3040701@FreeBSD.org> Date: Thu, 12 Jul 2012 14:16:41 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Craig Rodrigues References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Baptiste Daroussin , current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 21:16:42 -0000 On 07/12/2012 02:11 PM, Craig Rodrigues wrote: > You might want to view Baptiste's pkgng presentation at BSDCan: > > http://www.youtube.com/watch?v=4Hxq7AHZ27I Sure, the next time I have an hour to spare. I don't think what I'm asking for is unreasonable. One could even conclude that answering those 3 questions should have been a prerequisite for starting down this road in the first place. Doug From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 22:02:10 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D1521065676; Thu, 12 Jul 2012 22:02:10 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB1E8FC14; Thu, 12 Jul 2012 22:02:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6CM2AGm053597; Thu, 12 Jul 2012 22:02:10 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6CM29h2053595; Thu, 12 Jul 2012 22:02:09 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Thu, 12 Jul 2012 22:02:07 +0000 From: Baptiste Daroussin To: Doug Barton Message-ID: <20120712220207.GD49382@ithaqua.etoilebsd.net> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GpGaEY17fSl8rd50" Content-Disposition: inline In-Reply-To: <4FFF1C09.2020408@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, ports-announce@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 22:02:10 -0000 --GpGaEY17fSl8rd50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote: > I do not mean this e-mail to be in any way critical. I was told after > the new OPTIONS framework discussion that I should have asked questions > before the change, so I'm asking these questions now; in a genuine > attempt to get information. >=20 > On 07/12/2012 03:01 AM, Baptiste Daroussin wrote: >=20 > In the time that you have been working on this project I have asked > numerous times for you(pl.) to answer the following questions: >=20 > 1. What are the goals for pkg? The why part of this mail should reply this question, no? Anyway the goal is to have a decent package manager, providing modern featu= res: repositories, decent dependency tracking, decent reverse dependency trackin= g, managing upgrade correctly (I'll explain this more later), provide a decent library for third party tools (desktop integration via PackageKit for examp= le) Providing easy package management for enterprise (who never got problems managing packages on a large set of freebsd servers, and how complicated it= is on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools) One of the proof of this problem is how fast people integrated pkgng in tho= se tools. > 2. Why can't the existing tools fulfill those goals? The existing tools can't fulfill those goals, because they are hardly maintainable, the code hasn't change much since when they were written, lot= of people have tried over the year to improve them, but all of them gave up. T= he design of the tools, (I mean the code) is really imho not adapted to be improved, I spent a lot of time trying to work on it before starting a comp= lete new project. For example they do not know what is a version, they do not know what are t= he reverse dependencies except through this ugly hack that is +REQUIRED_BY, the database is pretty fragile: who never got the package corrupted: empty @pkg= dep line for example. > 3. How does pkg fulfill them? >=20 > You've put some of this in the various places where pkg is documented, > but I don't see any thorough treatment of these questions. You have some > of it below, which I'd like to see expanded on if you would be so kind. :) It is true that, I'm not very good at documenting in general, and even more= in english, hopefully, the documentation is improving a lot recently, there is= the for usage: http://wiki.freebsd.org/PkgPrimer and for all other things: http://wiki.freebsd.org/pkgng Lot of native english speakers have joined the project and help with documentation, if you find someting missing, do not hesitate to had the sec= tion in the apropriate wiki page, I often have a look at them, and try to fill a= ll the blank section to answer user questions. >=20 > > Why pkg? > > pkg_* tools have become hardly maintainable over the time, >=20 > I agree on this point, but the right solution (as some of us have been > saying for years) is to move the pkg_* tools into the ports tree. You > are correctly handling that by keeping pkg in the ports tree, I'm simply > pointing out that this isn't a reason we need to switch to pkg. >=20 > > it lacks lots of features most of people are expecting from a package m= anager: > > - binary upgrade >=20 > I'm not sure what you mean by this. We have the ability to create binary > packages now. No we haven't :), I know we can mimic a binary upgrade using for example portmaster (I describe this in a poudriere howto) but this is not fully bin= ary upgrade, it is deinstalling/reinstalling a package. Binary upgrade is much = more complexe than that, for example one thing you can't handle now is a package= that has been splitted into lib vs runtime will break with the current way we ca= n do it. Just as an example. Just have a look at this old video: http://www.youtube.com/watch?v=3DiBgcuKF8R_A (it is only 1m30) >=20 > > - ability to search information about remote packages >=20 > This is a good feature, certainly. However there is no reason we can't > create a tool to do this, or add the functionality to an existing tool. Have a look at what pkgng can present you as information and you will see t= he difference. >=20 > > - real reverse dependency tracking > > - tracking leaves >=20 > Can you expand on what these 2 mean? Of course. The current reverse dependency tracking in pkg_install is a hack= : a +REQUIRED_BY file trying to maintain the list of packages that may depend o= n the said dependency, a good way to see it is a hack is to see how often the fil= e get broken (and on portmaster you added an options to fix them so you might kno= w :)) >=20 > What I'm looking for is compelling motivation to make this overwhelming > change to the ports infrastructure. There is not much changes needed in the ports infrastructure. It now works = ootb But there are tons of improvements pkgng will offers, like: ability to simp= ly add new plist keyword without the need of modifying pkgng, native support f= or registering a package from a stagedir. >=20 >=20 > > Schedule > > -------- > >=20 > > The plan is to switch the ports tree to pkgng on CURRENT by default on = July 25th > > No dates are planned yet for other branches. >=20 > Can you describe how this is going to be done? I assume with an > OSVERSION knob in bsd.port.mk? Yes the plan if to check OSVERSION and define WITH_PKGNG on the concerned versions except if the user have defined NO_PKGNG in make.conf >=20 > > Note that there will be a NO_PKGNG knob for some time (undefined yet) f= or people > > not will to switch on July 25th > >=20 > > Please also note that some ports won't work with pkgng right now, becau= se pkgng > > is more strict than pkg_install on purpose. > > The major one is: nvidia drivers, because pkgng does not allow to overw= rite a file > > owned by another package, and we will not accept any hacks for that in = pkgng. >=20 > IMO it would be a very large mistake to switch the default in any branch > until the problem with the nvidia drivers is sorted out. We have a lot > of users (myself included) who use this port, and by switching the > default there's going to be 1 of 2 outcomes for those users. Either they > will opt-out, which means you won't get the level of testing you're > looking for; or you'll break their existing ports installation. Neither > outcome is desirable. I proposed 3 differents way to fix the nvidia driver problem, no one really takle the task on it even if most agreed with at least one of the method. So waiting for someone to provide a really clean way to provide nvidia driv= er, I'm now working on a small modification of the current way it works, that w= ill bypass the pkgng strictness. So nvidia-driver should be fixed on pkgng quite soon (if maintainer do acce= pt the modification :)). I hope, I have answered your question correctly? regards, Bapt --GpGaEY17fSl8rd50 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk//SV8ACgkQ8kTtMUmk6EzdVwCfUXyk+p9ImppQVpl0zCxPMl2d Xk0AoLlDHX/iQPiyQnyT+nZ67hKZ7bMg =cRzu -----END PGP SIGNATURE----- --GpGaEY17fSl8rd50-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:11:09 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 0F692106566B; Thu, 12 Jul 2012 23:11:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8C19114DFB9; Thu, 12 Jul 2012 23:10:59 +0000 (UTC) Message-ID: <4FFF5983.3010708@FreeBSD.org> Date: Thu, 12 Jul 2012 16:10:59 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Baptiste Daroussin References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> In-Reply-To: <20120712220207.GD49382@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 23:11:09 -0000 On 07/12/2012 03:02 PM, Baptiste Daroussin wrote: > On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote: >> I do not mean this e-mail to be in any way critical. I was told after >> the new OPTIONS framework discussion that I should have asked questions >> before the change, so I'm asking these questions now; in a genuine >> attempt to get information. >> >> On 07/12/2012 03:01 AM, Baptiste Daroussin wrote: >> >> In the time that you have been working on this project I have asked >> numerous times for you(pl.) to answer the following questions: >> >> 1. What are the goals for pkg? > > The why part of this mail should reply this question, no? Well clearly not, because if it did I wouldn't keep asking the same questions over and over again. :) > Anyway the goal is to have a decent package manager, providing modern features: > repositories, decent dependency tracking, decent reverse dependency tracking, > managing upgrade correctly (I'll explain this more later), provide a decent > library for third party tools (desktop integration via PackageKit for example) I don't know what "decent" means. I don't know what "modern features" means (beyond the buzzwords that you've included). > Providing easy package management for enterprise Having set up package management systems for enterprises before, *this* is actually a big-picture goal that I have a lot of sympathy for. But again, what's missing is *details* about here is what large enterprises need to make things work for them, here's why the existing tools don't meet those needs, and here is how pkg does meet them. > (who never got problems > managing packages on a large set of freebsd servers, and how complicated it is > on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools) > One of the proof of this problem is how fast people integrated pkgng in those > tools. This gets to the heart of my biggest fear regarding this whole project. It's new, it's shiny, and it looks like forward progress is being made. Thus, it's attracted a lot of attention, input, time, etc. Heck, it may even BE forward progress, but I don't know how to measure that because I don't know what the goals of the project are. Thus, my fear is that without *details* about what the project is, and what it's trying to accomplish, we're going to put an exponentially larger volume of work into the transition and end up no closer to the goal of having a mature package management system. And just to be clear, I am *not* saying that "pkg sucks" or that it's bad, or wrong, or anything else. I'm saying that I don't know how to evaluate it, because you haven't given us a criteria by which to measure it. So what's the problem? We *desperately* need a better system for ports and packages. We only have so many person-hours we can devote to making that happen. If we spend all of them on pkg, and it ends up not helping us enough, we've burnt out our volunteers for no good reason. >> 2. Why can't the existing tools fulfill those goals? > > The existing tools can't fulfill those goals, because they are hardly > maintainable, the code hasn't change much since when they were written, lot of > people have tried over the year to improve them, but all of them gave up. The > design of the tools, (I mean the code) is really imho not adapted to be > improved, I spent a lot of time trying to work on it before starting a complete > new project. This paragraph really frightens me. > For example they do not know what is a version, they do not know what are the > reverse dependencies except through this ugly hack that is +REQUIRED_BY, the > database is pretty fragile: who never got the package corrupted: empty @pkgdep > line for example. So these 2 are a lot closer to what I'd like to see ... *details* about what isn't working now. I would tend to disagree with you that +REQUIRED_BY is an ugly hack, it's no uglier than any of the other text file based dependency tracking we have. But thank you for giving us more information. So taking your last example, how does pkg handle the situation where the user wants to forcibly delete a package that is depended on by another package? >> 3. How does pkg fulfill them? >> >> You've put some of this in the various places where pkg is documented, >> but I don't see any thorough treatment of these questions. You have some >> of it below, which I'd like to see expanded on if you would be so kind. :) > > It is true that, I'm not very good at documenting in general, and even more in > english, hopefully, the documentation is improving a lot recently, there is the > for usage: > http://wiki.freebsd.org/PkgPrimer > and for all other things: > http://wiki.freebsd.org/pkgng > > Lot of native english speakers have joined the project and help with > documentation, if you find someting missing, do not hesitate to had the section > in the apropriate wiki page, I often have a look at them, and try to fill all > the blank section to answer user questions. I'm not looking for "how to." I've explained to you numerous times that I'm looking for a project description. And your English is fine, I understand what you write perfectly, the problem is that you are not willing to sit down and write out, in detail, what the project's goals are. So I'm left to conclude that either A) you don't know because you've never actually sat down and thought them through, or B) you don't think you should have to explain yourself. I find both answers disturbing. Of course there is always answer C) you think I'm a jerk and can't be bothered to answer my questions. If that's the case, fair enough. Just tell me that so I can stop trying to make sense of it. >>> Why pkg? >>> pkg_* tools have become hardly maintainable over the time, >> >> I agree on this point, but the right solution (as some of us have been >> saying for years) is to move the pkg_* tools into the ports tree. You >> are correctly handling that by keeping pkg in the ports tree, I'm simply >> pointing out that this isn't a reason we need to switch to pkg. >> >>> it lacks lots of features most of people are expecting from a package manager: >>> - binary upgrade >> >> I'm not sure what you mean by this. We have the ability to create binary >> packages now. > > No we haven't :), I know we can mimic a binary upgrade using for example > portmaster (I describe this in a poudriere howto) but this is not fully binary > upgrade, it is deinstalling/reinstalling a package. Binary upgrade is much more > complexe than that, for example one thing you can't handle now is a package that > has been splitted into lib vs runtime will break with the current way we can do > it. So what you're saying is that you want to do an in-place binary upgrade of an already installed package? If so, that's an interesting goal, and I'd like to hear more about it. Including but not limited to, what are the advantages and disadvantages to doing that, vs. deinstall->install of the "old" kind of packages? How do you handle the case where the new version has less files than the old? What happens if the files in the installed version have become modified/corrupted somehow? >>> - ability to search information about remote packages >> >> This is a good feature, certainly. However there is no reason we can't >> create a tool to do this, or add the functionality to an existing tool. > > Have a look at what pkgng can present you as information and you will see the > difference. Sorry, this response doesn't address what I wrote. You're saying that you want this feature, so you created a tool that does it. That doesn't change my point that moving to pkg isn't necessary to accomplish this. >>> - real reverse dependency tracking >>> - tracking leaves >> >> Can you expand on what these 2 mean? > > Of course. The current reverse dependency tracking in pkg_install is a hack: a > +REQUIRED_BY file trying to maintain the list of packages that may depend on the > said dependency, a good way to see it is a hack is to see how often the file get > broken (and on portmaster you added an options to fix them so you might know :)) Actually if you pkg_delete stuff in the right order it never gets broken. But, users don't do that, so you're correct that one of the features of portmaster is that it keeps +CONTENTS and +REQUIRED_BY up to date when dependent packages are updated. But the same logic I use in portmaster could easily be brought into the ports framework itself, if that was something that people wanted. >> What I'm looking for is compelling motivation to make this overwhelming >> change to the ports infrastructure. > > There is not much changes needed in the ports infrastructure. It now works ootb > But there are tons of improvements pkgng will offers, like: ability to simply > add new plist keyword without the need of modifying pkgng, That's a feature that could be had just as easily by moving pkg_* to the ports tree. > native support for registering a package from a stagedir. That's another set of changes that it would be nice to see a thorough project plan for. :) >> IMO it would be a very large mistake to switch the default in any branch >> until the problem with the nvidia drivers is sorted out. We have a lot >> of users (myself included) who use this port, and by switching the >> default there's going to be 1 of 2 outcomes for those users. Either they >> will opt-out, which means you won't get the level of testing you're >> looking for; or you'll break their existing ports installation. Neither >> outcome is desirable. > > I proposed 3 differents way to fix the nvidia driver problem, no one really > takle the task on it even if most agreed with at least one of the method. > > So waiting for someone to provide a really clean way to provide nvidia driver, > I'm now working on a small modification of the current way it works, that will > bypass the pkgng strictness. > > So nvidia-driver should be fixed on pkgng quite soon (if maintainer do accept > the modification :)). As long as the solution arrives in the ports tree *before* the default is switched, it should be fine. Doug From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:18:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52D0E106566B; Thu, 12 Jul 2012 23:18:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2492C8FC0A; Thu, 12 Jul 2012 23:18:13 +0000 (UTC) Received: by lbon10 with SMTP id n10so4844403lbo.13 for ; Thu, 12 Jul 2012 16:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=oN5gr8Xa4u6Yrq8qMUrNEgu6aYcZUyyntR+zpmTNojc=; b=pFqWVrK+7xMdfz6zqk79WW4f0gJ2mWCZmxYX+OalTIUdXRK67u3dJ6oRo0auFhPWDb 0orfsA89dvrE/fLHDvPcdnUXt45oQNZ5FrTn2pyzMP23Uy8ehq3YQ2jjz22VYTLPs0er ZHD46YdvEXQ+PP0Y99B9biD2GMKeHuK/nMWix/WCC9gV88zBtKl62YwD5C9T7gLpu2el 5/1Uyf9MDbMXHc7AQJo5I5O1Ca6KHge+j0533jDkRCFEtiw8+44jnWtJA4lPZ7EmNTVo tg3hwvEMh/fEuGVY1rfPZ8c6Fa5xmqxssnhsGVrFXbkSDepQgVQF0PONg7U+ZkSh0vAr 9reg== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr156386lab.17.1342135092829; Thu, 12 Jul 2012 16:18:12 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Thu, 12 Jul 2012 16:18:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jul 2012 00:18:12 +0100 X-Google-Sender-Auth: OpTdrpDJgACfGzZ9P5Xj4oGeLtA Message-ID: From: Attilio Rao To: FreeBSD FS , freebsd-current@freebsd.org, Peter Holm , =?UTF-8?Q?Gustau_P=C3=A9rez?= , George Neville-Neil Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: MPSAFE VFS -- List of upcoming actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 23:18:15 -0000 2012/7/4 Attilio Rao : > 2012/6/29 Attilio Rao : >> As already published several times, according to the following plan: >> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS >> > > I still haven't heard from Vivien or Edward, anyway as NTFS is > basically only used RO these days (also the mount_ntfs code just > permits RO mounting) I stripped all the uncomplete/bogus write support > with the following patch: > http://www.freebsd.org/~attilio/ntfs_remove_write.patch > > This is an attempt to make the code smaller and possibly just focus on > the locking that really matter (as read-only filesystem). > On some points of the patch I'm a bit less sure as we could easily > take into account also write for things like vaccess() arguments, and > make easier to re-add correct write support at some point in the > future, but still force RO, even if the approach used in the patch is > more correct IMHO. > As an added bonus this patch cleans some dirty code in the mount > operation and fixes a bug as vfs_mountedfrom() is called before real > mounting is completed and can still fail. A quick update on this. It looks like NTFS won't be completed for this GSoC thus I seriously need to find an alternative to not loose the NTFS support entirely. I tried to look into the NTFS implementation right now and it is really a poor support. As Peter has also verified, it can deadlock in no-time, it compeltely violates VFS rules, etc. IMHO it deserves a complete rewrite if we would still support in-kernel NTFS. I also tried to look at the NetBSD implementation. Their code is someway similar to our, but they used very complicated (and very dirty) code to do the locking. Even if I don't know well enough NetBSD VFS, I have the impression not all the races are correctly handled. Definitively, not something I would like to port. Considering all that the only viable option would be meaning an userland filesystem implementation. My preferred choice would be to import PUFFS and librefuse on top of it but honestly it requires a lot of time to be completed, time which I don't currently have as in 2 months Giant must be gone by the VFS. I then decided to switch to gnn's rewamp of FUSE patches. You can find his initial e-mail here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html I've precisely got the second version of George's patch and created this dolphin branch: svn://svn.freebsd.org/base/projects/fuse I'm fixing low hanging fruit for the moment (see r238411 for example) and I still have to make a throughful review. However my idea is to commit the support once: - ntfs-3g is well stress-tested and proves to be bug-free - there is no major/big technical issue pending after the reviews I'm now looking for people sticking with the branch and trying to stress-test ntfs-3g as much as they can. For example I know that Gustau (cc'ed) already had issues. It would be good if he tries to reproduce them and make a full report. Please try to stick with the code contained with this branch for the tests unless diversly advised. As final note, George as agreed to maintain FUSE in the long-term and of course I'll give him an hand as time permits. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:20:27 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1EE31065674; Thu, 12 Jul 2012 23:20:27 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 51DE88FC1A; Thu, 12 Jul 2012 23:20:27 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6CNKJgW074156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jul 2012 09:20:19 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6CNKDda019463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 09:20:13 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6CNKDa8019453; Fri, 13 Jul 2012 09:20:13 +1000 (EST) (envelope-from peter) Date: Fri, 13 Jul 2012 09:20:13 +1000 From: Peter Jeremy To: John Baldwin Message-ID: <20120712232013.GA34754@server.rulingia.com> References: <201207121040.27116.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <201207121040.27116.jhb@freebsd.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: scottl@freebsd.org, current@freebsd.org Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 23:20:27 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-12 10:40:27 -0400, John Baldwin wrote: >contigmalloc(). In fact, even better is to call kmem_alloc_contig() direc= tly >rather than using contigmalloc(). =2E.. >Peter, this is somewhat orthognal (but related) to your bus_dma patch whic= h is >what prompted me to post this. Overall, the change seems good to me. My sole thought on the API was whether the actual attribute should be passed, rather than having a couple of new BUS_DMA_ flags but you've addressed that in a followup. One change is that previously allocated memory was all charged to M_DEVBUF via the malloc_type_allocated() call in contigmalloc() whereas now only small allocations are counted. This would seem to indicate that large bus_dmamem_alloc() allocations won't be visible in (eg) "vmstat -m". --=20 Peter Jeremy --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk//W60ACgkQ/opHv/APuIdr6QCdHk7mMLXvzlKh6fBfaNi9q5sn pEkAnR/oKgGStC/HYMpkBBlx3bO2Fj4B =DKsp -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 12 23:43:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1FD4106566B; Thu, 12 Jul 2012 23:43:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 419FA8FC18; Thu, 12 Jul 2012 23:43:26 +0000 (UTC) Received: by qcsg15 with SMTP id g15so2169105qcs.13 for ; Thu, 12 Jul 2012 16:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; bh=cDZ2IcC/PteIDB98nPSbbKQgAO56aex/8xQN3HmL/7w=; b=hFdutBDQF3VzHAw9VZavhLk8MsEG+ZWXFDUnNrkwmxIBw7MkiyrAuMX61Qxummh8I8 anWDBPFFV0BuOa/sAD+zmNyLrRf2UdCb+WnGuhEyO+HJUYcZClfaHwoi32xtGihtN8iC p0hhsR5mwjGAd+DmHjBsNIzc9FJhEH3+Uzp44yUNd3A0t18wT0sZyyOiLD3/KB7UOzjz oE0uUFKrpZRkIREK8tghdn2apmCu5U2Xy6zW1gbZlZgYL7a169otNbhEyAoAsM5Mzn7Z iKl6c/fKRMSm6nGYq63As9VJw1/g+C2IC1zvP86/gnt4yDVD5CuAaqCpVtmCKMfNa8qn ohsA== Received: by 10.224.40.2 with SMTP id i2mr7901951qae.62.1342136605547; Thu, 12 Jul 2012 16:43:25 -0700 (PDT) Received: from triad.knownspace (pool-71-163-84-156.washdc.fios.verizon.net. [71.163.84.156]) by mx.google.com with ESMTPS id cg7sm8859632qab.19.2012.07.12.16.43.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 16:43:24 -0700 (PDT) Message-Id: From: Justin Hibbits To: FreeBSD PowerPC ML Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Jul 2012 19:43:23 -0400 X-Mailer: Apple Mail (2.936) Cc: freebsd-current Subject: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 12 Jul 2012 23:43:26 -0000 When tracking down a panic exposed by INVARIANTS, I tried setting DEBUG_MEMGUARD, so I could find the culprit that's trashing freed memory. However, this causes a panic at bootup. It shows up right after the first WARNING: WITNESS message, with the following: panic: kmem_suballoc: bad status return of 3 cpuid = 0 KDB: stack backtrace: 0xd0004ad0: at kdb_backtrace+0x4c 0xd0004b40: at panic+0x224 0xd0004ba0: at kmem_suballoc+0x8c 0xd0004bd0: at kmeminit+0x1ac 0xd0004c20: at mi_startup+0x13c 0xd0004c50: at btext+0xc0 Tracing, and printf() debugging, I see arguments to vm_map_findspace(): start: 0xD0000000, length: 4246446080, and map- >max_offset = 4026531839. Beyond that, I'm lost with tracking this down. Machine is a dual processor PowerPC G4, with 2GB RAM. Anyone have any ideas? Thanks, Justin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 00:03:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C9D106566B; Fri, 13 Jul 2012 00:03:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2D38FC14; Fri, 13 Jul 2012 00:03:10 +0000 (UTC) Message-ID: <4FFF65BD.4060707@FreeBSD.org> Date: Thu, 12 Jul 2012 20:03:09 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4FFF11CA.60004@FreeBSD.org> In-Reply-To: <4FFF11CA.60004@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , freebsd-security@freebsd.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 00:03:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-12 14:04:58 -0400, Jung-uk Kim wrote: > OpenSSL 1.0.1c will be merged to head today. There will be > several important changes to note. > > - Several crypto/engine modules will be added or enabled by default > to closely match OpenSSL default, e.g., Camellia (crypto), SEED > (crypto), GOST (engine), etc. - MD2 will be removed because a) it > is disabled by default and b) we removed it from libmd. - Optimized > amd64 asm files will be added and enabled by default. - Optimized > i386 asm files will be updated and new files will be added. - > opensslconf.h for amd64 and i386 will be merged. > > Unfortunately, library versions will be bumped, i.e., > > libcrypto.so.6 -> libcrypto.so.7 libssl.so.6 -> libssl.so.7 > > Therefore, all binaries depending on these need to be recompiled. > Also, you may have to merge your /etc/ssl/openssl.conf changes. FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you have any problem. Cheers, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk//Zb0ACgkQmlay1b9qnVMDXACgxjHtAdhyLasffkaqX/Jl9hHX He0An2EjtcRoNsHfTX/ZwZ+iHz2VW2Iq =mHkt -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 01:11:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931221065670; Fri, 13 Jul 2012 01:11:17 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7968FC0A; Fri, 13 Jul 2012 01:11:17 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5080280pbb.13 for ; Thu, 12 Jul 2012 18:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=e8JG8PY3voB1BPcJfQzkYg2OSd12BZA7WLwSiDc3HO8=; b=avdTi0/e1IRP4v5YzdKovS+Mj9iUBgVtS+IcgUlkWvgjxTdQ3V3q9vFEe70PRh+7cm bznN8gG9Gtak9zkoALHc9SbIPGzweMILDoyU99qKxEDCyVAmoBqHakvuqqA1ia55MXeQ SdwUF1If7fnB/X/q1rDrtBTafQ9evr/2cchGdxkyeUoCaFXACI/QQnQHH2lfv4XyfF/o 2kt9/RoH1qyLJgzHyuKHoJYg3x8JiVUT0dDAUFUzQ3VAU/NnYeMLuBAP4/9ygJ+gj3hb T75QXq/MfkxkTCJvUa+eYzVobft0cMUx8uYRLXw/p6Bn3dxAJl+cu0/f6dNaAS7HqBqB l/CQ== MIME-Version: 1.0 Received: by 10.68.242.7 with SMTP id wm7mr9930544pbc.98.1342141877141; Thu, 12 Jul 2012 18:11:17 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Thu, 12 Jul 2012 18:11:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 18:11:16 -0700 X-Google-Sender-Auth: _wikGF-DUsKYgcAYh54rkxtSq6c Message-ID: From: mdf@FreeBSD.org To: Justin Hibbits Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 01:11:17 -0000 On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits wrote: > When tracking down a panic exposed by INVARIANTS, I tried setting > DEBUG_MEMGUARD, so I could find the culprit that's trashing freed memory. > However, this causes a panic at bootup. It shows up right after the first > WARNING: WITNESS message, with the following: > > panic: kmem_suballoc: bad status return of 3 > cpuid = 0 > KDB: stack backtrace: > 0xd0004ad0: at kdb_backtrace+0x4c > 0xd0004b40: at panic+0x224 > 0xd0004ba0: at kmem_suballoc+0x8c > 0xd0004bd0: at kmeminit+0x1ac > 0xd0004c20: at mi_startup+0x13c > 0xd0004c50: at btext+0xc0 > > Tracing, and printf() debugging, I see arguments to vm_map_findspace(): > start: 0xD0000000, length: 4246446080, and map->max_offset = 4026531839. > > Beyond that, I'm lost with tracking this down. Machine is a dual processor > PowerPC G4, with 2GB RAM. The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of virtual space for 2GB of RAM sounds about right (it's been a while since I was in this code), unless this is a 32-bit kernel, in which case it'd be too much since there isn't that much virtual space available. So, is the kernel 32-bit? What are the values used and returned by memguard_fudge()? The intent of that routine is to get kmeminit() to allocate a larger map so memguard can use part of it for private virtual addresses. But it shouldn't be asking for "too much"; i.e. the intent was to check both physical and virtual space available and be greedy, but not too greedy. There were some issues with that code for some platforms that e.g. didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in r216425. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 01:33:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EB91106566B; Fri, 13 Jul 2012 01:33:30 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88FD68FC0A; Fri, 13 Jul 2012 01:33:29 +0000 (UTC) Received: by qcsg15 with SMTP id g15so2207256qcs.13 for ; Thu, 12 Jul 2012 18:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=J9lzbrPD07lW0bD1F9NokEnL7exyt5CQGPOgd9VzM9E=; b=IVK3gC2bY/3i0bEIpTDC0cUV9QIOLkV8pylGHWFqFO59wtsKiK8KGjbrBhZYD7v5sL 01PO7QZwaEVev/Uk1k3Bu6GvV44asX62HkpZOJpMTafmPu1b6zqU8QGnytAnWt4RB/rq uNqECtpzZ6SXdKe0knxr8qhCXcjod+jwggbovfCzGFvnJQdrzuJEpPZqdYWcir30tMEf k/zd9dT19ncAdz0OodlwRBU+rIshUrE+UrIwuYVQxNn3qwSjIRYzkiA/fwc0zNI7Fbr5 Mqn/+f/s7LMqVRJWxICEZGcEtR3hBRVoKWoB0CzS/kWx1SSYmo/waOWifNdWpjwpRSrQ RS+w== Received: by 10.224.176.204 with SMTP id bf12mr8429754qab.92.1342143208991; Thu, 12 Jul 2012 18:33:28 -0700 (PDT) Received: from triad.knownspace (pool-71-163-84-156.washdc.fios.verizon.net. [71.163.84.156]) by mx.google.com with ESMTPS id f14sm9232273qak.20.2012.07.12.18.33.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 18:33:28 -0700 (PDT) Message-Id: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> From: Justin Hibbits To: mdf@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Jul 2012 21:33:26 -0400 References: X-Mailer: Apple Mail (2.936) Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 01:33:30 -0000 On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote: > On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits > wrote: >> When tracking down a panic exposed by INVARIANTS, I tried setting >> DEBUG_MEMGUARD, so I could find the culprit that's trashing freed >> memory. >> However, this causes a panic at bootup. It shows up right after >> the first >> WARNING: WITNESS message, with the following: >> >> panic: kmem_suballoc: bad status return of 3 >> cpuid = 0 >> KDB: stack backtrace: >> 0xd0004ad0: at kdb_backtrace+0x4c >> 0xd0004b40: at panic+0x224 >> 0xd0004ba0: at kmem_suballoc+0x8c >> 0xd0004bd0: at kmeminit+0x1ac >> 0xd0004c20: at mi_startup+0x13c >> 0xd0004c50: at btext+0xc0 >> >> Tracing, and printf() debugging, I see arguments to >> vm_map_findspace(): >> start: 0xD0000000, length: 4246446080, and map->max_offset = >> 4026531839. >> >> Beyond that, I'm lost with tracking this down. Machine is a dual >> processor >> PowerPC G4, with 2GB RAM. > > The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of > virtual space for 2GB of RAM sounds about right (it's been a while > since I was in this code), unless this is a 32-bit kernel, in which > case it'd be too much since there isn't that much virtual space > available. > > So, is the kernel 32-bit? What are the values used and returned by > memguard_fudge()? The intent of that routine is to get kmeminit() to > allocate a larger map so memguard can use part of it for private > virtual addresses. But it shouldn't be asking for "too much"; i.e. > the intent was to check both physical and virtual space available and > be greedy, but not too greedy. > > There were some issues with that code for some platforms that e.g. > didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in r216425. > > Thanks, > matthew It is a 32-bit kernel, on 32-bit hardware. The values for memguard_fudge are (defaults): tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0 When setting vm.kmem_size/vm.kmem_size_max to 2GB they are: tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max: 2147483648 (all 2GB). But the start and map->max_offset remain the same on all runs I make. - Justin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 04:20:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5464C106564A; Fri, 13 Jul 2012 04:20:55 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5908FC17; Fri, 13 Jul 2012 04:20:55 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5316843pbb.13 for ; Thu, 12 Jul 2012 21:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PLaOEMn4ORdxM8wgSRp7kq3siperaJhLWrXgoqeN8ok=; b=eAqvdk4u42d3k7kLP98R+RD5cyVaj8swtSEcxIZVF4bgWlAtpZ/Ffr7F9M90zdjqj5 sinlMnu6csOPA/XvLl8m0XoOjfOAssxJf5pRuRf0U4EBLxih3d/I3OQ+xfyAISqS/n/b Nas4kEazcXxpMAm32ThT1yUyS2V0v/Hf0RZIL1SDt5pA1q49BEzLF/DpMGhfi06F7r0u qufVsB5TLVSVQvfXyhIxMcP8p6fASrH7oLUKxA/112D0bNMH4A0l6YKr4MpDmGIauDEL BePoxJLvmBnNfYzPLbQS6ELV2YvaIbSg2d4fsrB0oVUMgGL3n7Zswtsngdx/Cz6hUXE+ KdXQ== MIME-Version: 1.0 Received: by 10.68.233.132 with SMTP id tw4mr185651pbc.61.1342153254536; Thu, 12 Jul 2012 21:20:54 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Thu, 12 Jul 2012 21:20:54 -0700 (PDT) In-Reply-To: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> References: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> Date: Thu, 12 Jul 2012 21:20:54 -0700 X-Google-Sender-Auth: jk7lQQAheZ6nUYf2Sp01lDQDqvo Message-ID: From: mdf@FreeBSD.org To: Justin Hibbits Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 04:20:55 -0000 On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits wrote: > On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote: > >> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits >> wrote: >>> >>> When tracking down a panic exposed by INVARIANTS, I tried setting >>> DEBUG_MEMGUARD, so I could find the culprit that's trashing freed memory. >>> However, this causes a panic at bootup. It shows up right after the >>> first >>> WARNING: WITNESS message, with the following: >>> >>> Tracing, and printf() debugging, I see arguments to vm_map_findspace(): >>> start: 0xD0000000, length: 4246446080, and map->max_offset = 4026531839. >>> >>> Beyond that, I'm lost with tracking this down. Machine is a dual >>> processor >>> PowerPC G4, with 2GB RAM. >> >> >> The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of >> virtual space for 2GB of RAM sounds about right (it's been a while >> since I was in this code), unless this is a 32-bit kernel, in which >> case it'd be too much since there isn't that much virtual space >> available. >> >> So, is the kernel 32-bit? What are the values used and returned by >> memguard_fudge()? The intent of that routine is to get kmeminit() to >> allocate a larger map so memguard can use part of it for private >> virtual addresses. But it shouldn't be asking for "too much"; i.e. >> the intent was to check both physical and virtual space available and >> be greedy, but not too greedy. >> >> There were some issues with that code for some platforms that e.g. >> didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in r216425. > > It is a 32-bit kernel, on 32-bit hardware. The values for memguard_fudge > are (defaults): > > tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0 > > When setting vm.kmem_size/vm.kmem_size_max to 2GB they are: > > tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max: 2147483648 (all > 2GB). > > But the start and map->max_offset remain the same on all runs I make. memguard_fudge is still broken for 32-bit architectures with no vm_kmem_max. In the absence of a km_max to limit the value, we essentially use twice the physical memory for the virtual limit. But with 2GB on a 32-bit machine, this requires 4GB of virtual space. Setting vm_kmem_size_max to 2GB should work; I'd expect to see tmp=about 200MB, which is much larger than the input 112MB but the allocation should work. But I don't really know what else PowerPC has need of for virtual space, so that still could be too large. You can try smaller values of vm_kmem_size_max, like 1GB or 512MB. You shouldn't need to set vm_kmem_size at all. At some point the added space for the memguard_map will be small enough that the kmem_suballoc will work. Hmm, what is the min_offset and max_offset of kernel_map when the call to memguard_fudge is made? Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:00:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E95D106564A; Fri, 13 Jul 2012 08:00:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9460D8FC08; Fri, 13 Jul 2012 08:00:22 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6D80QZ0059327; Fri, 13 Jul 2012 11:00:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6D80ETd088942; Fri, 13 Jul 2012 11:00:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6D80E1W088941; Fri, 13 Jul 2012 11:00:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Jul 2012 11:00:14 +0300 From: Konstantin Belousov To: Jung-uk Kim Message-ID: <20120713080014.GN2338@deviant.kiev.zoral.com.ua> References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LwDZSyGAvxkXlqsD" Content-Disposition: inline In-Reply-To: <4FFF65BD.4060707@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ben Laurie , freebsd-security@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 08:00:23 -0000 --LwDZSyGAvxkXlqsD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 12, 2012 at 08:03:09PM -0400, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2012-07-12 14:04:58 -0400, Jung-uk Kim wrote: > > OpenSSL 1.0.1c will be merged to head today. There will be > > several important changes to note. > >=20 > > - Several crypto/engine modules will be added or enabled by default > > to closely match OpenSSL default, e.g., Camellia (crypto), SEED > > (crypto), GOST (engine), etc. - MD2 will be removed because a) it > > is disabled by default and b) we removed it from libmd. - Optimized > > amd64 asm files will be added and enabled by default. - Optimized > > i386 asm files will be updated and new files will be added. - How did the asm files were generated (I am sure they are generated) ? > > opensslconf.h for amd64 and i386 will be merged. > >=20 > > Unfortunately, library versions will be bumped, i.e., > >=20 > > libcrypto.so.6 -> libcrypto.so.7 libssl.so.6 -> libssl.so.7 > >=20 > > Therefore, all binaries depending on these need to be recompiled.=20 > > Also, you may have to merge your /etc/ssl/openssl.conf changes. >=20 > FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you > have any problem. >=20 > Cheers, >=20 > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk//Zb0ACgkQmlay1b9qnVMDXACgxjHtAdhyLasffkaqX/Jl9hHX > He0An2EjtcRoNsHfTX/ZwZ+iHz2VW2Iq > =3DmHkt > -----END PGP SIGNATURE----- > _______________________________________________ > 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" --LwDZSyGAvxkXlqsD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk//1Y4ACgkQC3+MBN1Mb4jCeACfQgIeuw5KN9J/9+QxvW/m8INM 7hgAn0wNfSn2d+knqXQX9Ks0VfMHQxMl =meVN -----END PGP SIGNATURE----- --LwDZSyGAvxkXlqsD-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:16:28 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1A27106564A; Fri, 13 Jul 2012 08:16:28 +0000 (UTC) (envelope-from michael@ranner.eu) Received: from mail.azedo.at (mail.azedo.at [91.118.6.139]) by mx1.freebsd.org (Postfix) with ESMTP id 0875A8FC0C; Fri, 13 Jul 2012 08:16:28 +0000 (UTC) Received: from mail.azedo.at (dovecot.azedo.at [172.20.10.3]) by mail.azedo.at (Postfix) with ESMTP id B0CC8A6C156; Fri, 13 Jul 2012 10:16:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at azedo.at Received: from mail.azedo.at ([172.20.10.3]) by mail.azedo.at (mail.azedo.at [172.20.10.3]) (amavisd-new, port 10024) with ESMTP id Fj-xznh6Jk8U; Fri, 13 Jul 2012 10:16:02 +0200 (CEST) Received: from panthera.fritz.box (mom.azedo.at [85.124.38.86]) by mail.azedo.at (Postfix) with ESMTPSA id 87380A6C138; Fri, 13 Jul 2012 10:16:02 +0200 (CEST) Message-ID: <4FFFD944.1030005@ranner.eu> Date: Fri, 13 Jul 2012 10:16:04 +0200 From: Michael Ranner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Doug Barton References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> In-Reply-To: <4FFF5983.3010708@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@FreeBSD.org, Baptiste Daroussin , current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 08:16:28 -0000 Am 13.07.12 01:10, schrieb Doug Barton: > On 07/12/2012 03:02 PM, Baptiste Daroussin wrote: >> On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote: >>> I do not mean this e-mail to be in any way critical. I was told after >>> the new OPTIONS framework discussion that I should have asked questions >>> before the change, so I'm asking these questions now; in a genuine >>> attempt to get information. >>> >>> On 07/12/2012 03:01 AM, Baptiste Daroussin wrote: >>> >>> In the time that you have been working on this project I have asked >>> numerous times for you(pl.) to answer the following questions: >>> >>> 1. What are the goals for pkg? >> The why part of this mail should reply this question, no? > Well clearly not, because if it did I wouldn't keep asking the same > questions over and over again. :) > >> Anyway the goal is to have a decent package manager, providing modern features: >> repositories, decent dependency tracking, decent reverse dependency tracking, >> managing upgrade correctly (I'll explain this more later), provide a decent >> library for third party tools (desktop integration via PackageKit for example) > I don't know what "decent" means. I don't know what "modern features" > means (beyond the buzzwords that you've included). > >> Providing easy package management for enterprise > Having set up package management systems for enterprises before, *this* > is actually a big-picture goal that I have a lot of sympathy for. But > again, what's missing is *details* about here is what large enterprises > need to make things work for them, here's why the existing tools don't > meet those needs, and here is how pkg does meet them. > >> (who never got problems >> managing packages on a large set of freebsd servers, and how complicated it is >> on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools) >> One of the proof of this problem is how fast people integrated pkgng in those >> tools. > This gets to the heart of my biggest fear regarding this whole project. > It's new, it's shiny, and it looks like forward progress is being made. > Thus, it's attracted a lot of attention, input, time, etc. Heck, it may > even BE forward progress, but I don't know how to measure that because I > don't know what the goals of the project are. Thus, my fear is that > without *details* about what the project is, and what it's trying to > accomplish, we're going to put an exponentially larger volume of work > into the transition and end up no closer to the goal of having a mature > package management system. > > And just to be clear, I am *not* saying that "pkg sucks" or that it's > bad, or wrong, or anything else. I'm saying that I don't know how to > evaluate it, because you haven't given us a criteria by which to measure > it. > > So what's the problem? We *desperately* need a better system for ports > and packages. We only have so many person-hours we can devote to making > that happen. If we spend all of them on pkg, and it ends up not helping > us enough, we've burnt out our volunteers for no good reason. I am using pkg_* tools since '94 and I am using portmaster for ports/pkg maintainance for years: pkg_* tools are a pain in the ass in the view of an administrator. I use it only and partly on fresh installs and doing further security auditing with portaudit and upgrading with portmaster - most time upgrading from source. But only, because its simply not possible the same way with the pkg_* tools. Because I manage dozens of installation across Europe, buildind and updating from ports will be more and more time consuming. portmaster is really a great tool to take control of this lack of features in pkg_* tools , but I am running out of time more and more. I was also a bit concerned and reserved to pkgng. But I am also in contact with some local FreeBSD ports committers and one of them (decke) told me some stories about pkgng and poudriere. I saw the talk from Beat Gätzi (beat) at EU BSD Day 2012 about pkgng and was I see was really nice and made me courious. So I tried to setup a small build environment with poudriere and pkgng to evaluate an substitution for my traditional pkg/port security upgrading with portmaster. Finally I think, I can complete replace portmaster with pkgng, poudriere and an self build and maintained pkg repository. This will save a huge amount of time in future and allow to roll out security updates for packages really fast and easy. So pkgng is not designed as a replacement for portmaster, but now it allows me to work without it on most of my installations. I know almost any of the "Linux Enterprise" package management features, pkg_* tools a far away from this kind of functionality, even with the support of the great portmaster tool. Bug pkgng improves much more. Its a very complex problematic. Yes documentation is not so good as it could be. But I saw the talks from beat in live, saw the screencasts from bapt on Youtube and finally I tried it on my own. It was necessary to try it out and see it, feel it, smell and taste it. I think its good work from admin and enterprise point of view. Doug has written portmaster and integrated package handeling, which I only use rarely on my old desktop. Why was this handling integrated in portmaster and not in pkg_* tools? I know its something unkown and new and I had also my problems with the idea of pkgng for the first time (why reinventing the wheel...) - but I tried it out and it works really really well. My opinion after 18 years of FreeBSD administration. Regards, Michael -- Mit freundlichen Grüßen Ing. Michael Ranner GSM: +43 676 4155044 Mail: michael@ranner.eu WWW: http://www.azedo.at/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:29:19 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 196CE106566C; Fri, 13 Jul 2012 08:29:19 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id C910A8FC14; Fri, 13 Jul 2012 08:29:18 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88ae:734:80aa:c1c1]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C8E6D4AC32; Fri, 13 Jul 2012 12:29:11 +0400 (MSK) Date: Fri, 13 Jul 2012 12:29:03 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1855149791.20120713122903@serebryakov.spb.ru> To: Jung-uk Kim In-Reply-To: <4FFF65BD.4060707@FreeBSD.org> References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 08:29:19 -0000 Hello, Jung-uk. You wrote 13 =D0=B8=D1=8E=D0=BB=D1=8F 2012 =D0=B3., 4:03:09: >> Therefore, all binaries depending on these need to be recompiled. >> Also, you may have to merge your /etc/ssl/openssl.conf changes. JuK> FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you JuK> have any problem. No ports with "USE_OPENSSL=3Dyes" could be built now :( Ports system complains about not-installed base OpenSSL. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 09:23:48 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0988B1065673; Fri, 13 Jul 2012 09:23:48 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id B8A088FC0C; Fri, 13 Jul 2012 09:23:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88ae:734:80aa:c1c1]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id B91414AC2D; Fri, 13 Jul 2012 13:23:46 +0400 (MSK) Date: Fri, 13 Jul 2012 13:23:38 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <661167458.20120713132338@serebryakov.spb.ru> To: Lev Serebryakov In-Reply-To: <1855149791.20120713122903@serebryakov.spb.ru> References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> <1855149791.20120713122903@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 09:23:48 -0000 Hello, Lev. You wrote 13 =D0=B8=D1=8E=D0=BB=D1=8F 2012 =D0=B3., 12:29:03: JuK>> FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you JuK>> have any problem. LS> No ports with "USE_OPENSSL=3Dyes" could be built now :( Ports system LS> complains about not-installed base OpenSSL. Sorry for noise, it is local problem. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 09:55:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B470D1065679 for ; Fri, 13 Jul 2012 09:55:15 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 710FC8FC1F for ; Fri, 13 Jul 2012 09:55:09 +0000 (UTC) Received: (qmail 23118 invoked by uid 399); 13 Jul 2012 09:55:01 -0000 Received: from unknown (HELO ?172.17.194.139?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 13 Jul 2012 09:55:01 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4FFFF078.6050109@dougbarton.us> Date: Fri, 13 Jul 2012 02:55:04 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jung-uk Kim References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> In-Reply-To: <4FFF65BD.4060707@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 13 Jul 2012 11:16:21 +0000 Cc: Ben Laurie , freebsd-security@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 09:55:15 -0000 On 07/12/2012 05:03 PM, Jung-uk Kim wrote: > FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you > have any problem. Sorry if I missed it, but did you bump OSVERSION for this change? If not, could you? It would be helpful for dealing with ports stuff, especially USE_OPENSSL. Doug From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 11:41:28 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB569106564A; Fri, 13 Jul 2012 11:41:28 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4D3428FC12; Fri, 13 Jul 2012 11:41:27 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6DBfBLd043641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jul 2012 21:41:11 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6DBf4kM086147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 21:41:05 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6DBf0D5086145; Fri, 13 Jul 2012 21:41:00 +1000 (EST) (envelope-from peter) Date: Fri, 13 Jul 2012 21:41:00 +1000 From: Peter Jeremy To: Steve Kargl Message-ID: <20120713114100.GB83006@server.rulingia.com> References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <20120711212009.GA15542@night.db.net> <20120711214346.GA9877@troutmask.apl.washington.edu> <20120711215414.GA16350@night.db.net> <20120711223247.GA9964@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline In-Reply-To: <20120711223247.GA9964@troutmask.apl.washington.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Diane Bruce , freebsd-current@FreeBSD.ORG, David Schultz , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 11:41:28 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-11 15:32:47 -0700, Steve Kargl wrote: >I know an approach to implementing many of the missing >functions. Are you willing to share this insight so someone else could do the work? > When I do find >some free time, I look at what is missing and start to >put together a new function. At the moment, it seems >that it takes 3+ years to get a new function written, >tested, and committed. And, from what I can see, much of this is done quietly - which opens up the possibility that two people might both implement the same code or that people will avoid the area in fear of treading on someone else's toes. As I said previously, I believe the existing wiki page could be improved to form a central co-ordinating point to show what what activity is (or isn't) occurring. >but most people seem to push the "easy button" and want >to grab either cephes or netlib's libm. There are >technical issues with this approach that I won't=20 >rehash again. Doing it properly requires significant effort by people with fairly specialised skills. Whilst the project has several people with the skills, it appears that none of them currently have the time. In the meantime, FreeBSD is taking free kicks from other FOSS groups that have gone down the quick-and-dirty path. AFAIK, none of the relevant standards (POSIX, IEEE754) have any precision requirements for functions other than +-*/ and sqrt() - all of which we have correctly implemented. I therefore believe that, for the remaining missing functions, the Project would be best served by committing the best code that is currently available under a suitable license and cleaning it up over time (as was done for the current libm). --=20 Peter Jeremy --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAACUwACgkQ/opHv/APuIcwqgCgwLaUHwzv44xZgBxteeiYX9U/ uTgAnj55TtruaclDQ+wAXqqWQOqwcY1a =wEeu -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:15:57 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0C311065670; Fri, 13 Jul 2012 12:15:57 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 87C088FC17; Fri, 13 Jul 2012 12:15:57 +0000 (UTC) Received: from [10.0.10.3] ([173.88.199.104]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jul 2012 05:14:54 -0700 Message-ID: <5000113D.2000004@a1poweruser.com> Date: Fri, 13 Jul 2012 08:14:53 -0400 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> <4FFFD944.1030005@ranner.eu> In-Reply-To: <4FFFD944.1030005@ranner.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2012 12:14:54.0482 (UTC) FILETIME=[1C7AFF20:01CD60F1] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:15:57 -0000 What I want to know is this new pkg system going to remove the requirement of having the complete ports tree on my system? What I am looking for in an port system, is to install a port and any files needed for the parent port and its dependents to automatically be downloaded. So in the end my system ports tree only contain the files used to install the ports I use and their dependents. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:27:50 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C9D61065670; Fri, 13 Jul 2012 12:27:50 +0000 (UTC) (envelope-from michael@ranner.eu) Received: from mail.azedo.at (mail.azedo.at [91.118.6.139]) by mx1.freebsd.org (Postfix) with ESMTP id 191868FC12; Fri, 13 Jul 2012 12:27:50 +0000 (UTC) Received: from mail.azedo.at (dovecot.azedo.at [172.20.10.3]) by mail.azedo.at (Postfix) with ESMTP id 3ABD7A6C153; Fri, 13 Jul 2012 14:27:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at azedo.at Received: from mail.azedo.at ([172.20.10.3]) by mail.azedo.at (mail.azedo.at [172.20.10.3]) (amavisd-new, port 10024) with ESMTP id dGkybSImRpwP; Fri, 13 Jul 2012 14:27:35 +0200 (CEST) Received: from panthera.fritz.box (mom.azedo.at [85.124.38.86]) by mail.azedo.at (Postfix) with ESMTPSA id C10C0A6C151; Fri, 13 Jul 2012 14:27:35 +0200 (CEST) Message-ID: <50001437.90305@ranner.eu> Date: Fri, 13 Jul 2012 14:27:35 +0200 From: Michael Ranner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fbsd8 References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> <4FFFD944.1030005@ranner.eu> <5000113D.2000004@a1poweruser.com> In-Reply-To: <5000113D.2000004@a1poweruser.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:27:50 -0000 Am 13.07.12 14:14, schrieb Fbsd8: > What I want to know is this new pkg system going to remove the > requirement of having the complete ports tree on my system? > > What I am looking for in an port system, is to install a port and any > files needed for the parent port and its dependents to automatically > be downloaded. So in the end my system ports tree only contain the > files used to install the ports I use and their dependents. > The new pkg system is not a replacement for the ports tree. If you still like to compile software from ports, you will need the ports tree. But you can install a precompiled package with the new pkg system and it automatically downloads all necessary binary packages it depends on. So probably you dont need the ports any more. Regards Michael -- Mit freundlichen Grüßen Ing. Michael Ranner GSM: +43 676 4155044 Mail: michael@ranner.eu WWW: http://www.azedo.at/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:28:45 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E209E1065670; Fri, 13 Jul 2012 12:28:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B48A88FC22; Fri, 13 Jul 2012 12:28:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E52D8B944; Fri, 13 Jul 2012 08:28:44 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2012 08:18:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> In-Reply-To: <20120713114100.GB83006@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207130818.38535.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 08:28:45 -0400 (EDT) Cc: Warner Losh , Diane Bruce , Peter Jeremy , David Schultz , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:28:46 -0000 On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote: > AFAIK, none of the relevant standards (POSIX, IEEE754) have any > precision requirements for functions other than +-*/ and sqrt() - all > of which we have correctly implemented. I therefore believe that, for > the remaining missing functions, the Project would be best served by > committing the best code that is currently available under a suitable > license and cleaning it up over time (as was done for the current > libm). I concur. However, are there any patches that we can commit now? It seems that there are some things that could go into the tree now that will certainly reduce the concerns of the R folk. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:28:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D3F106566C; Fri, 13 Jul 2012 12:28:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8D88FC18; Fri, 13 Jul 2012 12:28:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 950E8B94A; Fri, 13 Jul 2012 08:28:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2012 08:26:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> In-Reply-To: <4FFF3EB9.3040701@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207130826.32942.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 08:28:46 -0400 (EDT) Cc: ports@freebsd.org, Craig Rodrigues , Baptiste Daroussin , Doug Barton , current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:28:47 -0000 On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: > On 07/12/2012 02:11 PM, Craig Rodrigues wrote: > > You might want to view Baptiste's pkgng presentation at BSDCan: > > > > http://www.youtube.com/watch?v=4Hxq7AHZ27I > > Sure, the next time I have an hour to spare. > > I don't think what I'm asking for is unreasonable. One could even > conclude that answering those 3 questions should have been a > prerequisite for starting down this road in the first place. One could also assume that other people in the Project aren't morons and do actually put thought into the things they do for starters (you do realize, btw, that that is how you come across, that even though you don't intend that, constantly questioning decisions made by other people in an accusatory fashion gives that impression? At least adjust your wording to start off with the assumption that other people _have_ put thought into things. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:28:47 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D3F106566C; Fri, 13 Jul 2012 12:28:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8D88FC18; Fri, 13 Jul 2012 12:28:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 950E8B94A; Fri, 13 Jul 2012 08:28:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2012 08:26:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> In-Reply-To: <4FFF3EB9.3040701@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207130826.32942.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 08:28:46 -0400 (EDT) Cc: ports@freebsd.org, Craig Rodrigues , Baptiste Daroussin , Doug Barton , current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:28:47 -0000 On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: > On 07/12/2012 02:11 PM, Craig Rodrigues wrote: > > You might want to view Baptiste's pkgng presentation at BSDCan: > > > > http://www.youtube.com/watch?v=4Hxq7AHZ27I > > Sure, the next time I have an hour to spare. > > I don't think what I'm asking for is unreasonable. One could even > conclude that answering those 3 questions should have been a > prerequisite for starting down this road in the first place. One could also assume that other people in the Project aren't morons and do actually put thought into the things they do for starters (you do realize, btw, that that is how you come across, that even though you don't intend that, constantly questioning decisions made by other people in an accusatory fashion gives that impression? At least adjust your wording to start off with the assumption that other people _have_ put thought into things. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:37:56 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 340B6106568A; Fri, 13 Jul 2012 12:37:56 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id AAF408FC15; Fri, 13 Jul 2012 12:37:55 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q6DCbn2o018356 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 13:37:49 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q6DCbn2o018356 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1342183069; bh=IkePWXGYjkhsCN4ay50EJ5zeERKyeDI+E9G98YANJa0=; h=Date:From:To:CC:Subject:References:In-Reply-To:Content-Type: Message-ID:Mime-Version; b=pGeciKBC7v5Y/XWNWAS0iZqcA81u6tr3kFvYupBXdCESxAsz2PVoBy3FS9wpiLbRD CarHXOX/f81UQMEu+VUo10cfI9c5Kf8WXvRsC7QL9jwl2hjXvPQtWUDG604RxVJ+mC Qvbjtdj/YxHQ1xhQeker/vjSUw7IB3j358ydzQTY= Message-ID: <50001694.6060909@infracaninophile.co.uk> Date: Fri, 13 Jul 2012 13:37:40 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Fbsd8 References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> <4FFFD944.1030005@ranner.eu> <5000113D.2000004@a1poweruser.com> In-Reply-To: <5000113D.2000004@a1poweruser.com> X-Enigmail-Version: 1.4.2 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAABC28D015A23E52229546FE" X-Virus-Scanned: clamav-milter 0.97.5 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_ADSP_ALL,DKIM_SIGNED,T_DKIM_INVALID autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:37:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAABC28D015A23E52229546FE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 13/07/2012 13:14, Fbsd8 wrote: > What I want to know is this new pkg system going to remove the > requirement of having the complete ports tree on my system? >=20 > What I am looking for in an port system, is to install a port and any > files needed for the parent port and its dependents to automatically be= > downloaded. So in the end my system ports tree only contain the files > used to install the ports I use and their dependents. Yes, you will be able to use pkgng without having a full ports tree installed on your system. You can pretty much do that already, although the central pkgng package repository is still only in beta. The only bit of pkgng that still requires the ports to be installed is 'pkg version' which is not critical for maintaining your system. Modifying 'pkg version' so that it doesn't need to use the ports tree is an open issue on github: https://github.com/pkgng/pkgng/issues/195 Patches / pull requests gratefully received. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigAABC28D015A23E52229546FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAFpwACgkQ8Mjk52CukIwjbgCeLBWAJdMnwtg4p6RCokGQhe/y a6oAoJLH13Z8YssCHwhrfHFVk7iPUho/ =AgSG -----END PGP SIGNATURE----- --------------enigAABC28D015A23E52229546FE-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 12:55:04 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888A7106566C for ; Fri, 13 Jul 2012 12:55:04 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 464B48FC15 for ; Fri, 13 Jul 2012 12:55:04 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6DCt2C6069146 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 13 Jul 2012 12:55:03 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> Date: Fri, 13 Jul 2012 13:55:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> To: John Baldwin X-Mailer: Apple Mail (2.1278) Cc: Diane Bruce , freebsd-current@FreeBSD.org, Steve Kargl , David Schultz , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 12:55:04 -0000 On 13 Jul 2012, at 13:18, John Baldwin wrote: > On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote: >> AFAIK, none of the relevant standards (POSIX, IEEE754) have any >> precision requirements for functions other than +-*/ and sqrt() - all >> of which we have correctly implemented. I therefore believe that, = for >> the remaining missing functions, the Project would be best served by >> committing the best code that is currently available under a suitable >> license and cleaning it up over time (as was done for the current >> libm). >=20 > I concur. =20 As do I. I'd also point out that the ONLY requirement for long double = according to the standard is that it has at least the same precision as = double. Therefore, any implementation of these functions that is no = worse that the double version is compliant. Once we have something = meeting a minimum standard, then I'm very happy to see it improved, but = having C99 functions missing now is just embarrassing while we're = working on adding C11 features. David P.S. Someone said earlier that our clang still lacks some C99 features. = Please point me at the relevant clang PRs and I'll be happy to work on = them. There are quite a few open issues for C11 support, but C99 is, as = far as I know, done. =20= From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 13:30:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8524106566B for ; Fri, 13 Jul 2012 13:30:26 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 72CD08FC08 for ; Fri, 13 Jul 2012 13:30:26 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.10]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6DC4Pbt005643 for ; Fri, 13 Jul 2012 06:04:26 -0600 From: Erich Dollansky To: freebsd-current@freebsd.org Date: Fri, 13 Jul 2012 19:04:24 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201207131904.24490.erichfreebsdlist@ovitrap.com> Subject: Erratic USB mouse behaviour when wireless is down and USB hard disk connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 13:30:26 -0000 Hi, I know that this is not a very helpful information. I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed that the USB mouse (a wireless Logitech Trackman) becomes unusable when the wireless (iwn) is not able to connect to the access point and a USB hard disk is plugged in. Even when no data are transferred the USB mouse is unusable. The built-in track-point behaves just normal. When I turn off the wireless network via the hardware switch, the system stays usable as expected even under heavy hard disk access. If it was not something else I have missed, the only difference was the access point which went down when I noticed the problem. Please understand this just as a hint to the developers of the sub-systems which could cause the problem. As this network here is not mine, I am not able to do any tests with it. If somebody has an idea what could be tested, tell me please. I will have access to 'my' network the coming week again. Erich From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 14:10:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1124D106566B for ; Fri, 13 Jul 2012 14:10:18 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 856718FC14 for ; Fri, 13 Jul 2012 14:10:17 +0000 (UTC) Received: by lbon10 with SMTP id n10so5916233lbo.13 for ; Fri, 13 Jul 2012 07:10:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=nhk8G0xEv1DOp62nkDAAXRoweeHOHG5lN4nhsUBBQk8=; b=JunRmagp0qcY0Qedx0mo8LG5WHvihD6x+KAE8EOq7Lskm4q0IIF4yNP1zZuH21udUg dMFjpbu/eMlTBbjtNlFCqlBITovLCHNy2K8VhcLaA3EQuQHbuEKld7eWRpNtF77IYnRq z4PL6dDyhFDLEtwWh9Tzt/4Pe5nxA6y0f8yPvg4PFJFEIkj62YFL9TpLyMHo3WE/gdhZ P/+5/0jAs6ODSt4apzLKXM2pNawFM0iXV6hiyCEpoQC46OMbdhePAg3ldhBIu3+lsFWR ETKgtHyol30Y9V8AWndWRc/COmsvp0Z/eZ+akay9FQY/KyTqz1OcWAFRLZaYB0yDGHDa +JZw== MIME-Version: 1.0 Received: by 10.112.84.39 with SMTP id v7mr953683lby.15.1342188616508; Fri, 13 Jul 2012 07:10:16 -0700 (PDT) Received: by 10.152.106.167 with HTTP; Fri, 13 Jul 2012 07:10:16 -0700 (PDT) X-Originating-IP: [79.140.39.245] In-Reply-To: <201207131904.24490.erichfreebsdlist@ovitrap.com> References: <201207131904.24490.erichfreebsdlist@ovitrap.com> Date: Fri, 13 Jul 2012 16:10:16 +0200 Message-ID: From: Bernhard Schmidt To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnb0Iuc9VeHF3M/wzmTmbRKxmIbcuf/EUEfrbsQ00q9SqWu1hCBUZFqnH+Fa7x1wVX59aXk Cc: freebsd-current@freebsd.org Subject: Re: Erratic USB mouse behaviour when wireless is down and USB hard disk connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 14:10:18 -0000 On Fri, Jul 13, 2012 at 2:04 PM, Erich Dollansky wrote: > Hi, > > I know that this is not a very helpful information. > > I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed that > the USB mouse (a wireless Logitech Trackman) becomes unusable when the > wireless (iwn) is not able to connect to the access point and a USB hard disk > is plugged in. Even when no data are transferred the USB mouse is unusable. Which frequency is the mouse working on? something in the 2.4GHz region? I remember having lots of fun at $office with the mouse of colleague. It used channel 6 and the amount of traffic generating over wireless LAN had direct influence on the accuracy of his mouse activity ;) Anyways, if you have the chance to switch to another channel, give it a shot. -- Bernhard From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 14:52:17 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4079106564A for ; Fri, 13 Jul 2012 14:52:17 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 72C1D8FC1A for ; Fri, 13 Jul 2012 14:52:17 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=sweb; b=ztLZCLIBjQI1sHvdJMlYjUAhJQfHoRGk 7FzvKZtCeEZDsOnaqMWvLoPIRRAbf9vv0mLc3Hue4HWNGKkV6VDYFC7MTJJkfyQx 4NlIm8NskXSwhyQp0rJZzgC/4Rm6qOIUP1O8HnYnQDFQ2TLraXEc3z9oZe/M9Z34 H9N8oWPY9q8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=sweb; bh=i+DUCbk4Mioz1Wg2jSqDLpE5CSON305/WOZ52h QJyRU=; b=Tdc+JlekZbwaMyF3xs2HY7EcPTnLDddEFJtptAsl2GpzYx2YKwHIbn ET/F/r71vhXIhH9neMboE08S0Qj6uss4EIclp0x9XAXFd+wUfwznhlPH4ZNgnhHD 0g7EqYfKrOme3nFjOqJg3wQwZ06ebvWrW58UCcQTxUYmWwP+NDpSM= Received: (qmail 35719 invoked from network); 13 Jul 2012 09:52:14 -0500 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 13 Jul 2012 09:52:14 -0500 Message-ID: <50003628.1000706@shatow.net> Date: Fri, 13 Jul 2012 09:52:24 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ports@FreeBSD.org References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> <4FFFD944.1030005@ranner.eu> In-Reply-To: <4FFFD944.1030005@ranner.eu> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4328653FE749FA95A863BA1" Cc: Michael Ranner , Baptiste Daroussin , Doug Barton , current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 14:52:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB4328653FE749FA95A863BA1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7/13/2012 3:16 AM, Michael Ranner wrote: > I was also a bit concerned and reserved to pkgng. But I am also in > contact with some local FreeBSD ports committers and one of them (decke= ) > told me some stories about pkgng and poudriere. I saw the talk from Bea= t > G=E4tzi (beat) at EU BSD Day 2012 about pkgng and was I see was really > nice and made me courious. So I tried to setup a small build environmen= t > with poudriere and pkgng to evaluate an substitution for my traditional= > pkg/port security upgrading with portmaster. This explains how you can setup your own repository and build your own packages with poudriere+pkgng: http://blog.etoilebsd.net/post/Home_made_pkgng_repo --=20 Regards, Bryan Drewery bdrewery@freenode/EFNet --------------enigB4328653FE749FA95A863BA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQADYoAAoJEG54KsA8mwz5LG8P/3ymmQhXfUh+zm4cX/IpTuzW qnjBx/OJ0xSz2Y5udcjDzAM853HJ9DAmE1r+CLEWnfRTAV6RfMIAIJjJGfCzfWGw HaMNDuTYi1q63bNecJiRHVruBCzWwbWdj57rdcXKV8odMnqATjDR7Wbr8MzTOZiC UgwCDFCnnyvj9hiYo2L3XG60B5MAdB8Ges2XlogkMSJWPiVUiU3T2qbSoeSNnkou G9q/LE/7m/hiyiyKkYF9pOGtAP7KU0Uh2+QbWx5FX8/SOhzWHU9P53L2OHjmSnrq 3zQZX6OIxv2zbsipG/bYkoC8WfIdQKjSfA/f925v/GIXfWC8m2KY4g/VLYQR/pBn Zj/Gk4wMHmJU2dAEfw55HqN6LdrofK1qPzS+4/88HjJqR5Js65BPALfC6L/ZcVVy n825suBq4E3oYjZWpB0QZ0xX/+1nb9zTF3Z1REZBrtU7EM0NAeZ5Pige3BestK6N TCChGBpb2Ml18paZAG8MgWGCZ543jwJ8TpD0QFRsSjMgzNeIkRKQ6tW/etGgqZ+A cVfybMT9iR24VlC88YOOBFomrauw9I4LBq1yJpxkRwS0qRQw/+3v0ye5R3ABq/zw myWUdMNWZiZ53c1e3AIkgnMUTaoKjHD9D26LH40xbw3qhsYgFTan64V412lR7yC3 +cQE+JFhLlt7qBGCOSF8 =RVlC -----END PGP SIGNATURE----- --------------enigB4328653FE749FA95A863BA1-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:23:21 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FEF5106566C; Fri, 13 Jul 2012 15:23:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 346C58FC0C; Fri, 13 Jul 2012 15:23:21 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q6DFNJYn066979; Fri, 13 Jul 2012 08:23:19 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q6DFNHOC066978; Fri, 13 Jul 2012 08:23:17 -0700 (PDT) (envelope-from sgk) Date: Fri, 13 Jul 2012 08:23:17 -0700 From: Steve Kargl To: Peter Jeremy Message-ID: <20120713152317.GA66875@troutmask.apl.washington.edu> References: <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <20120711212009.GA15542@night.db.net> <20120711214346.GA9877@troutmask.apl.washington.edu> <20120711215414.GA16350@night.db.net> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120713114100.GB83006@server.rulingia.com> User-Agent: Mutt/1.4.2.3i Cc: Diane Bruce , freebsd-current@FreeBSD.ORG, David Schultz , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 15:23:21 -0000 On Fri, Jul 13, 2012 at 09:41:00PM +1000, Peter Jeremy wrote: > On 2012-Jul-11 15:32:47 -0700, Steve Kargl wrote: > >I know an approach to implementing many of the missing > >functions. > > Are you willing to share this insight so someone else could do the work? For the missing trig and hyperbolic functions of complex float and complex double arguments, one can follow the approach in msun/src/s_ccosh[f].c. For the missing hyperbolic functions of long double and complex long double argument, people will need to wait for expl() and expm1l() to show up in tree. I have a working expl() and almost working expm1l() for ld80 systems. Until a few months ago, I did not have access to a ld128 system, so I haven't wasted my time implementing ld128 version that I could not test. > >When I do find > >some free time, I look at what is missing and start to > >put together a new function. At the moment, it seems > >that it takes 3+ years to get a new function written, > >tested, and committed. > > And, from what I can see, much of this is done quietly - which opens > up the possibility that two people might both implement the same code > or that people will avoid the area in fear of treading on someone > else's toes. As I said previously, I believe the existing wiki page > could be improved to form a central co-ordinating point to show what > what activity is (or isn't) occurring. Well, I've posted the code I've written to freebsd-standards mailinglist more than once, and have only ever received comments from exactly 2 people. > >but most people seem to push the "easy button" and want > >to grab either cephes or netlib's libm. There are > >technical issues with this approach that I won't > >rehash again. > > Doing it properly requires significant effort by people with fairly > specialised skills. Whilst the project has several people with the > skills, it appears that none of them currently have the time. In the > meantime, FreeBSD is taking free kicks from other FOSS groups that > have gone down the quick-and-dirty path. > > AFAIK, none of the relevant standards (POSIX, IEEE754) have any > precision requirements for functions other than +-*/ and sqrt() - all > of which we have correctly implemented. I therefore believe that, for > the remaining missing functions, the Project would be best served by > committing the best code that is currently available under a suitable > license and cleaning it up over time (as was done for the current > libm). Well, hopefully, the someone who takes the best available code also tests this code before it is committed. I suspect that some if not all of those codes that involve complex arguments will have problems with the requirements in n1256.pdf[1], because neither gcc in base nor clang do complex arithmetic correctly under certains conditions when an expression uses I from complex.h. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:34:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74839106568F; Fri, 13 Jul 2012 15:34:46 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC748FC15; Fri, 13 Jul 2012 15:34:46 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 9DAAD2AA471; Fri, 13 Jul 2012 09:34:45 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id DCD401DAF2; Fri, 13 Jul 2012 10:34:37 -0500 (EST) Date: Fri, 13 Jul 2012 10:34:37 -0500 From: Diane Bruce To: David Chisnall Message-ID: <20120713153437.GA47229@night.db.net> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> User-Agent: Mutt/1.4.2.3i Cc: Diane Bruce , freebsd-current@freebsd.org, Steve Kargl , David Schultz , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 15:34:46 -0000 On Fri, Jul 13, 2012 at 01:53:39PM +0100, David Chisnall wrote: > On 13 Jul 2012, at 13:18, John Baldwin wrote: > > > On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote: > >> AFAIK, none of the relevant standards (POSIX, IEEE754) have any > >> precision requirements for functions other than +-*/ and sqrt() - all > >> of which we have correctly implemented. I therefore believe that, for > >> the remaining missing functions, the Project would be best served by > >> committing the best code that is currently available under a suitable > >> license and cleaning it up over time (as was done for the current > >> libm). > > > > I concur. > > As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. > I'd be curious how well the GPL functions in Linux compare to the NetBSD functions. I don't suppose we could grab some of the public domain routines in NetLib? > David > > P.S. Someone said earlier that our clang still lacks some C99 features. Please point me at the relevant clang PRs and I'll be happy to work on them. There are quite a few open issues for C11 support, but C99 is, as far as I know, done. Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db Nowadays tar can compress using yesterdays latest technologies! From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:38:01 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 93C741065672; Fri, 13 Jul 2012 15:38:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 261EB201AA9; Fri, 13 Jul 2012 15:36:11 +0000 (UTC) Message-ID: <5000406B.2060201@FreeBSD.org> Date: Fri, 13 Jul 2012 08:36:11 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> <201207130826.32942.jhb@freebsd.org> In-Reply-To: <201207130826.32942.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Craig Rodrigues , Baptiste Daroussin , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 15:38:01 -0000 On 07/13/2012 05:26 AM, John Baldwin wrote: > On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: >> On 07/12/2012 02:11 PM, Craig Rodrigues wrote: >>> You might want to view Baptiste's pkgng presentation at BSDCan: >>> >>> http://www.youtube.com/watch?v=4Hxq7AHZ27I >> >> Sure, the next time I have an hour to spare. >> >> I don't think what I'm asking for is unreasonable. One could even >> conclude that answering those 3 questions should have been a >> prerequisite for starting down this road in the first place. > > One could also assume that other people in the Project aren't morons and do > actually put thought into the things they do for starters I certainly *want* to believe that. But considering the giant mess that portmgr + Baptiste made of the changes to the OPTIONS framework, that only touches a fraction of the ports, my willingness to have faith in "them" to do it right is near zero. Not to mention that I've been asking for a project plan for pkg since long before it even hit the ports tree in beta. What I'm asking for should have been done already considering that this change will affect *every* port, and *every* user. So either it hasn't actually been done, or the PTB are refusing to provide it. Also, please keep in mind that I was criticized for *not* speaking up about the OPTIONS changes, now I'm being criticized *for* speaking up prior to pkg going live. In spite of the fact that I'm doing my best to (repeatedly) be clear that I'm not against the project, I just want to know more about it. > Also, when other > people have taken time to explain an large decision because you are too lazy > to invest the time doesn't really help your case). Um, I'm too lazy? I've read everything that's been written on pkg to date. Have you? 90% of it is "how to" type stuff that doesn't address what we need. The other 10% is so vague and general as to be useless as a project plan. You're an experienced project manager John. If someone who worked for you came to you with a plan this vague ("modern" foo, "decent" bar), for a critical system, how would you respond? (And yes, I realize that no one around here works for me, that isn't my point at all.) > In terms of the first feature (binary upgrades), the truth is that if you have > more than 5 machines to manage, our current pkg tools completely suck. There > is no automated upgrade mechanism. If you want one you have to write your own > set of infrastructure to do the right collection of pkg_delete/pkg_adds. > Certainly there is no support in the current package tools for doing batch > upgrades (i.e. upgrading from one completely package set to another). pkgng > adds that feature, and I find it a must for supporting large installations of > machines that need automated management. And as I wrote previously, I've been there and done that, so yes, I'm interested in the feature. But I'd like to know more about the plans for it so that those of us who *do* have experience in this topic can share that, and we can avoid having to reinvent the wheel. Or worse, putting out something half-assed that uses up a lot of developer cycles and doesn't get the job done. Doug From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:38:01 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 93C741065672; Fri, 13 Jul 2012 15:38:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 261EB201AA9; Fri, 13 Jul 2012 15:36:11 +0000 (UTC) Message-ID: <5000406B.2060201@FreeBSD.org> Date: Fri, 13 Jul 2012 08:36:11 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Baldwin References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> <201207130826.32942.jhb@freebsd.org> In-Reply-To: <201207130826.32942.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, Craig Rodrigues , Baptiste Daroussin , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 15:38:01 -0000 On 07/13/2012 05:26 AM, John Baldwin wrote: > On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: >> On 07/12/2012 02:11 PM, Craig Rodrigues wrote: >>> You might want to view Baptiste's pkgng presentation at BSDCan: >>> >>> http://www.youtube.com/watch?v=4Hxq7AHZ27I >> >> Sure, the next time I have an hour to spare. >> >> I don't think what I'm asking for is unreasonable. One could even >> conclude that answering those 3 questions should have been a >> prerequisite for starting down this road in the first place. > > One could also assume that other people in the Project aren't morons and do > actually put thought into the things they do for starters I certainly *want* to believe that. But considering the giant mess that portmgr + Baptiste made of the changes to the OPTIONS framework, that only touches a fraction of the ports, my willingness to have faith in "them" to do it right is near zero. Not to mention that I've been asking for a project plan for pkg since long before it even hit the ports tree in beta. What I'm asking for should have been done already considering that this change will affect *every* port, and *every* user. So either it hasn't actually been done, or the PTB are refusing to provide it. Also, please keep in mind that I was criticized for *not* speaking up about the OPTIONS changes, now I'm being criticized *for* speaking up prior to pkg going live. In spite of the fact that I'm doing my best to (repeatedly) be clear that I'm not against the project, I just want to know more about it. > Also, when other > people have taken time to explain an large decision because you are too lazy > to invest the time doesn't really help your case). Um, I'm too lazy? I've read everything that's been written on pkg to date. Have you? 90% of it is "how to" type stuff that doesn't address what we need. The other 10% is so vague and general as to be useless as a project plan. You're an experienced project manager John. If someone who worked for you came to you with a plan this vague ("modern" foo, "decent" bar), for a critical system, how would you respond? (And yes, I realize that no one around here works for me, that isn't my point at all.) > In terms of the first feature (binary upgrades), the truth is that if you have > more than 5 machines to manage, our current pkg tools completely suck. There > is no automated upgrade mechanism. If you want one you have to write your own > set of infrastructure to do the right collection of pkg_delete/pkg_adds. > Certainly there is no support in the current package tools for doing batch > upgrades (i.e. upgrading from one completely package set to another). pkgng > adds that feature, and I find it a must for supporting large installations of > machines that need automated management. And as I wrote previously, I've been there and done that, so yes, I'm interested in the feature. But I'd like to know more about the plans for it so that those of us who *do* have experience in this topic can share that, and we can avoid having to reinvent the wheel. Or worse, putting out something half-assed that uses up a lot of developer cycles and doesn't get the job done. Doug From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:52:45 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D341E106564A; Fri, 13 Jul 2012 15:52:45 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5885D8FC08; Fri, 13 Jul 2012 15:52:45 +0000 (UTC) Message-ID: <5000444C.6030000@FreeBSD.org> Date: Fri, 13 Jul 2012 11:52:44 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: Doug Barton References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> <4FFFF078.6050109@dougbarton.us> In-Reply-To: <4FFFF078.6050109@dougbarton.us> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , freebsd-security@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 15:52:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-13 05:55:04 -0400, Doug Barton wrote: > On 07/12/2012 05:03 PM, Jung-uk Kim wrote: >> FYI, OpenSSL 1.0.1c import is complete now. Please let me know >> if you have any problem. > > Sorry if I missed it, but did you bump OSVERSION for this change? > If not, could you? It would be helpful for dealing with ports > stuff, especially USE_OPENSSL. Yes, it was bumped with the commit. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAREwACgkQmlay1b9qnVNpkgCffS1dK8lvKRBXpxeebRGcx/kE UYIAoMxzzJUcx2JvTY996Vm4eHHriXVt =NvEB -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 15:58:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23F58106566B for ; Fri, 13 Jul 2012 15:58:13 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id B9EC18FC08 for ; Fri, 13 Jul 2012 15:58:12 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q6DFw62a082262; Fri, 13 Jul 2012 11:58:06 -0400 (EDT) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q6DFw5QA082261; Fri, 13 Jul 2012 11:58:05 -0400 (EDT) (envelope-from das@freebsd.org) Date: Fri, 13 Jul 2012 11:58:05 -0400 From: David Schultz To: David Chisnall Message-ID: <20120713155805.GC81965@zim.MIT.EDU> Mail-Followup-To: David Chisnall , John Baldwin , freebsd-current@freebsd.org, Warner Losh , Diane Bruce , Peter Jeremy , Steve Kargl References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Diane Bruce , freebsd-current@freebsd.org, Steve Kargl , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 15:58:13 -0000 On Fri, Jul 13, 2012, David Chisnall wrote: > As do I. I'd also point out that the ONLY requirement for long > double according to the standard is that it has at least the same > precision as double. Therefore, any implementation of these > functions that is no worse that the double version is compliant. > Once we have something meeting a minimum standard, then I'm very > happy to see it improved, but having C99 functions missing now is > just embarrassing while we're working on adding C11 features. There are several things wrong with this reasoning, but pragmatically the conclusion may be right: we do have a long list of users who would prefer a dubious implementation to none at all. I propose we set a timeframe for this, on the order of a few months. A rough outline might be something like: mid-August: expl logl log2l log10l -- just need to clean up Bruce and Steve's work; Steve recently sent me patches for expl, which I hope get committed soon mid-September: acoshl asinhl atanhl coshl sinhl tanhl -- easy once expl is in; others could probably help mid-October: powl expm1l mid-November: most complex.h functions If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. By the way, the trig and complex functions are areas where anyone with some calculus background could contribute. If anyone is interested in helping out, I'd be happy to coordinate things and review patches, although I will be unavailable for much of August. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:01:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 974251065678 for ; Fri, 13 Jul 2012 16:01:59 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1758FC19 for ; Fri, 13 Jul 2012 16:01:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=uTCI2E K1jt44n1yjFwQ65mlVjsnF9mvIjZmzwhgQjpuw7dR8PseiwIxwuMaTA29DriOsEM ReCvtljAMD+1HMjSsjQDcWW8W+MynNgWsfMxqImWLgpNIFphY8gLv26c+LgMCCxX kBA6DfoOWAukGzXu687imYfIBnx6C/WV8hMBQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=DpY7u9ZcITF1 gDP/HGnfTbW7bw2Xm13kBwOgpCw1mcU=; b=hUm8cCW4AJ5XjTMkRe85PWAtfc4V 70VrzkFh4vOfrplm2M4TRXfBBdOkZiEecLItPFGBCajpWo6G6Am/O2n11NTmy+me ObvLror4E5sgRCAxLLFkQz5Rq2CZ0Dd3hcAeuwg3dCZq6WzUpJ95qO1ExAkByo03 OBbmcXaCh6J+hIE= Received: (qmail 98128 invoked from network); 13 Jul 2012 11:01:55 -0500 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 13 Jul 2012 11:01:55 -0500 Message-ID: <5000467D.4000902@shatow.net> Date: Fri, 13 Jul 2012 11:02:05 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Doug Barton References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> <201207130826.32942.jhb@freebsd.org> <5000406B.2060201@FreeBSD.org> In-Reply-To: <5000406B.2060201@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , Baptiste Daroussin , current@freebsd.org, ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:01:59 -0000 On 7/13/2012 10:36 AM, Doug Barton wrote: > On 07/13/2012 05:26 AM, John Baldwin wrote: >> On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: >>> On 07/12/2012 02:11 PM, Craig Rodrigues wrote: >>>> You might want to view Baptiste's pkgng presentation at BSDCan: >>>> >>>> http://www.youtube.com/watch?v=4Hxq7AHZ27I >>> >>> Sure, the next time I have an hour to spare. >>> >>> I don't think what I'm asking for is unreasonable. One could even >>> conclude that answering those 3 questions should have been a >>> prerequisite for starting down this road in the first place. >> >> One could also assume that other people in the Project aren't morons and do >> actually put thought into the things they do for starters > > I certainly *want* to believe that. But considering the giant mess that > portmgr + Baptiste made of the changes to the OPTIONS framework, that > only touches a fraction of the ports, my willingness to have faith in > "them" to do it right is near zero. There's a *major* difference in the testing effort and community involvement in these 2 projects. OPTIONSng had maybe a handful of testers over a shorter period of time. PKGNG has had 40+ contributors and has been in development since 2010. It's been presented and discussed at multiple conferences and dev summits. Many people have been building their own packages with PKGNG for months now, greatly raising the testing coverage on the ports tree. > > Not to mention that I've been asking for a project plan for pkg since > long before it even hit the ports tree in beta. What I'm asking for > should have been done already considering that this change will affect > *every* port, and *every* user. So either it hasn't actually been done, > or the PTB are refusing to provide it. http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html I find bapt's research in that post to be evident that a lot of thought and time did go into planning this. > > Also, please keep in mind that I was criticized for *not* speaking up > about the OPTIONS changes, now I'm being criticized *for* speaking up > prior to pkg going live. In spite of the fact that I'm doing my best to > (repeatedly) be clear that I'm not against the project, I just want to > know more about it. > >> Also, when other >> people have taken time to explain an large decision because you are too lazy >> to invest the time doesn't really help your case). > > Um, I'm too lazy? I've read everything that's been written on pkg to > date. Have you? 90% of it is "how to" type stuff that doesn't address > what we need. The other 10% is so vague and general as to be useless as > a project plan. Have you watched the BSDCan presentation video yet? It is very compelling and exciting. > > You're an experienced project manager John. If someone who worked for > you came to you with a plan this vague ("modern" foo, "decent" bar), for > a critical system, how would you respond? (And yes, I realize that no > one around here works for me, that isn't my point at all.) > >> In terms of the first feature (binary upgrades), the truth is that if you have >> more than 5 machines to manage, our current pkg tools completely suck. There >> is no automated upgrade mechanism. If you want one you have to write your own >> set of infrastructure to do the right collection of pkg_delete/pkg_adds. >> Certainly there is no support in the current package tools for doing batch >> upgrades (i.e. upgrading from one completely package set to another). pkgng >> adds that feature, and I find it a must for supporting large installations of >> machines that need automated management. > > And as I wrote previously, I've been there and done that, so yes, I'm > interested in the feature. But I'd like to know more about the plans for > it so that those of us who *do* have experience in this topic can share > that, and we can avoid having to reinvent the wheel. Or worse, putting > out something half-assed that uses up a lot of developer cycles and > doesn't get the job done. So get involved! Come help. Contribute. > > Doug -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:02:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0961E1065672 for ; Fri, 13 Jul 2012 16:02:00 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id A0D5D8FC08 for ; Fri, 13 Jul 2012 16:01:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=uTCI2E K1jt44n1yjFwQ65mlVjsnF9mvIjZmzwhgQjpuw7dR8PseiwIxwuMaTA29DriOsEM ReCvtljAMD+1HMjSsjQDcWW8W+MynNgWsfMxqImWLgpNIFphY8gLv26c+LgMCCxX kBA6DfoOWAukGzXu687imYfIBnx6C/WV8hMBQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=DpY7u9ZcITF1 gDP/HGnfTbW7bw2Xm13kBwOgpCw1mcU=; b=hUm8cCW4AJ5XjTMkRe85PWAtfc4V 70VrzkFh4vOfrplm2M4TRXfBBdOkZiEecLItPFGBCajpWo6G6Am/O2n11NTmy+me ObvLror4E5sgRCAxLLFkQz5Rq2CZ0Dd3hcAeuwg3dCZq6WzUpJ95qO1ExAkByo03 OBbmcXaCh6J+hIE= Received: (qmail 98128 invoked from network); 13 Jul 2012 11:01:55 -0500 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 13 Jul 2012 11:01:55 -0500 Message-ID: <5000467D.4000902@shatow.net> Date: Fri, 13 Jul 2012 11:02:05 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Doug Barton References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> <201207130826.32942.jhb@freebsd.org> <5000406B.2060201@FreeBSD.org> In-Reply-To: <5000406B.2060201@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , Baptiste Daroussin , current@freebsd.org, ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:02:00 -0000 On 7/13/2012 10:36 AM, Doug Barton wrote: > On 07/13/2012 05:26 AM, John Baldwin wrote: >> On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: >>> On 07/12/2012 02:11 PM, Craig Rodrigues wrote: >>>> You might want to view Baptiste's pkgng presentation at BSDCan: >>>> >>>> http://www.youtube.com/watch?v=4Hxq7AHZ27I >>> >>> Sure, the next time I have an hour to spare. >>> >>> I don't think what I'm asking for is unreasonable. One could even >>> conclude that answering those 3 questions should have been a >>> prerequisite for starting down this road in the first place. >> >> One could also assume that other people in the Project aren't morons and do >> actually put thought into the things they do for starters > > I certainly *want* to believe that. But considering the giant mess that > portmgr + Baptiste made of the changes to the OPTIONS framework, that > only touches a fraction of the ports, my willingness to have faith in > "them" to do it right is near zero. There's a *major* difference in the testing effort and community involvement in these 2 projects. OPTIONSng had maybe a handful of testers over a shorter period of time. PKGNG has had 40+ contributors and has been in development since 2010. It's been presented and discussed at multiple conferences and dev summits. Many people have been building their own packages with PKGNG for months now, greatly raising the testing coverage on the ports tree. > > Not to mention that I've been asking for a project plan for pkg since > long before it even hit the ports tree in beta. What I'm asking for > should have been done already considering that this change will affect > *every* port, and *every* user. So either it hasn't actually been done, > or the PTB are refusing to provide it. http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html I find bapt's research in that post to be evident that a lot of thought and time did go into planning this. > > Also, please keep in mind that I was criticized for *not* speaking up > about the OPTIONS changes, now I'm being criticized *for* speaking up > prior to pkg going live. In spite of the fact that I'm doing my best to > (repeatedly) be clear that I'm not against the project, I just want to > know more about it. > >> Also, when other >> people have taken time to explain an large decision because you are too lazy >> to invest the time doesn't really help your case). > > Um, I'm too lazy? I've read everything that's been written on pkg to > date. Have you? 90% of it is "how to" type stuff that doesn't address > what we need. The other 10% is so vague and general as to be useless as > a project plan. Have you watched the BSDCan presentation video yet? It is very compelling and exciting. > > You're an experienced project manager John. If someone who worked for > you came to you with a plan this vague ("modern" foo, "decent" bar), for > a critical system, how would you respond? (And yes, I realize that no > one around here works for me, that isn't my point at all.) > >> In terms of the first feature (binary upgrades), the truth is that if you have >> more than 5 machines to manage, our current pkg tools completely suck. There >> is no automated upgrade mechanism. If you want one you have to write your own >> set of infrastructure to do the right collection of pkg_delete/pkg_adds. >> Certainly there is no support in the current package tools for doing batch >> upgrades (i.e. upgrading from one completely package set to another). pkgng >> adds that feature, and I find it a must for supporting large installations of >> machines that need automated management. > > And as I wrote previously, I've been there and done that, so yes, I'm > interested in the feature. But I'd like to know more about the plans for > it so that those of us who *do* have experience in this topic can share > that, and we can avoid having to reinvent the wheel. Or worse, putting > out something half-assed that uses up a lot of developer cycles and > doesn't get the job done. So get involved! Come help. Contribute. > > Doug -- Regards, Bryan Drewery bdrewery@freenode/EFNet From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:04:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8085D1065673; Fri, 13 Jul 2012 16:04:26 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 550028FC15; Fri, 13 Jul 2012 16:04:25 +0000 (UTC) Received: by bkcje9 with SMTP id je9so3487317bkc.13 for ; Fri, 13 Jul 2012 09:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=XB/wA4riI99uFO6aLtShfE/290W+bRfe8PLYlPE52QY=; b=sL5bcaIQCan2+8BdAJ8xJMlqmWXIm3ahVB0s7F8+2/Af3gZBiy35tg7hu8C1sgL8nR FWS5c8AXqU4wBjc9cWdYKVPhQrzEFLSd8JzqEmmpGfKz/+wKm14x81QvCSP1EOP7GdSB ynURGkdirPSepXIjEx0ERb/YFD+j2k0dbrEPMhu3G4t+lRdqKD+QyM0kNU9Gg7Cu56Mp L2yF9kXxN5SravNKn4e7ug3elsH3EbTkvGIE8XMXTPSV3KUJnrWojgNMzMmuNMwgafNv JqtMlhMyeNbwY48WOMdj3F1lK6WwNIG9hhRaNLMM6Xfwes4co0p5ZFqpgxyLkhjc3laU HTmg== Received: by 10.204.151.81 with SMTP id b17mr1312306bkw.95.1342195464396; Fri, 13 Jul 2012 09:04:24 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.49.87 with HTTP; Fri, 13 Jul 2012 09:03:53 -0700 (PDT) In-Reply-To: <5000467D.4000902@shatow.net> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> <201207130826.32942.jhb@freebsd.org> <5000406B.2060201@FreeBSD.org> <5000467D.4000902@shatow.net> From: Chris Rees Date: Fri, 13 Jul 2012 17:03:53 +0100 X-Google-Sender-Auth: NbQYWdPhR0xK41B2S707KuVmEqU Message-ID: To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 Cc: Craig Rodrigues , Baptiste Daroussin , Doug Barton , current@freebsd.org, ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:04:26 -0000 On 13 July 2012 17:02, Bryan Drewery wrote: > On 7/13/2012 10:36 AM, Doug Barton wrote: >> On 07/13/2012 05:26 AM, John Baldwin wrote: >>> On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: >>>> On 07/12/2012 02:11 PM, Craig Rodrigues wrote: >>>>> You might want to view Baptiste's pkgng presentation at BSDCan: >>>>> >>>>> http://www.youtube.com/watch?v=4Hxq7AHZ27I >>>> >>>> Sure, the next time I have an hour to spare. >>>> >>>> I don't think what I'm asking for is unreasonable. One could even >>>> conclude that answering those 3 questions should have been a >>>> prerequisite for starting down this road in the first place. >>> >>> One could also assume that other people in the Project aren't morons and do >>> actually put thought into the things they do for starters >> >> I certainly *want* to believe that. But considering the giant mess that >> portmgr + Baptiste made of the changes to the OPTIONS framework, that >> only touches a fraction of the ports, my willingness to have faith in >> "them" to do it right is near zero. > > There's a *major* difference in the testing effort and community > involvement in these 2 projects. OPTIONSng had maybe a handful of > testers over a shorter period of time. > > PKGNG has had 40+ contributors and has been in development since 2010. > It's been presented and discussed at multiple conferences and dev > summits. Many people have been building their own packages with PKGNG > for months now, greatly raising the testing coverage on the ports tree. > >> >> Not to mention that I've been asking for a project plan for pkg since >> long before it even hit the ports tree in beta. What I'm asking for >> should have been done already considering that this change will affect >> *every* port, and *every* user. So either it hasn't actually been done, >> or the PTB are refusing to provide it. > > http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html > > I find bapt's research in that post to be evident that a lot of thought > and time did go into planning this. > >> >> Also, please keep in mind that I was criticized for *not* speaking up >> about the OPTIONS changes, now I'm being criticized *for* speaking up >> prior to pkg going live. In spite of the fact that I'm doing my best to >> (repeatedly) be clear that I'm not against the project, I just want to >> know more about it. >> >>> Also, when other >>> people have taken time to explain an large decision because you are too lazy >>> to invest the time doesn't really help your case). >> >> Um, I'm too lazy? I've read everything that's been written on pkg to >> date. Have you? 90% of it is "how to" type stuff that doesn't address >> what we need. The other 10% is so vague and general as to be useless as >> a project plan. > > Have you watched the BSDCan presentation video yet? It is very > compelling and exciting. > >> >> You're an experienced project manager John. If someone who worked for >> you came to you with a plan this vague ("modern" foo, "decent" bar), for >> a critical system, how would you respond? (And yes, I realize that no >> one around here works for me, that isn't my point at all.) >> >>> In terms of the first feature (binary upgrades), the truth is that if you have >>> more than 5 machines to manage, our current pkg tools completely suck. There >>> is no automated upgrade mechanism. If you want one you have to write your own >>> set of infrastructure to do the right collection of pkg_delete/pkg_adds. >>> Certainly there is no support in the current package tools for doing batch >>> upgrades (i.e. upgrading from one completely package set to another). pkgng >>> adds that feature, and I find it a must for supporting large installations of >>> machines that need automated management. >> >> And as I wrote previously, I've been there and done that, so yes, I'm >> interested in the feature. But I'd like to know more about the plans for >> it so that those of us who *do* have experience in this topic can share >> that, and we can avoid having to reinvent the wheel. Or worse, putting >> out something half-assed that uses up a lot of developer cycles and >> doesn't get the job done. > > So get involved! Come help. Contribute. > And PLEASE get that portmaster patch integrated. Chris From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:04:26 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8085D1065673; Fri, 13 Jul 2012 16:04:26 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 550028FC15; Fri, 13 Jul 2012 16:04:25 +0000 (UTC) Received: by bkcje9 with SMTP id je9so3487317bkc.13 for ; Fri, 13 Jul 2012 09:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=XB/wA4riI99uFO6aLtShfE/290W+bRfe8PLYlPE52QY=; b=sL5bcaIQCan2+8BdAJ8xJMlqmWXIm3ahVB0s7F8+2/Af3gZBiy35tg7hu8C1sgL8nR FWS5c8AXqU4wBjc9cWdYKVPhQrzEFLSd8JzqEmmpGfKz/+wKm14x81QvCSP1EOP7GdSB ynURGkdirPSepXIjEx0ERb/YFD+j2k0dbrEPMhu3G4t+lRdqKD+QyM0kNU9Gg7Cu56Mp L2yF9kXxN5SravNKn4e7ug3elsH3EbTkvGIE8XMXTPSV3KUJnrWojgNMzMmuNMwgafNv JqtMlhMyeNbwY48WOMdj3F1lK6WwNIG9hhRaNLMM6Xfwes4co0p5ZFqpgxyLkhjc3laU HTmg== Received: by 10.204.151.81 with SMTP id b17mr1312306bkw.95.1342195464396; Fri, 13 Jul 2012 09:04:24 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.204.49.87 with HTTP; Fri, 13 Jul 2012 09:03:53 -0700 (PDT) In-Reply-To: <5000467D.4000902@shatow.net> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF3EB9.3040701@FreeBSD.org> <201207130826.32942.jhb@freebsd.org> <5000406B.2060201@FreeBSD.org> <5000467D.4000902@shatow.net> From: Chris Rees Date: Fri, 13 Jul 2012 17:03:53 +0100 X-Google-Sender-Auth: NbQYWdPhR0xK41B2S707KuVmEqU Message-ID: To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 Cc: Craig Rodrigues , Baptiste Daroussin , Doug Barton , current@freebsd.org, ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:04:26 -0000 On 13 July 2012 17:02, Bryan Drewery wrote: > On 7/13/2012 10:36 AM, Doug Barton wrote: >> On 07/13/2012 05:26 AM, John Baldwin wrote: >>> On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: >>>> On 07/12/2012 02:11 PM, Craig Rodrigues wrote: >>>>> You might want to view Baptiste's pkgng presentation at BSDCan: >>>>> >>>>> http://www.youtube.com/watch?v=4Hxq7AHZ27I >>>> >>>> Sure, the next time I have an hour to spare. >>>> >>>> I don't think what I'm asking for is unreasonable. One could even >>>> conclude that answering those 3 questions should have been a >>>> prerequisite for starting down this road in the first place. >>> >>> One could also assume that other people in the Project aren't morons and do >>> actually put thought into the things they do for starters >> >> I certainly *want* to believe that. But considering the giant mess that >> portmgr + Baptiste made of the changes to the OPTIONS framework, that >> only touches a fraction of the ports, my willingness to have faith in >> "them" to do it right is near zero. > > There's a *major* difference in the testing effort and community > involvement in these 2 projects. OPTIONSng had maybe a handful of > testers over a shorter period of time. > > PKGNG has had 40+ contributors and has been in development since 2010. > It's been presented and discussed at multiple conferences and dev > summits. Many people have been building their own packages with PKGNG > for months now, greatly raising the testing coverage on the ports tree. > >> >> Not to mention that I've been asking for a project plan for pkg since >> long before it even hit the ports tree in beta. What I'm asking for >> should have been done already considering that this change will affect >> *every* port, and *every* user. So either it hasn't actually been done, >> or the PTB are refusing to provide it. > > http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html > > I find bapt's research in that post to be evident that a lot of thought > and time did go into planning this. > >> >> Also, please keep in mind that I was criticized for *not* speaking up >> about the OPTIONS changes, now I'm being criticized *for* speaking up >> prior to pkg going live. In spite of the fact that I'm doing my best to >> (repeatedly) be clear that I'm not against the project, I just want to >> know more about it. >> >>> Also, when other >>> people have taken time to explain an large decision because you are too lazy >>> to invest the time doesn't really help your case). >> >> Um, I'm too lazy? I've read everything that's been written on pkg to >> date. Have you? 90% of it is "how to" type stuff that doesn't address >> what we need. The other 10% is so vague and general as to be useless as >> a project plan. > > Have you watched the BSDCan presentation video yet? It is very > compelling and exciting. > >> >> You're an experienced project manager John. If someone who worked for >> you came to you with a plan this vague ("modern" foo, "decent" bar), for >> a critical system, how would you respond? (And yes, I realize that no >> one around here works for me, that isn't my point at all.) >> >>> In terms of the first feature (binary upgrades), the truth is that if you have >>> more than 5 machines to manage, our current pkg tools completely suck. There >>> is no automated upgrade mechanism. If you want one you have to write your own >>> set of infrastructure to do the right collection of pkg_delete/pkg_adds. >>> Certainly there is no support in the current package tools for doing batch >>> upgrades (i.e. upgrading from one completely package set to another). pkgng >>> adds that feature, and I find it a must for supporting large installations of >>> machines that need automated management. >> >> And as I wrote previously, I've been there and done that, so yes, I'm >> interested in the feature. But I'd like to know more about the plans for >> it so that those of us who *do* have experience in this topic can share >> that, and we can avoid having to reinvent the wheel. Or worse, putting >> out something half-assed that uses up a lot of developer cycles and >> doesn't get the job done. > > So get involved! Come help. Contribute. > And PLEASE get that portmaster patch integrated. Chris From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:08:09 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4EE9106564A for ; Fri, 13 Jul 2012 16:08:09 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF208FC17 for ; Fri, 13 Jul 2012 16:08:09 +0000 (UTC) Received: from [128.206.184.213] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q6DG7tEE076436; Fri, 13 Jul 2012 11:07:55 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <500047DB.60607@missouri.edu> Date: Fri, 13 Jul 2012 11:07:55 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Chisnall , John Baldwin , freebsd-current@freebsd.org, Warner Losh , Diane Bruce , Peter Jeremy , Steve Kargl References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> In-Reply-To: <20120713155805.GC81965@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:08:09 -0000 On 07/13/12 10:58, David Schultz wrote: > On Fri, Jul 13, 2012, David Chisnall wrote: >> As do I. I'd also point out that the ONLY requirement for long >> double according to the standard is that it has at least the same >> precision as double. Therefore, any implementation of these >> functions that is no worse that the double version is compliant. >> Once we have something meeting a minimum standard, then I'm very >> happy to see it improved, but having C99 functions missing now is >> just embarrassing while we're working on adding C11 features. > > There are several things wrong with this reasoning, but pragmatically > the conclusion may be right: we do have a long list of users who would > prefer a dubious implementation to none at all. > > I propose we set a timeframe for this, on the order of a few months. > A rough outline might be something like: > > mid-August: expl logl log2l log10l > -- just need to clean up Bruce and Steve's work; Steve recently > sent me patches for expl, which I hope get committed soon > mid-September: acoshl asinhl atanhl coshl sinhl tanhl > -- easy once expl is in; others could probably help > mid-October: powl expm1l > mid-November: most complex.h functions > > If the schedule can't be met, then we can just import Cephes as an > interim solution without further ado. This provides Bruce and Steve > an opportunity to commit what they have been working on, without > forcing the rest of the FreeBSD community to wait indefinitely for > the pie in the sky. This sounds fantastic. > By the way, the trig and complex functions are areas where anyone with > some calculus background could contribute. If anyone is interested in > helping out, I'd be happy to coordinate things and review patches, > although I will be unavailable for much of August. I would be happy to help. Just give me a sense of direction of what I should try and work on, when and as you are ready. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:20:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85A0106566C; Fri, 13 Jul 2012 16:20:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 883268FC0A; Fri, 13 Jul 2012 16:20:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E6028B944; Fri, 13 Jul 2012 12:20:56 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Fri, 13 Jul 2012 12:20:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <201207130826.32942.jhb@freebsd.org> <5000406B.2060201@FreeBSD.org> In-Reply-To: <5000406B.2060201@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207131220.56501.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 12:20:57 -0400 (EDT) Cc: ports@freebsd.org, Craig Rodrigues , Baptiste Daroussin , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:20:58 -0000 On Friday, July 13, 2012 11:36:11 am Doug Barton wrote: > Also, please keep in mind that I was criticized for *not* speaking up > about the OPTIONS changes, now I'm being criticized *for* speaking up > prior to pkg going live. In spite of the fact that I'm doing my best to > (repeatedly) be clear that I'm not against the project, I just want to > know more about it. To clarify, you are not being criticized for speaking up, you are being criticized for the way in which you are speaking up (an accusatory tone) and for blowing off a pointer to a talk that would perhaps answer some of your questions. > > Also, when other > > people have taken time to explain an large decision because you are too lazy > > to invest the time doesn't really help your case). > > Um, I'm too lazy? I've read everything that's been written on pkg to > date. Have you? 90% of it is "how to" type stuff that doesn't address > what we need. The other 10% is so vague and general as to be useless as > a project plan. Hmm, that is not my distinct impression. However, I do have the advantage of having been part of several in-person meetings and discussions (for example, the ports working group at the developer summit for BSDCan where a lot of discussion and planning took place about the future of packages). > You're an experienced project manager John. If someone who worked for > you came to you with a plan this vague ("modern" foo, "decent" bar), for > a critical system, how would you respond? (And yes, I realize that no > one around here works for me, that isn't my point at all.) My understanding of this plan is far less vague. In practice, pkgng hasn't really been happening under a rock. There have been multiple announcements and calls for testing and I know that many folks are testing it and working with it. Large projects such as this can be a bit bumpy in FreeBSD land, and I expect that there will be things that crop up that have to be fixed as a result of wider testing. (For example, I agree with you that the nvidia driver packages have to work correctly as that is a non-starter for me as well). However, I am confident that pkgng and the new packages model is aiming at the right target based on my own interactions with Erwin, Baptiste, and others, and I think we need to push this forward and gain wider testing to make progress, even if there are bumps in the road. > > In terms of the first feature (binary upgrades), the truth is that if you have > > more than 5 machines to manage, our current pkg tools completely suck. There > > is no automated upgrade mechanism. If you want one you have to write your own > > set of infrastructure to do the right collection of pkg_delete/pkg_adds. > > Certainly there is no support in the current package tools for doing batch > > upgrades (i.e. upgrading from one completely package set to another). pkgng > > adds that feature, and I find it a must for supporting large installations of > > machines that need automated management. > > And as I wrote previously, I've been there and done that, so yes, I'm > interested in the feature. But I'd like to know more about the plans for > it so that those of us who *do* have experience in this topic can share > that, and we can avoid having to reinvent the wheel. Or worse, putting > out something half-assed that uses up a lot of developer cycles and > doesn't get the job done. Well, what I can tell you is that many of us who do have experience with that model have been discussing this in various fora, initially in e-mails, IRC discussions, informal discussions during the "hallway track" at conferences, etc. To build a broader consensus, portmgr@ has been holding larger, more formal discussions in the form of devsummit working groups, presentations at conferences, etc. I personally have been petitioning anyone's ear I could bend for package sets for example. I realize, btw, that not all of those discussions have occurred on public mailing lists. The fact is, there is a tradeoff between informal communication (such as in-person commucation) and mails to a mailing list. In-person communication especially offers far higher bandwidth and can be far more effective for reaching consensus and working through alternatives, but it has a more limited audience. Being a volunteer project distributed all over the globe, we are somewhat stuck with that tradeoff. We attempt to mitigate that tradeoff somewhat by making more of these informal discussions more formal (e.g. adding working groups at the devsummit which include wiki pages with summaries of the agenda and slide decks used to present the wg summary to the full complement of attendees so there is at least some information availble for folks who were not able to attend). However, it does mean that just because you were not personally involved in a discussion or did not see a long and tedious thread, you should not assume that no discussion has taken place at all. Back to my original e-mail: FreeBSD is a big project. I try to keep a pulse on as much of it as I can (mostly by reading/skimming a _lot_ of e-mail each day), but even with all that there is a lot going on that I don't know the intimate details of. Instead, I choose to trust my fellow developers to best manage the areas over which they have expertise and detailed knowledge until given strong evidence to assume otherwise. My humble suggestion to you would be to adopt a similar strategy. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:20:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85A0106566C; Fri, 13 Jul 2012 16:20:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 883268FC0A; Fri, 13 Jul 2012 16:20:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E6028B944; Fri, 13 Jul 2012 12:20:56 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Fri, 13 Jul 2012 12:20:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <201207130826.32942.jhb@freebsd.org> <5000406B.2060201@FreeBSD.org> In-Reply-To: <5000406B.2060201@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207131220.56501.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 12:20:57 -0400 (EDT) Cc: ports@freebsd.org, Craig Rodrigues , Baptiste Daroussin , freebsd-current@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:20:58 -0000 On Friday, July 13, 2012 11:36:11 am Doug Barton wrote: > Also, please keep in mind that I was criticized for *not* speaking up > about the OPTIONS changes, now I'm being criticized *for* speaking up > prior to pkg going live. In spite of the fact that I'm doing my best to > (repeatedly) be clear that I'm not against the project, I just want to > know more about it. To clarify, you are not being criticized for speaking up, you are being criticized for the way in which you are speaking up (an accusatory tone) and for blowing off a pointer to a talk that would perhaps answer some of your questions. > > Also, when other > > people have taken time to explain an large decision because you are too lazy > > to invest the time doesn't really help your case). > > Um, I'm too lazy? I've read everything that's been written on pkg to > date. Have you? 90% of it is "how to" type stuff that doesn't address > what we need. The other 10% is so vague and general as to be useless as > a project plan. Hmm, that is not my distinct impression. However, I do have the advantage of having been part of several in-person meetings and discussions (for example, the ports working group at the developer summit for BSDCan where a lot of discussion and planning took place about the future of packages). > You're an experienced project manager John. If someone who worked for > you came to you with a plan this vague ("modern" foo, "decent" bar), for > a critical system, how would you respond? (And yes, I realize that no > one around here works for me, that isn't my point at all.) My understanding of this plan is far less vague. In practice, pkgng hasn't really been happening under a rock. There have been multiple announcements and calls for testing and I know that many folks are testing it and working with it. Large projects such as this can be a bit bumpy in FreeBSD land, and I expect that there will be things that crop up that have to be fixed as a result of wider testing. (For example, I agree with you that the nvidia driver packages have to work correctly as that is a non-starter for me as well). However, I am confident that pkgng and the new packages model is aiming at the right target based on my own interactions with Erwin, Baptiste, and others, and I think we need to push this forward and gain wider testing to make progress, even if there are bumps in the road. > > In terms of the first feature (binary upgrades), the truth is that if you have > > more than 5 machines to manage, our current pkg tools completely suck. There > > is no automated upgrade mechanism. If you want one you have to write your own > > set of infrastructure to do the right collection of pkg_delete/pkg_adds. > > Certainly there is no support in the current package tools for doing batch > > upgrades (i.e. upgrading from one completely package set to another). pkgng > > adds that feature, and I find it a must for supporting large installations of > > machines that need automated management. > > And as I wrote previously, I've been there and done that, so yes, I'm > interested in the feature. But I'd like to know more about the plans for > it so that those of us who *do* have experience in this topic can share > that, and we can avoid having to reinvent the wheel. Or worse, putting > out something half-assed that uses up a lot of developer cycles and > doesn't get the job done. Well, what I can tell you is that many of us who do have experience with that model have been discussing this in various fora, initially in e-mails, IRC discussions, informal discussions during the "hallway track" at conferences, etc. To build a broader consensus, portmgr@ has been holding larger, more formal discussions in the form of devsummit working groups, presentations at conferences, etc. I personally have been petitioning anyone's ear I could bend for package sets for example. I realize, btw, that not all of those discussions have occurred on public mailing lists. The fact is, there is a tradeoff between informal communication (such as in-person commucation) and mails to a mailing list. In-person communication especially offers far higher bandwidth and can be far more effective for reaching consensus and working through alternatives, but it has a more limited audience. Being a volunteer project distributed all over the globe, we are somewhat stuck with that tradeoff. We attempt to mitigate that tradeoff somewhat by making more of these informal discussions more formal (e.g. adding working groups at the devsummit which include wiki pages with summaries of the agenda and slide decks used to present the wg summary to the full complement of attendees so there is at least some information availble for folks who were not able to attend). However, it does mean that just because you were not personally involved in a discussion or did not see a long and tedious thread, you should not assume that no discussion has taken place at all. Back to my original e-mail: FreeBSD is a big project. I try to keep a pulse on as much of it as I can (mostly by reading/skimming a _lot_ of e-mail each day), but even with all that there is a lot going on that I don't know the intimate details of. Instead, I choose to trust my fellow developers to best manage the areas over which they have expertise and detailed knowledge until given strong evidence to assume otherwise. My humble suggestion to you would be to adopt a similar strategy. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:36:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E41F1065670 for ; Fri, 13 Jul 2012 16:36:16 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 479D18FC14 for ; Fri, 13 Jul 2012 16:36:15 +0000 (UTC) Received: by obbun3 with SMTP id un3so6306793obb.13 for ; Fri, 13 Jul 2012 09:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q2TFexp7bufOmIhE0OoN1zni6Da1jhjVq4BCSvL9yTk=; b=fA2JZWAG7IM7H3VdijRg9C58+yBkU59sbGHT7t/7xWhparJ4Cuei6ysg5wefr7sLQu zrS79O1s8mXk/aMm4Ir4lWatkSzQAPbWy9Xj5bp7NuWD5Vmyu0LcwUX3cz66K5XCZ+vq 3VONo7Pd/kVCRAFnbWQRjEww3sM0vXspMBzes= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=q2TFexp7bufOmIhE0OoN1zni6Da1jhjVq4BCSvL9yTk=; b=EITR/VjqhB0r9cx+io5X6pFlCeC4MYFIKCtSr1XsXFxq0XfrkDB8d2eJcfYbNNTwdn pFgF/Pxy8fsg0hJPPmThy9turn5pm6gwZtVUEo230X11NbagwR5LfiF7uNfusE95R8P7 Wwxxiw44/exvTXx54F7tXbbmWnOdBDjjdxM6He8HBE71N81N2KNuj9m963MCaSzYroDC qYjCovO/EfBqi7DhqzviEt2jR1I+lmGOOOz0iVwWe2Uc1JHPHsXeyFvM/bKm+LZy/Jji PMS7Xm+Ck8aZwRcVkjp+wXd4o7qy+9R7a6Bs5gYIR93v4UdhTPB0f6QHHEka+wg2gDr7 HdGg== Received: by 10.182.31.102 with SMTP id z6mr2510545obh.66.1342197374809; Fri, 13 Jul 2012 09:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.125.70 with HTTP; Fri, 13 Jul 2012 09:35:44 -0700 (PDT) In-Reply-To: <500047DB.60607@missouri.edu> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> <500047DB.60607@missouri.edu> From: Eitan Adler Date: Fri, 13 Jul 2012 09:35:44 -0700 Message-ID: To: Stephen Montgomery-Smith Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnXqLRifLcbU3vBFONBn3xFlN6pNrsmPMnFm/BUOLa9N5NystJDh2WhHOlVw7JkrW+TEazp Cc: Diane Bruce , David Chisnall , freebsd-current@freebsd.org, Steve Kargl , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:36:16 -0000 On 13 July 2012 09:07, Stephen Montgomery-Smith wrote: > On 07/13/12 10:58, David Schultz wrote: >> >> On Fri, Jul 13, 2012, David Chisnall wrote: >>> >>> As do I. I'd also point out that the ONLY requirement for long >>> double according to the standard is that it has at least the same >>> precision as double. Therefore, any implementation of these >>> functions that is no worse that the double version is compliant. >>> Once we have something meeting a minimum standard, then I'm very >>> happy to see it improved, but having C99 functions missing now is >>> just embarrassing while we're working on adding C11 features. >> >> >> There are several things wrong with this reasoning, but pragmatically >> the conclusion may be right: we do have a long list of users who would >> prefer a dubious implementation to none at all. >> >> I propose we set a timeframe for this, on the order of a few months. >> A rough outline might be something like: >> >> mid-August: expl logl log2l log10l >> -- just need to clean up Bruce and Steve's work; Steve recently >> sent me patches for expl, which I hope get committed soon >> mid-September: acoshl asinhl atanhl coshl sinhl tanhl >> -- easy once expl is in; others could probably help >> mid-October: powl expm1l >> mid-November: most complex.h functions >> >> If the schedule can't be met, then we can just import Cephes as an >> interim solution without further ado. This provides Bruce and Steve >> an opportunity to commit what they have been working on, without >> forcing the rest of the FreeBSD community to wait indefinitely for >> the pie in the sky. +1 If we do import Cephes the questionable functions should probably be explicitly marked somewhere so that if there is still $someone can still work on them though. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 16:40:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BEB1065980 for ; Fri, 13 Jul 2012 16:40:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A02638FC0C for ; Fri, 13 Jul 2012 16:40:25 +0000 (UTC) Received: by obbun3 with SMTP id un3so6313064obb.13 for ; Fri, 13 Jul 2012 09:40:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=c+yzg9V4eQeb8lE8hWYXEaB8Nf6CY+mqD5RN621xJYo=; b=Pjf2XVvpu8JNwzq6BmmJcYQeh8YnI/o5ccA5Wu9apLYAMEvULmndnV756hX5zf2+/W pUhhmr/OFeM+6OPn2jDvNqFm96yHMisWyi/QepmhjfrKnqTkOLQjuLgBSISR0ZsngOFP Cw3dkf3PPTlgfhgX9VFzPmDqR7Gc5cbrE0TCuAFREBMjLuLEe7d9Q/Gv+/L84mBnUihu sX5ssesThUIesg7SjpSd6J9B2QQdi22c6tl9xmdj8VbVoziYXo8SEhGZwnkxU/DpCFjr x1MTCfMxzL1CEKLAClea4yhxb2Td9HTQR/Ai9IIM9D6ab/7hNZqaDtiPMN4P07arBgyX 7r/Q== Received: by 10.182.169.40 with SMTP id ab8mr2634170obc.34.1342197625191; Fri, 13 Jul 2012 09:40:25 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id e9sm4984466oee.12.2012.07.13.09.40.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2012 09:40:24 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120711005506.GA88249@server.rulingia.com> Date: Fri, 13 Jul 2012 10:40:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <777FA576-7DBA-43B1-817A-0BB7CCF232E9@bsdimp.com> References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <20120711005506.GA88249@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnLEyeI3DteasiUHoopPuE/vLFcQ3htzi2am4qHMdh0CJ/Mjz73IvTST14FsDt33F67bZp8 Cc: freebsd-current@FreeBSD.ORG Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 16:40:26 -0000 Just to jump back into the fray a bit, since this point hasn't been = articulated well. On Jul 10, 2012, at 6:55 PM, Peter Jeremy wrote: > On 2012-Jul-08 19:01:07 -0700, Steve Kargl = wrote: >> Well, on the most popular hardware (that being i386/amd64), >> ld80 will use hardware fp instruction while ld128 must be >> done completely in software. The speed difference is >> significant. >=20 > AFAIK, of the architectures that FreeBSD supports, only sparc64 > defines ld128 in the architecture and I don't believe there are any > SPARC chip implementations that implement ld128 math in hardware. We shouldn't be gating the new math on an issue that only affects = sparc64 machines. If they have ld80 level of support for that = architecture, then that is sufficient to get things into the tree. = There's no real benefit from making numerics good on sparc64 for the = project, since our support for the platform isn't stellar and the = platform itself is getting a bit long in the tooth. That said, if people want to do it, be my guest. If it is important = enough to catch someone's attention, then it is important enough to = have. It just isn't important enough to be a gating factor if nobody = has signed up for it yet. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 17:09:18 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B530106564A; Fri, 13 Jul 2012 17:09:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F11FA8FC16; Fri, 13 Jul 2012 17:09:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 22B6DB944; Fri, 13 Jul 2012 13:09:17 -0400 (EDT) From: John Baldwin To: David Schultz Date: Fri, 13 Jul 2012 13:07:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120529045612.GB4445@server.rulingia.com> <20120713155805.GC81965@zim.MIT.EDU> In-Reply-To: <20120713155805.GC81965@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207131307.59537.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 13:09:17 -0400 (EDT) Cc: Diane Bruce , David Chisnall , freebsd-current@freebsd.org, Steve Kargl , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 17:09:18 -0000 On Friday, July 13, 2012 11:58:05 am David Schultz wrote: > On Fri, Jul 13, 2012, David Chisnall wrote: > > As do I. I'd also point out that the ONLY requirement for long > > double according to the standard is that it has at least the same > > precision as double. Therefore, any implementation of these > > functions that is no worse that the double version is compliant. > > Once we have something meeting a minimum standard, then I'm very > > happy to see it improved, but having C99 functions missing now is > > just embarrassing while we're working on adding C11 features. > > There are several things wrong with this reasoning, but pragmatically > the conclusion may be right: we do have a long list of users who would > prefer a dubious implementation to none at all. > > I propose we set a timeframe for this, on the order of a few months. > A rough outline might be something like: > > mid-August: expl logl log2l log10l > -- just need to clean up Bruce and Steve's work; Steve recently > sent me patches for expl, which I hope get committed soon > mid-September: acoshl asinhl atanhl coshl sinhl tanhl > -- easy once expl is in; others could probably help > mid-October: powl expm1l > mid-November: most complex.h functions > > If the schedule can't be met, then we can just import Cephes as an > interim solution without further ado. This provides Bruce and Steve > an opportunity to commit what they have been working on, without > forcing the rest of the FreeBSD community to wait indefinitely for > the pie in the sky. > > By the way, the trig and complex functions are areas where anyone with > some calculus background could contribute. If anyone is interested in > helping out, I'd be happy to coordinate things and review patches, > although I will be unavailable for much of August. I think this sounds like an excellent plan, thanks! -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 17:30:43 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D85191065674 for ; Fri, 13 Jul 2012 17:30:43 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 610A38FC18 for ; Fri, 13 Jul 2012 17:30:42 +0000 (UTC) Received: (qmail 23779 invoked by uid 399); 13 Jul 2012 17:30:33 -0000 Received: from unknown (HELO ?172.17.194.139?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 13 Jul 2012 17:30:33 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <50005B3D.80505@dougbarton.us> Date: Fri, 13 Jul 2012 10:30:37 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jung-uk Kim References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> <4FFFF078.6050109@dougbarton.us> <5000444C.6030000@FreeBSD.org> In-Reply-To: <5000444C.6030000@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 13 Jul 2012 17:34:53 +0000 Cc: Ben Laurie , freebsd-security@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 17:30:44 -0000 On 07/13/2012 08:52 AM, Jung-uk Kim wrote: > On 2012-07-13 05:55:04 -0400, Doug Barton wrote: >> On 07/12/2012 05:03 PM, Jung-uk Kim wrote: >>> FYI, OpenSSL 1.0.1c import is complete now. Please let me know >>> if you have any problem. > >> Sorry if I missed it, but did you bump OSVERSION for this change? >> If not, could you? It would be helpful for dealing with ports >> stuff, especially USE_OPENSSL. > > Yes, it was bumped with the commit. Thanks, and again, sorry I missed it. From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 17:55:55 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C54091065674 for ; Fri, 13 Jul 2012 17:55:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6068FC08 for ; Fri, 13 Jul 2012 17:55:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0748B926; Fri, 13 Jul 2012 13:55:54 -0400 (EDT) From: John Baldwin To: Scott Long Date: Fri, 13 Jul 2012 13:55:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201207121040.27116.jhb@freebsd.org> <1342111033.198.YahooMailNeo@web45716.mail.sp1.yahoo.com> <201207121351.20951.jhb@freebsd.org> In-Reply-To: <201207121351.20951.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207131355.54432.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 13:55:55 -0400 (EDT) Cc: Peter Jeremy , "current@freebsd.org" Subject: Re: Adding support for WC (write-combining) memory to bus_dma X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 17:55:55 -0000 On Thursday, July 12, 2012 1:51:20 pm John Baldwin wrote: > On Thursday, July 12, 2012 12:37:13 pm Scott Long wrote: > > Yup, this is a problem, and I like your fix; this kind of state is exactly what > > belongs in the map. > > Why don't I break out the fix first as a separate patch. Here is a patch to just fix this. I also mirrored the changes into powerpc since it had copied the same code from x86 (albeit disabled). If you feel the malloc stats via M_DEVBUF are important, I can restore those (probably by adding a contigmalloc_attr() wrapper). Index: powerpc/powerpc/busdma_machdep.c =================================================================== --- powerpc/powerpc/busdma_machdep.c (revision 238365) +++ powerpc/powerpc/busdma_machdep.c (working copy) @@ -46,6 +46,8 @@ #include #include +#include +#include #include #include @@ -130,6 +132,7 @@ bus_dmamap_callback_t *callback; void *callback_arg; STAILQ_ENTRY(bus_dmamap) links; + int contigalloc; }; static STAILQ_HEAD(, bus_dmamap) bounce_map_waitinglist; @@ -489,6 +492,7 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags, bus_dmamap_t *mapp) { + vm_memattr_t attr; int mflags; if (flags & BUS_DMA_NOWAIT) @@ -500,6 +504,12 @@ if (flags & BUS_DMA_ZERO) mflags |= M_ZERO; +#ifdef NOTYET + if (flags & BUS_DMA_NOCACHE) + attr = VM_MEMATTR_UNCACHEABLE; + else +#endif + attr = VM_MEMATTR_DEFAULT; /* * XXX: @@ -511,7 +521,8 @@ */ if ((dmat->maxsize <= PAGE_SIZE) && (dmat->alignment < dmat->maxsize) && - dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) { + dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem) && + attr == VM_MEMATTR_DEFAULT) { *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); } else { /* @@ -520,9 +531,10 @@ * multi-seg allocations yet though. * XXX Certain AGP hardware does. */ - *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags, - 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul, - dmat->boundary); + *vaddr = (void *)kmem_alloc_contig(kernel_map, dmat->maxsize, + mflags, 0ul, dmat->lowaddr, dmat->alignment ? + dmat->alignment : 1ul, dmat->boundary, attr); + (*mapp)->contigalloc = 1; } if (*vaddr == NULL) { CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", @@ -531,11 +543,6 @@ } else if (vtophys(*vaddr) & (dmat->alignment - 1)) { printf("bus_dmamem_alloc failed to align memory properly.\n"); } -#ifdef NOTYET - if (flags & BUS_DMA_NOCACHE) - pmap_change_attr((vm_offset_t)*vaddr, dmat->maxsize, - VM_MEMATTR_UNCACHEABLE); -#endif CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", __func__, dmat, dmat->flags, 0); return (0); @@ -548,18 +555,12 @@ void bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map) { - bus_dmamap_destroy(dmat, map); -#ifdef NOTYET - pmap_change_attr((vm_offset_t)vaddr, dmat->maxsize, VM_MEMATTR_DEFAULT); -#endif - if ((dmat->maxsize <= PAGE_SIZE) && - (dmat->alignment < dmat->maxsize) && - dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) + if (!map->contigalloc) free(vaddr, M_DEVBUF); - else { - contigfree(vaddr, dmat->maxsize, M_DEVBUF); - } + else + kmem_free(kernel_map, (vm_offset_t)vaddr, dmat->maxsize); + bus_dmamap_destroy(dmat, map); CTR3(KTR_BUSDMA, "%s: tag %p flags 0x%x", __func__, dmat, dmat->flags); } Index: x86/x86/busdma_machdep.c =================================================================== --- x86/x86/busdma_machdep.c (revision 238365) +++ x86/x86/busdma_machdep.c (working copy) @@ -42,6 +42,8 @@ #include #include +#include +#include #include #include @@ -131,7 +133,7 @@ static STAILQ_HEAD(, bus_dmamap) bounce_map_waitinglist; static STAILQ_HEAD(, bus_dmamap) bounce_map_callbacklist; -static struct bus_dmamap nobounce_dmamap; +static struct bus_dmamap nobounce_dmamap, contig_dmamap; static void init_bounce_pages(void *dummy); static int alloc_bounce_zone(bus_dma_tag_t dmat); @@ -465,7 +467,7 @@ int bus_dmamap_destroy(bus_dma_tag_t dmat, bus_dmamap_t map) { - if (map != NULL && map != &nobounce_dmamap) { + if (map != NULL && map != &nobounce_dmamap && map != &contig_dmamap) { if (STAILQ_FIRST(&map->bpages) != NULL) { CTR3(KTR_BUSDMA, "%s: tag %p error %d", __func__, dmat, EBUSY); @@ -490,6 +492,7 @@ bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags, bus_dmamap_t *mapp) { + vm_memattr_t attr; int mflags; if (flags & BUS_DMA_NOWAIT) @@ -512,6 +515,10 @@ } if (flags & BUS_DMA_ZERO) mflags |= M_ZERO; + if (flags & BUS_DMA_NOCACHE) + attr = VM_MEMATTR_UNCACHEABLE; + else + attr = VM_MEMATTR_DEFAULT; /* * XXX: @@ -523,7 +530,8 @@ */ if ((dmat->maxsize <= PAGE_SIZE) && (dmat->alignment < dmat->maxsize) && - dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) { + dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem) && + attr == VM_MEMATTR_DEFAULT) { *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); } else { /* @@ -532,9 +540,10 @@ * multi-seg allocations yet though. * XXX Certain AGP hardware does. */ - *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags, - 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul, - dmat->boundary); + *vaddr = (void *)kmem_alloc_contig(kernel_map, dmat->maxsize, + mflags, 0ul, dmat->lowaddr, dmat->alignment ? + dmat->alignment : 1ul, dmat->boundary, attr); + *mapp = &contig_dmamap; } if (*vaddr == NULL) { CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", @@ -543,9 +552,6 @@ } else if (vtophys(*vaddr) & (dmat->alignment - 1)) { printf("bus_dmamem_alloc failed to align memory properly.\n"); } - if (flags & BUS_DMA_NOCACHE) - pmap_change_attr((vm_offset_t)*vaddr, dmat->maxsize, - PAT_UNCACHEABLE); CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", __func__, dmat, dmat->flags, 0); return (0); @@ -560,18 +566,15 @@ { /* * dmamem does not need to be bounced, so the map should be - * NULL + * NULL if malloc() was used and contig_dmamap if + * contigmalloc() was used. */ - if (map != NULL) + if (!(map == NULL || map == &contig_dmamap)) panic("bus_dmamem_free: Invalid map freed\n"); - pmap_change_attr((vm_offset_t)vaddr, dmat->maxsize, PAT_WRITE_BACK); - if ((dmat->maxsize <= PAGE_SIZE) && - (dmat->alignment < dmat->maxsize) && - dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) + if (map == NULL) free(vaddr, M_DEVBUF); - else { - contigfree(vaddr, dmat->maxsize, M_DEVBUF); - } + else + kmem_free(kernel_map, (vm_offset_t)vaddr, dmat->maxsize); CTR3(KTR_BUSDMA, "%s: tag %p flags 0x%x", __func__, dmat, dmat->flags); } @@ -662,7 +665,7 @@ vm_offset_t vaddr; int seg, error; - if (map == NULL) + if (map == NULL || map == &contig_dmamap) map = &nobounce_dmamap; if ((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) { @@ -1139,7 +1142,7 @@ struct bounce_page *bpage; KASSERT(dmat->bounce_zone != NULL, ("no bounce zone in dma tag")); - KASSERT(map != NULL && map != &nobounce_dmamap, + KASSERT(map != NULL && map != &nobounce_dmamap && map != &contig_dmamap, ("add_bounce_page: bad map %p", map)); bz = dmat->bounce_zone; -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 17:56:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B48651065673; Fri, 13 Jul 2012 17:56:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19B6F8FC14; Fri, 13 Jul 2012 17:56:58 +0000 (UTC) Received: by weyx56 with SMTP id x56so3552896wey.13 for ; Fri, 13 Jul 2012 10:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ni6wES3hVOMhStcZoBcASbqzS5yXiXojkyav9c/BjY=; b=Gym12y7kMzTE6ihNNtGei0GwVJIs5U8ebe1IJ9FGYfb+De9FgJR/BGVwKveD34q2OC xshl0SfRuLwonxFr8PlNagrp3xXk/QM5lJlv2XxC0PWk95508BhqMnCQyUJNIiAoUYiy MaLd2dbPg1ejfDCuqXpvAAiQ5BvGebNiSNSl1gsxL1oXTHvy08bwDajGlodor8Wpn0Vk vRGGj7HCL3oiRBE5hfQfYNvTgfKLL0zdTVT1rIoFAYjh95B0KnsjGgybIwBMk9I0I5Yk KF2wCcwILbO6M4qtNpzej0rkYEJTh9R2BibhEMBGErbk7kxU+t+cinhFfAGQE1Y+5oMb p5Dw== MIME-Version: 1.0 Received: by 10.180.102.136 with SMTP id fo8mr4440898wib.19.1342202218019; Fri, 13 Jul 2012 10:56:58 -0700 (PDT) Received: by 10.216.23.200 with HTTP; Fri, 13 Jul 2012 10:56:57 -0700 (PDT) In-Reply-To: <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> References: <31A0DCE7-3B93-41BC-805A-E0B163892112@bsdimp.com> <5C18109D-E7A8-4868-BEA9-26B63360BB24@bsdimp.com> <8048FFC5-6952-49FC-849D-EA1A5675ACBE@bsdimp.com> <73F3FBC9-337C-4F61-9470-5173D6DAE56B@bsdimp.com> Date: Fri, 13 Jul 2012 13:56:57 -0400 Message-ID: From: Arnaud Lacombe To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: newbus' ivar's limitation.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 17:56:59 -0000 Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh wrote: > [..] > Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. > I will just pass function pointers for now, if things should be done dirty, let's be explicit about it. Now, the hinted device attachment did work quite smoothly, however, I would have a few suggestion: 1) add a call to bus_enumerate_hinted_children() before the call DEVICE_IDENTIFY() call in bus_generic_driver_added() this is required to be able to support dynamic loading and attachment of hinted children. 2) have a generic bus_hinted_child method which would just add a new child to the bus. 3) have bus_enumerate_hinted_children() and bus_generic_attach() always ran on device attachment. There is current +100 explicit call to bus_generic_attach() in the sys/dev/ tree. This should be done always and implicitly. 4) have bus_generic_detach() always ran prior to device detachment If not already the case. There is still the same +100 direct call to bus_generic_detach is the tree. 5) have the bus_generic_* method be the default of their respective method 6) have device_delete_child() called upon device detachment. As a rule of thumb, when a kld is unloaded there should not be any remains of anything built previously. Without device_delete_child() or proper singleton implementation, multiple load/unload sequence of bus will attempt to attach multiple version of a child, even if the single child was added prior to the bus_generic_attach() call. Also, as a rule of thumb, if the same logic is implemented in more than a few buses, it should be made generic and implicit. I am lazy, I hate doing the same things over and over, not to say it raised the likelihood of bugs' introduction... - Arnaud From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 18:39:32 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B8F21065670; Fri, 13 Jul 2012 18:39:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA68D8FC12; Fri, 13 Jul 2012 18:39:31 +0000 (UTC) Message-ID: <50006B63.4020901@FreeBSD.org> Date: Fri, 13 Jul 2012 14:39:31 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> <20120713080014.GN2338@deviant.kiev.zoral.com.ua> In-Reply-To: <20120713080014.GN2338@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , freebsd-security@freebsd.org, freebsd-current@freebsd.org Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 18:39:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-13 04:00:14 -0400, Konstantin Belousov wrote: > How did the asm files were generated (I am sure they are generated) > ? Yes, they are all re-generated. Mostly, it is described in FREEBSD-upgrade file: http://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/FREEBSD-upgrade?view=markup&pathrev=238384 Basically, it goes something like this: cd ${SRCDIR}/secure/lib/libcrypto make -f Makefile.asm all mv *.[Ss] ${MACHINE_CPUARCH} make -f Makefile.asm clean Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAa2MACgkQmlay1b9qnVMBtACgoxxI+jmAmhcpLnbozW3y2LNd /bUAnjeZ8f9K2ccwTDgicwLBLYUw+Mlp =Gy0L -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 19:33:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 335721065674; Fri, 13 Jul 2012 19:33:28 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8488FC14; Fri, 13 Jul 2012 19:33:27 +0000 (UTC) Received: from WildRover.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA05515; Fri, 13 Jul 2012 13:03:43 -0600 (MDT) Message-Id: <201207131903.NAA05515@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Jul 2012 13:03:39 -0600 To: Jung-uk Kim , freebsd-current@freebsd.org From: Brett Glass In-Reply-To: <4FFF65BD.4060707@FreeBSD.org> References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 13 Jul 2012 19:39:30 +0000 Cc: Ben Laurie , freebsd-security@freebsd.org, dougb@dougbarton.us Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 19:33:28 -0000 Will port also be MFCed to 9-RELENG and 9.1-RELEASE? Do not want to have to go to -CURRENT to get latest OpenSSL. --Brett Glass From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:01:17 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 745F3106566C; Fri, 13 Jul 2012 20:01:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C141E8FC17; Fri, 13 Jul 2012 20:01:16 +0000 (UTC) Message-ID: <50007E8C.2000207@FreeBSD.org> Date: Fri, 13 Jul 2012 16:01:16 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120626 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brett Glass References: <4FFF11CA.60004@FreeBSD.org> <4FFF65BD.4060707@FreeBSD.org> <201207131903.NAA05515@lariat.net> In-Reply-To: <201207131903.NAA05515@lariat.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , freebsd-security@freebsd.org, freebsd-current@freebsd.org, dougb@dougbarton.us Subject: Re: [HEADSUP] OpenSSL 1.0.1c merge in progress X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 20:01:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-07-13 15:03:39 -0400, Brett Glass wrote: > Will port also be MFCed to 9-RELENG and 9.1-RELEASE? Do not want > to have to go to -CURRENT to get latest OpenSSL. Sorry, we have no plan to MFC this to stable branches because of API and feature changes. However, you may need OpenSSL from ports tree, which has the same version ATM. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAfowACgkQmlay1b9qnVO6FQCePL/lmITYUw5xmI4weIX+NOtE ASYAoJBeDaIxmj2wG4j7keczkhU62WAS =Ed5I -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 20:41:32 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0B8D106566B for ; Fri, 13 Jul 2012 20:41:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9F28FC16 for ; Fri, 13 Jul 2012 20:41:31 +0000 (UTC) Received: by obbun3 with SMTP id un3so6648515obb.13 for ; Fri, 13 Jul 2012 13:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AEZAQ+/uILb+xjEDzi/og7DYZAM3nPhTGxx/WbEVrK0=; b=ZVKYbR6hUFGwZth+0+m4zjewooHj6AhflWCWwbQIblqJnDw1d6bH+Ir8EpX2PVjscK cixheGHLxi9B9V853pmAbs8GJ+fvtyhFXrn/rc2j38zo75uUVF/zPOqqGo2Jqxwylygj lWRfNlO9235HIYVc5iJHfh9iK30Cq+4QY6PTA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=AEZAQ+/uILb+xjEDzi/og7DYZAM3nPhTGxx/WbEVrK0=; b=GU6HgdMzihKPslVCEDYQ96YstRdQn+QJ2W8/T/51O6UQ/Np6FUpIi1UdtFrJ7MVsP4 Y2CVCLfobhZj9RhS6CG9w2cSxpfUE43siVqjvQ9acIIiRy1PeAImUQvZXFzpWAf1S3su Am/yHoGRvO9fFitAQV+ylkSsgwBIfLypmOPal8zuYSoZC0HQxwCmhZwICPZlpavOXcmn ZoTwROTo/QLzNsShOktsw/zH9nRW15I7Xm2Ae69BmY8mTM+OjdP5/kfjz3AyAdodZKqY KR9jNdgOacxJVhAZPkAIjYJ6gGV8RCruB2Lp0uU19nGJeJbi/S+gj/cMCcLsc0s4Suzd 3GRg== MIME-Version: 1.0 Received: by 10.60.2.99 with SMTP id 3mr3622060oet.20.1342212091150; Fri, 13 Jul 2012 13:41:31 -0700 (PDT) Received: by 10.182.97.164 with HTTP; Fri, 13 Jul 2012 13:41:31 -0700 (PDT) In-Reply-To: <5000113D.2000004@a1poweruser.com> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> <4FFFD944.1030005@ranner.eu> <5000113D.2000004@a1poweruser.com> Date: Fri, 13 Jul 2012 13:41:31 -0700 Message-ID: From: Peter Wemm To: Fbsd8 Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmyTWeT5MXn1dPepffQoNi9RQsx8T7AdrZsadK5Gwt+d+vGZl+l4ILPqh3kAvo+OWvrm5y3 Cc: ports@freebsd.org, current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 20:41:32 -0000 On Fri, Jul 13, 2012 at 5:14 AM, Fbsd8 wrote: > What I want to know is this new pkg system going to remove the requirement > of having the complete ports tree on my system? > > What I am looking for in an port system, is to install a port and any files > needed for the parent port and its dependents to automatically be > downloaded. So in the end my system ports tree only contain the files used > to install the ports I use and their dependents. That is precisely what pkgng is for. At the risk of over-simplifying: * Generally eliminate the need for having /usr/ports installed for end user consumers of freebsd if you have no desire to compile ports with custom options. * Generally eliminate the need for layers over the top of pkg* like portupgrade/portmaster/portmanager for those people. * Play nicely with people who *are* building some (or all) of their packages from /usr/ports. * Provide enough look and feel compatibility with the old pkg_* tools so people will feel enough at home. * Assimilate an existing pkg_* machine. * Store complete metadata so that going foward we have much better support for package sets - eg: package repositories with custom options that play nicely with official packages. * Be extensible so that we can add to it as we go forward. In the new world order, things like portupgrade and portmanager tend to be used to manage interactions between personally build ports from /usr/ports and external binary packages. If you continue to build from /usr/ports, the only thing that changes is bsd.port.mk uses a different command to register a package and you still use portupgrade/portmaster/whatever to orchestrate your personal package rebuilding. (Well, portmaster does if you apply the simple patch to it). pkg-1.0 is primarily an infrastructure change. Instead of metadata being stored in discrete +FOO and +BAR files in a .tgz file, it is stored in a structured, extensible file. Instead of an incomplete set of metadata being stored in /var/db/pkg/* and having to be augmented by reaching over to /usr/ports/*, a full set of data is stored in a .sqlite file. Instead of version numbers being baked into the package name as an ascii string, the package system uses version numbers as first class metadata. In reality, not much will change at the switch throwing, except that of having good reason to be afraid of "pkg_add -r", you'll be able to reasonably expect it's replacement (pkg install) to work. And a bunch of people who have a /usr/ports tree will suddenly wonder why they even have it there at all. It becomes incredibly convenient and fast to use packages. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:14:26 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7B8106566C; Fri, 13 Jul 2012 22:14:26 +0000 (UTC) (envelope-from gibbs@FreeBSD.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 459148FC0A; Fri, 13 Jul 2012 22:14:26 +0000 (UTC) Received: from [192.168.6.131] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q6DMEPYC051819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jul 2012 16:14:25 -0600 (MDT) (envelope-from gibbs@FreeBSD.org) From: "Justin T. Gibbs" Content-Type: multipart/mixed; boundary="Apple-Mail=_410A4854-04E8-4B9A-B54B-38F6603F628C" Date: Fri, 13 Jul 2012 16:14:17 -0600 Message-Id: To: current@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [70.89.174.89]); Fri, 13 Jul 2012 16:14:25 -0600 (MDT) Cc: des@FreeBSD.org Subject: PAM passwdqc, strict aliasing, and WARNS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 22:14:26 -0000 --Apple-Mail=_410A4854-04E8-4B9A-B54B-38F6603F628C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the "logically const" issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? Thanks, Justin --Apple-Mail=_410A4854-04E8-4B9A-B54B-38F6603F628C Content-Disposition: attachment; filename=pam_passwdqc.diff Content-Type: application/octet-stream; name="pam_passwdqc.diff" Content-Transfer-Encoding: 7bit Change 575701 by justing@justing_ns1_spectrabsd on 2012/07/13 15:57:57 Make the PAM password strength checking module WARNS=2 safe. lib/libpam/modules/pam_passwdqc/Makefile: Bump WARNS to 2. contrib/pam_modules/pam_passwdqc/pam_passwdqc.c: Bump _XOPEN_SOURCE and _XOPEN_VERSION from 500 to 600 so that vsnprint() is declared. Use the two new union types (pam_conv_item_t and pam_text_item_t) to resolve strict aliasing violations caused by casts to comply with the pam_get_item() API taking a "const void **" for all item types. Correct a CLANG "printf-like function with more arguments than format" warning. Affected files ... ... //SpectraBSD/stable/contrib/pam_modules/pam_passwdqc/pam_passwdqc.c#2 edit ... //SpectraBSD/stable/lib/libpam/modules/pam_passwdqc/Makefile#2 edit Differences ... ==== //SpectraBSD/stable/contrib/pam_modules/pam_passwdqc/pam_passwdqc.c#2 (text) ==== @@ -2,9 +2,9 @@ * Copyright (c) 2000-2002 by Solar Designer. See LICENSE. */ -#define _XOPEN_SOURCE 500 +#define _XOPEN_SOURCE 600 #define _XOPEN_SOURCE_EXTENDED -#define _XOPEN_VERSION 500 +#define _XOPEN_VERSION 600 #include #include #include @@ -38,7 +38,16 @@ #else #define lo_const const #endif -typedef lo_const void *pam_item_t; + +typedef union { + struct pam_conv *conv; + lo_const void *item; +} pam_conv_item_t; + +typedef union { + char *text; + lo_const void *item; +} pam_text_item_t; #include "passwdqc.h" @@ -132,21 +141,21 @@ static int converse(pam_handle_t *pamh, int style, lo_const char *text, struct pam_response **resp) { - struct pam_conv *conv; + pam_conv_item_t conv; struct pam_message msg, *pmsg; int status; - status = pam_get_item(pamh, PAM_CONV, (pam_item_t *)&conv); + status = pam_get_item(pamh, PAM_CONV, &conv.item); if (status != PAM_SUCCESS) return status; pmsg = &msg; msg.msg_style = style; - msg.msg = text; + msg.msg = (char *)text; *resp = NULL; - return conv->conv(1, (lo_const struct pam_message **)&pmsg, resp, - conv->appdata_ptr); + return conv.conv->conv(1, (lo_const struct pam_message **)&pmsg, resp, + conv.conv->appdata_ptr); } #ifdef __GNUC__ @@ -294,8 +303,11 @@ } if (argc) { - say(pamh, PAM_ERROR_MSG, getuid() != 0 ? - MESSAGE_MISCONFIGURED : MESSAGE_INVALID_OPTION, *argv); + if (getuid() != 0) { + say(pamh, PAM_ERROR_MSG, MESSAGE_MISCONFIGURED); + } else { + say(pamh, PAM_ERROR_MSG, MESSAGE_INVALID_OPTION, *argv); + } return PAM_ABORT; } @@ -311,7 +323,7 @@ #ifdef HAVE_SHADOW struct spwd *spw; #endif - char *user, *oldpass, *newpass, *randompass; + pam_text_item_t user, oldpass, newpass, randompass; const char *reason; int ask_oldauthtok; int randomonly, enforce, retries_left, retry_wanted; @@ -353,34 +365,34 @@ if (flags & PAM_PRELIM_CHECK) return status; - status = pam_get_item(pamh, PAM_USER, (pam_item_t *)&user); + status = pam_get_item(pamh, PAM_USER, &user.item); if (status != PAM_SUCCESS) return status; - status = pam_get_item(pamh, PAM_OLDAUTHTOK, (pam_item_t *)&oldpass); + status = pam_get_item(pamh, PAM_OLDAUTHTOK, &oldpass.item); if (status != PAM_SUCCESS) return status; if (params.flags & F_NON_UNIX) { pw = &fake_pw; - pw->pw_name = user; + pw->pw_name = user.text; pw->pw_gecos = ""; } else { - pw = getpwnam(user); + pw = getpwnam(user.text); endpwent(); if (!pw) return PAM_USER_UNKNOWN; if ((params.flags & F_CHECK_OLDAUTHTOK) && getuid() != 0) { - if (!oldpass) + if (!oldpass.text) status = PAM_AUTH_ERR; else #ifdef HAVE_SHADOW if (!strcmp(pw->pw_passwd, "x")) { - spw = getspnam(user); + spw = getspnam(user.text); endspent(); if (spw) { - if (strcmp(crypt(oldpass, spw->sp_pwdp), - spw->sp_pwdp)) + if (strcmp(crypt(oldpass.text, + spw->sp_pwdp), spw->sp_pwdp)) status = PAM_AUTH_ERR; memset(spw->sp_pwdp, 0, strlen(spw->sp_pwdp)); @@ -388,7 +400,7 @@ status = PAM_AUTH_ERR; } else #endif - if (strcmp(crypt(oldpass, pw->pw_passwd), + if (strcmp(crypt(oldpass.text, pw->pw_passwd), pw->pw_passwd)) status = PAM_AUTH_ERR; } @@ -405,13 +417,14 @@ enforce = params.flags & F_ENFORCE_ROOT; if (params.flags & F_USE_AUTHTOK) { - status = pam_get_item(pamh, PAM_AUTHTOK, - (pam_item_t *)&newpass); + status = pam_get_item(pamh, PAM_AUTHTOK, &newpass.item); if (status != PAM_SUCCESS) return status; - if (!newpass || (check_max(¶ms, pamh, newpass) && enforce)) + if (!newpass.text || + (check_max(¶ms, pamh, newpass.text) && enforce)) return PAM_AUTHTOK_ERR; - reason = _passwdqc_check(¶ms.qc, newpass, oldpass, pw); + reason = _passwdqc_check(¶ms.qc, newpass.text, + oldpass.text, pw); if (reason) { say(pamh, PAM_ERROR_MSG, MESSAGE_WEAKPASS, reason); if (enforce) @@ -457,13 +470,13 @@ return status; } - randompass = _passwdqc_random(¶ms.qc); - if (randompass) { + randompass.text = _passwdqc_random(¶ms.qc); + if (randompass.text) { status = say(pamh, PAM_TEXT_INFO, randomonly ? - MESSAGE_RANDOMONLY : MESSAGE_RANDOM, randompass); + MESSAGE_RANDOMONLY : MESSAGE_RANDOM, randompass.text); if (status != PAM_SUCCESS) { - _pam_overwrite(randompass); - randompass = NULL; + _pam_overwrite(randompass.text); + randompass.text = NULL; } } else if (randomonly) { @@ -477,29 +490,30 @@ status = PAM_AUTHTOK_ERR; if (status != PAM_SUCCESS) { - if (randompass) _pam_overwrite(randompass); + if (randompass.text) _pam_overwrite(randompass.text); return status; } - newpass = strdup(resp->resp); + newpass.text = strdup(resp->resp); _pam_drop_reply(resp, 1); - if (!newpass) { - if (randompass) _pam_overwrite(randompass); + if (!newpass.text) { + if (randompass.text) _pam_overwrite(randompass.text); return PAM_AUTHTOK_ERR; } - if (check_max(¶ms, pamh, newpass) && enforce) { + if (check_max(¶ms, pamh, newpass.text) && enforce) { status = PAM_AUTHTOK_ERR; retry_wanted = 1; } reason = NULL; if (status == PAM_SUCCESS && - (!randompass || !strstr(newpass, randompass)) && + (!randompass.text || !strstr(newpass.text, randompass.text)) && (randomonly || - (reason = _passwdqc_check(¶ms.qc, newpass, oldpass, pw)))) { + (reason = _passwdqc_check(¶ms.qc, newpass.text, + oldpass.text, pw)))) { if (randomonly) say(pamh, PAM_ERROR_MSG, MESSAGE_NOTRANDOM); else @@ -515,7 +529,7 @@ PROMPT_NEWPASS2, &resp); if (status == PAM_SUCCESS) { if (resp && resp->resp) { - if (strcmp(newpass, resp->resp)) { + if (strcmp(newpass.text, resp->resp)) { status = say(pamh, PAM_ERROR_MSG, MESSAGE_MISTYPED); if (status == PAM_SUCCESS) { @@ -529,11 +543,11 @@ } if (status == PAM_SUCCESS) - status = pam_set_item(pamh, PAM_AUTHTOK, newpass); + status = pam_set_item(pamh, PAM_AUTHTOK, newpass.text); - if (randompass) _pam_overwrite(randompass); - _pam_overwrite(newpass); - free(newpass); + if (randompass.text) _pam_overwrite(randompass.text); + _pam_overwrite(newpass.text); + free(newpass.text); if (retry_wanted && --retries_left > 0) { status = say(pamh, PAM_TEXT_INFO, MESSAGE_RETRY); ==== //SpectraBSD/stable/lib/libpam/modules/pam_passwdqc/Makefile#2 (text) ==== @@ -7,7 +7,7 @@ SRCS= pam_passwdqc.c passwdqc_check.c passwdqc_random.c wordset_4k.c MAN= pam_passwdqc.8 -WARNS?= 0 +WARNS?= 2 CFLAGS+= -I${SRCDIR} DPADD= ${LIBCRYPT} --Apple-Mail=_410A4854-04E8-4B9A-B54B-38F6603F628C-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:38:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D91951065673; Fri, 13 Jul 2012 22:38:25 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6238E8FC0A; Fri, 13 Jul 2012 22:38:25 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6DMcGdg049362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Jul 2012 08:38:16 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6DMcAx5068106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 08:38:10 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6DMc8tq068105; Sat, 14 Jul 2012 08:38:08 +1000 (EST) (envelope-from peter) Date: Sat, 14 Jul 2012 08:38:08 +1000 From: Peter Jeremy To: David Chisnall , John Baldwin , freebsd-current@freebsd.org, Warner Losh , Diane Bruce , Steve Kargl Message-ID: <20120713223808.GA54733@server.rulingia.com> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20120713155805.GC81965@zim.MIT.EDU> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 22:38:25 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-13 11:58:05 -0400, David Schultz wrote: >I propose we set a timeframe for this, on the order of a few months. =2E.. >If the schedule can't be met, then we can just import Cephes as an >interim solution without further ado. This provides Bruce and Steve >an opportunity to commit what they have been working on, without >forcing the rest of the FreeBSD community to wait indefinitely for >the pie in the sky. This sounds good to me as well and I'd be happy to help. --=20 Peter Jeremy --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAAo1AACgkQ/opHv/APuIcu6QCgvrA7magqoTYa0T3ctBtKir9y nicAoLgIfQlh15AzooJ/+4tjuKTtifS4 =e2Tl -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 22:53:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC401065673 for ; Fri, 13 Jul 2012 22:53:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B22A18FC0C for ; Fri, 13 Jul 2012 22:53:05 +0000 (UTC) Received: by obbun3 with SMTP id un3so6825235obb.13 for ; Fri, 13 Jul 2012 15:53:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=kugHE3CwrJCKR1/Tez3E4M5OM8hsJeksxeHCxn6DmqI=; b=FygBPGM8++UVdbJk8aEg/+mKS/b8h+lTJg0FjL7e1+5Kbj1ih8XIHWPf6AluAUJwRi zEk84gSUWt7MbWUH+vmgBmt4dQbU/ywAPw4vaeUOc28Jn6TOToRSEkUA4P0RxUhynsxZ uziyOQigUouIISg7OC64W7d3sa9mq4Xhx28ZbCoYHUa9JWXnA8Ox5faV4AWs6dvnpYYB Jw/w0mgEpNI+XNKJlUZKl/mVi6WzW12mJDhUsBtUjD1qavPwSQ3YhK6oVP6RoihBIv/P yI///33d+QT8SOad4/KubCavXBKMxhPJQmQQZjTMvyOdmI+xfBBR0FKhBkwqt5NQcKkx eTDQ== Received: by 10.182.15.103 with SMTP id w7mr4064463obc.26.1342219985352; Fri, 13 Jul 2012 15:53:05 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id g3sm5523058oeb.5.2012.07.13.15.53.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jul 2012 15:53:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120713223808.GA54733@server.rulingia.com> Date: Fri, 13 Jul 2012 16:53:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5F003BC0-4041-4891-AF04-0A530831AA3A@bsdimp.com> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> <20120713223808.GA54733@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQknsN5xm+KsH/eAWMM03XEeHEwb1IAWX/5+q1aRuBVOo+0YTNNnDPFb3u2ENmPyO7jRvHxB Cc: Diane Bruce , freebsd-current@freebsd.org, David Chisnall , Steve Kargl Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 13 Jul 2012 22:53:06 -0000 On Jul 13, 2012, at 4:38 PM, Peter Jeremy wrote: > On 2012-Jul-13 11:58:05 -0400, David Schultz wrote: >> I propose we set a timeframe for this, on the order of a few months. > ... >> If the schedule can't be met, then we can just import Cephes as an >> interim solution without further ado. This provides Bruce and Steve >> an opportunity to commit what they have been working on, without >> forcing the rest of the FreeBSD community to wait indefinitely for >> the pie in the sky. >=20 > This sounds good to me as well and I'd be happy to help. Also sounds good to me. If Peter gets busy, I'd be able to help as well = with the back-stop proposal. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 00:52:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2280F106564A for ; Sat, 14 Jul 2012 00:52:10 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id C6F9F8FC0C for ; Sat, 14 Jul 2012 00:52:09 +0000 (UTC) Received: from x220.ovitrap.com ([122.129.201.10]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q6E0q6Dg002106; Fri, 13 Jul 2012 18:52:08 -0600 From: Erich Dollansky To: Bernhard Schmidt Date: Sat, 14 Jul 2012 07:52:05 +0700 User-Agent: KMail/1.13.7 (FreeBSD/10.0-CURRENT; KDE/4.8.3; amd64; ; ) References: <201207131904.24490.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207140752.05898.erichfreebsdlist@ovitrap.com> Cc: freebsd-current@freebsd.org Subject: Re: Erratic USB mouse behaviour when wireless is down and USB hard disk connected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 00:52:10 -0000 Hi, On Friday, July 13, 2012 09:10:16 PM Bernhard Schmidt wrote: > On Fri, Jul 13, 2012 at 2:04 PM, Erich Dollansky > > wrote: > > Hi, > > > > I know that this is not a very helpful information. > > > > I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed > > that the USB mouse (a wireless Logitech Trackman) becomes unusable when > > the wireless (iwn) is not able to connect to the access point and a USB > > hard disk is plugged in. Even when no data are transferred the USB mouse > > is unusable. > > Which frequency is the mouse working on? something in the 2.4GHz region? > > I remember having lots of fun at $office with the mouse of colleague. > It used channel 6 and the amount of traffic generating over wireless > LAN had direct influence on the accuracy of his mouse activity ;) > > Anyways, if you have the chance to switch to another channel, give it a > shot. I have to check on this. As the channels of the network here are fixed, this only can happen when the network is down. As I said, I can test it next week. Erich From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 02:48:43 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FA88106566B; Sat, 14 Jul 2012 02:48:43 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id EE01C8FC08; Sat, 14 Jul 2012 02:48:42 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with ESMTP id q6E2mgSU028489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jul 2012 21:48:42 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 13 Jul 2012 21:48:41 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1257) From: Devin Teske Date: Fri, 13 Jul 2012 19:48:44 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: To: X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-13_06:2012-07-13, 2012-07-13, 1970-01-01 signatures=0 Cc: Devin Teske Subject: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 02:48:43 -0000 Hello -current, I'm [re-]announcing that (after much delay from the first announcement) tha= t I am finally importing bsdconfig(8) into HEAD. Here's what to expect from= the import: 1. The Makefile for usr.sbin will not automatically descend into the new us= r.sbin/bsdconfig directory. 2. To add bsdconfig(8) to your system, define WITH_BSDCONFIG=3DYES (either = on the make line with -D or in src.conf(5) for convenience). 3. After the import, not only is it possible but-encouraged to test the HEA= D code on RELENG_9 (but no-lower than 9.0-R as this is the lowest compatibl= e release and RELENG_9 is the lowest target MFC). 4. Aside from the following [tiny] patches, everything lives in usr.sbin/bs= dconfig/ tools/build/options/WITH_BSDCONFIG share/mk/bsd.own.mk usr.sbin/Makefile Please report any problems, kudos, comments to me at-will. --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 03:12:37 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60187106566C; Sat, 14 Jul 2012 03:12:37 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4F08FC0A; Sat, 14 Jul 2012 03:12:37 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 24D4A2AA509; Fri, 13 Jul 2012 21:12:31 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 444181DAF2; Fri, 13 Jul 2012 22:12:23 -0500 (EST) Date: Fri, 13 Jul 2012 22:12:23 -0500 From: Diane Bruce To: Peter Jeremy Message-ID: <20120714031223.GA56963@night.db.net> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> <20120713223808.GA54733@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120713223808.GA54733@server.rulingia.com> User-Agent: Mutt/1.4.2.3i Cc: Diane Bruce , David Chisnall , freebsd-current@freebsd.org, Steve Kargl , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 03:12:37 -0000 On Sat, Jul 14, 2012 at 08:38:08AM +1000, Peter Jeremy wrote: > On 2012-Jul-13 11:58:05 -0400, David Schultz wrote: > >I propose we set a timeframe for this, on the order of a few months. > ... > >If the schedule can't be met, then we can just import Cephes as an > >interim solution without further ado. This provides Bruce and Steve > >an opportunity to commit what they have been working on, without > >forcing the rest of the FreeBSD community to wait indefinitely for > >the pie in the sky. > > This sounds good to me as well and I'd be happy to help. Perfect, all that is needed. I'd also be happy to help of course. > > -- > Peter Jeremy Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db Nowadays tar can compress using yesterdays latest technologies! From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 03:18:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00B93106564A; Sat, 14 Jul 2012 03:18:44 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 020CD8FC1E; Sat, 14 Jul 2012 03:18:42 +0000 (UTC) Received: from [10.138.31.232] ([1.142.139.38]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id q6E34FKq068016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 14 Jul 2012 12:34:22 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_BCE3C826-A1E9-4CBA-ADBD-086FADAB0736"; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: Date: Sat, 14 Jul 2012 13:04:14 +1000 Message-Id: <34BBD043-4FE1-4F0F-9C37-2170BB3F2032@gsoft.com.au> References: <20120529045612.GB4445@server.rulingia.com> <20120711223247.GA9964@troutmask.apl.washington.edu> <20120713114100.GB83006@server.rulingia.com> <201207130818.38535.jhb@freebsd.org> <9EB2DA4F-19D7-4BA5-8811-D9451CB1D907@theravensnest.org> <20120713155805.GC81965@zim.MIT.EDU> <500047DB.60607@missouri.edu> To: Eitan Adler X-Mailer: Apple Mail (2.1278) X-Spam-Score: -0.272 () BAYES_00,RDNS_NONE X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Diane Bruce , David Chisnall , Stephen Montgomery-Smith , freebsd-current@freebsd.org, Steve Kargl , Peter Jeremy , Warner Losh Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 03:18:44 -0000 --Apple-Mail=_BCE3C826-A1E9-4CBA-ADBD-086FADAB0736 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 14/07/2012, at 2:35, Eitan Adler wrote: >>> >>> If the schedule can't be met, then we can just import Cephes as an >>> interim solution without further ado. This provides Bruce and Steve >>> an opportunity to commit what they have been working on, without >>> forcing the rest of the FreeBSD community to wait indefinitely for >>> the pie in the sky. > > +1 > > If we do import Cephes the questionable functions should probably be > explicitly marked somewhere so that if there is still $someone can > still work on them though. Perhaps the same way mktemp et al are marked.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_BCE3C826-A1E9-4CBA-ADBD-086FADAB0736-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 03:33:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1982E106564A; Sat, 14 Jul 2012 03:33:02 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id CB35A8FC0C; Sat, 14 Jul 2012 03:33:01 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q6E3WswX012853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jul 2012 22:32:55 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 13 Jul 2012 22:32:54 -0500 MIME-Version: 1.0 (Apple Message framework v1257) From: Devin Teske In-Reply-To: Date: Fri, 13 Jul 2012 20:32:56 -0700 Message-ID: <6B2450C5-0366-4218-83A7-2FC89E21EFEB@fisglobal.com> References: <4FEF81F5.3050509@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-13_06:2012-07-13, 2012-07-13, 1970-01-01 signatures=0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Devin Teske , McDowell , Ron, freebsd-current@freebsd.org Subject: Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 03:33:02 -0000 On Jul 2, 2012, at 6:24 PM, Devin Teske wrote: >=20 > On Jun 30, 2012, at 3:47 PM, Bruce Cran wrote: >=20 >> On 28/06/2012 00:11, Devin Teske wrote: >>> I'd like to announce that I intend to import bsdconfig(8) today. >>=20 >> I haven't seen this get committed yet - was there a problem? >>=20 >=20 > No problems. A long weekend put the damper on the process but it has pick= ed up again. >=20 > By week's end there should be more info. Just committed! See SVN r238438 http://svnweb.FreeBSD.org/base?limit_changes=3D0&view=3Drevision&revision= =3D238438 In the additional time that was taken many people were spoken with. The onl= y thing that has really changed is that phk recommended adding a "WITH_BSDC= ONFIG" hook, and so that was done. Happy Day! --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 04:46:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4A7D1065672; Sat, 14 Jul 2012 04:46:06 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from server2.allsitecontrol.com (server2.allsitecontrol.com [63.143.36.210]) by mx1.freebsd.org (Postfix) with ESMTP id 983AC8FC15; Sat, 14 Jul 2012 04:46:06 +0000 (UTC) Received: from [93.182.129.86] (port=44669 helo=internal.tormail.org) by server2.allsitecontrol.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.77) (envelope-from ) id 1SpuF2-002CbN-IQ; Sat, 14 Jul 2012 00:46:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:Subject:Cc:To:From; bh=qCuaGixXq0+0MoVoCAzhKPq0tkdU0ynthmnxxiTHOvE=; b=ecSSZSQWvmOHAOogWhu7OpT6RTgVcjkYTJopbwhR/0mt24gPC5X9d4y4MRJMUq3kgvb7RNZ89Rg76C+j8L4V6pRco7VUhO3LSxXWd5Y5HBU+hXA7syKZzrT3+6sXIqhf58P4JUOYXo51uqB+pN1tK3CE8Ul7kmP+Sx0LQTnvSw8=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1SpuD9-0006kw-6D; Sat, 14 Jul 2012 04:44:16 +0000 From: Jan Beich To: freebsd-current@freebsd.org Date: Sat, 14 Jul 2012 01:21:03 -0300 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1SpuD9-0006kw-6D@internal.tormail.org> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.allsitecontrol.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.org X-Source: X-Source-Args: X-Source-Dir: Cc: Jung-uk Kim Subject: fetch(1) fails with https:// - Authentication error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 04:46:06 -0000 It seems recent OpenSSL update broke fetch(1) for me. $ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf $ fetch https://foo/bar fetch: https://foo/bar: Authentication error Same error as with the patch for 1.0.0d from a year ago and same workaround - s/SSLv23_client_method/SSLv3_client_method/. -- FreeBSD 10.0-CURRENT #0 r238415: Fri Jul 13 07:18:02 UTC 2012 foo@bar:/home/blah/.cache/a/freebsd/sys/a/misc/MODULAR amd64 world built with clang From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 04:57:29 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06740106566C; Sat, 14 Jul 2012 04:57:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C07B88FC0A; Sat, 14 Jul 2012 04:57:28 +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 q6E4vM5Q057552; Sat, 14 Jul 2012 00:57:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6E4vM3W057546; Sat, 14 Jul 2012 04:57:22 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 04:57:22 GMT Message-Id: <201207140457.q6E4vM3W057546@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 04:57:29 -0000 TB --- 2012-07-14 03:14:06 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 03:14:06 - 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 --- 2012-07-14 03:14:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-14 03:14:06 - cleaning the object tree TB --- 2012-07-14 03:14:06 - cvsupping the source tree TB --- 2012-07-14 03:14:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-14 03:15:13 - building world TB --- 2012-07-14 03:15:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 03:15:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 03:15:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 03:15:13 - SRCCONF=/dev/null TB --- 2012-07-14 03:15:13 - TARGET=ia64 TB --- 2012-07-14 03:15:13 - TARGET_ARCH=ia64 TB --- 2012-07-14 03:15:13 - TZ=UTC TB --- 2012-07-14 03:15:13 - __MAKE_CONF=/dev/null TB --- 2012-07-14 03:15:13 - cd /src TB --- 2012-07-14 03:15:13 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 03:15:14 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 04:50:54 UTC 2012 TB --- 2012-07-14 04:50:54 - generating LINT kernel config TB --- 2012-07-14 04:50:54 - cd /src/sys/ia64/conf TB --- 2012-07-14 04:50:54 - /usr/bin/make -B LINT TB --- 2012-07-14 04:50:55 - cd /src/sys/ia64/conf TB --- 2012-07-14 04:50:55 - /usr/sbin/config -m LINT TB --- 2012-07-14 04:50:55 - building LINT kernel TB --- 2012-07-14 04:50:55 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 04:50:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 04:50:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 04:50:55 - SRCCONF=/dev/null TB --- 2012-07-14 04:50:55 - TARGET=ia64 TB --- 2012-07-14 04:50:55 - TARGET_ARCH=ia64 TB --- 2012-07-14 04:50:55 - TZ=UTC TB --- 2012-07-14 04:50:55 - __MAKE_CONF=/dev/null TB --- 2012-07-14 04:50:55 - cd /src TB --- 2012-07-14 04:50:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 04:50:55 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_descdma_setup_rx_edma': /src/sys/dev/ath/if_ath.c:2949: warning: 'error' is used uninitialized in this function *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 04:57:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 04:57:22 - ERROR: failed to build LINT kernel TB --- 2012-07-14 04:57:22 - 4544.68 user 711.63 system 6195.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 05:15:50 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E4BB106564A; Sat, 14 Jul 2012 05:15:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB228FC0A; Sat, 14 Jul 2012 05:15:50 +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 q6E5Fnb3096360; Sat, 14 Jul 2012 01:15:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6E5FnbK096350; Sat, 14 Jul 2012 05:15:49 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 05:15:49 GMT Message-Id: <201207140515.q6E5FnbK096350@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 05:15:50 -0000 TB --- 2012-07-14 04:10:08 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 04:10:08 - 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 --- 2012-07-14 04:10:08 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-14 04:10:08 - cleaning the object tree TB --- 2012-07-14 04:10:08 - cvsupping the source tree TB --- 2012-07-14 04:10:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-14 04:10:59 - building world TB --- 2012-07-14 04:10:59 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 04:10:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 04:10:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 04:10:59 - SRCCONF=/dev/null TB --- 2012-07-14 04:10:59 - TARGET=mips TB --- 2012-07-14 04:10:59 - TARGET_ARCH=mips TB --- 2012-07-14 04:10:59 - TZ=UTC TB --- 2012-07-14 04:10:59 - __MAKE_CONF=/dev/null TB --- 2012-07-14 04:10:59 - cd /src TB --- 2012-07-14 04:10:59 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 04:11:00 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 05:14:47 UTC 2012 TB --- 2012-07-14 05:14:47 - cd /src/sys/mips/conf TB --- 2012-07-14 05:14:47 - /usr/sbin/config -m ADM5120 TB --- 2012-07-14 05:14:47 - skipping ADM5120 kernel TB --- 2012-07-14 05:14:47 - cd /src/sys/mips/conf TB --- 2012-07-14 05:14:47 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-14 05:14:47 - skipping ALCHEMY kernel TB --- 2012-07-14 05:14:47 - cd /src/sys/mips/conf TB --- 2012-07-14 05:14:47 - /usr/sbin/config -m AP93 TB --- 2012-07-14 05:14:47 - building AP93 kernel TB --- 2012-07-14 05:14:47 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 05:14:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 05:14:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 05:14:47 - SRCCONF=/dev/null TB --- 2012-07-14 05:14:47 - TARGET=mips TB --- 2012-07-14 05:14:47 - TARGET_ARCH=mips TB --- 2012-07-14 05:14:47 - TZ=UTC TB --- 2012-07-14 05:14:47 - __MAKE_CONF=/dev/null TB --- 2012-07-14 05:14:47 - cd /src TB --- 2012-07-14 05:14:47 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Sat Jul 14 05:14:48 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_variables.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_watch.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_write_cmd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_pci.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_descdma_setup_rx_edma': /src/sys/dev/ath/if_ath.c:2949: warning: 'error' is used uninitialized in this function *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 05:15:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 05:15:49 - ERROR: failed to build AP93 kernel TB --- 2012-07-14 05:15:49 - 2621.59 user 560.81 system 3941.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 07:33:18 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F12E9106564A; Sat, 14 Jul 2012 07:33:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BEB5E8FC08; Sat, 14 Jul 2012 07:33:18 +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 q6E7XHea017624; Sat, 14 Jul 2012 03:33:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6E7XHTG017612; Sat, 14 Jul 2012 07:33:17 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 07:33:17 GMT Message-Id: <201207140733.q6E7XHTG017612@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 07:33:19 -0000 TB --- 2012-07-14 04:57:22 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 04:57:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-14 04:57:22 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-14 04:57:22 - cleaning the object tree TB --- 2012-07-14 04:57:22 - cvsupping the source tree TB --- 2012-07-14 04:57:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-14 04:58:38 - building world TB --- 2012-07-14 04:58:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 04:58:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 04:58:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 04:58:38 - SRCCONF=/dev/null TB --- 2012-07-14 04:58:38 - TARGET=powerpc TB --- 2012-07-14 04:58:38 - TARGET_ARCH=powerpc TB --- 2012-07-14 04:58:38 - TZ=UTC TB --- 2012-07-14 04:58:38 - __MAKE_CONF=/dev/null TB --- 2012-07-14 04:58:38 - cd /src TB --- 2012-07-14 04:58:38 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 04:58:39 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 07:28:38 UTC 2012 TB --- 2012-07-14 07:28:38 - generating LINT kernel config TB --- 2012-07-14 07:28:38 - cd /src/sys/powerpc/conf TB --- 2012-07-14 07:28:38 - /usr/bin/make -B LINT TB --- 2012-07-14 07:28:38 - cd /src/sys/powerpc/conf TB --- 2012-07-14 07:28:38 - /usr/sbin/config -m LINT TB --- 2012-07-14 07:28:38 - building LINT kernel TB --- 2012-07-14 07:28:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 07:28:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 07:28:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 07:28:38 - SRCCONF=/dev/null TB --- 2012-07-14 07:28:38 - TARGET=powerpc TB --- 2012-07-14 07:28:38 - TARGET_ARCH=powerpc TB --- 2012-07-14 07:28:38 - TZ=UTC TB --- 2012-07-14 07:28:38 - __MAKE_CONF=/dev/null TB --- 2012-07-14 07:28:38 - cd /src TB --- 2012-07-14 07:28:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 07:28:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_descdma_setup_rx_edma': /src/sys/dev/ath/if_ath.c:2949: warning: 'error' is used uninitialized in this function *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 07:33:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 07:33:17 - ERROR: failed to build LINT kernel TB --- 2012-07-14 07:33:17 - 6851.54 user 891.73 system 9354.97 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 08:16:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 562DF106566B; Sat, 14 Jul 2012 08:16:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 23D8E8FC0C; Sat, 14 Jul 2012 08:16:09 +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 q6E8G3Ro018077; Sat, 14 Jul 2012 04:16:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6E8G3dK018076; Sat, 14 Jul 2012 08:16:03 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 08:16:03 GMT Message-Id: <201207140816.q6E8G3dK018076@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 08:16:09 -0000 TB --- 2012-07-14 05:15:49 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 05:15:49 - 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 --- 2012-07-14 05:15:49 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-14 05:15:49 - cleaning the object tree TB --- 2012-07-14 05:15:49 - cvsupping the source tree TB --- 2012-07-14 05:15:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-14 05:16:44 - building world TB --- 2012-07-14 05:16:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 05:16:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 05:16:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 05:16:44 - SRCCONF=/dev/null TB --- 2012-07-14 05:16:44 - TARGET=powerpc TB --- 2012-07-14 05:16:44 - TARGET_ARCH=powerpc64 TB --- 2012-07-14 05:16:44 - TZ=UTC TB --- 2012-07-14 05:16:44 - __MAKE_CONF=/dev/null TB --- 2012-07-14 05:16:44 - cd /src TB --- 2012-07-14 05:16:44 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 05:16:45 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 14 08:12:21 UTC 2012 TB --- 2012-07-14 08:12:21 - generating LINT kernel config TB --- 2012-07-14 08:12:21 - cd /src/sys/powerpc/conf TB --- 2012-07-14 08:12:21 - /usr/bin/make -B LINT TB --- 2012-07-14 08:12:21 - cd /src/sys/powerpc/conf TB --- 2012-07-14 08:12:21 - /usr/sbin/config -m LINT TB --- 2012-07-14 08:12:21 - building LINT kernel TB --- 2012-07-14 08:12:21 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 08:12:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 08:12:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 08:12:21 - SRCCONF=/dev/null TB --- 2012-07-14 08:12:21 - TARGET=powerpc TB --- 2012-07-14 08:12:21 - TARGET_ARCH=powerpc64 TB --- 2012-07-14 08:12:21 - TZ=UTC TB --- 2012-07-14 08:12:21 - __MAKE_CONF=/dev/null TB --- 2012-07-14 08:12:21 - cd /src TB --- 2012-07-14 08:12:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 08:12:21 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath.c: In function 'ath_descdma_setup_rx_edma': /src/sys/dev/ath/if_ath.c:2949: warning: 'error' is used uninitialized in this function *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 08:16:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 08:16:03 - ERROR: failed to build LINT kernel TB --- 2012-07-14 08:16:03 - 8314.33 user 1159.95 system 10813.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 09:35:00 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7F2F106564A; Sat, 14 Jul 2012 09:35:00 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id 96FC08FC0C; Sat, 14 Jul 2012 09:35:00 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 213B4E656F; Sat, 14 Jul 2012 10:36:26 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=npQ8lPB3PnVT ufNym6LYHe0x2fU=; b=g9LOp5bI/WHfDYBPw7ByTUEtqCYqmNK+fDNyI75ZH9eh BFflIr5saLS7TYbWfSd5mBAImaFQfhoJTN6rOZnrUKm98IGe971BFpcil7j+3G/c B1xSVYaEOFMjnqTVcscv6Bxeoza7TELRns9R64H+Huk2QXUP34DrRdrwWoRtcJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=q+93OZ 4xz0ATpohk7uP6ZT6dauSNX+JiSwZu1q6IaFL38VjCJhxlyo53yEAN6M/TZveiC0 zGFvc5Oy0iDRRZJ+z2n/4TjloA5PUKiLHr5ER/BezjKkmLPaBNUfioznMrxyaQ6x Fm0fM89gHc+FuVNmXRRfuQvrt6CmZTTxpaEis= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id E56ECE6559; Sat, 14 Jul 2012 10:36:25 +0100 (BST) Message-ID: <50013D3B.90206@cran.org.uk> Date: Sat, 14 Jul 2012 10:34:51 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Devin Teske , freebsd-current@freebsd.org Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 09:35:01 -0000 On 14/07/2012 03:48, Devin Teske wrote: > I'm [re-]announcing that (after much delay from the first announcement) that I am finally importing bsdconfig(8) into HEAD. I've noticed a couple of issues: The welcome page mentions setting the root password and the time zone, but bsdinstall will have already done that. "...look at the 'Packages' item in this menu." and on the main page - "Most importantly, you can use the Packages utility..." - I don't see a Packages entry in the menu. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 10:35:57 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66FA8106566C; Sat, 14 Jul 2012 10:35:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2B64D8FC0C; Sat, 14 Jul 2012 10:35:57 +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 q6EAZu3W005706; Sat, 14 Jul 2012 06:35:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EAZuj2005705; Sat, 14 Jul 2012 10:35:56 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 10:35:56 GMT Message-Id: <201207141035.q6EAZuj2005705@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 10:35:57 -0000 TB --- 2012-07-14 09:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 09:20:00 - 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 --- 2012-07-14 09:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-07-14 09:20:00 - cleaning the object tree TB --- 2012-07-14 09:20:00 - cvsupping the source tree TB --- 2012-07-14 09:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-07-14 09:25:44 - building world TB --- 2012-07-14 09:25:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 09:25:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 09:25:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 09:25:44 - SRCCONF=/dev/null TB --- 2012-07-14 09:25:44 - TARGET=arm TB --- 2012-07-14 09:25:44 - TARGET_ARCH=arm TB --- 2012-07-14 09:25:44 - TZ=UTC TB --- 2012-07-14 09:25:44 - __MAKE_CONF=/dev/null TB --- 2012-07-14 09:25:44 - cd /src TB --- 2012-07-14 09:25:44 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 09:25:45 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 10:31:44 UTC 2012 TB --- 2012-07-14 10:31:44 - cd /src/sys/arm/conf TB --- 2012-07-14 10:31:44 - /usr/sbin/config -m ATMEL TB --- 2012-07-14 10:31:44 - building ATMEL kernel TB --- 2012-07-14 10:31:44 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 10:31:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 10:31:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 10:31:44 - SRCCONF=/dev/null TB --- 2012-07-14 10:31:44 - TARGET=arm TB --- 2012-07-14 10:31:44 - TARGET_ARCH=arm TB --- 2012-07-14 10:31:44 - TZ=UTC TB --- 2012-07-14 10:31:44 - __MAKE_CONF=/dev/null TB --- 2012-07-14 10:31:44 - cd /src TB --- 2012-07-14 10:31:44 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Sat Jul 14 10:31:44 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Sat Jul 14 10:35:14 UTC 2012 TB --- 2012-07-14 10:35:14 - cd /src/sys/arm/conf TB --- 2012-07-14 10:35:14 - /usr/sbin/config -m AVILA TB --- 2012-07-14 10:35:14 - building AVILA kernel TB --- 2012-07-14 10:35:14 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 10:35:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 10:35:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 10:35:14 - SRCCONF=/dev/null TB --- 2012-07-14 10:35:14 - TARGET=arm TB --- 2012-07-14 10:35:14 - TARGET_ARCH=arm TB --- 2012-07-14 10:35:14 - TZ=UTC TB --- 2012-07-14 10:35:14 - __MAKE_CONF=/dev/null TB --- 2012-07-14 10:35:14 - cd /src TB --- 2012-07-14 10:35:14 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Sat Jul 14 10:35:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 10:35:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 10:35:56 - ERROR: failed to build AVILA kernel TB --- 2012-07-14 10:35:56 - 2688.47 user 604.44 system 4555.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 09:25:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFA011065673 for ; Sat, 14 Jul 2012 09:25:27 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 96BE48FC12 for ; Sat, 14 Jul 2012 09:25:27 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q6E9PCuk074586 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 14 Jul 2012 09:25:15 GMT (envelope-from theraven@theravensnest.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <777FA576-7DBA-43B1-817A-0BB7CCF232E9@bsdimp.com> Date: Sat, 14 Jul 2012 10:24:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <20120711005506.GA88249@server.rulingia.com> <777FA576-7DBA-43B1-817A-0BB7CCF232E9@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sat, 14 Jul 2012 11:34:29 +0000 Cc: freebsd-current , Peter Jeremy Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 09:25:27 -0000 On 13 Jul 2012, at 17:40, Warner Losh wrote: > We shouldn't be gating the new math on an issue that only affects = sparc64 machines Mostly agreed, but it's worth noting that the APCS for ARMv8[1] = specifies that long double should be IEEE 754- 2008 quad precision. I = think ARMv8 is going to be an important platform for us in the next few = years, so ld128 is not just for SPARC (I'd also like us to switch to = ld128 on PowerPC, since that's the ABI that everyone else uses, but I = don't anticipate PowerPC becoming tier 1 any time soon, whereas I would = very much like to see ARMv8 become tier 1 within a year of shipping = silicon). That's not to say that we should hold things up waiting for ld128 = versions, just that adding ld128 versions soon after adding ld80 ones = would be very helpful. David [1] = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055a/IHI0055A_aapcs64= .pdf= From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 12:06:39 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E221065691; Sat, 14 Jul 2012 12:06:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B210B8FC0C; Sat, 14 Jul 2012 12:06:39 +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 q6EC6ca2025356; Sat, 14 Jul 2012 08:06:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EC6cmZ025355; Sat, 14 Jul 2012 12:06:38 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 12:06:38 GMT Message-Id: <201207141206.q6EC6cmZ025355@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 12:06:40 -0000 TB --- 2012-07-14 09:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 09:20:00 - 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 --- 2012-07-14 09:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-07-14 09:20:00 - cleaning the object tree TB --- 2012-07-14 09:20:00 - cvsupping the source tree TB --- 2012-07-14 09:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-07-14 09:22:34 - building world TB --- 2012-07-14 09:22:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 09:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 09:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 09:22:34 - SRCCONF=/dev/null TB --- 2012-07-14 09:22:34 - TARGET=i386 TB --- 2012-07-14 09:22:34 - TARGET_ARCH=i386 TB --- 2012-07-14 09:22:34 - TZ=UTC TB --- 2012-07-14 09:22:34 - __MAKE_CONF=/dev/null TB --- 2012-07-14 09:22:34 - cd /src TB --- 2012-07-14 09:22:34 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 09:22:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 11:56:39 UTC 2012 TB --- 2012-07-14 11:56:39 - generating LINT kernel config TB --- 2012-07-14 11:56:39 - cd /src/sys/i386/conf TB --- 2012-07-14 11:56:39 - /usr/bin/make -B LINT TB --- 2012-07-14 11:56:39 - cd /src/sys/i386/conf TB --- 2012-07-14 11:56:39 - /usr/sbin/config -m LINT TB --- 2012-07-14 11:56:39 - building LINT kernel TB --- 2012-07-14 11:56:39 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 11:56:39 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 11:56:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 11:56:39 - SRCCONF=/dev/null TB --- 2012-07-14 11:56:39 - TARGET=i386 TB --- 2012-07-14 11:56:39 - TARGET_ARCH=i386 TB --- 2012-07-14 11:56:39 - TZ=UTC TB --- 2012-07-14 11:56:39 - __MAKE_CONF=/dev/null TB --- 2012-07-14 11:56:39 - cd /src TB --- 2012-07-14 11:56:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 11:56:39 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 12:06:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 12:06:38 - ERROR: failed to build LINT kernel TB --- 2012-07-14 12:06:38 - 6820.40 user 979.97 system 9998.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 12:06:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86C9A10656B1; Sat, 14 Jul 2012 12:06:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5426B8FC0C; Sat, 14 Jul 2012 12:06:59 +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 q6EC6wfJ026407; Sat, 14 Jul 2012 08:06:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EC6wwj026403; Sat, 14 Jul 2012 12:06:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 12:06:58 GMT Message-Id: <201207141206.q6EC6wwj026403@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 12:06:59 -0000 TB --- 2012-07-14 09:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 09:20:00 - 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 --- 2012-07-14 09:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-07-14 09:20:00 - cleaning the object tree TB --- 2012-07-14 09:20:00 - cvsupping the source tree TB --- 2012-07-14 09:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-07-14 09:22:34 - building world TB --- 2012-07-14 09:22:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 09:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 09:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 09:22:34 - SRCCONF=/dev/null TB --- 2012-07-14 09:22:34 - TARGET=pc98 TB --- 2012-07-14 09:22:34 - TARGET_ARCH=i386 TB --- 2012-07-14 09:22:34 - TZ=UTC TB --- 2012-07-14 09:22:34 - __MAKE_CONF=/dev/null TB --- 2012-07-14 09:22:34 - cd /src TB --- 2012-07-14 09:22:34 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 09:22:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 11:58:38 UTC 2012 TB --- 2012-07-14 11:58:38 - generating LINT kernel config TB --- 2012-07-14 11:58:38 - cd /src/sys/pc98/conf TB --- 2012-07-14 11:58:38 - /usr/bin/make -B LINT TB --- 2012-07-14 11:58:38 - cd /src/sys/pc98/conf TB --- 2012-07-14 11:58:38 - /usr/sbin/config -m LINT TB --- 2012-07-14 11:58:38 - building LINT kernel TB --- 2012-07-14 11:58:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 11:58:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 11:58:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 11:58:38 - SRCCONF=/dev/null TB --- 2012-07-14 11:58:38 - TARGET=pc98 TB --- 2012-07-14 11:58:38 - TARGET_ARCH=i386 TB --- 2012-07-14 11:58:38 - TZ=UTC TB --- 2012-07-14 11:58:38 - __MAKE_CONF=/dev/null TB --- 2012-07-14 11:58:38 - cd /src TB --- 2012-07-14 11:58:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 11:58:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 12:06:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 12:06:58 - ERROR: failed to build LINT kernel TB --- 2012-07-14 12:06:58 - 6744.55 user 963.60 system 10018.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 12:24:00 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A8AB106564A; Sat, 14 Jul 2012 12:24:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 13BED8FC08; Sat, 14 Jul 2012 12:23:59 +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 q6ECNx9C047122; Sat, 14 Jul 2012 08:23:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ECNxBJ047121; Sat, 14 Jul 2012 12:23:59 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 12:23:59 GMT Message-Id: <201207141223.q6ECNxBJ047121@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 12:24:00 -0000 TB --- 2012-07-14 10:35:56 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 10:35:56 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-14 10:35:56 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-14 10:35:56 - cleaning the object tree TB --- 2012-07-14 10:36:44 - cvsupping the source tree TB --- 2012-07-14 10:36:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-14 10:37:11 - building world TB --- 2012-07-14 10:37:11 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 10:37:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 10:37:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 10:37:11 - SRCCONF=/dev/null TB --- 2012-07-14 10:37:11 - TARGET=ia64 TB --- 2012-07-14 10:37:11 - TARGET_ARCH=ia64 TB --- 2012-07-14 10:37:11 - TZ=UTC TB --- 2012-07-14 10:37:11 - __MAKE_CONF=/dev/null TB --- 2012-07-14 10:37:11 - cd /src TB --- 2012-07-14 10:37:11 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 10:37:12 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 12:17:20 UTC 2012 TB --- 2012-07-14 12:17:20 - generating LINT kernel config TB --- 2012-07-14 12:17:20 - cd /src/sys/ia64/conf TB --- 2012-07-14 12:17:20 - /usr/bin/make -B LINT TB --- 2012-07-14 12:17:20 - cd /src/sys/ia64/conf TB --- 2012-07-14 12:17:20 - /usr/sbin/config -m LINT TB --- 2012-07-14 12:17:20 - building LINT kernel TB --- 2012-07-14 12:17:20 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 12:17:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 12:17:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 12:17:20 - SRCCONF=/dev/null TB --- 2012-07-14 12:17:20 - TARGET=ia64 TB --- 2012-07-14 12:17:20 - TARGET_ARCH=ia64 TB --- 2012-07-14 12:17:20 - TZ=UTC TB --- 2012-07-14 12:17:20 - __MAKE_CONF=/dev/null TB --- 2012-07-14 12:17:20 - cd /src TB --- 2012-07-14 12:17:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 12:17:20 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 12:23:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 12:23:59 - ERROR: failed to build LINT kernel TB --- 2012-07-14 12:23:59 - 4565.56 user 700.70 system 6482.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 12:43:35 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B898E106566B; Sat, 14 Jul 2012 12:43:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 74A9D8FC08; Sat, 14 Jul 2012 12:43:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6EChYdv016057; Sat, 14 Jul 2012 08:43:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EChYAf016055; Sat, 14 Jul 2012 12:43:34 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 12:43:34 GMT Message-Id: <201207141243.q6EChYAf016055@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 12:43:35 -0000 TB --- 2012-07-14 09:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 09:20:00 - 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 --- 2012-07-14 09:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-07-14 09:20:00 - cleaning the object tree TB --- 2012-07-14 09:20:00 - cvsupping the source tree TB --- 2012-07-14 09:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-07-14 09:22:34 - building world TB --- 2012-07-14 09:22:34 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 09:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 09:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 09:22:34 - SRCCONF=/dev/null TB --- 2012-07-14 09:22:34 - TARGET=amd64 TB --- 2012-07-14 09:22:34 - TARGET_ARCH=amd64 TB --- 2012-07-14 09:22:34 - TZ=UTC TB --- 2012-07-14 09:22:34 - __MAKE_CONF=/dev/null TB --- 2012-07-14 09:22:34 - cd /src TB --- 2012-07-14 09:22:34 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 09:22:34 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 14 12:35:46 UTC 2012 TB --- 2012-07-14 12:35:46 - generating LINT kernel config TB --- 2012-07-14 12:35:46 - cd /src/sys/amd64/conf TB --- 2012-07-14 12:35:46 - /usr/bin/make -B LINT TB --- 2012-07-14 12:35:46 - cd /src/sys/amd64/conf TB --- 2012-07-14 12:35:46 - /usr/sbin/config -m LINT TB --- 2012-07-14 12:35:46 - building LINT kernel TB --- 2012-07-14 12:35:46 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 12:35:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 12:35:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 12:35:46 - SRCCONF=/dev/null TB --- 2012-07-14 12:35:46 - TARGET=amd64 TB --- 2012-07-14 12:35:46 - TARGET_ARCH=amd64 TB --- 2012-07-14 12:35:46 - TZ=UTC TB --- 2012-07-14 12:35:46 - __MAKE_CONF=/dev/null TB --- 2012-07-14 12:35:46 - cd /src TB --- 2012-07-14 12:35:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 12:35:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 12:43:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 12:43:34 - ERROR: failed to build LINT kernel TB --- 2012-07-14 12:43:34 - 8259.34 user 1299.45 system 12214.09 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 13:00:38 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7ECA6106566B for ; Sat, 14 Jul 2012 13:00:38 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0701C8FC14 for ; Sat, 14 Jul 2012 13:00:37 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 25794 invoked from network); 14 Jul 2012 15:00:35 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1342270835; bh=xJLV64FlqED9V/zkbXwN/blQExMBF1iVsfast75QmjY=; h=From:To:CC:Subject; b=f72hoiAtDn1mTsAEW9MuumavdVpC6ETPu4T/JkZU3YnsQv/urXVYm1z628aGmYLbz JUWlmN7JlHBnUbthOObB48j9UG2tnLK530jrqU7e3ZzTyuB0R0Oyakf/LYozyvDWKQ xZuLNmYcsNqv2z2m0dAG++oOhZeREEc9oMAWGAnc= Received: from nat.misal.pl (HELO [127.0.0.1]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 14 Jul 2012 15:00:35 +0200 Message-ID: <50016D73.3020902@wp.pl> Date: Sat, 14 Jul 2012 15:00:35 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: matt References: <4F470DFF.3070906@gmail.com> In-Reply-To: <4F470DFF.3070906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [UVM0] Cc: freebsd-current@freebsd.org Subject: Re: Syscons issue Intel D2700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 13:00:38 -0000 Hi, W dniu 2012-02-24 05:11, matt pisze: > I'm currently trying to boot an intel evaluation board (D2700) with > 10-CURRENT. > Installation was > make installworld DESTDIR=/mnt/disk > make installkernel DESTDIR=/mnt/disk > make distribution DESTDIR=/mnt/disk > vi /mnt/disk/fstab (added lines for root, swap) > unmount /mnt/disk > > Boot goes fine until the kernel is loaded. > Once the kernel is loaded, boot continues, however only the very > bottom line is showing kernel messages...the rest of the screen still > "looks" like loader. > > Once booted, a number of silly attempts with vidcontrol 80x25, > vidcontrol -C, vidcontrol VESA_800x600 do not fix the situation. did you manage to fix your issue? I recently bought a D2500HN m/b and have the same problem with 9-Release (I'm trying to install it via PXE but installer menu doesn't work properly..) Regards, -- Marek From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 13:12:54 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF03B106566C; Sat, 14 Jul 2012 13:12:54 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 672A68FC0A; Sat, 14 Jul 2012 13:12:54 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C142C3592E4; Sat, 14 Jul 2012 15:12:53 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 9D3CB2847B; Sat, 14 Jul 2012 15:12:53 +0200 (CEST) Date: Sat, 14 Jul 2012 15:12:53 +0200 From: Jilles Tjoelker To: "Justin T. Gibbs" Message-ID: <20120714131253.GA82559@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org, des@FreeBSD.org Subject: Re: PAM passwdqc, strict aliasing, and WARNS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 13:12:54 -0000 On Fri, Jul 13, 2012 at 04:14:17PM -0600, Justin T. Gibbs wrote: > Someone who has yet to confess added -Werror to the global CFLAGS > (via /etc/make.conf) for one of our systems at work. Before I > figured out that this was the cause of builds failing, I hacked up > pam_passwdc to resolve the problem. This gets the module to > WARNS=2, but to go farther, the "logically const" issues with this > code will need to be sorted out. > Is this change worth committing? Is this the best way to resolve > the strict aliasing issues in this code? The prototype of pam_get_item() is int pam_get_item(const pam_handle_t *pamh, int item_type, const void **item); Therefore, you should pass a pointer to a const void pointer as the last argument. You can then convert the const void pointer to the desired type. For example: const void *item; const struct pam_conv *conv; result = pam_get_item(pamh, PAM_CONV, &item); conv = item; Passing something like a pointer to a 'const struct pam_conv *' to pam_get_item() will cause a strict-aliasing violation because pam_get_item() will attempt to store a value into an object of declared type 'const struct pam_conv *' using an lvalue of type 'const void *'. In both C99 and C11, these rules are in 6.5 Expressions. In the case of const struct pam_conv *, the union approach violates the C standard because the C standard does not guarantee that all object pointers have the same representation. The conversion might be non-trivial and a "type-pun" may not work properly. However, in almost all real machines the conversion is trivial. Some compilers may still consider the union approach a strict-aliasing violation. In any case, I think it is a bit ugly and should be avoided when possible (like here). -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 13:16:33 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B92311065674; Sat, 14 Jul 2012 13:16:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 826888FC1F; Sat, 14 Jul 2012 13:16: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 q6EDGWLa011904; Sat, 14 Jul 2012 09:16:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EDGWmC011903; Sat, 14 Jul 2012 13:16:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 13:16:32 GMT Message-Id: <201207141316.q6EDGWmC011903@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 13:16:33 -0000 TB --- 2012-07-14 12:06:39 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 12:06:39 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-14 12:06:39 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-14 12:06:39 - cleaning the object tree TB --- 2012-07-14 12:08:05 - cvsupping the source tree TB --- 2012-07-14 12:08:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-14 12:09:21 - building world TB --- 2012-07-14 12:09:21 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 12:09:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 12:09:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 12:09:21 - SRCCONF=/dev/null TB --- 2012-07-14 12:09:21 - TARGET=mips TB --- 2012-07-14 12:09:21 - TARGET_ARCH=mips TB --- 2012-07-14 12:09:21 - TZ=UTC TB --- 2012-07-14 12:09:21 - __MAKE_CONF=/dev/null TB --- 2012-07-14 12:09:21 - cd /src TB --- 2012-07-14 12:09:21 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 12:09:22 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 13:15:31 UTC 2012 TB --- 2012-07-14 13:15:31 - cd /src/sys/mips/conf TB --- 2012-07-14 13:15:31 - /usr/sbin/config -m ADM5120 TB --- 2012-07-14 13:15:31 - skipping ADM5120 kernel TB --- 2012-07-14 13:15:31 - cd /src/sys/mips/conf TB --- 2012-07-14 13:15:31 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-14 13:15:31 - skipping ALCHEMY kernel TB --- 2012-07-14 13:15:31 - cd /src/sys/mips/conf TB --- 2012-07-14 13:15:31 - /usr/sbin/config -m AP93 TB --- 2012-07-14 13:15:31 - building AP93 kernel TB --- 2012-07-14 13:15:31 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 13:15:31 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 13:15:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 13:15:31 - SRCCONF=/dev/null TB --- 2012-07-14 13:15:31 - TARGET=mips TB --- 2012-07-14 13:15:31 - TARGET_ARCH=mips TB --- 2012-07-14 13:15:31 - TZ=UTC TB --- 2012-07-14 13:15:31 - __MAKE_CONF=/dev/null TB --- 2012-07-14 13:15:31 - cd /src TB --- 2012-07-14 13:15:31 - /usr/bin/make -B buildkernel KERNCONF=AP93 >>> Kernel build for AP93 started on Sat Jul 14 13:15:32 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=10000 --param large-function-growth=100000 --param max-inline-insns-single=10000 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80050000 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/mips.mips/src/sys/AP93. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 13:16:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 13:16:32 - ERROR: failed to build AP93 kernel TB --- 2012-07-14 13:16:32 - 2620.89 user 582.09 system 4193.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 14:32:13 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 750A3106566B; Sat, 14 Jul 2012 14:32:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 32AE08FC0C; Sat, 14 Jul 2012 14:32:13 +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 q6EEWC3n092882; Sat, 14 Jul 2012 10:32:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EEWCeW092881; Sat, 14 Jul 2012 14:32:12 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 14:32:12 GMT Message-Id: <201207141432.q6EEWCeW092881@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 14:32:13 -0000 TB --- 2012-07-14 12:06:58 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 12:06: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 --- 2012-07-14 12:06:59 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2012-07-14 12:06:59 - cleaning the object tree TB --- 2012-07-14 12:09:54 - cvsupping the source tree TB --- 2012-07-14 12:09:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2012-07-14 12:11:03 - building world TB --- 2012-07-14 12:11:03 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 12:11:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 12:11:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 12:11:03 - SRCCONF=/dev/null TB --- 2012-07-14 12:11:03 - TARGET=powerpc TB --- 2012-07-14 12:11:03 - TARGET_ARCH=powerpc TB --- 2012-07-14 12:11:03 - TZ=UTC TB --- 2012-07-14 12:11:03 - __MAKE_CONF=/dev/null TB --- 2012-07-14 12:11:03 - cd /src TB --- 2012-07-14 12:11:03 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 12:11:04 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jul 14 14:28:14 UTC 2012 TB --- 2012-07-14 14:28:14 - generating LINT kernel config TB --- 2012-07-14 14:28:14 - cd /src/sys/powerpc/conf TB --- 2012-07-14 14:28:14 - /usr/bin/make -B LINT TB --- 2012-07-14 14:28:14 - cd /src/sys/powerpc/conf TB --- 2012-07-14 14:28:14 - /usr/sbin/config -m LINT TB --- 2012-07-14 14:28:14 - building LINT kernel TB --- 2012-07-14 14:28:14 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 14:28:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 14:28:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 14:28:14 - SRCCONF=/dev/null TB --- 2012-07-14 14:28:14 - TARGET=powerpc TB --- 2012-07-14 14:28:14 - TARGET_ARCH=powerpc TB --- 2012-07-14 14:28:14 - TZ=UTC TB --- 2012-07-14 14:28:14 - __MAKE_CONF=/dev/null TB --- 2012-07-14 14:28:14 - cd /src TB --- 2012-07-14 14:28:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 14:28:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 14:32:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 14:32:12 - ERROR: failed to build LINT kernel TB --- 2012-07-14 14:32:12 - 6794.13 user 915.06 system 8713.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 15:13:31 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE800106566C; Sat, 14 Jul 2012 15:13:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 720818FC08; Sat, 14 Jul 2012 15:13: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 q6EFDU16098312; Sat, 14 Jul 2012 11:13:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6EFDULv098311; Sat, 14 Jul 2012 15:13:30 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 14 Jul 2012 15:13:30 GMT Message-Id: <201207141513.q6EFDULv098311@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 , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 15:13:31 -0000 TB --- 2012-07-14 12:23:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 12:23: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 --- 2012-07-14 12:23:59 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-07-14 12:23:59 - cleaning the object tree TB --- 2012-07-14 12:26:14 - cvsupping the source tree TB --- 2012-07-14 12:26:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-07-14 12:26:55 - building world TB --- 2012-07-14 12:26:55 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 12:26:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 12:26:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 12:26:55 - SRCCONF=/dev/null TB --- 2012-07-14 12:26:55 - TARGET=powerpc TB --- 2012-07-14 12:26:55 - TARGET_ARCH=powerpc64 TB --- 2012-07-14 12:26:55 - TZ=UTC TB --- 2012-07-14 12:26:55 - __MAKE_CONF=/dev/null TB --- 2012-07-14 12:26:55 - cd /src TB --- 2012-07-14 12:26:55 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 14 12:26:56 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Jul 14 15:10:03 UTC 2012 TB --- 2012-07-14 15:10:03 - generating LINT kernel config TB --- 2012-07-14 15:10:03 - cd /src/sys/powerpc/conf TB --- 2012-07-14 15:10:03 - /usr/bin/make -B LINT TB --- 2012-07-14 15:10:03 - cd /src/sys/powerpc/conf TB --- 2012-07-14 15:10:03 - /usr/sbin/config -m LINT TB --- 2012-07-14 15:10:03 - building LINT kernel TB --- 2012-07-14 15:10:03 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 15:10:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 15:10:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 15:10:03 - SRCCONF=/dev/null TB --- 2012-07-14 15:10:03 - TARGET=powerpc TB --- 2012-07-14 15:10:03 - TARGET_ARCH=powerpc64 TB --- 2012-07-14 15:10:03 - TZ=UTC TB --- 2012-07-14 15:10:03 - __MAKE_CONF=/dev/null TB --- 2012-07-14 15:10:03 - cd /src TB --- 2012-07-14 15:10:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jul 14 15:10:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wunused-variable] *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-14 15:13:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-14 15:13:30 - ERROR: failed to build LINT kernel TB --- 2012-07-14 15:13:30 - 8307.13 user 1152.00 system 10171.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 15:39:47 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25A05106564A; Sat, 14 Jul 2012 15:39:47 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8E88FC0C; Sat, 14 Jul 2012 15:39:46 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3091789qcs.13 for ; Sat, 14 Jul 2012 08:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=lcbXdD4DIrAOIke/qnHbgDZfJaDQEKaQzS+bbd12xRM=; b=XrZOVWPwdXewN7KiXtoZnlHNYdMnKTXcrD673T97rKl9fm7ljUwIcp26Nr3GWk5t8M LE4TOXdgZFf7CF+vCXbf+0VikupPC66rtwx0T0BmdLGaCvpf5VKyZV71CuKxdewE0oi0 GeDU6TMRbtMXtWuN1aCZzp/Z4cntYOMs+VdZK0IIq64eWVTRKZiXuD3/6id/Gtq2ZIhE 8npT1sY27vw4RVfpQJph4pZG7+G80XuM7KKxogE0AlyVCzU7zq86ACtQQZA7/Qj4Frve Ixw39geGtWOFdTS9t+UAbiEgMXRlCVfUAkLgUUyu2fwM2LbZMlFsxGv3QkOthXcEa2Gl 35gA== Received: by 10.224.59.212 with SMTP id m20mr10514523qah.35.1342280386107; Sat, 14 Jul 2012 08:39:46 -0700 (PDT) Received: from triad.knownspace (pool-71-163-84-156.washdc.fios.verizon.net. [71.163.84.156]) by mx.google.com with ESMTPS id fx5sm15288208qab.14.2012.07.14.08.39.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 08:39:45 -0700 (PDT) Message-Id: From: Justin Hibbits To: mdf@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Jul 2012 11:39:43 -0400 References: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 15:39:47 -0000 On Jul 13, 2012, at 12:20 AM, mdf@freebsd.org wrote: > On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits > wrote: >> On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote: >> >>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits >> > >>> wrote: >>>> >>>> When tracking down a panic exposed by INVARIANTS, I tried setting >>>> DEBUG_MEMGUARD, so I could find the culprit that's trashing freed >>>> memory. >>>> However, this causes a panic at bootup. It shows up right after >>>> the >>>> first >>>> WARNING: WITNESS message, with the following: >>>> >>>> Tracing, and printf() debugging, I see arguments to >>>> vm_map_findspace(): >>>> start: 0xD0000000, length: 4246446080, and map->max_offset = >>>> 4026531839. >>>> >>>> Beyond that, I'm lost with tracking this down. Machine is a dual >>>> processor >>>> PowerPC G4, with 2GB RAM. >>> >>> >>> The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of >>> virtual space for 2GB of RAM sounds about right (it's been a while >>> since I was in this code), unless this is a 32-bit kernel, in which >>> case it'd be too much since there isn't that much virtual space >>> available. >>> >>> So, is the kernel 32-bit? What are the values used and returned by >>> memguard_fudge()? The intent of that routine is to get kmeminit() >>> to >>> allocate a larger map so memguard can use part of it for private >>> virtual addresses. But it shouldn't be asking for "too much"; i.e. >>> the intent was to check both physical and virtual space available >>> and >>> be greedy, but not too greedy. >>> >>> There were some issues with that code for some platforms that e.g. >>> didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in r216425. >> >> It is a 32-bit kernel, on 32-bit hardware. The values for >> memguard_fudge >> are (defaults): >> >> tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0 >> >> When setting vm.kmem_size/vm.kmem_size_max to 2GB they are: >> >> tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max: >> 2147483648 (all >> 2GB). >> >> But the start and map->max_offset remain the same on all runs I make. > > memguard_fudge is still broken for 32-bit architectures with no > vm_kmem_max. In the absence of a km_max to limit the value, we > essentially use twice the physical memory for the virtual limit. But > with 2GB on a 32-bit machine, this requires 4GB of virtual space. > > Setting vm_kmem_size_max to 2GB should work; I'd expect to see > tmp=about 200MB, which is much larger than the input 112MB but the > allocation should work. But I don't really know what else PowerPC has > need of for virtual space, so that still could be too large. > > You can try smaller values of vm_kmem_size_max, like 1GB or 512MB. > You shouldn't need to set vm_kmem_size at all. At some point the > added space for the memguard_map will be small enough that the > kmem_suballoc will work. > > Hmm, what is the min_offset and max_offset of kernel_map when the call > to memguard_fudge is made? > > Thanks, > matthew Without setting vm.kmem_size/vm.kmem_size_max, I see the following: map: 0x1000000, min_offset: 0xD0000000, max_offset: 0xEFFFFFFF It does boot when I set vm.kmem_size=256M/vm.kmem_size_max=512M. When I tried 512M/1024M, it panicked at the same place -- kmem_suballoc from kmeminit. So it looks like I have to set vm.kmem_size/vm.kmem_size_max way back in order for it to boot with memguard(9). - Justin From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 16:12:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E951065677 for ; Sat, 14 Jul 2012 16:12:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE7598FC1D for ; Sat, 14 Jul 2012 16:12:45 +0000 (UTC) Received: by obbun3 with SMTP id un3so8225533obb.13 for ; Sat, 14 Jul 2012 09:12:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nCb52YUdRq/huSy4nJ/pyf7K+g8aXgUc8RSV7BkJKTQ=; b=WgQ1EoB3R3ycbgP3DZ/iE5iQKPKXe89F8qBDDOrK6I9+H5MglzaZL8WLd5m24Bjtgm ehkP1sQqw8xJLwPMXLey4TMbFBmpSE0lPM+LIX9dlyGhYQzWnO6dPB+PHXYX25jM4EWi Ts1O4jJWo+6J93Lm/o0e3sTl1DiSqWCxSllkOfr5BOQ8l0CPsNr2ldQ1ACqemR10XeoM 3yC08JVsCxfxwPJc5E0cUdJ6vU7yPrgqSpprvm87S5RyHj7pwCUaBwfpad/vF8d59Bbp mhHkeqXQ6AELySrYgbmm9BCaB5N4txWS7U0ACH/YfadNufB01RR58Vw2EFwl9IRyUs8H Zzvg== Received: by 10.50.186.162 with SMTP id fl2mr1732860igc.44.1342282365169; Sat, 14 Jul 2012 09:12:45 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ga6sm4234253igc.2.2012.07.14.09.12.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 09:12:44 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 14 Jul 2012 10:12:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <37B3FD2A-94E9-46DB-980C-DDC8C93C4D4B@bsdimp.com> References: <20120529045612.GB4445@server.rulingia.com> <20120708124047.GA44061@zim.MIT.EDU> <210816F0-7ED7-4481-ABFF-C94A700A3EA0@bsdimp.com> <20120708233624.GA53462@troutmask.apl.washington.edu> <4FFBF16D.2030007@gwdg.de> <2A1DE516-ABB4-49D7-8C3D-2C4DA2D9FCF5@bsdimp.com> <4FFC412B.4090202@gwdg.de> <20120710151115.GA56950@zim.MIT.EDU> <4FFC5E5D.8000502@gwdg.de> <20120710225801.GB58778@zim.MIT.EDU> <20120711005506.GA88249@server.rulingia.com> <777FA576-7DBA-43B1-817A-0BB7CCF232E9@bsdimp.com> To: David Chisnall X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmUpiUmdRDEAydpp6x44CsnEe07GTXde0QSmqHtse0FBcfxkUfTfoPaA/mzedh53ANB/6DE Cc: freebsd-current , Peter Jeremy Subject: Re: Use of C99 extra long double math functions after r236148 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 16:12:46 -0000 On Jul 14, 2012, at 3:24 AM, David Chisnall wrote: > On 13 Jul 2012, at 17:40, Warner Losh wrote: >=20 >> We shouldn't be gating the new math on an issue that only affects = sparc64 machines >=20 > Mostly agreed, but it's worth noting that the APCS for ARMv8[1] = specifies that long double should be IEEE 754- 2008 quad precision. I = think ARMv8 is going to be an important platform for us in the next few = years, so ld128 is not just for SPARC (I'd also like us to switch to = ld128 on PowerPC, since that's the ABI that everyone else uses, but I = don't anticipate PowerPC becoming tier 1 any time soon, whereas I would = very much like to see ARMv8 become tier 1 within a year of shipping = silicon). >=20 > That's not to say that we should hold things up waiting for ld128 = versions, just that adding ld128 versions soon after adding ld80 ones = would be very helpful. Agreed. My point was more "don't gate everything on the 128-bit = versions" not "hey, nobody do this, it is stupid." If the 128-bit = versions are ready at the same time as the 80-bit versions, so much the = better. Warner > David >=20 > [1] = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055a/IHI0055A_aapcs64= .pdf From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 17:01:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A70BE106566B; Sat, 14 Jul 2012 17:01:16 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 700FF8FC08; Sat, 14 Jul 2012 17:01:16 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8056766pbb.13 for ; Sat, 14 Jul 2012 10:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SZWV7xSUSiifW1jCUbelNQWaHyFCrr3m8GQXGWAQ0os=; b=L9Sh29SOFPfnWU/9H7JWAK6I3hr61QbzOspsPCBvioXnV06NI/qa+yQetbdNeNSuyr fnsiwiAB2BiZY90zDP/lkA2jkfu0YEwcTl06xNEHkdGmKl9nj0xKRMl40IVeQ5YFVYsB ITv5svFHDW6NtD/ZGsrC+5yXPP91zkP+xdnHua02x8WarWFUtHxapZ9mqgUiiBL01DqA Bmj7Gr06jIPB+3lbdKxJzxgWcJu/BDdkYE55/hWaf09hYY69kRUNMAVgNzvUDwGcC7JZ 42VcOEFF/CiGR4Xh4S8GWhhabnIlaiqKOOMI5tagpJRrI0JAlnPyCb0in7PcK2LHAQoQ zzcg== MIME-Version: 1.0 Received: by 10.66.81.106 with SMTP id z10mr10412805pax.26.1342285276001; Sat, 14 Jul 2012 10:01:16 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Sat, 14 Jul 2012 10:01:15 -0700 (PDT) In-Reply-To: References: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> Date: Sat, 14 Jul 2012 10:01:15 -0700 X-Google-Sender-Auth: ZAI8j_cPZpXgG7iLt1plTml3Qxg Message-ID: From: mdf@FreeBSD.org To: Justin Hibbits Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 17:01:16 -0000 On Sat, Jul 14, 2012 at 8:39 AM, Justin Hibbits wrote: > On Jul 13, 2012, at 12:20 AM, mdf@freebsd.org wrote: > >> On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits >> wrote: >>> >>> On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote: >>> >>>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits >>>> wrote: >>>>> >>>>> >>>>> When tracking down a panic exposed by INVARIANTS, I tried setting >>>>> DEBUG_MEMGUARD, so I could find the culprit that's trashing freed >>>>> memory. >>>>> However, this causes a panic at bootup. It shows up right after the >>>>> first >>>>> WARNING: WITNESS message, with the following: >>>>> >>>>> Tracing, and printf() debugging, I see arguments to vm_map_findspace(): >>>>> start: 0xD0000000, length: 4246446080, and map->max_offset = >>>>> 4026531839. >>>>> >>>>> Beyond that, I'm lost with tracking this down. Machine is a dual >>>>> processor >>>>> PowerPC G4, with 2GB RAM. >>>> >>>> >>>> >>>> The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of >>>> virtual space for 2GB of RAM sounds about right (it's been a while >>>> since I was in this code), unless this is a 32-bit kernel, in which >>>> case it'd be too much since there isn't that much virtual space >>>> available. >>>> >>>> So, is the kernel 32-bit? What are the values used and returned by >>>> memguard_fudge()? The intent of that routine is to get kmeminit() to >>>> allocate a larger map so memguard can use part of it for private >>>> virtual addresses. But it shouldn't be asking for "too much"; i.e. >>>> the intent was to check both physical and virtual space available and >>>> be greedy, but not too greedy. >>>> >>>> There were some issues with that code for some platforms that e.g. >>>> didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in r216425. >>> >>> >>> It is a 32-bit kernel, on 32-bit hardware. The values for memguard_fudge >>> are (defaults): >>> >>> tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0 >>> >>> When setting vm.kmem_size/vm.kmem_size_max to 2GB they are: >>> >>> tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max: 2147483648 >>> (all >>> 2GB). >>> >>> But the start and map->max_offset remain the same on all runs I make. >> >> >> memguard_fudge is still broken for 32-bit architectures with no >> vm_kmem_max. In the absence of a km_max to limit the value, we >> essentially use twice the physical memory for the virtual limit. But >> with 2GB on a 32-bit machine, this requires 4GB of virtual space. >> >> Setting vm_kmem_size_max to 2GB should work; I'd expect to see >> tmp=about 200MB, which is much larger than the input 112MB but the >> allocation should work. But I don't really know what else PowerPC has >> need of for virtual space, so that still could be too large. >> >> You can try smaller values of vm_kmem_size_max, like 1GB or 512MB. >> You shouldn't need to set vm_kmem_size at all. At some point the >> added space for the memguard_map will be small enough that the >> kmem_suballoc will work. >> >> Hmm, what is the min_offset and max_offset of kernel_map when the call >> to memguard_fudge is made? >> >> Thanks, >> matthew > > > > Without setting vm.kmem_size/vm.kmem_size_max, I see the following: > > map: 0x1000000, min_offset: 0xD0000000, max_offset: 0xEFFFFFFF > > It does boot when I set vm.kmem_size=256M/vm.kmem_size_max=512M. > > When I tried 512M/1024M, it panicked at the same place -- kmem_suballoc from > kmeminit. So it looks like I have to set vm.kmem_size/vm.kmem_size_max way > back in order for it to boot with memguard(9). I'll see about crafting a patch when I can get access to a machine that works (my current woes with my laptop, VM image, etc. are quite frustrating). The gist is that, in the absence of a kmem_max, the routine for determining the size of the kmem map should use the kernel_map's size as a limiting factor. In this case it looks like the map's size is 512MB. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 17:32:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2470106566B for ; Sat, 14 Jul 2012 17:32:39 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8B98FC08 for ; Sat, 14 Jul 2012 17:32:39 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 987B63B74C; Sat, 14 Jul 2012 17:32:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q6EHWVvO050249; Sat, 14 Jul 2012 17:32:31 GMT (envelope-from phk@phk.freebsd.dk) To: Marek Salwerowicz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 14 Jul 2012 15:00:35 +0200." <50016D73.3020902@wp.pl> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 14 Jul 2012 17:32:31 +0000 Message-ID: <50248.1342287151@critter.freebsd.dk> Cc: matt , freebsd-current@freebsd.org Subject: Re: Syscons issue Intel D2700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 17:32:39 -0000 In message <50016D73.3020902@wp.pl>, Marek Salwerowicz writes: >> I'm currently trying to boot an intel evaluation board (D2700) with >> Boot goes fine until the kernel is loaded. >> Once the kernel is loaded, boot continues, however only the very >> bottom line is showing kernel messages...the rest of the screen still >> "looks" like loader. Try the fix I committed in r237203+r237223, that was for a D2500CC which also had bogus VGA behaviour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 18:11:08 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC18210657C1 for ; Sat, 14 Jul 2012 18:11:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 490AB8FC0A for ; Sat, 14 Jul 2012 18:11:08 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6EIBB8i099749; Sat, 14 Jul 2012 21:11:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6EIAwOF057875; Sat, 14 Jul 2012 21:10:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6EIAwDL057874; Sat, 14 Jul 2012 21:10:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Jul 2012 21:10:58 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Message-ID: <20120714181058.GR2338@deviant.kiev.zoral.com.ua> References: <50016D73.3020902@wp.pl> <50248.1342287151@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f4dG/P76kr9Ksab9" Content-Disposition: inline In-Reply-To: <50248.1342287151@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: matt , Marek Salwerowicz , freebsd-current@freebsd.org Subject: Re: Syscons issue Intel D2700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 18:11:08 -0000 --f4dG/P76kr9Ksab9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 14, 2012 at 05:32:31PM +0000, Poul-Henning Kamp wrote: > In message <50016D73.3020902@wp.pl>, Marek Salwerowicz writes: >=20 > >> I'm currently trying to boot an intel evaluation board (D2700) with=20 >=20 > >> Boot goes fine until the kernel is loaded. > >> Once the kernel is loaded, boot continues, however only the very=20 > >> bottom line is showing kernel messages...the rest of the screen still= =20 > >> "looks" like loader. >=20 > Try the fix I committed in r237203+r237223, that was for a D2500CC > which also had bogus VGA behaviour. >=20 This should be merged for upcoming 9.1. --f4dG/P76kr9Ksab9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlABtjIACgkQC3+MBN1Mb4jnoACg62TIIk0J1rc4N6mO7oFY9/O3 T+kAoKrYEaUp05u+XauSeWRUqaqh3QQj =W6gE -----END PGP SIGNATURE----- --f4dG/P76kr9Ksab9-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 18:47:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55135106564A for ; Sat, 14 Jul 2012 18:47:13 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA188FC08 for ; Sat, 14 Jul 2012 18:47:12 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id AE9A43B74B; Sat, 14 Jul 2012 18:47:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q6EIlALh050575; Sat, 14 Jul 2012 18:47:10 GMT (envelope-from phk@phk.freebsd.dk) To: Konstantin Belousov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 14 Jul 2012 21:10:58 +0300." <20120714181058.GR2338@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 14 Jul 2012 18:47:10 +0000 Message-ID: <50574.1342291630@critter.freebsd.dk> Cc: matt , Marek Salwerowicz , freebsd-current@freebsd.org Subject: Re: Syscons issue Intel D2700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 18:47:13 -0000 In message <20120714181058.GR2338@deviant.kiev.zoral.com.ua>, Konstantin Belous ov writes: >> Try the fix I committed in r237203+r237223, that was for a D2500CC >> which also had bogus VGA behaviour. > >This should be merged for upcoming 9.1. I don't have a 9.1 machine I can test it on, so I have not planned to do a MFC. You're welcome to do so if you want/test. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 19:00:39 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC243106566B for ; Sat, 14 Jul 2012 19:00:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 563738FC0C for ; Sat, 14 Jul 2012 19:00:39 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6EIxwKB009385; Sat, 14 Jul 2012 21:59:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q6EIxiKq058103; Sat, 14 Jul 2012 21:59:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6EIxi6s058102; Sat, 14 Jul 2012 21:59:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Jul 2012 21:59:44 +0300 From: Konstantin Belousov To: Poul-Henning Kamp Message-ID: <20120714185944.GS2338@deviant.kiev.zoral.com.ua> References: <20120714181058.GR2338@deviant.kiev.zoral.com.ua> <50574.1342291630@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hRJ+CtUtsUVQl6Pn" Content-Disposition: inline In-Reply-To: <50574.1342291630@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: matt , Marek Salwerowicz , freebsd-current@freebsd.org Subject: Re: Syscons issue Intel D2700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 19:00:40 -0000 --hRJ+CtUtsUVQl6Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 14, 2012 at 06:47:10PM +0000, Poul-Henning Kamp wrote: > In message <20120714181058.GR2338@deviant.kiev.zoral.com.ua>, Konstantin = Belous > ov writes: >=20 > >> Try the fix I committed in r237203+r237223, that was for a D2500CC > >> which also had bogus VGA behaviour. > > > >This should be merged for upcoming 9.1. >=20 > I don't have a 9.1 machine I can test it on, so I have not planned to > do a MFC. You're welcome to do so if you want/test. Ok, will do. --hRJ+CtUtsUVQl6Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlABwaAACgkQC3+MBN1Mb4jWgACgojZTs+jFgmu+5953OdUwvExg 2yEAnikm8KIp219kB66iX16+RUJFOpwQ =4AJL -----END PGP SIGNATURE----- --hRJ+CtUtsUVQl6Pn-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 19:49:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED977106566B; Sat, 14 Jul 2012 19:49:26 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B46728FC08; Sat, 14 Jul 2012 19:49:26 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa07.fnfis.com (8.14.4/8.14.4) with ESMTP id q6EJnGT0011648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2012 14:49:16 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 14 Jul 2012 14:49:15 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <50013D3B.90206@cran.org.uk> Date: Sat, 14 Jul 2012 12:49:18 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> References: <50013D3B.90206@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-14_05:2012-07-13, 2012-07-14, 1970-01-01 signatures=0 Cc: Devin Teske , freebsd-current@freebsd.org, McDowell , Ron Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 19:49:27 -0000 On Jul 14, 2012, at 2:34 AM, Bruce Cran wrote: > On 14/07/2012 03:48, Devin Teske wrote: >> I'm [re-]announcing that (after much delay from the first announcement) = that I am finally importing bsdconfig(8) into HEAD. >=20 > I've noticed a couple of issues: >=20 > The welcome page mentions setting the root password and the time zone, bu= t bsdinstall will have already done that. >=20 The goal is to have bsdinstall drop those functionalities and instead link = to bsdconfig. > "...look at the 'Packages' item in this menu." and on the main page - "Mo= st importantly, you can use the Packages utility..." - I don't see a Packag= es entry in the menu. >=20 This will be added before MFC and before switching WITH_BSDCONFIG to WITHOU= T_BSDCONFIG. bsdconfig needs to replicate package installation because sysinstall had it= =85 but bsdconfig is going to use pkgng instead of the legacy tools. This w= ill greatly improve the abilities of the tool (you'll be able to perform re= mote package queries, etc. -- something you couldn't ever do in sysinstall). However, in order to build a more full-and-complete package management tool= based on pkgng, we needed the help of bapt (and he's agreed to help -- lat= er). Right now, bsdconfig and pkgng are maturing side-by-side without knowl= edge of each other. As they both slow down a bit, integration becomes a clo= ser reality and less of a moving target. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 20:06:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CD23106564A; Sat, 14 Jul 2012 20:06:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id 0E29F8FC0C; Sat, 14 Jul 2012 20:06:46 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 33718E656F; Sat, 14 Jul 2012 21:08:18 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=icytUlfndz5P ZECL5TtSaaFn/BI=; b=i2JOWRMG9COIhGPjhYUfdvqX9NYoLp9hxU0d7CkqI4il PyX+sD10Qr80M7o2UiE/9Acl7V32oZ91UJCkSvMBmC+x1gbLaHP98TzKUyA4lpzU P36hYLM4jvUw4L2vvTjKd2Af8N4LTlcuEiFcv+Gz4unW8UFlgdGUODsdIBJxSEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=cCs7Vj KF0WDq4BoRSEC4WECrRgNFbiN9kaJVSsCUGr7Xf8P8EEFzAQBwaoy/rYw75eGMHd /Npl47ScUn22kZybjkFdP0KFztxbx8MO19XF9tHaIviALRps/qkkV29DoL9m8ppP kZlISVed8HRYU0vbCFTynyCoLa4pbMOdcDC28= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 09DF1E6559; Sat, 14 Jul 2012 21:08:18 +0100 (BST) Message-ID: <5001D152.2050007@cran.org.uk> Date: Sat, 14 Jul 2012 21:06:42 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> In-Reply-To: <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ron McDowell , Devin Teske Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 20:06:46 -0000 On 14/07/2012 20:49, Devin Teske wrote: > The goal is to have bsdinstall drop those functionalities and instead link to bsdconfig. Won't that mean it'll be possible to end up with an installation without a root password set? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 20:17:55 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78AE7106564A; Sat, 14 Jul 2012 20:17:55 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3D5088FC15; Sat, 14 Jul 2012 20:17:55 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with ESMTP id q6EKHqCo030855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2012 15:17:52 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 14 Jul 2012 15:17:51 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <5001D152.2050007@cran.org.uk> Date: Sat, 14 Jul 2012 13:17:53 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-14_05:2012-07-13, 2012-07-14, 1970-01-01 signatures=0 Cc: Devin Teske , McDowell , Ron, freebsd-current@freebsd.org Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:17:55 -0000 On Jul 14, 2012, at 1:06 PM, Bruce Cran wrote: > On 14/07/2012 20:49, Devin Teske wrote: >> The goal is to have bsdinstall drop those functionalities and instead li= nk to bsdconfig. >=20 > Won't that mean it'll be possible to end up with an installation without = a root password set? >=20 No. The implication is that bsdconfig and bsdinstall will forever live side-by-= side once linked together. That includes having bsdconfig live on the insta= llation media so that bsdinstall can utilize it during the installation to = (among other things) set the root password. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 20:31:59 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B74E81065679; Sat, 14 Jul 2012 20:31:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7A68FC0C; Sat, 14 Jul 2012 20:31:59 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8264744pbb.13 for ; Sat, 14 Jul 2012 13:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+/JiRjGhxHA2qkugoDiNTUDYi040/J2u8QxRYq7Hoco=; b=l1hbKAvgTDzca/UDRGqQDCHfwkTZcoubtVAZjUg6Mays992mT61lkUuyPc7owT/rXa wrqarsM4wI4lBfUloskfC6EbIDWfpYeSIqzUbvOnP+4bGWMpVkwt/WWUTIC/5e6faJyg +h0E4F6wt+KxRaavhQuSA7KkPsfkHKOBGV99PfADRSBxmV9ml0D3Ur8hvQ/qKYByM+Hl CTlC0fzWJNqryOJe4TPlzDXkbUnT8RPOfj28bPAU6hnVk8h0j1eOcXXpmcLUXPT2OlFi KelEFREvefwmSC96LpFYlYpPY2LvSLEXdxmsJWYXvNMG67NcryBWRugajpvlqb6KRb9Y UzUQ== MIME-Version: 1.0 Received: by 10.68.220.193 with SMTP id py1mr14004419pbc.4.1342297919238; Sat, 14 Jul 2012 13:31:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.195.102 with HTTP; Sat, 14 Jul 2012 13:31:59 -0700 (PDT) In-Reply-To: <201207141243.q6EChYAf016055@freebsd-current.sentex.ca> References: <201207141243.q6EChYAf016055@freebsd-current.sentex.ca> Date: Sat, 14 Jul 2012 13:31:59 -0700 X-Google-Sender-Auth: -9IRIG6sN2ONZQOJ9eXU5eD_MRg Message-ID: From: Adrian Chadd To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 20:31:59 -0000 This, like the others, has been fixed. Adrian On 14 July 2012 05:43, FreeBSD Tinderbox wrote: > TB --- 2012-07-14 09:20:00 - tinderbox 2.9 running on freebsd-current.sen= tex.ca > TB --- 2012-07-14 09:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PREREL= EASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebs= d-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2012-07-14 09:20:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2012-07-14 09:20:00 - cleaning the object tree > TB --- 2012-07-14 09:20:00 - cvsupping the source tree > TB --- 2012-07-14 09:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2012-07-14 09:22:34 - building world > TB --- 2012-07-14 09:22:34 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-07-14 09:22:34 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-07-14 09:22:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-07-14 09:22:34 - SRCCONF=3D/dev/null > TB --- 2012-07-14 09:22:34 - TARGET=3Damd64 > TB --- 2012-07-14 09:22:34 - TARGET_ARCH=3Damd64 > TB --- 2012-07-14 09:22:34 - TZ=3DUTC > TB --- 2012-07-14 09:22:34 - __MAKE_CONF=3D/dev/null > TB --- 2012-07-14 09:22:34 - cd /src > TB --- 2012-07-14 09:22:34 - /usr/bin/make -B buildworld >>>> World build started on Sat Jul 14 09:22:34 UTC 2012 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> stage 5.1: building 32 bit shim libraries >>>> World build completed on Sat Jul 14 12:35:46 UTC 2012 > TB --- 2012-07-14 12:35:46 - generating LINT kernel config > TB --- 2012-07-14 12:35:46 - cd /src/sys/amd64/conf > TB --- 2012-07-14 12:35:46 - /usr/bin/make -B LINT > TB --- 2012-07-14 12:35:46 - cd /src/sys/amd64/conf > TB --- 2012-07-14 12:35:46 - /usr/sbin/config -m LINT > TB --- 2012-07-14 12:35:46 - building LINT kernel > TB --- 2012-07-14 12:35:46 - CROSS_BUILD_TESTING=3DYES > TB --- 2012-07-14 12:35:46 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2012-07-14 12:35:46 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-07-14 12:35:46 - SRCCONF=3D/dev/null > TB --- 2012-07-14 12:35:46 - TARGET=3Damd64 > TB --- 2012-07-14 12:35:46 - TARGET_ARCH=3Damd64 > TB --- 2012-07-14 12:35:46 - TZ=3DUTC > TB --- 2012-07-14 12:35:46 - __MAKE_CONF=3D/dev/null > TB --- 2012-07-14 12:35:46 - cd /src > TB --- 2012-07-14 12:35:46 - /usr/bin/make -B buildkernel KERNCONF=3DLINT >>>> Kernel build for LINT started on Sat Jul 14 12:35:47 UTC 2012 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies >>>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc = -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEAD= ERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-= unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-func= tions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel= =3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-u= nwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilog= ue /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc = -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEAD= ERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-= unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-func= tions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel= =3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-u= nwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilog= ue /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc = -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEAD= ERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-= unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-func= tions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel= =3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-u= nwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilog= ue /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc = -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEAD= ERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-= unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-func= tions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel= =3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-u= nwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilog= ue /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc = -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEAD= ERS -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-= unit-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-func= tions=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel= =3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-u= nwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilog= ue /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath > cc1: warnings being treated as errors > /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_recv_tasklet': > /src/sys/dev/ath/if_ath_rx_edma.c:450: warning: unused variable 'ic' [-Wu= nused-variable] > *** Error code 1 > > Stop in /obj/amd64.amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2012-07-14 12:43:34 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2012-07-14 12:43:34 - ERROR: failed to build LINT kernel > TB --- 2012-07-14 12:43:34 - 8259.34 user 1299.45 system 12214.09 real > > > http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full > _______________________________________________ > 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 Jul 14 20:52:25 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95FF8106566B; Sat, 14 Jul 2012 20:52:25 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1C12E8FC08; Sat, 14 Jul 2012 20:52:21 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 2CAD8E656F; Sat, 14 Jul 2012 21:53:54 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=YSyM0lZqEZpj 8WgD08KjN63LarA=; b=l4OelAHeyt0wMC0e6kkeiDXBSVt/nW5WklyidqKW/CPm Nigd8k6yDVzrgJG+A6lS8LPzXQHMQ3cj59AT3VWk4se6wT3WbMft0Bhq27zpD2bi 33EJPar3MUS1NjPGAUwp0xMPnhvGEilt3Armje0ZxPh3EtDe1gaPwqAqe4+Crtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=btso1N 86Q3g5xDjN10gkRdBB1M/A75Diwc//qqXZQlUAyflOSMtzKUa7bdlib0GAhqaCeL zf639lptH7FmAgOuVXGiwb2EAzyEg46tpncdidx7iPfLbFSjKv/NQEQ99J4HselW t++sx5QpU7sVwtxnxFgL6UBoXEmDwm/jNzI7Y= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id EF6ACE6559; Sat, 14 Jul 2012 21:53:53 +0100 (BST) Message-ID: <5001DC03.6010705@cran.org.uk> Date: Sat, 14 Jul 2012 21:52:19 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron@FreeBSD.ORG, McDowell , Devin Teske , freebsd-current@freebsd.org Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 20:52:25 -0000 On 14/07/2012 21:17, Devin Teske wrote: > The implication is that bsdconfig and bsdinstall will forever live side-by-side once linked together. That includes having bsdconfig live on the installation media so that bsdinstall can utilize it during the installation to (among other things) set the root password. Doesn't that mean that bsdconfig would be invoked as "bsdconfig password" which would bypass the welcome screen and so by the time the user does see it the root password (and timezone) will have been set? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 21:07:23 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A437106566C; Sat, 14 Jul 2012 21:07:23 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id E16A88FC0A; Sat, 14 Jul 2012 21:07:22 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with ESMTP id q6EL7IVk011089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2012 16:07:19 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 14 Jul 2012 16:07:17 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <5001DC03.6010705@cran.org.uk> Date: Sat, 14 Jul 2012 14:07:21 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> <5001DC03.6010705@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-14_05:2012-07-13, 2012-07-14, 1970-01-01 signatures=0 Cc: Ron@FreeBSD.ORG, Devin Teske , McDowell , freebsd-current@freebsd.org Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:07:23 -0000 On Jul 14, 2012, at 1:52 PM, Bruce Cran wrote: > On 14/07/2012 21:17, Devin Teske wrote: >> The implication is that bsdconfig and bsdinstall will forever live side-= by-side once linked together. That includes having bsdconfig live on the in= stallation media so that bsdinstall can utilize it during the installation = to (among other things) set the root password. >=20 > Doesn't that mean that bsdconfig would be invoked as "bsdconfig password"= which would bypass the welcome screen and so by the time the user does see= it the root password (and timezone) will have been set? >=20 No. In 8.x, when you're performing the guided install, will prompt you to set t= he root password among many other things. At the very end, it prompts you a= s to whether you'd like to visit the configuration menu one more time. In 9.x and higher, bsdinstall (taking the place of sysinstall) in a similar= manner asks you to set the root password among many other things, but does= not ask you if you'd like to visit the configuration menu one more time (b= ecause there isn't one). So think of it this way=85 bsdinstall has these functionalities but no menu= to invoke them. By removing these functionalities from bsdinstall and instead using bsdconf= ig for these functionalities, the scenario now becomes=85 bsdinstall asks to set the root password (by either executing "bsdconfig pa= ssword" -- in which a transition is only noticeable because the --backtitle= changes from "FreeBSD Installer" to "bsdconfig" -- or bsdinstall could ins= tead include /usr/libexec/bsdconfig/040.password/include/password.subr and = call the f_dialog_input_password() function where it can control --backtitl= e to make the usage even more seemless; making bsdconfig's functionality lo= ok like bsdinstall's). After asking to set the root password, bsdinstall ca= n now (like sysinstall) ask the user if they'd like to visit the configurat= ion menu one last time to make any additional changes (and bsdconfig -- no = arguments -- would provide that menu). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 21:46:28 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD97E106564A; Sat, 14 Jul 2012 21:46:28 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 6D9D48FC0A; Sat, 14 Jul 2012 21:46:28 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id DFF6BE656F; Sat, 14 Jul 2012 22:48:00 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=2pmaPtv/zrZ+ 0mSGf5J/COILaL4=; b=Sg2DTiR4RV5chJaD1rCnOxZK1T5HNd4ki/noDkGJyrKG Yi0G3mBySz7d1wOEVzWXm9L3G0DQK7mKRNx21NMnupMul4QXBF/uxR1fBMgJLea/ YP8p8/X3O6DYdeGkDnu2VO22Ier/8r9YwBGxXPaFGxMXcmnqPI7FSQDFYbZZKQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=jUXAye yHp5fiQEunzfxgJgFnRxK4AEeiGwKQ5HO6gxgI2j8kLeavjhrMDJ4s/ttIqg8V+L PNWnE6yL5YWhpToXFlOOgu79lEGG8W+4TERMKHFJjEd01ozO5UXqt9XA3OMHubp/ kTC/uTe6cFmQPdyrDNV+uYsjG8xu7rq+9Pm0k= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id B0584E6559; Sat, 14 Jul 2012 22:48:00 +0100 (BST) Message-ID: <5001E8B2.8010803@cran.org.uk> Date: Sat, 14 Jul 2012 22:46:26 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> <5001DC03.6010705@cran.org.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ron McDowell , Devin Teske Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 21:46:28 -0000 On 14/07/2012 22:07, Devin Teske wrote: > bsdinstall asks to set the root password (by either executing "bsdconfig password" -- in which a transition is only noticeable because the --backtitle changes from "FreeBSD Installer" to "bsdconfig" -- or bsdinstall could instead include /usr/libexec/bsdconfig/040.password/include/password.subr and call the f_dialog_input_password() function where it can control --backtitle to make the usage even more seemless; making bsdconfig's functionality look like bsdinstall's). After asking to set the root password, bsdinstall can now (like sysinstall) ask the user if they'd like to visit the configuration menu one last time to make any additional changes (and bsdconfig -- no arguments -- would provide that menu). You forgot to explain the 'express' mode that bypasses the "bsdconfig password" step. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 21:58:27 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C81E8106564A; Sat, 14 Jul 2012 21:58:27 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 89F578FC08; Sat, 14 Jul 2012 21:58:27 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.4/8.14.4) with ESMTP id q6ELwMVf030687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2012 16:58:22 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 14 Jul 2012 16:58:22 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <5001E8B2.8010803@cran.org.uk> Date: Sat, 14 Jul 2012 14:58:25 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> <5001DC03.6010705@cran.org.uk> <5001E8B2.8010803@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-14_05:2012-07-13, 2012-07-14, 1970-01-01 signatures=0 Cc: Devin Teske , Ron McDowell , freebsd-current@freebsd.org Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 21:58:27 -0000 On Jul 14, 2012, at 2:46 PM, Bruce Cran wrote: > On 14/07/2012 22:07, Devin Teske wrote: >> bsdinstall asks to set the root password (by either executing "bsdconfig= password" -- in which a transition is only noticeable because the --backti= tle changes from "FreeBSD Installer" to "bsdconfig" -- or bsdinstall could = instead include /usr/libexec/bsdconfig/040.password/include/password.subr a= nd call the f_dialog_input_password() function where it can control --backt= itle to make the usage even more seemless; making bsdconfig's functionality= look like bsdinstall's). After asking to set the root password, bsdinstall= can now (like sysinstall) ask the user if they'd like to visit the configu= ration menu one last time to make any additional changes (and bsdconfig -- = no arguments -- would provide that menu). >=20 > You forgot to explain the 'express' mode that bypasses the "bsdconfig pas= sword" step. >=20 Did I? When one starts discussing 'Express Install', we're clearly in the r= ealm of bsdinstall, not bsdconfig. Like you stated, in that case bsdinstall would not use bsdconfig. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 22:00:20 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444A9106564A for ; Sat, 14 Jul 2012 22:00:20 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F23B38FC14 for ; Sat, 14 Jul 2012 22:00:19 +0000 (UTC) Received: by obbun3 with SMTP id un3so8682550obb.13 for ; Sat, 14 Jul 2012 15:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=X2DAdbzmV9cACqT/4bgxKPtCIMpyS98Sv0SrTTdpFLQ=; b=rkO/2pxWzAe1v1X1KRELqXOM9seqDrNFiJGS2B8uI697qnZCtYw9wIXXo2/k03hO/p zF+9iWq/90obfeKcUwQhheX7F+zIv8Vu2AUIrEF54fPCGcIpZVHdkFJlgRIyPIhOYbNG lQMJdQUkyrvmJN6AdQHQP83OJ5a/85Mhc/qH9199Lt52IcKnx8FDwGxpEStpvg7UFY2V F7q3XDbg5FHAKlJs6sn7daJt3VRU0sTVtW6eqQewnvBDbDHnNktm8nZKAPAY2UMNUAN3 CZ6D1+bs4HBTtubzd0KkW0faayUay5c/lRPki5IhSLgDzsONfiqPAh9hY1L8B7DqejtM MU1Q== MIME-Version: 1.0 Received: by 10.182.49.7 with SMTP id q7mr8212669obn.68.1342303219372; Sat, 14 Jul 2012 15:00:19 -0700 (PDT) Received: by 10.182.32.234 with HTTP; Sat, 14 Jul 2012 15:00:19 -0700 (PDT) Date: Sun, 15 Jul 2012 01:00:19 +0300 Message-ID: From: Alexander Yerenkow To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Subject: Fstab file path X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 22:00:20 -0000 Hello all. I'm trying to get single-world in read-only and multi-userland media and I get difficulties with path "/etc/fstab" been hardcoded and there is no way for override it. I'm talking about getrootmount in sys/boot/common/boot.c:315 Could we elaborate a bit this moment? What I'm trying to do is to get one single partition, with installed world+kernel; let's call it rootPT and also I have few partitions for mount to /usr/local and to /var, like localA, varA, localB, varB, etc. Main difficulty is that "fstab" path is hardcoded, and it searched in subdir of root partition, and I can't specify it in any way in stock FreeBSD. How about have one more env with path to fstab (like vfs.root.mountfrom, but with vfs.fstab.filepath, which checks, and if it's null falling back to default hard-coded one)? Note, that this will not change some default standards or behaviors, it will just add some flexibility. Currently, to make media as I need, I would need several absolutely same filesystems on different partitions, just to separate fstabs (As a result - duplication of world/kernel, or I end up with complex root system with many links). With ability to set path to fstab, I would need only edit loader.conf and restart system into new setup. Also, I noticed that fstab.c is implemented way for specifying different fstab (maybe just for editing?...). But there's also relatively lot of other scripts which used hardcoded fstab path too. Now I'm thinking that I'll end up with writing handy script which will override /etc/fstab just before reboot :) I just thought that lack of flexibility in this point could be interesting for someone. -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 22:09:24 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB00106566B; Sat, 14 Jul 2012 22:09:24 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA4AF8FC15; Sat, 14 Jul 2012 22:09:24 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 5C73A686E; Sat, 14 Jul 2012 22:09:18 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 22ECB8F29; Sun, 15 Jul 2012 00:09:18 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Justin T. Gibbs" References: Date: Sun, 15 Jul 2012 00:09:17 +0200 In-Reply-To: (Justin T. Gibbs's message of "Fri, 13 Jul 2012 16:14:17 -0600") Message-ID: <86obnif10y.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@FreeBSD.org Subject: Re: PAM passwdqc, strict aliasing, and WARNS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 22:09:25 -0000 "Justin T. Gibbs" writes: > Someone who has yet to confess added -Werror to the global CFLAGS > (via /etc/make.conf) for one of our systems at work. Before I > figured out that this was the cause of builds failing, I hacked up > pam_passwdc to resolve the problem. This gets the module to > WARNS=3D2, but to go farther, the "logically const" issues with this > code will need to be sorted out. > > Is this change worth committing? Is this the best way to resolve > the strict aliasing issues in this code? I really don't like that sort of game. If you look at other PAM consumer code, you'll see that the common idiom is what Jilles suggested, i.e. use a temporary variable of the appropriate type. That being said, pam_passwdqc should probably be either updated or removed. The version we have is ten years old. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 22:33:02 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31FA81065670; Sat, 14 Jul 2012 22:33:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [93.89.92.64]) by mx1.freebsd.org (Postfix) with ESMTP id D4AA98FC0A; Sat, 14 Jul 2012 22:33:01 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 131BEE656F; Sat, 14 Jul 2012 23:34:34 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=Yabu00tuXyfW xBpYCW8NCWOfd6U=; b=vPB/yNIXu6PnusBuDjpOybV3pbdc8zcFG36IDC/ZeJYr MC6+7xX7GDyuiqAEN5IZHs3HSHSIWfox+eNBtVuoxISDQFwOutiE1c93nw9iiORt pFiQlNxuFlBSFAEqleAcNQu2Xgx7iAv1Q8eV6WDaKTFzb7FjC2UZZX6JzRz7ycs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=yXwkTI CuN3bdETAn6G+4bC/10mL5deadEtC0n3zmEDHEu62nIqwDUkWdsD7bf7hGiJk7K9 gq3Lr3iRaQJCgOOcNlQwlpBwZeG+vpQZIMkoUSl+k0A60FYdCEL2XDQXtqu7L3oL Zc1Nb5BAFF3xy8a9i87HWK9dIkV3z6FqzWiow= Received: from [192.168.2.11] (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id DC559E6559; Sat, 14 Jul 2012 23:34:33 +0100 (BST) Message-ID: <5001F39B.4010403@cran.org.uk> Date: Sat, 14 Jul 2012 23:32:59 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Devin Teske References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> <5001DC03.6010705@cran.org.uk> <5001E8B2.8010803@cran.org.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ron McDowell , Devin Teske Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 22:33:02 -0000 On 14/07/2012 22:58, Devin Teske wrote: > Did I? When one starts discussing 'Express Install', we're clearly in the realm of bsdinstall, not bsdconfig. > > Like you stated, in that case bsdinstall would not use bsdconfig. I'm getting really confused here. Either "bsdconfig password" gets run before the post-install configuration menu is shown and therefore the text saying to set the root password in the welcome screen is unnecessary, or it doesn't get run and it's possible to quit bsdconfig without setting the root password. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 23:04:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99823106564A; Sat, 14 Jul 2012 23:04:16 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0B58FC0A; Sat, 14 Jul 2012 23:04:15 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q6EN4Bul019353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2012 18:04:11 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 14 Jul 2012 18:04:10 -0500 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <5001F39B.4010403@cran.org.uk> Date: Sat, 14 Jul 2012 16:04:13 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <50013D3B.90206@cran.org.uk> <04E88813-2416-4B60-93D3-D620DBE5A8AF@fisglobal.com> <5001D152.2050007@cran.org.uk> <5001DC03.6010705@cran.org.uk> <5001E8B2.8010803@cran.org.uk> <5001F39B.4010403@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1257) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-07-14_05:2012-07-13, 2012-07-14, 1970-01-01 signatures=0 Cc: Devin Teske , Ron McDowell , freebsd-current@freebsd.org Subject: Re: [IMPORT] bsdconfig(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 23:04:16 -0000 On Jul 14, 2012, at 3:32 PM, Bruce Cran wrote: > On 14/07/2012 22:58, Devin Teske wrote: >> Did I? When one starts discussing 'Express Install', we're clearly in th= e realm of bsdinstall, not bsdconfig. >>=20 >> Like you stated, in that case bsdinstall would not use bsdconfig. >=20 > I'm getting really confused here. Either "bsdconfig password" gets run be= fore the post-install configuration menu is shown and therefore the text sa= ying to set the root password in the welcome screen is unnecessary, or it d= oesn't get run and it's possible to quit bsdconfig without setting the root= password. >=20 Ok, it's more clear to me that the concern is with the welcome screen. 1. The welcome screen _text_ was ripped straight from sysinstall except wit= h one difference=85 s/Pascal/Firefox/ (updating it for the current generati= ons). 2. Currently this text is shoved in your face but it won't always be. The t= ext will be moved to a "Help" screen. So, in a way you're absolutely right=85 you've highlighted a conundrum (the= welcome screen contains text which is not suitable for a welcome screen) b= ecause bsdinstall did something differently than sysinstall in this one cas= e (reasons below; solution above -- get rid of the welcome screen). The reason why we (Ron and I) chose to not implement the help-text in the s= ame way that sysinstall does (go to the "Configure" top-level menu and then= press F1) is that bsdconfig strives to be compatible with both dialog(1) a= nd [purported drop-in replacement] Xdialog(1) -- and the latter doesn't sup= port hooking into F1. However, it's agreed that the welcome screen is not the right way to re-imp= lement the configure.help file from sysinstall (actually rescuing _all_ of = the *.help files from the clutches of the Attic -- further internationalizi= ng them in the process too). The envisioned construct right now is to add a third button labeled "Help".= This can be done in both dialog(1) and Xdialog(1) (see "bsdconfig startup_= rcconf" and the "Details" button -- except instead of dangling a menu off o= f it, it will produce a box with the desired help-text. Of course, making this scalable and usable is a challenge so we haven't yet= migrated away from the welcome screen before the import to HEAD. It will be dealt with before MFC and also before WITH_BSDCONFIG becomes WIT= HOUT_BSDCONFIG. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 23:28:07 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B65A81065674 for ; Sat, 14 Jul 2012 23:28:07 +0000 (UTC) (envelope-from bsd-src@helfman.org) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id F16068FC0C for ; Sat, 14 Jul 2012 23:28:06 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1829882wgb.31 for ; Sat, 14 Jul 2012 16:28:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KAfnFwx9FkMNvQup2B8RlMJin9kXpMNQFFFyXIDl6lo=; b=L0EhxLnswVWcd/F0OsHYVQEh3JvOFDbTFtC11dY5zh0tZ0PpSjQlN+CrznSugeXQCX cYHQtmohxkwY6qxmlGV+34BSYBjY89pWDzgiyf8ltDVwslr0kaF/JK/xVDtJNeVMe/Oz cQHq0XubkXAHit3y+yDHKt0deDad8YxAqsh5YGG/Hyr0R7+klZLFb49s9UoCoHPNDJZ3 j7guSMRqiDbaPL/ocnKaLVCWncqr5YAFoDbnj3ZXQYgbF0+lP/+mGS3QJqLeLoMRqP5Y Dp94mKMowQXmWANH0t/O08mYRJR/08hD5RyJzN+3qEzJHr4J/ywl7g/oeA6uKGsg1fF5 ZceA== MIME-Version: 1.0 Received: by 10.216.36.71 with SMTP id v49mr3109950wea.70.1342308485711; Sat, 14 Jul 2012 16:28:05 -0700 (PDT) Sender: bsd-src@helfman.org Received: by 10.194.45.133 with HTTP; Sat, 14 Jul 2012 16:28:05 -0700 (PDT) In-Reply-To: References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <4FFF1C09.2020408@FreeBSD.org> <20120712220207.GD49382@ithaqua.etoilebsd.net> <4FFF5983.3010708@FreeBSD.org> <4FFFD944.1030005@ranner.eu> <5000113D.2000004@a1poweruser.com> Date: Sat, 14 Jul 2012 16:28:05 -0700 X-Google-Sender-Auth: DvXK1jOJTx0wuKSij22RgwEAt0I Message-ID: From: Jason Helfman To: Peter Wemm X-Gm-Message-State: ALoCoQmj4edPIaK5fud6WebbedoYdh9nAFCQRiDrn/aAo6P04nOK446jH5ip7DWau8TBubYyq9UZ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, Fbsd8 , current@freebsd.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 14 Jul 2012 23:28:07 -0000 On Fri, Jul 13, 2012 at 1:41 PM, Peter Wemm wrote: > On Fri, Jul 13, 2012 at 5:14 AM, Fbsd8 wrote: > > What I want to know is this new pkg system going to remove the > requirement > > of having the complete ports tree on my system? > > > > What I am looking for in an port system, is to install a port and any > files > > needed for the parent port and its dependents to automatically be > > downloaded. So in the end my system ports tree only contain the files > used > > to install the ports I use and their dependents. > > That is precisely what pkgng is for. > > At the risk of over-simplifying: > * Generally eliminate the need for having /usr/ports installed for end > user consumers of freebsd if you have no desire to compile ports with > custom options. > * Generally eliminate the need for layers over the top of pkg* like > portupgrade/portmaster/portmanager for those people. > * Play nicely with people who *are* building some (or all) of their > packages from /usr/ports. > * Provide enough look and feel compatibility with the old pkg_* tools > so people will feel enough at home. > * Assimilate an existing pkg_* machine. > * Store complete metadata so that going foward we have much better > support for package sets - eg: package repositories with custom > options that play nicely with official packages. > * Be extensible so that we can add to it as we go forward. > > In the new world order, things like portupgrade and portmanager tend > to be used to manage interactions between personally build ports from > /usr/ports and external binary packages. If you continue to build > from /usr/ports, the only thing that changes is bsd.port.mk uses a > different command to register a package and you still use > portupgrade/portmaster/whatever to orchestrate your personal package > rebuilding. (Well, portmaster does if you apply the simple patch to > it). > > pkg-1.0 is primarily an infrastructure change. Instead of metadata > being stored in discrete +FOO and +BAR files in a .tgz file, it is > stored in a structured, extensible file. Instead of an incomplete set > of metadata being stored in /var/db/pkg/* and having to be augmented > by reaching over to /usr/ports/*, a full set of data is stored in a > .sqlite file. Instead of version numbers being baked into the package > name as an ascii string, the package system uses version numbers as > first class metadata. > > In reality, not much will change at the switch throwing, except that > of having good reason to be afraid of "pkg_add -r", you'll be able to > reasonably expect it's replacement (pkg install) to work. And a bunch > of people who have a /usr/ports tree will suddenly wonder why they > even have it there at all. It becomes incredibly convenient and fast > to use packages. > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; > KI6FJV > "All of this is for nothing if we don't go to the stars" - JMS/B5 > "If Java had true garbage collection, most programs would delete > themselves upon execution." -- Robert Sewell > > I am by no means speaking for the pkgng direction, goal or for portmgr, but I thought that this thread message spoke to the goal pretty clearly for me. http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/076395.html If this is in fact the case, I don't know if this is documented anywhere. -jgh -- Jason Helfman | FreeBSD Committer jgh@FreeBSD.org | http://people.freebsd.org/~jgh