From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 02:03:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52BCC7D1; Sun, 21 Sep 2014 02:03:28 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 219FC7EE; Sun, 21 Sep 2014 02:03:24 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-253-99.lns20.per2.internode.on.net [121.45.253.99]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8L23Ig3026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 19:03:21 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <541E31E0.8020108@freebsd.org> Date: Sun, 21 Sep 2014 10:03:12 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org Subject: Re: libthr and main thread stack size References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> In-Reply-To: <5242716.s4iaScq0Bu@ralph.baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , deischen@FreeBSD.ORG, "Ivan A. Kosarev" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 02:03:28 -0000 On 9/20/14, 3:27 AM, John Baldwin wrote: > On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: >> On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: >>> On Aug 8, 2014, at 5:22 AM, Konstantin Belousov >>> wrote: >>> >>> ? >>> >>>> Below is the patch which adds environment variable >>>> LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the >>>> main thread stack left as is, and other threads allocate stack >>>> below the area of RLIMIT_STACK. Try it. I do not want to set this >>>> behaviour as default. >>> Is there a reason this should not be the default? Looking at the >>> getrlimit() page on the OpenGroup?s site they say: >>> >>> RLIMIT_STACK This is the maximum size of the initial thread's stack, >>> in bytes. The implementation does not automatically grow the stack >>> beyond this limit. If this limit is exceeded, SIGSEGV shall be >>> generated for the thread. If the thread is blocking SIGSEGV, or the >>> process is ignoring or catching SIGSEGV and has not made arrangements >>> to use an alternate stack, the disposition of SIGSEGV shall be set to >>> SIG_DFL before it is generated. >>> >>> Does posix say something different? >>> >>> I ran into this issue when debugging a segfault on Postgres when >>> running an (arguably quite bogus) query that should have fit within >>> both the configured stack rlimit and Postgres? configured stack limit. >>> The Postgres backend is really just single threaded, but happens >>> to pull in libpthread due to the threading support in some of the >>> libraries it uses. The segfault definitely violates POLA. >>> >>> ? Justin >> I am conservative to not disturb the address space layout in single go. >> If enough people test this setting, I can consider flipping the default >> to the reverse. >> >> I am still curious why the things were done in this way, but nobody >> replied. > I suspect it was done out of reasons of being overly conservative in > interpreting RLIMIT_STACK. I think it is quite surprising behavior though and > would rather we make your option the default and implement what the Open Group > says above. > that is my memory.. The transition from a non threaded app to a threaded app with one thread is sort of an undefined area. Feel free to change it if Dan agrees.. From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 02:37:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1E5BAE6; Sun, 21 Sep 2014 02:37:20 +0000 (UTC) Received: from smtpout1.timeweb.ru (smtpout1.timeweb.ru [92.53.117.15]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 740F0A31; Sun, 21 Sep 2014 02:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=amdmi3.ru; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Y0igZex+hKXf6qkDtloAIwRdedPIWWMnJtnQ3Fax+Do=; b=RwPptpemFd6/NACQUgzvlrUM8xHNSI1da2sxA78DnV0AMGrhTHWwuOFOADmersV3fBxHgZPwzxFmPHM1y9Pf7+N2oOnYgoApIcOsDb6uW76OPRk6VjUc/nU4n8funpH8tlLACuFBP+naSc+r8xS3dO5ghBidhQYhe5dBQMFf0c0=; Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XVX1R-000422-H8; Sun, 21 Sep 2014 06:37:09 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 0140D102; Sun, 21 Sep 2014 06:37:08 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id E0B9E3D37; Sun, 21 Sep 2014 06:37:08 +0400 (MSK) Date: Sun, 21 Sep 2014 06:37:08 +0400 From: Dmitry Marakasov To: Maxim V FIlimonov Subject: Re: FreeBSD-11.0-CURRENT on ARM: performance and load average Message-ID: <20140921023708.GA29778@hades.panopticon> References: <7351653.A2UeEk9AA3@quad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7351653.A2UeEk9AA3@quad> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 02:37:20 -0000 * Maxim V FIlimonov (che@bein.link) wrote: > Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 > to be precise). The problem was that the load average was above 2. Including > the fact that the board has 2 CPU cores, that's strange. Also, the network > throughput was way too slow: from 3 kilobytes per second earlier to 20..50 > about now. > > Here's a workaround for that: > > sysctl kern.eventtimer.periodic=1 > With that, the network performance increased while LA decreased to a decent > 0.3..0.5. I'm just started to experiment with cubieboard (1) as well. I've also noticed poor network performance at first, however later (without any tuning) it gave out 111 kBps. kern.eventtimer.periodic doesn't seem to affect it. I've also played with clocks a bit, and was able to increase CPU rate 3x by configuring PLL1. I've experienced some instability later (board doesn't always boot from USB, perl build fails), and now I'm checking if reclocking was the cause. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 02:54:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFAC2C83 for ; Sun, 21 Sep 2014 02:54:24 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68185B8C for ; Sun, 21 Sep 2014 02:54:24 +0000 (UTC) Received: from fortune.joker.local (180-198-225-68.nagoya1.commufa.jp [180.198.225.68]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id s8L1vlJ8061364 for ; Sun, 21 Sep 2014 10:57:48 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 21 Sep 2014 10:57:46 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-Id: <20140921105746.ab225e27e03d1cbdea6b41d8@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 02:54:24 -0000 Hi. Very preliminary question, but not mentioned before if I haven't missed it. Have you disabled Optimus? If not, you need to disable it (or definately select nvidia discrete GPU) in BIOS / UEFI firmware, as currently any version of nvidia proprietary driver for FreeBSD does NOT support Optimus. Please read /usr/local/share/doc/NVIDIA_GLX-1.0/README for detail. (The location could be different if you installed nvidia driver WITHOUT using ports nor pkg.) At least, my ThinkPad T420 has an option to select Optimus / internal intel GPU / nvidia discrete GPU, and I need to select nvidia discrete GPU to use x11/nvidia-driver. Sat Sep 20 23:11:54 UTC 2014 O. Hartmann wrote: >Am Sat, 20 Sep 2014 21:21:46 +0200 >Koop Mast schrieb: > >> On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: >> > Am Sat, 20 Sep 2014 19:15:30 +0200 >> > "O. Hartmann" schrieb: >> > >> > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) >> > > Warren Block schrieb: >> > > >> > > > On Sat, 20 Sep 2014, O. Hartmann wrote: >> > > > >> > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) >> > > > > Warren Block schrieb: >> > > > > >> > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: >> > > > >> >> > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems >in FreeBSD >> > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on >Lenovo >> > > > >>> ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with >integrated HD4600 >> > > > >>> Intel iGPU and dedicated nVidia GT 740M (Optimus) working >correctly. >> > > > >> >> > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia >GPU. The >> > > > >> extra GPU uses the same display memory and can be enabled to >speed up >> > > > >> the Intel graphics or disabled for power saving. I don't know if >> > > > >> versions where the Nvidia section is a full discrete video >adapter that >> > > > >> can be used alone are still called "Optimus". >> > > > >> >> > > > >> Some Optimus owners have reported being able to use the Intel >drivers >> > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option >to >> > > > >> disable the Nvidia GPU is not present, some people have reported >success >> > > > >> with an xorg.conf that uses only the intel driver and ignores the >Nvidia >> > > > >> hardware. >> > > > > >> > > > > Thanks Warren. >> > > > > >> > > > > But this sounds even more frustrating now. I look around the web >even at >> > > > > Lenovo's support forum. Many people report the GT 740M nVidia >adaptor as a >> > > > > discrete adaptor with Optimus technology and everything sounds to >me like it >> > > > > can be selected exclusively. What you describes is that I >definitely need to >> > > > > use the HD4600 iGPU on FreeBSD in the first place since the nVidia >hardware is >> > > > > a kind of "appendix" to the HD4600. >> > > > >> > > > Optimus started out that way, but they might use the same name now >for >> > > > models where the additional GPU is a full discrete adapter. >> > > >> > > I tried to retrieve informations about the settings and >implementations in the >> > > lenovo E540, but I guess the only answer can be given by developer >documentation. I >> > > can not figure out how the GPU is attached to the system. The technical >> > > specifications do not mention the requirement of a iGPU and shared >memory - as >> > > Optimus would require. >> > > >> > > But extrapolating from that "shit-covering" public relations talking >at nVidia's >> > > site I guess the GT 740M is definitely a shared memory solution and >requires the >> > > presence of the iGPU. That would explain why the nvidia BLOB is >detecting the GPU, >> > > but can not find any physical display socket, not even the built-in >LCD. They're >> > > maybe wired all throught the Haswell's HD4600 iGPU? >> > > >> > > > >> > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 >doesn't work >> > > > > properly: it doesn't even start up and loading the "intel" driver >complains >> > > > > about a missing device >> > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in >a naiv manner, >> > > > > that this HD4600 isn't recodnized by the kernel, either. I do not >see any kind >> > > > > of vga0: entry in the kernel log when enabling "Integrated >Graphics" only in the >> > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a >recognized vga0: >> > > > > device shows up. >> > > > >> > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not >support >> > > > Haswell video yet. >> > > >> > > >> > > I suspected that :-( >> > > >> > > Thanks anyway, >> > > >> > > Oliver >> > >> > Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find >> > x11-drivers/xf86-video-nv, which covers old hardware and it is not >applicable to the >> > GT 740M (complains, rightfully, that the found device isn't supported by >the "nv" >> > driver). >> > >> > I face a mess here ... :-( >> >> It was removed, because we missing kernel support for the nouveau >> driver. > > >So, every new GPU not supported by xf86-video-nv has to use nVidia's >BLOB then? -- Tomoaki AOKI junchoon@dec.sakura.ne.jp From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 06:45:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D71C1414; Sun, 21 Sep 2014 06:45:41 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C36E01C4; Sun, 21 Sep 2014 06:45:41 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F0F3F9BD; Sun, 21 Sep 2014 06:45:41 +0000 (UTC) Date: Sun, 21 Sep 2014 06:45:41 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, hrs@FreeBSD.org Message-ID: <2082354981.7.1411281941764.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1501 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 06:45:41 -0000 See Changes: [hrs] Fix a typo. [hrs] Add a change missing in r271916. [hrs] Fix a bug which could make routed(8) daemon exit by sending a special= RIP query from a remote machine, and disable accepting it by default. This requests a routed(8) daemon to dump routing information base for debugging purpose. An -i flag to enable it has been added. [hrs] - Virtualize interface cloner for gre(4). This fixes a panic when de= stroying a vnet jail which has a gre(4) interface. - Make net.link.gre.max_nesting vnet-local. [hrs] Virtualize interface cloner for gif(4). This fixes a panic when dest= roying a vnet jail which has a gif(4) interface. [hrs] Make net.add_addr_allfibs vnet-local. ------------------------------------------ [...truncated 63572 lines...] --- nsap_addr.So --- --- inet_pton.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o inet_pton.So --- nsap_addr.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o nsap_addr.So --- ev_streams.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ev_streams.So --- ev_timers.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ev_timers.So --- ascii.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ascii.So --- big5.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o big5.So --- btowc.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o btowc.So --- collate.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o collate.So --- collcmp.So --- --- euc.So --- --- collcmp.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o collcmp.So --- euc.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o euc.So --- fix_grouping.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o fix_grouping.So --- gb18030.So --- --- gb2312.So --- --- gb18030.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gb18030.So --- gb2312.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gb2312.So --- gbk.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gbk.So --- ctype.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ctype.So --- isctype.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o isctype.So --- iswctype.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o iswctype.So --- ldpart.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ldpart.So --- lmessages.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o lmessages.So --- lmonetary.So --- --- lnumeric.So --- --- lmonetary.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o lmonetary.So --- lnumeric.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o lnumeric.So --- localeconv.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o localeconv.So --- mblen.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mblen.So --- mbrlen.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbrlen.So --- mbrtowc.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbrtowc.So --- mbsinit.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbsinit.So --- mbsnrtowcs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbsnrtowcs.So --- mbsrtowcs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbsrtowcs.So --- mbtowc.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbtowc.So --- mbstowcs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbstowcs.So --- mskanji.So --- --- nextwctype.So --- --- mskanji.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mskanji.So --- nextwctype.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o nextwctype.So --- nl_langinfo.So --- --- nomacros.So --- --- nl_langinfo.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o nl_langinfo.So --- nomacros.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o nomacros.So --- none.So --- --- rpmatch.So --- --- none.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o none.So --- rpmatch.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o rpmatch.So --- rune.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o rune.So --- runetype.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o runetype.So --- setlocale.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o setlocale.So --- setrunelocale.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o setrunelocale.So --- table.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o table.So --- tolower.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o tolower.So --- toupper.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o toupper.So --- utf8.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o utf8.So --- wcrtomb.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcrtomb.So --- wcsnrtombs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcsnrtombs.So --- wcsrtombs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcsrtombs.So --- wcsftime.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcsftime.So --- wcstof.So --- --- wcstod.So --- --- wcstof.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstof.So --- wcstod.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstod.So --- wcstoimax.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstoimax.So --- wcstol.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstol.So --- wcstold.So --- --- wcstoll.So --- --- wcstold.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstold.So --- wcstoll.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstoll.So --- wcstombs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstombs.So --- wcstoul.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstoul.So --- wcstoull.So --- --- wcstoumax.So --- --- wcstoull.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstoull.So --- wcstoumax.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcstoumax.So --- wctob.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wctob.So --- wctomb.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wctomb.So --- wctrans.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wctrans.So --- wctype.So --- --- wcwidth.So --- --- xlocale.So --- --- wctype.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wctype.So --- wcwidth.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o wcwidth.So --- xlocale.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o xlocale.So --- c16rtomb_iconv.So --- --- c32rtomb_iconv.So --- --- c16rtomb_iconv.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o c16rtomb_iconv.= So --- c32rtomb_iconv.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o c32rtomb_iconv.= So --- mbrtoc16_iconv.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbrtoc16_iconv.= So --- mbrtoc32_iconv.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o mbrtoc32_iconv.= So --- md5c.So --- --- ns_name.So --- --- md5c.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o md5c.So --- ns_name.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ns_name.So --- ns_netint.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ns_netint.So --- ns_parse.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ns_parse.So --- ns_print.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ns_print.So --- ns_samedomain.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ns_samedomain.S= o --- ns_ttl.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ns_ttl.So --- base64.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o base64.So --- ether_addr.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o ether_addr.So --- eui64.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o eui64.So --- gai_strerror.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gai_strerror.So --- getaddrinfo.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o getaddrinfo.So --- gethostbydns.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gethostbydns.So --- gethostbyht.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gethostbyht.So --- gethostbynis.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gethostbynis.So --- gethostnamadr.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o gethostnamadr.So --- getifaddrs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o getifaddrs.So --- getifmaddrs.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DNLS -D__DBINTERFACE_PRIVATE -I -I -DINET6 -I/usr/obj -I -D_ACL_PRIVATE -DPOSIX_MISTAKE -I -I -I -I -I -DBROKEN_DES -DPORTMAP -DDE= S_BUILTIN -I -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=3Dgnu99 -fstack-protecto= r -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-po= inter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-= unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Qunused-arguments -c -o getifmaddrs.So --- getifaddrs.So --- In file included from :42: /usr/obj:89:21: error: type specifier missing, defaults to 'int' = [-Werror,-Wimplicit-int] VNET_DECLARE(u_int, rt_add_addr_allfibs); /* Announce interfaces to all fib= s */ ^~~~~~~~~~~~~~~~~~~ /usr/obj:89:1: error: type specifier missing, defaults to 'int' [= -Werror,-Wimplicit-int] VNET_DECLARE(u_int, rt_add_addr_allfibs); /* Announce interfaces to all fib= s */ ^~~~~~~~~~~~ 2 errors generated. --- getifmaddrs.So --- In file included from :37: /usr/obj:89:21: error: type specifier missing, defaults to 'int' = [-Werror,-Wimplicit-int] VNET_DECLARE(u_int, rt_add_addr_allfibs); /* Announce interfaces to all fib= s */ ^~~~~~~~~~~~~~~~~~~ /usr/obj:89:1: error: type specifier missing, defaults to 'int' [= -Werror,-Wimplicit-int] VNET_DECLARE(u_int, rt_add_addr_allfibs); /* Announce interfaces to all fib= s */ ^~~~~~~~~~~~ --- getifaddrs.So --- *** [getifaddrs.So] Error code 1 make[4]: stopped in --- getifmaddrs.So --- 2 errors generated. *** [getifmaddrs.So] Error code 1 make[4]: stopped in 2 errors make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 08:12:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 637C6F1B; Sun, 21 Sep 2014 08:12:36 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0FC6ACB; Sun, 21 Sep 2014 08:12:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XVcFu-000Pff-DM>; Sun, 21 Sep 2014 10:12:26 +0200 Received: from g225184070.adsl.alicedsl.de ([92.225.184.70] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XVcFu-000YO5-4H>; Sun, 21 Sep 2014 10:12:26 +0200 Date: Sun, 21 Sep 2014 10:11:52 +0200 From: "O. Hartmann" To: Larry Rosenman Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140921101152.0b95bf67.ohartman@zedat.fu-berlin.de> In-Reply-To: <65cfbb363809ee6e1078c28390d02603@thebighonker.lerctr.org> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <65cfbb363809ee6e1078c28390d02603@thebighonker.lerctr.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/4H7S9UKyopUs/XxFhxkTW3q"; protocol="application/pgp-signature" X-Originating-IP: 92.225.184.70 X-ZEDAT-Hint: A Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT , owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 08:12:36 -0000 --Sig_/4H7S9UKyopUs/XxFhxkTW3q Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 09:21:34 -0500 Larry Rosenman schrieb: > On 2014-09-20 09:10, O. Hartmann wrote: > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > Warren Block schrieb: > >=20 > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > >>=20 > >> > nVidia's BLOB from port x11/nvidia-driver seems to have problems in = FreeBSD > >> > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Len= ovo ThinkPad > >> > Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 = Intel iGPU and > >> > dedicated nVidia GT 740M (Optimus) working correctly. > >>=20 > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > >> extra GPU uses the same display memory and can be enabled to speed up > >> the Intel graphics or disabled for power saving. I don't know if > >> versions where the Nvidia section is a full discrete video adapter=20 > >> that > >> can be used alone are still called "Optimus". > >>=20 > >> Some Optimus owners have reported being able to use the Intel drivers > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > >> disable the Nvidia GPU is not present, some people have reported=20 > >> success > >> with an xorg.conf that uses only the intel driver and ignores the=20 > >> Nvidia > >> hardware. > >=20 > > Thanks Warren. > >=20 > > But this sounds even more frustrating now. I look around the web even > > at Lenovo's support > > forum. Many people report the GT 740M nVidia adaptor as a discrete > > adaptor with Optimus > > technology and everything sounds to me like it can be selected > > exclusively. What you > > describes is that I definitely need to use the HD4600 iGPU on FreeBSD > > in the first place > > since the nVidia hardware is a kind of "appendix" to the HD4600. > >=20 > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't > > work properly: it > > doesn't even start up and loading the "intel" driver complains about a > > missing device - > > preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv > > manner, that this > > HD4600 isn't recodnized by the kernel, either. I do not see any kind > > of vga0: entry in > > the kernel log when enabling "Integrated Graphics" only in the > > laptop's UEFI/Firmware. > > When enabling "nVidia Optimus", a recognized vga0: device shows up. > >=20 > > From my server, equipted with a IvyBridge i3-class CPU with integrated > > iGPU, I even get > > this message from 11.0-CURRENT: > >=20 > > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x01521849 chip=3D0x015= 28086 > > rev=3D0x09 hdr=3D0x00 > > vendor =3D 'Intel Corporation' > > device =3D 'Xeon E3-1200 v2/3rd Gen Core processor Graphics=20 > > Controller' > > class =3D display > > subclass =3D VGA > > bar [10] =3D type Memory, range 64, base 0xf7800000, size 4194304= ,=20 > > enabled > > bar [18] =3D type Prefetchable Memory, range 64, base 0xe0000000, > > size 268435456, > > enabled bar [20] =3D type I/O Port, range 32, base 0xf000, size 64,=20 > > enabled > > cap 05[90] =3D MSI supports 1 message > > cap 01[d0] =3D powerspec 2 supports D0 D3 current D0 > > cap 13[a4] =3D PCI Advanced Features: FLR TP > >=20 > >=20 > > The very same CURRENT (most recent as I built world on all system=20 > > today) doesn't > > recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems > > impossible to me that people > > can report having this GPU working if even the most recent FreeBSD > > CURRENT doesn't > > recognize it. > for the record, on my Thinkpad W520+Docking Station, I get two HDMI /=20 > DVI outputs off the Nvidia GPU, in addition to the > Intel graphics on the local LCD. This is under Windows, but..... >=20 >=20 Fiddling around longer, I realizes now a console message popping up wheneve= r I try to start the nVidia GPU. I have ignored that the whole time: Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Ar= gument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument = #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130823/nsarguments-97= ) Sep 21 09:38:30 hermann kernel: ACPI Error: Field [TBF3] at 270336 exceeds Buffer = [NULL] size 262144 (bits) (20130823/dsopcode-249) Sep 21 09:38:30 hermann kernel: ACPI = Error: Method parse/execution failed [\_SB_.PCI0.PEG_.VID_.GETB] (Node 0xfffff800044ef740= ), AE_AML_BUFFER_LIMIT (20130823/psparse-553) Sep 21 09:38:30 hermann kernel: = ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEG_.VID_._ROM] (Node 0xfffff8000= 44ef780), AE_AML_BUFFER_LIMIT (20130823/psparse-553) Sep 21 09:38:30 hermann kernel: = ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI= requires [Package] (20130823/nsarguments-97) I'm no ACPI expert, but could this message inform me about some ACPI issues= with selecting the right device/display socket? I can also provide an ACPI dump,= if requested and secure. Oliver --Sig_/4H7S9UKyopUs/XxFhxkTW3q Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUHohIAAoJEOgBcD7A/5N8UToIAOPClmhtbUy2F1C61f9Z4YFz dqJzAXh1ndc126mGEHNasMwwzsgoqjr7nMtf07d3S0EleIkKgfSiiCM8+mtvgKiY ptTCN92jb51LehcFgtfV12eeqqqT1rG7DNTpR1tx4PcyOlk+IimySavZ41xIswVk l9tyF+UDwNsxHhOZsOv4rUIaPi4z8W95pc+70YiRrPXasKUm5XW7ry2khoBikZ8a LYtRM58+3VVfEnaUfqS2OFBbCPGDnkiKx1z0rgvh9nzBzx7O2VwTsR4HyqJnrZY4 /ET9DTCfKudIls2Sbu72TiLKsdeaNv4SlQKRot3G6KoZkKvZZLCIRSUTSL4+Ijw= =B9kD -----END PGP SIGNATURE----- --Sig_/4H7S9UKyopUs/XxFhxkTW3q-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 09:16:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 726385E1 for ; Sun, 21 Sep 2014 09:16:27 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55EE6C1 for ; Sun, 21 Sep 2014 09:16:27 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XVcxC-0001DA-6Q for freebsd-current@freebsd.org; Sun, 21 Sep 2014 01:57:10 -0700 Date: Sun, 21 Sep 2014 01:57:10 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1411289830171-5950788.post@n5.nabble.com> Subject: zpool frag MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 09:16:27 -0000 FRAG means fragmentation, right? Zpool fragmentation? That's news to me. If this is real how do I fix it? NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH ALTROOT pool1 75.5G 53.7G 21.8G 60% - 71% 1.00x ONLINE - pool2 48.8G 26.2G 22.6G 68% - 53% 1.00x ONLINE - pool3 204G 177G 27.0G 53% - 86% 1.11x ONLINE - Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-frag-tp5950788.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 11:02:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3598A8D; Sun, 21 Sep 2014 11:02:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D11C8BE5; Sun, 21 Sep 2014 11:02:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CB4BAA16; Sun, 21 Sep 2014 11:02:42 +0000 (UTC) Date: Sun, 21 Sep 2014 11:02:42 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kib@FreeBSD.org, hrs@FreeBSD.org Message-ID: <580792520.8.1411297362661.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2082354981.7.1411281941764.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2082354981.7.1411281941764.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1502 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 11:02:43 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 13:17:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5322A536 for ; Sun, 21 Sep 2014 13:17:44 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 18306950 for ; Sun, 21 Sep 2014 13:17:43 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id B0CF120E7088F; Sun, 21 Sep 2014 13:17:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE,URI_HEX autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id F1B1F20E7088A; Sun, 21 Sep 2014 13:17:38 +0000 (UTC) Message-ID: <5EE253EAE0A84950B3CEA19751580825@multiplay.co.uk> From: "Steven Hartland" To: "Beeblebrox" , References: <1411289830171-5950788.post@n5.nabble.com> Subject: Re: zpool frag Date: Sun, 21 Sep 2014 14:17:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 13:17:44 -0000 Backup the pool and restore it is the only way I'm aware of. ----- Original Message ----- From: "Beeblebrox" To: Sent: Sunday, September 21, 2014 9:57 AM Subject: zpool frag > FRAG means fragmentation, right? Zpool fragmentation? That's news to me. If > this is real how do I fix it? > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH ALTROOT > pool1 75.5G 53.7G 21.8G 60% - 71% 1.00x ONLINE - > pool2 48.8G 26.2G 22.6G 68% - 53% 1.00x ONLINE - > pool3 204G 177G 27.0G 53% - 86% 1.11x ONLINE - > > Regards. > > > > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-frag-tp5950788.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > 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 Sep 21 15:06:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6484A3D7 for ; Sun, 21 Sep 2014 15:06:19 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6502FA for ; Sun, 21 Sep 2014 15:06:18 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 2E8544EC1A for ; Sun, 21 Sep 2014 15:06:12 +0000 (UTC) Message-ID: <541EE962.2000801@freebsd.org> Date: Sun, 21 Sep 2014 11:06:10 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zpool frag References: <1411289830171-5950788.post@n5.nabble.com> In-Reply-To: <1411289830171-5950788.post@n5.nabble.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2e20LbLAWAxPAxWuoIUlLTrTvTjFTVepF" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 15:06:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2e20LbLAWAxPAxWuoIUlLTrTvTjFTVepF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-09-21 04:57, Beeblebrox wrote: > FRAG means fragmentation, right? Zpool fragmentation? That's news to me= =2E If > this is real how do I fix it? >=20 > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH AL= TROOT > pool1 75.5G 53.7G 21.8G 60% - 71% 1.00x ONLINE = - > pool2 48.8G 26.2G 22.6G 68% - 53% 1.00x ONLINE = - > pool3 204G 177G 27.0G 53% - 86% 1.11x ONLINE = - >=20 > Regards. >=20 >=20 >=20 > ----- > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/zpoo= l-frag-tp5950788.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 It is not something you 'fix', it is just a metric to help you understand the performance of your pool. The higher the fragmentation, the longer it might take to allocate new space, and obviously you will have more random seek time while reading from the pool. As Steven mentions, there is no defragmentation tool for ZFS. You can zfs send/recv or backup/restore the pool if you have a strong enough reason to want to get the fragmentation number down. It is a fairly natural side effect of a copy-on-write file system. Note: the % is not the % fragmented, IIRC, it is the percentage of the free blocks that are less that a specific size. I forget what that size i= s. --=20 Allan Jude --2e20LbLAWAxPAxWuoIUlLTrTvTjFTVepF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUHullAAoJEJrBFpNRJZKf9dUP/38JxsXqgDMVp8dPfkVGZba+ bxrqH65LPbW9B5VEI98XipWzauQ5oHQlsqn6tZ0afoVvcq+vjPzHqJJXOdu8rAPt 6hVMaCE0FeeWDvzVtTeQSg/W4o2ICxsAN7OJf/L3m6bI9xdB4fYmowwUX3Ma7iGV r/OEbHuHwZMAXgYW0V3Lgqb4k6jBcwPhEqvRjIPzVUFujDwp5wP3fWRmslykfmzA afmKurateJJd85nf9RoaQ3xCqJj3n8w7zbqerRz0RORX2ESvAgA5+o+xZWTGqjKW cuPAqa1oZTu9sXhJPaKrUYOmYWUB6wzJIwK1UbRKCf0BXMWmzp012ZEuDIH0i2vw HGmWEZFh5m+F79w90tUESEqKskZGJ/KeobjJiDxuslAq60nKL3SjjvOmytRwF80q qcOa1e7bGEZ/MQxqcd+z0nLOLCz9g2ov/MLE8FU19/1L5+baQpbXF4wF8cMcJNU8 dRnVgxV7lIoymiFpGMsaEMKRm2J2l3AQARuZbijZ7UmWXojYde6EewbAwoGUFNsb Le5PBDcYCSyRmtvf3foaxNWhoHS9Cq6QJsrW0sKPiHnGV2FLLqcxZ2c1/9Ksas2z H17OHI4pWsrLqUmPCfEJRl98kFQw8Ysu1zVbftxiEmZdMsVRaYhDEJN/EQXWQSa+ JwVBLcns/7Qfgk75JtGv =7l3G -----END PGP SIGNATURE----- --2e20LbLAWAxPAxWuoIUlLTrTvTjFTVepF-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 16:46:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 847D67B2 for ; Sun, 21 Sep 2014 16:46:55 +0000 (UTC) Received: from galore.getmail.no (galore.getmail.no [84.210.184.6]) by mx1.freebsd.org (Postfix) with ESMTP id 36E94D80 for ; Sun, 21 Sep 2014 16:46:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 9EE23414EA for ; Sun, 21 Sep 2014 18:39:38 +0200 (CEST) Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id twqqvUxPkt5H for ; Sun, 21 Sep 2014 18:39:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by galore.getmail.no (Postfix) with ESMTP id 2AC57457EF for ; Sun, 21 Sep 2014 18:39:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at galore.get.c.bitbit.net Received: from galore.getmail.no ([127.0.0.1]) by localhost (galore.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0qFoYAiZTAxe for ; Sun, 21 Sep 2014 18:39:38 +0200 (CEST) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by galore.getmail.no (Postfix) with ESMTP id 0674A42D19 for ; Sun, 21 Sep 2014 18:39:38 +0200 (CEST) Date: Sun, 21 Sep 2014 18:39:36 +0200 From: Gyrd Thane Lange To: freebsd-current@freebsd.org Subject: [patch] syscons/vt keymap: Norwegian country code conflicts with default value Message-ID: <20140921183936.03617590@onyx.thanelange.no> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/P1rm_rClhgPAl2o3+cdNbqO" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 16:46:55 -0000 --MP_/P1rm_rClhgPAl2o3+cdNbqO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Recent changes in keymap namning for syscons/vt to use shorter names has exposed a conflict with the value "no" both used as country code for Norway and as a default value indicating that no keymap is set. The attached patch proposes to use "" (empty string) as default value instead. Also available here: http://onyx.thanelange.no/freebsd/patches/syscons.patch Best regards Gyrd ^_^ --MP_/P1rm_rClhgPAl2o3+cdNbqO Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=syscons.patch Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 271880) +++ etc/defaults/rc.conf (working copy) @@ -531,7 +531,7 @@ ############################################################## keyboard="" # keyboard device to use (default /dev/kbd0). -keymap="NO" # keymap in /usr/share/{syscons,vt}/keymaps/* (or NO). +keymap="" # keymap in /usr/share/{syscons,vt}/keymaps/* (or empty). keyrate="NO" # keyboard rate to: slow, normal, fast (or NO). keybell="NO" # See kbdcontrol(1) for options. Use "off" to disable. keychange="NO" # function keys default values (or NO). Index: etc/rc.d/syscons =================================================================== --- etc/rc.d/syscons (revision 271880) +++ etc/rc.d/syscons (working copy) @@ -167,7 +167,7 @@ # keymap # case ${keymap} in - [Nn][Oo] | '') + '') ;; *) sc_init --MP_/P1rm_rClhgPAl2o3+cdNbqO-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 17:00:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB848AEA; Sun, 21 Sep 2014 17:00:53 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8FB1E70; Sun, 21 Sep 2014 17:00:53 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 706E6C00; Sun, 21 Sep 2014 10:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1411318847; bh=pVAh6u4q89cGlgfcnVQQU4INsGsAJ7TiIHrwl9n5OeM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RdNN0srUIcUanx3GRvZKqd0bRASFgznjbUKCJaID8Xr0Oy0y5R+OR5ndOoARRDCBy wq0V+Bw0OAJ7S5KkQcgCLbiYU8Tn3yHp1ZYH0gpTNu2q56gVXxCy5W5FUUaKRkaWBR ztjoCqV3ePD/o98PUuHsK15QLAgqyCY3aZQit+t8= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: zpool frag Date: Sun, 21 Sep 2014 10:00:40 -0700 Message-ID: <1691600.4gjp5IhhyR@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <541EE962.2000801@freebsd.org> References: <1411289830171-5950788.post@n5.nabble.com> <541EE962.2000801@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2139920.ZNsoPLKslq"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 17:00:54 -0000 --nextPart2139920.ZNsoPLKslq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote: > On 2014-09-21 04:57, Beeblebrox wrote: > > FRAG means fragmentation, right? Zpool fragmentation? That's news t= o me. > > If > > this is real how do I fix it? > >=20 > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH= =20 > > ALTROOT pool1 75.5G 53.7G 21.8G 60% - 71% 1.0= 0x=20 > > ONLINE - pool2 48.8G 26.2G 22.6G 68% - 53% 1= .00x=20 > > ONLINE - pool3 204G 177G 27.0G 53% - 86% 1= .11x=20 > > ONLINE - > >=20 > > Regards. > >=20 > >=20 > >=20 > > ----- > > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > > -- > > View this message in context: > > http://freebsd.1045724.n5.nabble.com/zpool-frag-tp5950788.html Sent= from > > the freebsd-current mailing list archive at Nabble.com. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.org" >=20 > It is not something you 'fix', it is just a metric to help you > understand the performance of your pool. The higher the fragmentation= , > the longer it might take to allocate new space, and obviously you wil= l > have more random seek time while reading from the pool. >=20 > As Steven mentions, there is no defragmentation tool for ZFS. You can= > zfs send/recv or backup/restore the pool if you have a strong enough > reason to want to get the fragmentation number down. >=20 > It is a fairly natural side effect of a copy-on-write file system. >=20 > Note: the % is not the % fragmented, IIRC, it is the percentage of th= e > free blocks that are less that a specific size. I forget what that si= ze is. I fear that the information presented in its current form is going to g= enerate=20 lots of fear and confusion. The other thing to consider is that this gets much, much worse as the p= ool=20 fills up. Even UFS has issues with fragmentation when it fills, but ZF= S is far=20 more sensative to it. In the freebsd.org cluster we have a health chec= k alert=20 at 80% full, but even that's probably on the high side. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2139920.ZNsoPLKslq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUHwQ+AAoJEDXWlwnsgJ4E9VMH/iTx9u9RTWOEbAiDJrZ8M23p ZediIzo2ZZjea9+NL9kGF/oiV0a+wyAOCL84unX+KxWBAipL8d6/7R4cP4y67fYn aICNy9BkHVWLYm09UN1TYjSzI6qshagrCG0CWbWunPx6EmkBhFD0xhQNazUKweQf zpAv62Lul35dUKy11jMb2y4WcjQhcZDGFUyJ0unTvg9l9tyddxsdTvoBCQuNvTP1 B+UAFHKQhHnnoKLCUSDosgjvnIuOsJP0Iv+C/e6LdLB1SJd3V6c+yoCdi3mdf+T9 SiPmvDBXIJmGrAVwzGjSEK1xw9J2RXFLVI0bN2edmO0kLHC4ZGAhbiYggPIzZJA= =JBr4 -----END PGP SIGNATURE----- --nextPart2139920.ZNsoPLKslq-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 17:12:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C689DE02; Sun, 21 Sep 2014 17:12:18 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 8950AFF9; Sun, 21 Sep 2014 17:12:18 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 0890920E7088E; Sun, 21 Sep 2014 17:12:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 8159D20E7088A; Sun, 21 Sep 2014 17:12:14 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Peter Wemm" , References: <1411289830171-5950788.post@n5.nabble.com> <541EE962.2000801@freebsd.org> <1691600.4gjp5IhhyR@overcee.wemm.org> Subject: Re: zpool frag Date: Sun, 21 Sep 2014 18:12:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 17:12:18 -0000 ----- Original Message ----- > From: "Peter Wemm" > On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote: > > On 2014-09-21 04:57, Beeblebrox wrote: > > > FRAG means fragmentation, right? Zpool fragmentation? That's news to me. > > > If > > > this is real how do I fix it? > > > > > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH > > > ALTROOT pool1 75.5G 53.7G 21.8G 60% - 71% 1.00x > > > ONLINE - pool2 48.8G 26.2G 22.6G 68% - 53% 1.00x > > > ONLINE - pool3 204G 177G 27.0G 53% - 86% 1.11x > > > ONLINE - > > It is not something you 'fix', it is just a metric to help you > > understand the performance of your pool. The higher the fragmentation, > > the longer it might take to allocate new space, and obviously you will > > have more random seek time while reading from the pool. > > > > As Steven mentions, there is no defragmentation tool for ZFS. You can > > zfs send/recv or backup/restore the pool if you have a strong enough > > reason to want to get the fragmentation number down. > > > > It is a fairly natural side effect of a copy-on-write file system. > > > > Note: the % is not the % fragmented, IIRC, it is the percentage of the > > free blocks that are less that a specific size. I forget what that size is. > > I fear that the information presented in its current form is going to generate > lots of fear and confusion. > > The other thing to consider is that this gets much, much worse as the pool > fills up. Even UFS has issues with fragmentation when it fills, but ZFS is far > more sensative to it. In the freebsd.org cluster we have a health check alert > at 80% full, but even that's probably on the high side. This "should" be less of an issue if you have the spacemap_histogram feature enabled on the pool, which IIRC if your seeing FRAG details should be the case. Regards Steve From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 17:39:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68AF6318; Sun, 21 Sep 2014 17:39:53 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AA7C21D; Sun, 21 Sep 2014 17:39:53 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 54D09C16; Sun, 21 Sep 2014 10:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1411321192; bh=ylyAJsAj7cNj+mmfQWIEOjuIp/1LRIFUUVtqQ+EmIeg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XRic4ph43LquC8mTpn84wBddun+gcAl4kCyCLXxKEpJYhqNMADy7OCru+K4sbUYAs fCowY8fzqPUzPXqM81EOTno6fNv1kaMOVqk3qZdaclU9xFPD96SQnxj8Md2zfnuimh xTRun+LxTMUyCysev25KebBV/SBepKGh6oyQHR98= From: Peter Wemm To: Steven Hartland Subject: Re: zpool frag Date: Sun, 21 Sep 2014 10:39:43 -0700 Message-ID: <1965644.89SVIqCBMH@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1411289830171-5950788.post@n5.nabble.com> <1691600.4gjp5IhhyR@overcee.wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2047581.7hXjsinto4"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 17:39:53 -0000 --nextPart2047581.7hXjsinto4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sunday, September 21, 2014 06:12:09 PM Steven Hartland wrote: > ----- Original Message ----- >=20 > > From: "Peter Wemm" > >=20 > > On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote: > > > On 2014-09-21 04:57, Beeblebrox wrote: > > > > FRAG means fragmentation, right? Zpool fragmentation? That's ne= ws to > > > > me. > > > > If > > > > this is real how do I fix it? > > > >=20 > > > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HE= ALTH > > > > ALTROOT pool1 75.5G 53.7G 21.8G 60% - 71% = 1.00x > > > > ONLINE - pool2 48.8G 26.2G 22.6G 68% - 53= %=20 > > > > 1.00x > > > > ONLINE - pool3 204G 177G 27.0G 53% - 86= %=20 > > > > 1.11x > > > > ONLINE - > > >=20 > > > It is not something you 'fix', it is just a metric to help you > > > understand the performance of your pool. The higher the fragmenta= tion, > > > the longer it might take to allocate new space, and obviously you= will > > > have more random seek time while reading from the pool. > > >=20 > > > As Steven mentions, there is no defragmentation tool for ZFS. You= can > > > zfs send/recv or backup/restore the pool if you have a strong eno= ugh > > > reason to want to get the fragmentation number down. > > >=20 > > > It is a fairly natural side effect of a copy-on-write file system= . > > >=20 > > > Note: the % is not the % fragmented, IIRC, it is the percentage o= f the > > > free blocks that are less that a specific size. I forget what tha= t size > > > is. > >=20 > > I fear that the information presented in its current form is going = to > > generate lots of fear and confusion. > >=20 > > The other thing to consider is that this gets much, much worse as t= he pool > > fills up. Even UFS has issues with fragmentation when it fills, bu= t ZFS > > is far more sensative to it. In the freebsd.org cluster we have a = health > > check alert at 80% full, but even that's probably on the high side.= >=20 > This "should" be less of an issue if you have the spacemap_histogram = feature > enabled on the pool, which IIRC if your seeing FRAG details should be= the > case. Hopefully so. The catch though is when its been run without it until r= ecently=20 it can be a bit of a surprise. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2047581.7hXjsinto4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUHw1oAAoJEDXWlwnsgJ4EPbAIALjgkSFKIi2eOjvpOpvN0Fa4 +MLbgW8aprpLO6tQYvshi77cDa4CCoshnQhAqfp+5lSPFDXB9TZh3awl2fmynEhk YODto3xsqJpAlJXAYV0LANCQD0/Cb3jZ9LAywuPjHoYzLwAN7JGT7ocUUWsXWUnh cI3y9I6+oAq1BWbM/L68p2dAmWKm3AsWQlQuIHCoYNBzizalNtLoE7Pu/m6w1GnG AxKHq486EprDRjU09RIPkndrkYSe18/WUYNtFfZ/Ees+qtyUvan4KmJkbuuBWCjG PsO63ZVpxM5WJ57OqWNORy/yhL8xbADIDCy+ttYCikKwLdiolHHmY5yHIVrcaVw= =zt04 -----END PGP SIGNATURE----- --nextPart2047581.7hXjsinto4-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 17:51:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 985E1531 for ; Sun, 21 Sep 2014 17:51:26 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 558973A5 for ; Sun, 21 Sep 2014 17:51:25 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 714FB4F117 for ; Sun, 21 Sep 2014 17:51:24 +0000 (UTC) Message-ID: <541F101A.6000701@freebsd.org> Date: Sun, 21 Sep 2014 13:51:22 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: zpool frag References: <1411289830171-5950788.post@n5.nabble.com> <1691600.4gjp5IhhyR@overcee.wemm.org> <1965644.89SVIqCBMH@overcee.wemm.org> In-Reply-To: <1965644.89SVIqCBMH@overcee.wemm.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xOFUeXpGFAUIqdh5w5pkivvHfEECAw5VO" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 17:51:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xOFUeXpGFAUIqdh5w5pkivvHfEECAw5VO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-09-21 13:39, Peter Wemm wrote: > On Sunday, September 21, 2014 06:12:09 PM Steven Hartland wrote: >> ----- Original Message ----- >> >>> From: "Peter Wemm" >>> >>> On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote: >>>> On 2014-09-21 04:57, Beeblebrox wrote: >>>>> FRAG means fragmentation, right? Zpool fragmentation? That's news t= o >>>>> me. >>>>> If >>>>> this is real how do I fix it? >>>>> >>>>> NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH= >>>>> ALTROOT pool1 75.5G 53.7G 21.8G 60% - 71% 1.0= 0x >>>>> ONLINE - pool2 48.8G 26.2G 22.6G 68% - 53%=20 >>>>> 1.00x >>>>> ONLINE - pool3 204G 177G 27.0G 53% - 86%=20 >>>>> 1.11x >>>>> ONLINE - >>>> >>>> It is not something you 'fix', it is just a metric to help you >>>> understand the performance of your pool. The higher the fragmentatio= n, >>>> the longer it might take to allocate new space, and obviously you wi= ll >>>> have more random seek time while reading from the pool. >>>> >>>> As Steven mentions, there is no defragmentation tool for ZFS. You ca= n >>>> zfs send/recv or backup/restore the pool if you have a strong enough= >>>> reason to want to get the fragmentation number down. >>>> >>>> It is a fairly natural side effect of a copy-on-write file system. >>>> >>>> Note: the % is not the % fragmented, IIRC, it is the percentage of t= he >>>> free blocks that are less that a specific size. I forget what that s= ize >>>> is. >>> >>> I fear that the information presented in its current form is going to= >>> generate lots of fear and confusion. >>> >>> The other thing to consider is that this gets much, much worse as the= pool >>> fills up. Even UFS has issues with fragmentation when it fills, but = ZFS >>> is far more sensative to it. In the freebsd.org cluster we have a he= alth >>> check alert at 80% full, but even that's probably on the high side. >> >> This "should" be less of an issue if you have the spacemap_histogram f= eature >> enabled on the pool, which IIRC if your seeing FRAG details should be = the >> case. >=20 > Hopefully so. The catch though is when its been run without it until r= ecently=20 > it can be a bit of a surprise. >=20 >=20 =46rom an email exchange with George Wilson (developer of the spacemap_histogram feature): "You can use it on existing pools but the histogram only gets created when you condense a space_map (a process by which ZFS tries to make the space_map ondisk smaller). This means that when you look at an existing pool it may have some space_maps with histograms and ones without." This likely means that on a pool that has (recently??) been upgrade, the FRAG metric may fluctuate wildly, as more and more space_maps get a histogram. The histogram feature doesn't really solve the problem of fragmentation, it just makes the pool perform better when it is fragmented, as the pool can more reliably find the space_map containing the largest area of contiguous free space in order to maintain performance. --=20 Allan Jude --xOFUeXpGFAUIqdh5w5pkivvHfEECAw5VO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUHxAeAAoJEJrBFpNRJZKf+sYP/3HoqWRfbj86sB6zIWJYgnAO 4U3hEMQlMljSTMptTwv+mR7Rj2wBxL/mIKyeNJD0agrJ+1FsHlahYcBwqrzPCq6S oGAlIPYLpBW3TL/lpS1XC6SyR34JJU4EFHDHqvMsXq47YLUTa9wd2IEsayvCRt9/ m2AteSpC16UEoALUXRRO97qThzbBmmtA0faMjQskL3wsNHfjb4MCG0YR0esge4cI ZdtxYM/1/GHYICzmFz67zjAYE8hrW/BAssXk07gEHD78zZe8Hvm6fsy5rP54o0Wa eC4OM0+wCStqq3yzLjvXIH5AailJOj5CtsDmCJBhqoBNGdVGfSvLmb/BrwKmFzyE IZ2tdOMa8R5Ymb8rul+7By3+3LoZgPnHIm2nPBjtWK75IeKsKTlE31xx4OYdF/Zn hWDAP5ERiLTn/Dq2dGNEDBRPUnNYPa9JbuhZ2LyWw44qOe2boeBi8wruy8T1tkbF lZWCbKbWwUZLrXpDYcqwHz+6iHVhLfgHhcm1x9fAfBaLTbCsxHqN85xEaCHZ047w imRnl1nr2AZD01G5tbuU7tnupen3usSx68IeSEfQSEdxbnO7vhAFPL9sBzHx31yq h5LFptYXqQcJ/GryhZg0C13TMadyXY4aMcWUUDDn9ZPE028Vgqv6s/JFWtrr8xgk 0SfSSJhRQtwjttt2EhZ+ =6SBK -----END PGP SIGNATURE----- --xOFUeXpGFAUIqdh5w5pkivvHfEECAw5VO-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 23:53:53 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F54FE97; Sun, 21 Sep 2014 23:53:53 +0000 (UTC) Received: from hades.sorbs.net (hades.sorbs.net [67.231.146.201]) by mx1.freebsd.org (Postfix) with ESMTP id 2B617AD0; Sun, 21 Sep 2014 23:53:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NC90033ZZW87F00@hades.sorbs.net>; Sun, 21 Sep 2014 16:57:46 -0700 (PDT) Message-id: <541F6507.70904@sorbs.net> Date: Mon, 22 Sep 2014 01:53:43 +0200 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: ports@FreeBSD.org Subject: Re: [HEADSUP] pkg(8) is now the only package management tool References: <20140901195520.GB77917@ivaldir.etoilebsd.net> <54050D07.4010404@sorbs.net> In-reply-to: <54050D07.4010404@sorbs.net> X-Mailman-Approved-At: Mon, 22 Sep 2014 00:42:06 +0000 Cc: pkg@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 21 Sep 2014 23:53:53 -0000 Michelle Sullivan wrote: > Baptiste Daroussin wrote: > >> Hi all, >> >> The ports tree has been modified to only support pkg(8) as package management >> system for all supported version of FreeBSD. >> >> if you were still using pkg_install (pkg_* tools) you will have to upgrade your >> system. >> >> The simplest way is >> cd /usr/ports/ports-mgmt/pkg >> make install >> then run >> pkg2ng >> >> So despite being told 'use the quarterly, patches can be applied to it if requested' and updating ports I maintain asking specifically for the patches to be merged... Still all broken (though patches applied to HEAD)... Nice one... -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 02:13:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD230F9C for ; Mon, 22 Sep 2014 02:13:26 +0000 (UTC) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B19368C4 for ; Mon, 22 Sep 2014 02:13:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=IFufWqnGTTpKvBlG751EXPOnC7+XCHd0ls4/SV0yAyg=; b=FcsEo1pcxj0ZgkaXmEKk/ObyXZmZWgeUBNBJJdLzIVK6PQ1XuLo5VFkNYbmHQCP4NS2rJSfuejxM9icQRwx3pBiJveZD+yhtFQ3WkZFAWh9ImbHE6ZfDC4CDuolPUPsgbbmUOaT3RQJlXkwg2V/kFPTvOr0rnTYg3TVVdNofvi0=; Received: from localhost.lerctr.org ([127.0.0.1]:54646 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XVt80-0000Nm-AJ for freebsd-current@freebsd.org; Sun, 21 Sep 2014 21:13:25 -0500 Received: from 104-54-221-134.lightspeed.austtx.sbcglobal.net ([104.54.221.134]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Sun, 21 Sep 2014 21:13:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 21 Sep 2014 21:13:24 -0500 From: Larry Rosenman To: Freebsd current Subject: Intel SoC's Message-ID: <04c8c6dd4961e5097cb7e9f21e6c3ae1@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.0.2 X-Spam-Score: -3.7 (---) X-LERCTR-Spam-Score: -3.7 (---) X-Spam-Report: SpamScore (-3.7/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786 X-LERCTR-Spam-Report: SpamScore (-3.7/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 02:13:27 -0000 I got 2 Intel SoC's at the Intel IOT Hackathon here in Austin this weekend. They are both I586/Pentium processors, with some other stuff hanging out. They currently run Yactoh Linux. I'm wondering how hard it would be to get FreeBSD up on them.... They are the Galileo Gen 2, and Edison boards. Any ideas on how/where to start? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 03:36:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79AEDD22; Mon, 22 Sep 2014 03:36:30 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27E369D; Mon, 22 Sep 2014 03:36:29 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8M3aPFU078926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Sep 2014 21:36:26 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: multipart/signed; boundary="Apple-Mail=_5F347363-3BBD-4CAC-80DA-C602E0339DFA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libthr and main thread stack size From: "Justin T. Gibbs" In-Reply-To: <20140920170658.GE2210@kib.kiev.ua> Date: Sun, 21 Sep 2014 21:36:25 -0600 Message-Id: References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> <20140920170658.GE2210@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org, doc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 03:36:30 -0000 --Apple-Mail=_5F347363-3BBD-4CAC-80DA-C602E0339DFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 20, 2014, at 11:06 AM, Konstantin Belousov = wrote: > On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote: >> I suspect it was done out of reasons of being overly conservative in >> interpreting RLIMIT_STACK. I think it is quite surprising behavior >> though and would rather we make your option the default and implement >> what the Open Group says above. >=20 > Ok, below is the patch. I felt bad about adding yet another magic and > undocumented tunable to our libthr. Since there seems to be no > alternative than a tunable to enforce old behaviour, I documented > the quirks I am aware of. Why do we need to support the old behavior? Any program that ran in the = old model will run in the new. In the unlikely event that someone was = using the old scheme for administrative control, there are other = mechanisms for this already available that we can point them to instead. =97 Justin --Apple-Mail=_5F347363-3BBD-4CAC-80DA-C602E0339DFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUH5k5AAoJED9n8CuvaSf4r3QH/imMeCsoVyLJQC4JO9vDum8B DEHcPN0A4j7eZaO9itzbGY9R7Ie9F+orBsFra+ucCBTwSvzpD5YXTsnaY+oS+rV3 a0iefizkVpRrC3GOe9g5cjtJ5bHIKl2Oi7pfxvXEQTOdjwniNHOXozG0CCWQPX52 iIoLJ4q98acKxb/qTm5fsy0Xyx6exmk1YOY6o9PKv6te6ane81BnmPS+wmdD98nH 7q4qME8Y379Ul1NIo1crkw7qVu6jZZHgiEaX/BDDdE/tvx2F6Ot+PsJ6d79ilM7z Wat1t6GCcZAbytNjqR9sgZX8cpY43jgXzjceBA6uGJd/wPRxUm/gZhIN5QGs80k= =o76e -----END PGP SIGNATURE----- --Apple-Mail=_5F347363-3BBD-4CAC-80DA-C602E0339DFA-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 05:12:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E28886B; Mon, 22 Sep 2014 05:12:40 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id B8713ACC; Mon, 22 Sep 2014 05:12:39 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id s8M4w08e010824; Mon, 22 Sep 2014 13:58:00 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili14) with ESMTP id s8M4w0L14607; Mon, 22 Sep 2014 13:58:00 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi13) id s8M4w0tL010515; Mon, 22 Sep 2014 13:58:00 +0900 Received: from localhost by lomi13.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s8M4w0oX010470; Mon, 22 Sep 2014 13:58:00 +0900 Date: Mon, 22 Sep 2014 13:58:00 +0900 (JST) Message-Id: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> To: freebsd-current@freebsd.org Subject: Does the xHCI driver has a spec violation? From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: okuno.kohji@jp.panasonic.com, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 05:12:40 -0000 Hi, I encountered a issue for USB mic. In fist time, my host controller (xHCI) sends single IN-tokens every 8-SOFs. This is expected action. But, after I open, close and open, my host controller sends plural IN-tokens between SOF and SOF. In Intel Lynx Point, I could not reproduce this issue. I'm sorry. Unfortunately, I can't explain details about my proprietary host controler. I found the following explanation in the xHCI 1.1 specification http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf In 4.8.3 Endpoint Context State, 6. The Configure Endpoint Command (Add (A) = `1' and Drop (D) =`1') shall transition an endpoint, except the Default Control Endpoint, from the Stopped to the Running state.' So, I modify as the following, then I can run expectedly. What do you think about this change? Best regards, Kohji Okuno static usb_error_t xhci_configure_mask(struct usb_device *udev, uint32_t mask, uint8_t drop) { struct xhci_softc *sc = XHCI_BUS2SC(udev->bus); struct usb_page_search buf_inp; struct xhci_input_dev_ctx *pinp; uint32_t temp; uint8_t index; uint8_t x; index = udev->controller_slot_id; usbd_get_page(&sc->sc_hw.devs[index].input_pc, 0, &buf_inp); pinp = buf_inp.buffer; if (drop) { mask &= XHCI_INCTX_NON_CTRL_MASK; xhci_ctx_set_le32(sc, &pinp->ctx_input.dwInCtx0, mask); xhci_ctx_set_le32(sc, &pinp->ctx_input.dwInCtx1, 0); } else { - xhci_ctx_set_le32(sc, &pinp->ctx_input.dwInCtx0, 0); + xhci_ctx_set_le32(sc, &pinp->ctx_input.dwInCtx0, mask); xhci_ctx_set_le32(sc, &pinp->ctx_input.dwInCtx1, mask); From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 06:02:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79363D6; Mon, 22 Sep 2014 06:02:57 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34D19EFF; Mon, 22 Sep 2014 06:02:56 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7EF4D1FE027; Mon, 22 Sep 2014 08:02:53 +0200 (CEST) Message-ID: <541FBB84.6050508@selasky.org> Date: Mon, 22 Sep 2014 08:02:44 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kohji Okuno , freebsd-current@freebsd.org Subject: Re: Does the xHCI driver has a spec violation? References: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> In-Reply-To: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> Content-Type: multipart/mixed; boundary="------------020008010507050400020707" Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 06:02:57 -0000 This is a multi-part message in MIME format. --------------020008010507050400020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/22/14 06:58, Kohji Okuno wrote: > Hi, > > I encountered a issue for USB mic. > > In fist time, my host controller (xHCI) sends single IN-tokens every > 8-SOFs. This is expected action. But, after I open, close and open, my > host controller sends plural IN-tokens between SOF and SOF. > > In Intel Lynx Point, I could not reproduce this issue. > I'm sorry. Unfortunately, I can't explain details about my proprietary > host controler. > > I found the following explanation in the xHCI 1.1 specification > http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf > > In 4.8.3 Endpoint Context State, > 6. The Configure Endpoint Command (Add (A) = `1' and Drop (D) =`1') > shall transition an endpoint, except the Default Control > Endpoint, from the Stopped to the Running state.' > > > So, I modify as the following, then I can run expectedly. > What do you think about this change? Hi, I think we should issue the context drop separately. Are we certain that if both drop and add bits are set at the same time, that the drop bit will be processed before the add? This might be a bug in your hardware, which apparently doesn't check if the context has already been added or not. I'll be glad to make a workaround for it once we have settled on a solution. Can you test the attached patch using both your hardware and the Lynx Point. Thank you! --HPS > > Best regards, > Kohji Okuno --------------020008010507050400020707 Content-Type: text/x-diff; name="xhci.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xhci.diff" === ./xhci.c ================================================================== --- ./xhci.c (revision 271878) +++ ./xhci.c (local) @@ -3805,7 +3805,17 @@ * Get the endpoint into the running state according to the * endpoint context state diagram in the XHCI specification: */ + if (epno > 1) { + /* need to disable endpoint context first */ + xhci_configure_mask(udev, (1U << epno), 1); + + err = xhci_cmd_evaluate_ctx(sc, buf_inp.physaddr, index); + + if (err != 0) + DPRINTF("Could not configure endpoint %u\n", epno); + } + xhci_configure_mask(udev, (1U << epno) | 1U, 0); err = xhci_cmd_evaluate_ctx(sc, buf_inp.physaddr, index); --------------020008010507050400020707-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 06:31:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 751FCA5E; Mon, 22 Sep 2014 06:31:33 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 135521BF; Mon, 22 Sep 2014 06:31:32 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id s8M6VMXl011826; Mon, 22 Sep 2014 15:31:22 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id s8M6VMR08258; Mon, 22 Sep 2014 15:31:22 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi12) id s8M6VMFP001495; Mon, 22 Sep 2014 15:31:22 +0900 Received: from localhost by lomi12.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s8M6VMge001475; Mon, 22 Sep 2014 15:31:22 +0900 Date: Mon, 22 Sep 2014 15:31:22 +0900 (JST) Message-Id: <20140922.153122.2173639902447525862.okuno.kohji@jp.panasonic.com> To: hps@selasky.org Subject: Re: Does the xHCI driver has a spec violation? From: Kohji Okuno In-Reply-To: <541FBB84.6050508@selasky.org> References: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> <541FBB84.6050508@selasky.org> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 06:31:33 -0000 Hi HPS, Could you refer to the following document (4.6.6 Configure Endpoint:P.99)? This document shows: If the Drop Context flag is `1' and the Add Context flag is `1', the xHC shall: o Release the current Resources and Bandwidth allocated to the endpoint and assign the new Resources and Bandwidth requested for the endpoint. Regards, Kohji Okuno. > On 09/22/14 06:58, Kohji Okuno wrote: >> Hi, >> >> I encountered a issue for USB mic. >> >> In fist time, my host controller (xHCI) sends single IN-tokens every >> 8-SOFs. This is expected action. But, after I open, close and open, my >> host controller sends plural IN-tokens between SOF and SOF. >> >> In Intel Lynx Point, I could not reproduce this issue. >> I'm sorry. Unfortunately, I can't explain details about my proprietary >> host controler. >> >> I found the following explanation in the xHCI 1.1 specification >> http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf >> >> In 4.8.3 Endpoint Context State, >> 6. The Configure Endpoint Command (Add (A) = `1' and Drop (D) =`1') >> shall transition an endpoint, except the Default Control >> Endpoint, from the Stopped to the Running state.' >> >> >> So, I modify as the following, then I can run expectedly. >> What do you think about this change? > > Hi, > > I think we should issue the context drop separately. Are we certain that if > both drop and add bits are set at the same time, that the drop bit will be > processed before the add? > > This might be a bug in your hardware, which apparently doesn't check if the > context has already been added or not. I'll be glad to make a workaround for > it once we have settled on a solution. > > Can you test the attached patch using both your hardware and the Lynx Point. > > Thank you! > > --HPS > >> >> Best regards, >> Kohji Okuno > From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 06:42:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0851D5C; Mon, 22 Sep 2014 06:42:08 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D542350; Mon, 22 Sep 2014 06:42:08 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F3B731FE027; Mon, 22 Sep 2014 08:42:05 +0200 (CEST) Message-ID: <541FC4B5.2030406@selasky.org> Date: Mon, 22 Sep 2014 08:41:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kohji Okuno Subject: Re: Does the xHCI driver has a spec violation? References: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> <541FBB84.6050508@selasky.org> <20140922.153122.2173639902447525862.okuno.kohji@jp.panasonic.com> In-Reply-To: <20140922.153122.2173639902447525862.okuno.kohji@jp.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 06:42:08 -0000 On 09/22/14 08:31, Kohji Okuno wrote: > Hi HPS, > > Could you refer to the following document (4.6.6 Configure Endpoint:P.99)? > This document shows: > > If the Drop Context flag is `1' and the Add Context flag is `1', the xHC shall: > o Release the current Resources and Bandwidth allocated to the > endpoint and assign the new Resources and Bandwidth requested for > the endpoint. > Hi, I see. Then what is missing to your patch is to mask away bits 0 and 1, because those are reserved for D0 and D1 and should be zero? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 06:53:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF98BF3F; Mon, 22 Sep 2014 06:53:14 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 80C3F60E; Mon, 22 Sep 2014 06:53:14 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id s8M6rBid008826; Mon, 22 Sep 2014 15:53:12 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili13) with ESMTP id s8M6rCJ26573; Mon, 22 Sep 2014 15:53:12 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi12) id s8M6rCYh011104; Mon, 22 Sep 2014 15:53:12 +0900 Received: from localhost by lomi12.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s8M6rBdo011074; Mon, 22 Sep 2014 15:53:12 +0900 Date: Mon, 22 Sep 2014 15:53:10 +0900 (JST) Message-Id: <20140922.155310.745066180705048059.okuno.kohji@jp.panasonic.com> To: hps@selasky.org Subject: Re: Does the xHCI driver has a spec violation? From: Kohji Okuno In-Reply-To: <541FC4B5.2030406@selasky.org> References: <541FBB84.6050508@selasky.org> <20140922.153122.2173639902447525862.okuno.kohji@jp.panasonic.com> <541FC4B5.2030406@selasky.org> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 06:53:15 -0000 > On 09/22/14 08:31, Kohji Okuno wrote: >> Hi HPS, >> >> Could you refer to the following document (4.6.6 Configure Endpoint:P.99)? >> This document shows: >> >> If the Drop Context flag is `1' and the Add Context flag is `1', the xHC >> shall: >> o Release the current Resources and Bandwidth allocated to the >> endpoint and assign the new Resources and Bandwidth requested for >> the endpoint. >> > > Hi, > > I see. > > Then what is missing to your patch is to mask away bits 0 and 1, because those > are reserved for D0 and D1 and should be zero? Hi, HPS, You are correct, I think. We shold mask D0 and D1. My host controller works both. Thanks, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 09:16:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBDECC6E for ; Mon, 22 Sep 2014 09:16:54 +0000 (UTC) Received: from nm18-vm1.access.bullet.mail.gq1.yahoo.com (nm18-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B09CE7C4 for ; Mon, 22 Sep 2014 09:16:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1411377312; bh=nJCWYyj5mv7qdMoKDAow5CVu5kOxIoTzKi/z9z09QAY=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject:From:Subject; b=xsyje+oMZMnUI0wE3qBP3Pe37F9xEeLanVJo6rTkQBmqtfa/0ODKCBgnW2OmoxLpL6d94dX9jysG8gMo6Sh4lYFuN0S0HHjZjgu/fsQ3D58dwVqKwFbGzOS0a7CqLXqChrKf7kxYj7Zi/SO5dX9ahE/o9a43QOZ76DGFj4aKL3o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=bellsouth.net; b=OPw5Hq7uEm9wn2mMxDR3Bbq9JQsd3jtDvclH9tMMy5wPslvhORgRR0F0g7lQ+y1DC1pOMd9UrtY/Ggnfqsf+X6ecz2ouyroiwlciDIdHIjwtktz+R6AP26WRpZ0UUfoqDE0OQCTSK36bIU2RiXVSNBHqAnZuHxEp8pwQg4vn08Y=; Received: from [216.39.60.176] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 22 Sep 2014 09:15:12 -0000 Received: from [98.138.104.98] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 22 Sep 2014 09:15:12 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 22 Sep 2014 09:15:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1411377312; bh=nJCWYyj5mv7qdMoKDAow5CVu5kOxIoTzKi/z9z09QAY=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject; b=Hsq4spdXYjGXFFykjxfuIpVhtnrYrJcb1Vy6G8yRYoURdykNna/JsmLo3+fO/gZeyl89w9FxUWg2vOLq/OV2OUO7p1eKGcJdr1m+YOBJ3hn8MJo+jw7rLVkJ+O781HiKve5lgkStZw0EJ0gDINKxw2twTPfFuU9LsmLA+KJwTGw= X-Yahoo-Newman-Id: 14666.10975.bm@smtp118.sbc.mail.ne1.yahoo.com Message-ID: <14666.10975.bm@smtp118.sbc.mail.ne1.yahoo.com> Date: Mon, 22 Sep 2014 09:15:12 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: n7wsPekVM1kfjBWA1C0RpN8OrXckfAoyFw37CCWx1VuxNfx YHrPhkKZCGWADurwe.A8GQSq6mgiBs6iqaPohPelSt5wzQg8buh51F8Aa_R7 zcuD2yMg01b9ExFNDmVC.L.KMTjUuKQzjB5SCDMqWG4Uu7yowy8LCfUY1Oth jN7fXepnQkW0sxuEzb2qpKS_UncD3YMMgLRDg9ls7kX6UBU0fLGlQVTKmbKs RSgRRqa.Dqp8SDGYq13U0Owf.rErlKzjXbGzy9cAbP03nZspO0598pEBKOPI xFmigHz9W_Y41uadVR5sP7k0nqRKtH_7WKKr1rzCSj3pi22yIqMgMsHI0qQv cb4qxOcyx0aRJt2Qk.6vWtbhEZqe_A8v9wOfHY.0w4G3rXe46NLKW5qEPjM2 eSFxcdSxKHhh1Qh34VGoysv5zU3u0RDX2P.Vd_sZipddGb2XaPRkbomzQMs9 arOVQ_05qZah5.r98w2JL8mXF1whT9bIKy0FzLqJfOkI.X1etbkiWNwoOQPW kN9mj2mXdjpi6fdcgwmgwpSH5UHPAzTsWZAnBVLsny35u4whUvGZ6WCy_Qcs gqlxHQbzjzBp7n2c70nx21BEpLTfp3MrvVKFj_XvzK4n2jWvR X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: make installworld for i386 fails on Kyuafile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 09:16:55 -0000 I was successful on make buildworld and kernel, but make installworld failed on a missing file somewhere: /usr/share/man/man3/pmclog_read.3.gz -> /usr/share/man/man3/pmclog.3.gz ===> lib/libproc (install) install -C -o root -g wheel -m 444 libproc.a /usr/lib install -C -o root -g wheel -m 444 libproc_p.a /usr/lib install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib install -l s libproc.so.2 /usr/lib/libproc.so install -C -o root -g wheel -m 444 /BETA1/usr/src/lib/libproc/libproc.h /usr/include ===> lib/libproc/tests (install) install -o root -g wheel -m 444 Kyuafile.auto /usr/tests/lib/libproc/Kyuafile install: /usr/tests/lib/libproc/Kyuafile: No such file or directory *** Error code 71 Stop. bmake[6]: stopped in /BETA1/usr/src/lib/libproc/tests *** Error code 1 svn revision is 271942. I never had this particular error happen before, even though I've had successful builds and installs subsequent to 20140110 (referring to UPDATING; I never used NO_CLEAN). What could have happened this time? Shouuld I follow the directions in UPDATING 20140110 and find /BETA1/usr/obj.i386 -name Kyuafile | xargs rm -f ? or svn update and rebuild, but this time running rm -R /BETA1/usr/obj.i386/* before rebuilding? Or is there a bug? Tom From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 09:56:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D16A1BCD for ; Mon, 22 Sep 2014 09:56:22 +0000 (UTC) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91383BB4 for ; Mon, 22 Sep 2014 09:56:22 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id n8so5109903qaq.40 for ; Mon, 22 Sep 2014 02:56:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=lf6crV02ohnzNMv2oQKavk31MOj1tlU+AN+yfgEBhag=; b=WiSrf2o0I+r3nM+6fyrQCaJCvdGJWhQM11oFtaQ3tt6UWd8vdUmNPlMwsudV1gvFP9 a4gV0CPnqMouXCeD7w0csf9V5hKq9LTmRfDU5nrk4pugETBVr3JRLcip0e6Vk0xg2nuz nJc/0xC7JjIhmuiop2aqiBcTdZ3HOBOdsEN3/oDb9yTSyBGCsT/QKIPG5yIvoY3LZbcC e+zv0Aja6t2StnxBOg8adUTlS++ApJnThZUi9goIUaA+pdSe0UA1IhcxTUjW+0t6a9ik UsD+oWn4NFEZRFwaizdIc967G4gLQsb9IXMcRqVpVhww+4yMU4RGAFe+64qnU8ahMwO+ GEoA== X-Gm-Message-State: ALoCoQnhl4Zmc77liZD6Z7WSPCBP8rAR8tX3DOUCZ9BACN1F9ISu5Mxf3OdZUrFsb7WaY9zN5hUU X-Received: by 10.229.192.197 with SMTP id dr5mr28739941qcb.18.1411379780884; Mon, 22 Sep 2014 02:56:20 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.75.134 with HTTP; Mon, 22 Sep 2014 02:56:00 -0700 (PDT) X-Originating-IP: [172.28.89.191] In-Reply-To: <14666.10975.bm@smtp118.sbc.mail.ne1.yahoo.com> References: <14666.10975.bm@smtp118.sbc.mail.ne1.yahoo.com> From: Julio Merino Date: Mon, 22 Sep 2014 11:56:00 +0200 X-Google-Sender-Auth: K1dXdaD2p25vvhR7MsaaatU6tpc Message-ID: Subject: Re: make installworld for i386 fails on Kyuafile To: Thomas Mueller Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 09:56:22 -0000 On Mon, Sep 22, 2014 at 11:15 AM, Thomas Mueller wrote: > I was successful on make buildworld and kernel, but make installworld failed on a missing file somewhere: > > /usr/share/man/man3/pmclog_read.3.gz -> /usr/share/man/man3/pmclog.3.gz > ===> lib/libproc (install) > install -C -o root -g wheel -m 444 libproc.a /usr/lib > install -C -o root -g wheel -m 444 libproc_p.a /usr/lib > install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib > install -l s libproc.so.2 /usr/lib/libproc.so > install -C -o root -g wheel -m 444 /BETA1/usr/src/lib/libproc/libproc.h /usr/include > ===> lib/libproc/tests (install) > install -o root -g wheel -m 444 Kyuafile.auto /usr/tests/lib/libproc/Kyuafile > install: /usr/tests/lib/libproc/Kyuafile: No such file or directory Fixed in r271950. Problem introduced in r271937 which seems to have missed part of the change sent out for review in D710. From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 10:22:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60B9F9CC; Mon, 22 Sep 2014 10:22:29 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D380E79; Mon, 22 Sep 2014 10:22:28 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 80A4B1FE027; Mon, 22 Sep 2014 12:22:26 +0200 (CEST) Message-ID: <541FF859.6090709@selasky.org> Date: Mon, 22 Sep 2014 12:22:17 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kohji Okuno Subject: Re: Does the xHCI driver has a spec violation? References: <541FBB84.6050508@selasky.org> <20140922.153122.2173639902447525862.okuno.kohji@jp.panasonic.com> <541FC4B5.2030406@selasky.org> <20140922.155310.745066180705048059.okuno.kohji@jp.panasonic.com> In-Reply-To: <20140922.155310.745066180705048059.okuno.kohji@jp.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 10:22:29 -0000 Hi, Please verify: http://svnweb.freebsd.org/changeset/base/271953 Thank you! --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 12:10:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C98087B3; Mon, 22 Sep 2014 12:10:12 +0000 (UTC) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 865B7C2E; Mon, 22 Sep 2014 12:10:12 +0000 (UTC) Received: from fwd16.aul.t-online.de (fwd16.aul.t-online.de [172.20.26.243]) by mailout06.t-online.de (Postfix) with SMTP id 1DF7F44D460; Mon, 22 Sep 2014 14:10:04 +0200 (CEST) Received: from [192.168.119.10] (XLtQT6ZAQh5vn+3boH63ziuZO38FWvsFKxcBhmIhzQGlLwXHcU30Dyvlfihfw0hgnj@[84.154.118.168]) by fwd16.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XW2RJ-0rEt5E0; Mon, 22 Sep 2014 14:09:57 +0200 Message-ID: <54201192.5080906@freebsd.org> Date: Mon, 22 Sep 2014 14:09:54 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Gyrd Thane Lange , freebsd-current@freebsd.org Subject: Re: [patch] syscons/vt keymap: Norwegian country code conflicts with default value References: <20140921183936.03617590@onyx.thanelange.no> In-Reply-To: <20140921183936.03617590@onyx.thanelange.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: XLtQT6ZAQh5vn+3boH63ziuZO38FWvsFKxcBhmIhzQGlLwXHcU30Dyvlfihfw0hgnj X-TOI-MSGID: 514bd1c8-1bb9-4619-9413-10a360754b0b Cc: freebsd-stable stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 12:10:12 -0000 Am 21.09.2014 um 18:39 schrieb Gyrd Thane Lange: > Hi, > > Recent changes in keymap namning for syscons/vt to use shorter names > has exposed a conflict with the value "no" both used as country code > for Norway and as a default value indicating that no keymap is set. > > The attached patch proposes to use "" (empty string) as default value > instead. Hi Gyrd, thank you for reporting the issue! I have just committed a slightly different patch to -CURRENT and plan to merge it to 10-STABLE in time for the next BETA. You may want to check-out r271958 ... The approach I have chosen it to let "NO" continue to stand for "do not load any keymap", while "no" is now recognized as equivalent to "no.kbd". The new semantics of the keymap parameter in rc.conf are: keymap='' ==> do not load any keymap (unchanged) keymap=NO ==> do not load any keymap (unchanged) keymap=no ==> load Norwegian keymap (new) This may still catch people that have edited rc.conf to use "no" in the meaning "no keymap" by accident, but I see no other approach that better complies with POLA ... An alternative to a MFC to 10-STABLE (and 10.1) might be to mention this specific case in the release notes (and to suggest "keymap=no.kbd" as a work-around). But I'll try to get approval for the MFC in time for 10.1-BETA3 ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 12:12:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76C9CBA7; Mon, 22 Sep 2014 12:12:24 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB05D08; Mon, 22 Sep 2014 12:12:23 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id s8MCCLAV000603; Mon, 22 Sep 2014 21:12:21 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili16) with ESMTP id s8MCCLM23752; Mon, 22 Sep 2014 21:12:21 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi15) id s8MCCLdO027424; Mon, 22 Sep 2014 21:12:21 +0900 Received: from localhost by lomi15.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s8MCCLWZ027398; Mon, 22 Sep 2014 21:12:21 +0900 Date: Mon, 22 Sep 2014 21:12:21 +0900 (JST) Message-Id: <20140922.211221.200497674823696129.okuno.kohji@jp.panasonic.com> To: hps@selasky.org Subject: Re: Does the xHCI driver has a spec violation? From: Kohji Okuno In-Reply-To: <541FF859.6090709@selasky.org> References: <541FC4B5.2030406@selasky.org> <20140922.155310.745066180705048059.okuno.kohji@jp.panasonic.com> <541FF859.6090709@selasky.org> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 12:12:24 -0000 > Hi, > > Please verify: > http://svnweb.freebsd.org/changeset/base/271953 > > Thank you! > > --HPS Hi, HPS, I confirmed your commit. It was no problem. Many thanks, Kohji Okuno. From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 12:18:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32B5C29D; Mon, 22 Sep 2014 12:18:40 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0BD0D85; Mon, 22 Sep 2014 12:18:39 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id j5so1811189qga.25 for ; Mon, 22 Sep 2014 05:18: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=l7q4xn43AYPwUsyuVnrWBAEpbwpnhAI3bAPdYr7u77w=; b=c0TpLnKyk3ZARxiMxP9lapc316EQPfaQdqCXHSbxzo97pz7/yWURbAg7gziS1gmkKn H+wzxs6+KiVR4q0BzhC+MT0WRvN7y5pN+QXtbeebLPdTCY8ZreFMSFf5qjbn+gvvC4k2 wBUECvOCLErwuoN/ko5UC+whdArpE8XFdalZ7G6b9UmtrpjeFpr3jbtXlBeVY3LNDhcz HkOQOg+D+c/XbEzb8DpjEj/0VY7r1kfPpHcjByDNx+xaI1cQ3zgZj5+buoUqemt1D1KA zzBsq9dhaU5N2NwPOXRrLFH9ZjlcaKegjw2/cxG8Na+IbbRw9KbIqmZBR/m8FEjAD+FT bLig== MIME-Version: 1.0 X-Received: by 10.140.30.227 with SMTP id d90mr21776793qgd.55.1411388318852; Mon, 22 Sep 2014 05:18:38 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Mon, 22 Sep 2014 05:18:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Sep 2014 14:18:38 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Ryan Stone Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 12:18:40 -0000 Hi Ryan, in gso_dispatch(), I put the "eh_len" parameter in order to have the offset of the L3 header. In this way, if someone adds QinQ support, just call gso_dispatch() with the right length of the MAC header. During the execution the GSO, the MAC header is simply copied as it is in each new segment. Instead, for the vxlan support, we can define a new entries in gso_type, define a new "gso_functions" to properly handle these types of packets and mark the packet in the network stack with the correct GSO type. For now we used only 4 bit to encode the gso_type in m_pkthdr.csum_flags, but, in the future, we can use more bit or a specific field in the m_pkthdr. Your suggestions are very good, but I tried to make a software TSO, modifying as little as possible the network stack. Thanks, Stefano 2014-09-18 20:50 GMT+02:00 Ryan Stone : > On Wed, Sep 17, 2014 at 4:27 AM, Stefano Garzarella > wrote: > > Much of the advantage of TSO comes from crossing the network stack only > > once per (large) segment instead of once per 1500-byte frame. > > GSO does the same both for segmentation (TCP) and fragmentation (UDP) > > by doing these operations as late as possible. > > My initial impression is that this is a layering violation. Code like > this gives me pause: > > + eh = mtod(m, struct ether_vlan_header *); > + if (eh->evl_encap_proto == htons(ETHERTYPE_VLAN)) { > + eh_len = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN; > + } else { > + eh_len = ETHER_HDR_LEN; > + } > + > + return gso_dispatch(ifp, m, eh_len); > > If someone adds QinQ support, this code must be updated. When vxlan > support comes in, we must update this code or else the outer UDP > packet gets fragmented instead of the inner TCP payload being > segmented. As more tunneling protocols get added to FreeBSD, the > dispatch code for GSO gets uglier and uglier. > > It seems to me that the real problem that we are trying to solve is a > lack of batching in the kernel. Currently the network stack operates > on the mbuf (packet) boundary. It seems to me that we could introduce > a "packet group" concept that is guaranteed to have the same L3 and L2 > endpoint. In the transmit path, we would initially have a single > (potentially oversized) packet in the group. When TCP segments the > packet, it would add each packet to the packet group and pass it down > the stack. Because we guarantee that the endpoints are the same for > every packet in the group, the L3 code can do a single routing table > lookup and the L2 code can do a single l2table lookup for the entire > group. > > The disadvantages of packet groups would be that: > a) You have touch a lot more code in a lot more places to take > advantage of the concept. > b) TSO inherently has the same layering problems. If we're going to > solve the problem for tunneling protocols then GSO might well be able > to take advantage of them. > -- *Stefano Garzarella* stefano.garzarella@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 13:31:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F4C7EE8; Mon, 22 Sep 2014 13:31:33 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD8C48EA; Mon, 22 Sep 2014 13:31:32 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id s8MDJUqC018844; Mon, 22 Sep 2014 09:19:30 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Mon, 22 Sep 2014 09:19:30 -0400 (EDT) Date: Mon, 22 Sep 2014 09:19:30 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Julian Elischer Subject: Re: libthr and main thread stack size In-Reply-To: <541E31E0.8020108@freebsd.org> Message-ID: References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> <541E31E0.8020108@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , "Ivan A. Kosarev" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 13:31:33 -0000 On Sun, 21 Sep 2014, Julian Elischer wrote: > On 9/20/14, 3:27 AM, John Baldwin wrote: >> On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: >>> On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: >>>> On Aug 8, 2014, at 5:22 AM, Konstantin Belousov >>>> wrote: >>>> >>>> ? >>>> >>>>> Below is the patch which adds environment variable >>>>> LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the >>>>> main thread stack left as is, and other threads allocate stack >>>>> below the area of RLIMIT_STACK. Try it. I do not want to set this >>>>> behaviour as default. >>>> Is there a reason this should not be the default? Looking at the >>>> getrlimit() page on the OpenGroup?s site they say: >>>> >>>> RLIMIT_STACK This is the maximum size of the initial thread's stack, >>>> in bytes. The implementation does not automatically grow the stack >>>> beyond this limit. If this limit is exceeded, SIGSEGV shall be >>>> generated for the thread. If the thread is blocking SIGSEGV, or the >>>> process is ignoring or catching SIGSEGV and has not made arrangements >>>> to use an alternate stack, the disposition of SIGSEGV shall be set to >>>> SIG_DFL before it is generated. >>>> >>>> Does posix say something different? >>>> >>>> I ran into this issue when debugging a segfault on Postgres when >>>> running an (arguably quite bogus) query that should have fit within >>>> both the configured stack rlimit and Postgres? configured stack limit. >>>> The Postgres backend is really just single threaded, but happens >>>> to pull in libpthread due to the threading support in some of the >>>> libraries it uses. The segfault definitely violates POLA. >>>> >>>> ? Justin >>> I am conservative to not disturb the address space layout in single go. >>> If enough people test this setting, I can consider flipping the default >>> to the reverse. >>> >>> I am still curious why the things were done in this way, but nobody >>> replied. >> I suspect it was done out of reasons of being overly conservative in >> interpreting RLIMIT_STACK. I think it is quite surprising behavior though >> and >> would rather we make your option the default and implement what the Open >> Group >> says above. >> > that is my memory.. > The transition from a non threaded app to a threaded app with one thread is > sort of an undefined area. > Feel free to change it if Dan agrees.. I'm all for adopting what POSIX specifies as the default. I would shy away from adding another knob (LIBPTHREAD_BIGSTACK_MAIN) if possible. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 15:14:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29C4A817 for ; Mon, 22 Sep 2014 15:14:46 +0000 (UTC) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAF5F820 for ; Mon, 22 Sep 2014 15:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s2048; t=1411398884; bh=l+YG0TlKYqBEhr8PdZGGSSd+sfr8DGRkJCOTBFWOQk4=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:From:Subject; b=cPhezwFi86kRBrhwkPP91Kh9dKOl0ZNrDHQNdme5dwJac0ChLm6qz2E7FLUa+UG5ofGl/tQIWmmJ2LhtpOpKjYsD17D276MTApMS4kHFREXVaUWnlEEQbYfzhG8VfXu/jiTU6aVd4lP5DmlgwU4eH49pZS6npNWXKbcEl5J2j2ccj5Sssz9ZPW6Xe+srpcQOrBg+SyO+ycYGfS0JQL3cwTZIE38KXGwglBke/jFcTwAkphPtvPqPZdq4XsI/t1S3GDtVGyW9rADI92BfvZjf65PuwLNb9zxHSzIsJDxlYiw4Ujtphtsz3Xolkk7INFln7/LHI/ob6uFbsMFmDuYLVg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com.br; b=Vs1sIUJoSAOHOO07CQ3O/sPKpWiH2OK3x9r8Z6smvb8n69DMvedga9QQ+2nTEBwx8CNTuN5GOmuSAvWLNXGHQ4wW5vOqYpFQ2o6Upsz7jL31QnsKCAs3hVTx14AhjXI+AEqOwxT2E4GpQtyxLUKrVjQUg+z2au1YyCTSlf8ZHEwanxERRyv6wIzgijMQ3szpXPAF12jv2urzvd9TYjQV/Zdc4k8V5T9SfaAEGy4iwcwAIulibNXR7WDCaMoiZOmRZaUpYbFEy1ifdJ0vOE1WayVJx7fp/6OSsS6VQv+zIy4mXLMj/75FoI/Ss4Ik6uCgEbgpy3ZTkBbqNGgZPfnx8A==; Received: from [66.196.81.170] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 22 Sep 2014 15:14:44 -0000 Received: from [68.142.230.74] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 22 Sep 2014 15:14:43 -0000 Received: from [127.0.0.1] by smtp231.mail.bf1.yahoo.com with NNFMP; 22 Sep 2014 15:14:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.br; s=s1024; t=1411398883; bh=l+YG0TlKYqBEhr8PdZGGSSd+sfr8DGRkJCOTBFWOQk4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=ugrvvpyxE3OzrPUsEHJsoz/4CJFMdPCD6eZtM7XbS1Kxob2ZFW2IdB9e/G4ntBs+N1IlgSxmrR+WR2r1YyiZBnz8wqBTpzVj1L8+5A4UOjVoBa9p59L70itzHADD47e8GlKvfLoDHk5oXwaWrXxD5clmfX3GNE6jquZja57QzF4= X-Yahoo-Newman-Id: 937305.91079.bm@smtp231.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SPgEDuoVM1n50sVTGBbkzmlZwDMZtD9PiXf63q6kZKT3oKR 5B7AcDlDejSgL81SgBT2vTrTB12B3lattfifew3iC_nc.IDRddiWgLEx68ac 74Rk0yDOWDegTbzPmk8eqaWiaF_7uUOBD96hT7t2Ci1diXd1q0Ed33CX1uvT k4ZUY2TkNCrIcZlacjhBdJHrFMmV7DI7VrnnAd2M4H6PXOzyz_V8b9Igt8lx HvsD5RI9m4EA_8UMWVbUDDPGKbYhWnHFY1lxsfupmoti.kfMhr39siX8sHrw zep29peBzy61PJjdJMWbIbwRb77akvEIN11EBYLo3bqgLPBDJQdvz7vjUFt6 kkXXV3LVlNlji4QQb0l2NpfIXSA3tkCtynpzEZJUZKybMig9OHWPYUpbCqFI urtqNZlxZZGTXeqNKkfaxzU8aJDUmGGFSHdRmvpz7rl65w75B_rD33YNcaNS 7OEcAbhy4c6tOL815dTgqEm.z177mKlWnLgBj2WDyHh6pSovAprwuLuTb2Mq R9kSXpxCv_reNzW_cphSLg2icZ.vRPkTb93VCBSRGu.gT322NP6jCaSU9_g9 g0rTvGR18XTa.StctOG_KUcbeP4JukvjyDsP6cNwvJh0clJ.z4NnpZpjudKo - X-Yahoo-SMTP: 51p0rh2swBCh3zxf6sJkNseoFwQzw1o- Message-ID: <54203CE7.60900@yahoo.com.br> Date: Mon, 22 Sep 2014 12:14:47 -0300 From: Danilo Egea Gondolfo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 15:14:46 -0000 Hello, After r271705 (probably) I'm getting this error in dmesg: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state The system freezes for a little while. The "sysctl hw.dri.0.info.i915_error_state" is here: https://people.freebsd.org/~danilo/i915.txt # uname -a FreeBSD capeta 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r271887: Fri Sep 19 23:11:02 BRT 2014 danilo@capeta:/usr/obj/usr/src/sys/CAPETA amd64 CPU info: [drm] Initialized drm 1.1.0 20060810 CPU: Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz (2095.29-MHz K8-class CPU) Origin="GenuineIntel" Id=0x206a7 Family=0x6 Model=0x2a Stepping=7 Features=0xbfebfbff Features2=0x1dbae3bf AMD Features=0x28100800 AMD Features2=0x1 XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 16:11:43 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51F62575 for ; Mon, 22 Sep 2014 16:11:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A49DE39 for ; Mon, 22 Sep 2014 16:11:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8MGBgq8023538 for ; Mon, 22 Sep 2014 16:11:42 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8MGBgbA023536 for current@FreeBSD.org; Mon, 22 Sep 2014 16:11:42 GMT (envelope-from bdrewery) Received: (qmail 42361 invoked from network); 22 Sep 2014 11:11:38 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 22 Sep 2014 11:11:38 -0500 Message-ID: <54204A33.3070700@FreeBSD.org> Date: Mon, 22 Sep 2014 11:11:31 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Michelle Sullivan , ports@FreeBSD.org Subject: Re: [HEADSUP] pkg(8) is now the only package management tool References: <20140901195520.GB77917@ivaldir.etoilebsd.net> <54050D07.4010404@sorbs.net> <541F6507.70904@sorbs.net> In-Reply-To: <541F6507.70904@sorbs.net> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j9M15kmcleetDPhw7XHuDmKAXdcSBPCre" Cc: pkg@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 16:11:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j9M15kmcleetDPhw7XHuDmKAXdcSBPCre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/21/2014 6:53 PM, Michelle Sullivan wrote: > Michelle Sullivan wrote: >> Baptiste Daroussin wrote: >> =20 >>> Hi all, >>> >>> The ports tree has been modified to only support pkg(8) as package ma= nagement >>> system for all supported version of FreeBSD. >>> >>> if you were still using pkg_install (pkg_* tools) you will have to up= grade your >>> system. >>> >>> The simplest way is >>> cd /usr/ports/ports-mgmt/pkg >>> make install >>> then run=20 >>> pkg2ng >>> >>> =20 >=20 > So despite being told 'use the quarterly, patches can be applied to it > if requested' and updating ports I maintain asking specifically for the= > patches to be merged... >=20 > Still all broken (though patches applied to HEAD)... Nice one... >=20 Which ports and PR? --=20 Regards, Bryan Drewery --j9M15kmcleetDPhw7XHuDmKAXdcSBPCre Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUIEo2AAoJEDXXcbtuRpfP58wIAJ1zYr4wC8ZuH9Quqci4SiIJ /7+fYYEFL32zUqBIYpEJuZaE8Gz8LlUqydRxbfay9bcDWTypLFlSkQ21Ryr/SjY3 okoe9eXB/RaSzTaKNaDiJCK/DFdyPViXYPCIc8YvppTr46wyzYSwzRXlFezS8x7/ nQi4l8tfwcn1VQQkkfMCQiJKN6DepofrK1Jw1qA4ZHV4MQ5XW+NA0zdhEENCD/O5 voIXmIi7g+zTOS0ODZ1yVLiVZ9fqspEP5y4rM/IM1yrSqzOBB4ByYchURZOWnViz IrtOOqu6g+rkORucwtF8fPAlxXzkc8TKVchJoOUI/uQ4Dp5iJodgUYQH5U1PA8o= =tx7X -----END PGP SIGNATURE----- --j9M15kmcleetDPhw7XHuDmKAXdcSBPCre-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 17:28:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17A2A8ED; Mon, 22 Sep 2014 17:28:53 +0000 (UTC) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1E6A2C; Mon, 22 Sep 2014 17:28:52 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIGAC5YIFRR8bfp/2dsb2JhbABggw6BIArSIAGBDRcBeYQEAQEEOhwjEAsOCgklDyoeBhOIQgGyApI9AReQBgeESwEEnRWVU4IegUU7L4JKAQEB Received: from 233.183-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.183.233]) by relay.skynet.be with ESMTP; 22 Sep 2014 19:28:45 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.9/8.14.9) with ESMTP id s8MHSiHF004814; Mon, 22 Sep 2014 19:28:44 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Mon, 22 Sep 2014 19:28:44 +0200 From: Tijl Coosemans To: Stefan Esser Subject: Re: [patch] syscons/vt keymap: Norwegian country code conflicts with default value Message-ID: <20140922192844.7de1bb6b@kalimero.tijl.coosemans.org> In-Reply-To: <54201192.5080906@freebsd.org> References: <20140921183936.03617590@onyx.thanelange.no> <54201192.5080906@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Gyrd Thane Lange , freebsd-current@freebsd.org, freebsd-stable stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 17:28:53 -0000 On Mon, 22 Sep 2014 14:09:54 +0200 Stefan Esser wrote: > Am 21.09.2014 um 18:39 schrieb Gyrd Thane Lange: > > Hi, > > > > Recent changes in keymap namning for syscons/vt to use shorter names > > has exposed a conflict with the value "no" both used as country code > > for Norway and as a default value indicating that no keymap is set. > > > > The attached patch proposes to use "" (empty string) as default value > > instead. > > Hi Gyrd, > > thank you for reporting the issue! > > I have just committed a slightly different patch to -CURRENT and plan > to merge it to 10-STABLE in time for the next BETA. > > You may want to check-out r271958 ... > > > The approach I have chosen it to let "NO" continue to stand for "do > not load any keymap", while "no" is now recognized as equivalent to > "no.kbd". > > > The new semantics of the keymap parameter in rc.conf are: > > keymap='' ==> do not load any keymap (unchanged) > keymap=NO ==> do not load any keymap (unchanged) > keymap=no ==> load Norwegian keymap (new) > > This may still catch people that have edited rc.conf to use "no" in > the meaning "no keymap" by accident, but I see no other approach that > better complies with POLA ... Maybe NONE. It's already being used in a number of cases. From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 19:21:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2AD7B38; Mon, 22 Sep 2014 19:21:49 +0000 (UTC) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F483A92; Mon, 22 Sep 2014 19:21:49 +0000 (UTC) Received: from fwd24.aul.t-online.de (fwd24.aul.t-online.de [172.20.26.129]) by mailout04.t-online.de (Postfix) with SMTP id CCB6336769A; Mon, 22 Sep 2014 21:15:25 +0200 (CEST) Received: from [192.168.119.10] (X7AZigZZQh2eqVyBZuJx9r9NqoPALGJ1aIP9sE8xnOZivG2OtG9w3-xJ8ZJbOeNwHB@[84.154.118.168]) by fwd24.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XW951-1J2CaO0; Mon, 22 Sep 2014 21:15:23 +0200 Message-ID: <54207548.2010906@freebsd.org> Date: Mon, 22 Sep 2014 21:15:20 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Tijl Coosemans Subject: Re: [patch] syscons/vt keymap: Norwegian country code conflicts with default value References: <20140921183936.03617590@onyx.thanelange.no> <54201192.5080906@freebsd.org> <20140922192844.7de1bb6b@kalimero.tijl.coosemans.org> In-Reply-To: <20140922192844.7de1bb6b@kalimero.tijl.coosemans.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: X7AZigZZQh2eqVyBZuJx9r9NqoPALGJ1aIP9sE8xnOZivG2OtG9w3-xJ8ZJbOeNwHB X-TOI-MSGID: 2e1c4859-7c55-4392-b730-90e921824b81 Cc: Gyrd Thane Lange , freebsd-current@freebsd.org, freebsd-stable stable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 19:21:50 -0000 Am 22.09.2014 um 19:28 schrieb Tijl Coosemans: > On Mon, 22 Sep 2014 14:09:54 +0200 Stefan Esser wrote: >> Am 21.09.2014 um 18:39 schrieb Gyrd Thane Lange: >>> Hi, >>> >>> Recent changes in keymap namning for syscons/vt to use shorter names >>> has exposed a conflict with the value "no" both used as country code >>> for Norway and as a default value indicating that no keymap is set. >>> >>> The attached patch proposes to use "" (empty string) as default value >>> instead. >> >> Hi Gyrd, >> >> thank you for reporting the issue! >> >> I have just committed a slightly different patch to -CURRENT and plan >> to merge it to 10-STABLE in time for the next BETA. >> >> You may want to check-out r271958 ... >> >> >> The approach I have chosen it to let "NO" continue to stand for "do >> not load any keymap", while "no" is now recognized as equivalent to >> "no.kbd". >> >> >> The new semantics of the keymap parameter in rc.conf are: >> >> keymap='' ==> do not load any keymap (unchanged) >> keymap=NO ==> do not load any keymap (unchanged) >> keymap=no ==> load Norwegian keymap (new) >> >> This may still catch people that have edited rc.conf to use "no" in >> the meaning "no keymap" by accident, but I see no other approach that >> better complies with POLA ... > > Maybe NONE. It's already being used in a number of cases. This was one of the alternatives, which I considered before the commit. Reasons for my choice of "no" vs. "NO" (and not "NONE"): 1) NO is the default (in defaults/rc.conf) and may have found its way into individual rc.conf files. I wanted to preserve its meaning. 2) Tools like bsdconfig need to be made version aware and to use NO for releases before 10.1 and NONE for 10.1 and later. IIRC, the use of NONE in rc.conf should be limited to cases that need a value besides NO (e.g. in the case of sendmail_enable, where both NO and NONE have special meaning). If there are no strong arguments against the patch that I committed, I'd like to MFC it to -STABLE. But if there are better alternatives (and I do not think that "NONE" is better, sorry), I'd like to hear about them in time for BETA3 ... Regards, STefan From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 19:22:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE1F1D1A; Mon, 22 Sep 2014 19:22:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5BE1A9E; Mon, 22 Sep 2014 19:22:04 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E3302B98E; Mon, 22 Sep 2014 15:22:02 -0400 (EDT) From: John Baldwin To: Warner Losh Subject: Re: [PATCH] Various fixes to wl(4) Date: Mon, 22 Sep 2014 15:20:05 -0400 Message-ID: <2930763.7FbKMgYveJ@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <4D1FD834-2861-4D16-9ABF-21B8B07561F8@bsdimp.com> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <4D1FD834-2861-4D16-9ABF-21B8B07561F8@bsdimp.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Sep 2014 15:22:03 -0400 (EDT) Cc: freebsd-current@freebsd.org, imp@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 19:22:05 -0000 On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: > I got rid of my pre-802.11 WaveLAN cards about 8 years go after not h= aving > them in a system at all for 8 years. And they were about 4 years obso= lete > when I took them out of service=E2=80=A6 I=E2=80=99m not even sure I = have a machine with an > ISA slot to test the card, even if I still had it. >=20 > Sorry I can=E2=80=99t help more :) If no one tests them then I will happily toss the driver into the dustb= in,=20 just giving folks a chance to test patches before I do so. (I'm secret= ly=20 hoping I can purge several old drivers during the current round of time= out()=20 purging.) > Warner >=20 > On Sep 19, 2014, at 2:07 PM, John Baldwin wrote: > > This patch fixes various issues in wl(4) including: > >=20 > > - Use bus_space instead of inb/outb. > > - Use device_printf() and if_printf() > > - Use callout(9) instead of timeout(9) > > - Don't hold the driver lock across sleeping actions like > >=20 > > bus_teardown_intr(), subyte(), etc. > >=20 > > - Don't recurse on the driver lock. > >=20 > > The patch is against HEAD but probably applies to 9 and 10 as well.= > >=20 > > http://people.freebsd.org/~jhb/patches/wl_cleanup.patch --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 19:22:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07CC8D1C; Mon, 22 Sep 2014 19:22:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2463A9F; Mon, 22 Sep 2014 19:22:04 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E212B99A; Mon, 22 Sep 2014 15:22:03 -0400 (EDT) From: John Baldwin To: "Justin T. Gibbs" Subject: Re: libthr and main thread stack size Date: Mon, 22 Sep 2014 15:18:54 -0400 Message-ID: <1502207.DmYsYJhHW2@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <53E36E84.4060806@ivan-labs.com> <20140920170658.GE2210@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Sep 2014 15:22:03 -0400 (EDT) Cc: Konstantin Belousov , "Ivan A. Kosarev" , freebsd-current@freebsd.org, doc@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 19:22:05 -0000 On Sunday, September 21, 2014 09:36:25 PM Justin T. Gibbs wrote: > On Sep 20, 2014, at 11:06 AM, Konstantin Belousov wrote: > > On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote: > >> I suspect it was done out of reasons of being overly conservative in > >> interpreting RLIMIT_STACK. I think it is quite surprising behavior > >> though and would rather we make your option the default and implement > >> what the Open Group says above. > > > > Ok, below is the patch. I felt bad about adding yet another magic and > > undocumented tunable to our libthr. Since there seems to be no > > alternative than a tunable to enforce old behaviour, I documented > > the quirks I am aware of. > > Why do we need to support the old behavior? Any program that ran in the old > model will run in the new. In the unlikely event that someone was using > the old scheme for administrative control, there are other mechanisms for > this already available that we can point them to instead. I agree with this. In my experience the issue it has always been the opposite (people having issues with the main stack shrinking). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 19:41:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35A80744; Mon, 22 Sep 2014 19:41:28 +0000 (UTC) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) by mx1.freebsd.org (Postfix) with ESMTP id B095DCCB; Mon, 22 Sep 2014 19:41:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id E5D0240518; Mon, 22 Sep 2014 21:35:27 +0200 (CEST) Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id b1W6-s1m4Jue; Mon, 22 Sep 2014 21:35:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 7D28840591; Mon, 22 Sep 2014 21:35:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at bouvier.get.c.bitbit.net Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xQPwuIU_cre9; Mon, 22 Sep 2014 21:35:27 +0200 (CEST) Received: from onyx.thanelange.no (cm-84.208.179.208.getinternet.no [84.208.179.208]) by bouvier.getmail.no (Postfix) with ESMTP id A668840518; Mon, 22 Sep 2014 21:35:26 +0200 (CEST) Date: Mon, 22 Sep 2014 21:35:24 +0200 From: Gyrd Thane Lange To: Tijl Coosemans Subject: Re: [patch] syscons/vt keymap: Norwegian country code conflicts with default value Message-ID: <20140922213524.3b95b9a5@onyx.thanelange.no> In-Reply-To: <20140922192844.7de1bb6b@kalimero.tijl.coosemans.org> References: <20140921183936.03617590@onyx.thanelange.no> <54201192.5080906@freebsd.org> <20140922192844.7de1bb6b@kalimero.tijl.coosemans.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable stable , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 19:41:28 -0000 On Mon, 22 Sep 2014 19:28:44 +0200 Tijl Coosemans wrote: > On Mon, 22 Sep 2014 14:09:54 +0200 Stefan Esser > wrote: > > Am 21.09.2014 um 18:39 schrieb Gyrd Thane Lange: > > > Hi, > > > > > > Recent changes in keymap namning for syscons/vt to use shorter > > > names has exposed a conflict with the value "no" both used as > > > country code for Norway and as a default value indicating that no > > > keymap is set. > > > > > > The attached patch proposes to use "" (empty string) as default > > > value instead. > > > > Hi Gyrd, > > > > thank you for reporting the issue! > > > > I have just committed a slightly different patch to -CURRENT and > > plan to merge it to 10-STABLE in time for the next BETA. > > > > You may want to check-out r271958 ... > > > > > > The approach I have chosen it to let "NO" continue to stand for "do > > not load any keymap", while "no" is now recognized as equivalent to > > "no.kbd". Thanks! That'll get the keymap working. > > The new semantics of the keymap parameter in rc.conf are: > > > > keymap='' ==> do not load any keymap (unchanged) > > keymap=NO ==> do not load any keymap (unchanged) > > keymap=no ==> load Norwegian keymap (new) > > > > This may still catch people that have edited rc.conf to use "no" in > > the meaning "no keymap" by accident, but I see no other approach > > that better complies with POLA ... > > Maybe NONE. It's already being used in a number of cases. My original patch suggested an empty string '', and I still favour that. That is already an accepted value for "no keyboard specified" and thus requires no code change to work. The keyboard setting next to keymap already use an empty string for a default value, so there is already precedent. Using NONE still risks the possibility of colliding with a valid file name in the future, but anything is better than NO. In general I think the use of NO as a default value should only be used when there exists a complementing YES value. In any case, whatever new default value (either empty or NONE) should be documented in defaults/rc.conf as the preferred way, in order to stop more users placing NO in the keymap setting. Additionally we can provide a warning in the syscons script for users that have used "NO" (capital case). Gyrd ^_^ From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 19:42:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93E39B56; Mon, 22 Sep 2014 19:42:36 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA4CDCFC; Mon, 22 Sep 2014 19:42:35 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id x48so2059830wes.1 for ; Mon, 22 Sep 2014 12:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=cyWY6fKFdRpqO/P0Cf26Z/umC0v/mNON5r/9JnD93nc=; b=zr48FyzaDvirojuWr3wRozivPFMPBW+tJsz58KtqZPKnwmHroxswHP7zlpAw64DR3U PCEmo3wUgW7QOc2dy+V00AmolMDEgpb8QMmx6X65x7GhtvCtxiKaIwyQ8hpkwdsxF61m Aq7Hx4xmlKyK3MOx89SvmRIvUh6YYV36RIg22TOCXa7BtlvgvjMhbeGf4MxFhDfCNFpm C78oT9NmMTaFBed7bkDdIVBczAkO8wzLvzv7x+3DYQl2EUWxECWL44IjrsTtEQGqoX6C u+aQ0l45uIM77YX55/x3CR+45xO9rt4uoj13aVdE5ykHOkk9re/V1u+XKg+gxQhoVSLa h6+Q== MIME-Version: 1.0 X-Received: by 10.194.59.244 with SMTP id c20mr22899520wjr.59.1411414954087; Mon, 22 Sep 2014 12:42:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 12:42:34 -0700 (PDT) In-Reply-To: <2930763.7FbKMgYveJ@ralph.baldwin.cx> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <4D1FD834-2861-4D16-9ABF-21B8B07561F8@bsdimp.com> <2930763.7FbKMgYveJ@ralph.baldwin.cx> Date: Mon, 22 Sep 2014 12:42:34 -0700 X-Google-Sender-Auth: E_jFD5VTRNDUurQX91mKj9vY91I Message-ID: Subject: Re: [PATCH] Various fixes to wl(4) From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Warner Losh , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 19:42:36 -0000 On 22 September 2014 12:20, John Baldwin wrote: > On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: >> I got rid of my pre-802.11 WaveLAN cards about 8 years go after not havi= ng >> them in a system at all for 8 years. And they were about 4 years obsolet= e >> when I took them out of service=E2=80=A6 I=E2=80=99m not even sure I hav= e a machine with an >> ISA slot to test the card, even if I still had it. >> >> Sorry I can=E2=80=99t help more :) > > If no one tests them then I will happily toss the driver into the dustbin= , > just giving folks a chance to test patches before I do so. (I'm secretly > hoping I can purge several old drivers during the current round of timeou= t() > purging.) > The wavelan/prism driver no longer works out of the box and hasn't since I took over the net80211 stack. TL;DR - some changes from sam and others a few years ago to do raw 802.11 frame transmit just doesn't work on all the wavelan cards that are in use. I've asked for someone interested to go through the changelog and back out those changes, making the driver again a straight 802.3 transmit driver - but noone has. :( So yes, you have a +1 to disconnect the wavelan driver from the build. -a From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 20:36:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB118F59; Mon, 22 Sep 2014 20:36:11 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1BCB382; Mon, 22 Sep 2014 20:36:11 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9B665B91F; Mon, 22 Sep 2014 16:36:10 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: [PATCH] Various fixes to wl(4) Date: Mon, 22 Sep 2014 16:35:54 -0400 Message-ID: <9238703.p5asNz0dlH@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Sep 2014 16:36:10 -0400 (EDT) Cc: freebsd-current , Warner Losh , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 20:36:12 -0000 On Monday, September 22, 2014 12:42:34 PM Adrian Chadd wrote: > On 22 September 2014 12:20, John Baldwin wrote: > > On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: > >> I got rid of my pre-802.11 WaveLAN cards about 8 years go after no= t > >> having > >> them in a system at all for 8 years. And they were about 4 years o= bsolete > >> when I took them out of service=E2=80=A6 I=E2=80=99m not even sure= I have a machine with > >> an > >> ISA slot to test the card, even if I still had it. > >>=20 > >> Sorry I can=E2=80=99t help more :) > >=20 > > If no one tests them then I will happily toss the driver into the d= ustbin, > > just giving folks a chance to test patches before I do so. (I'm se= cretly > > hoping I can purge several old drivers during the current round of > > timeout() purging.) >=20 > The wavelan/prism driver no longer works out of the box and hasn't > since I took over the net80211 stack. >=20 > TL;DR - some changes from sam and others a few years ago to do raw > 802.11 frame transmit just doesn't work on all the wavelan cards that= > are in use. I've asked for someone interested to go through the > changelog and back out those changes, making the driver again a > straight 802.3 transmit driver - but noone has. :( >=20 > So yes, you have a +1 to disconnect the wavelan driver from the build= . I think you are referring to wi(4)? --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 20:45:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4876C59F; Mon, 22 Sep 2014 20:45:02 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BCA268B; Mon, 22 Sep 2014 20:45:01 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id k48so3557548wev.28 for ; Mon, 22 Sep 2014 13:44: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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Nu1i67SOK4vjT1Tms/utpVh7gmtgbID+qzvao17JtQc=; b=Kl4c4aZMk7bkU+JY+wGfQ/YUisc+5jwiZOsr0asMuyyTZNJmNJzh6nlYnMRs6ePQg5 nekhbZviXEWEuQ28mE7htnAsclEcllK5ra5EHtiqSJ/hVG/Q75/UOnTmp2J2XSSoVcP2 7/ifO6gwjybjv0qomoyLXRJGomH+6JvUkw4FfvBhm2N0YMJTY5EK5gyZEk6o5HjoYWEj hUikhMlE20Q3f6INL8+IetHwuZKv1LddGIpYHsfj8DoN7WVP1GhTp5uOxKaaq5Dxfpbq jp2grtBWNk3mTewy2vtn1XG+p6dmHLUhOz/U/TC7xI00dwkwPoRMDCq00WrAqxH5YeLp rHJg== MIME-Version: 1.0 X-Received: by 10.180.9.144 with SMTP id z16mr17325561wia.26.1411418699734; Mon, 22 Sep 2014 13:44:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 13:44:59 -0700 (PDT) In-Reply-To: <9238703.p5asNz0dlH@ralph.baldwin.cx> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> Date: Mon, 22 Sep 2014 13:44:59 -0700 X-Google-Sender-Auth: vz2inGSI66oXlMecvpvpmJvRNZI Message-ID: Subject: Re: [PATCH] Various fixes to wl(4) From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Warner Losh , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 20:45:02 -0000 Oh yeah, I am. but wl likely hasn't been tested in a long time.. I think my last pair of wl(4) NICs disappeared in 2001. -a On 22 September 2014 13:35, John Baldwin wrote: > On Monday, September 22, 2014 12:42:34 PM Adrian Chadd wrote: >> On 22 September 2014 12:20, John Baldwin wrote: >> > On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: >> >> I got rid of my pre-802.11 WaveLAN cards about 8 years go after not >> >> having >> >> them in a system at all for 8 years. And they were about 4 years obso= lete >> >> when I took them out of service=E2=80=A6 I=E2=80=99m not even sure I = have a machine with >> >> an >> >> ISA slot to test the card, even if I still had it. >> >> >> >> Sorry I can=E2=80=99t help more :) >> > >> > If no one tests them then I will happily toss the driver into the dust= bin, >> > just giving folks a chance to test patches before I do so. (I'm secre= tly >> > hoping I can purge several old drivers during the current round of >> > timeout() purging.) >> >> The wavelan/prism driver no longer works out of the box and hasn't >> since I took over the net80211 stack. >> >> TL;DR - some changes from sam and others a few years ago to do raw >> 802.11 frame transmit just doesn't work on all the wavelan cards that >> are in use. I've asked for someone interested to go through the >> changelog and back out those changes, making the driver again a >> straight 802.3 transmit driver - but noone has. :( >> >> So yes, you have a +1 to disconnect the wavelan driver from the build. > > I think you are referring to wi(4)? > > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 20:52:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1DDC89B for ; Mon, 22 Sep 2014 20:52:23 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 634E17D9 for ; Mon, 22 Sep 2014 20:52:23 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id tr6so8361782ieb.18 for ; Mon, 22 Sep 2014 13:52:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=cW3BuPhSA6iMlFaV9JHNrOQRmcO0XTY31SmLEQal4h4=; b=Y+zh0V0CgIeAl9pmduzbaiwoZBAeBcPNYPy2vQDdWDRjWhUUYfqDMj/Q3PvR57o2vJ YRPam8EgHklVOAIb8mb2+amCIiyGv5cEKvBCLrw0qR+i1lZ22+LThHiXlTNK51sDXkia PsnWKuac+v02+/eXWnAMuDqMTmNe3iw1deft9Xl7hF1B3SPpkA1OgsuIND4qURUuCqfd SpKvenqWgDLU+ac3IPJyzdCKyV66P2Ggvs9hTjvJYGf5grZCLhyQI0bWVncb8DCVQKtE Lf14r6Afrf7HWtawdfXAY3eUOPclM29yHcP6UmPPwV68haBqdgnccWW5FA0qn51qDchQ hP3g== X-Gm-Message-State: ALoCoQljrb2HBy+Q5LFTiWDPBENXMpMgQNr9ts8Jh4PoYtEWSDgWswxgc7VXK04cPXTi7jNTtThg X-Received: by 10.42.206.210 with SMTP id fv18mr18829656icb.47.1411418817440; Mon, 22 Sep 2014 13:46:57 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id hg4sm9662049igb.15.2014.09.22.13.46.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 13:46:56 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_B0F5A67D-4AE1-49EF-A78A-496F6169D26D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] Various fixes to wl(4) From: Warner Losh In-Reply-To: Date: Mon, 22 Sep 2014 14:46:53 -0600 Message-Id: References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 20:52:23 -0000 --Apple-Mail=_B0F5A67D-4AE1-49EF-A78A-496F6169D26D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have a dozen I can bring to the next bafug I go to :) Warner On Sep 22, 2014, at 2:44 PM, Adrian Chadd wrote: > Oh yeah, I am. >=20 > but wl likely hasn't been tested in a long time.. I think my last pair > of wl(4) NICs disappeared in 2001. >=20 >=20 > -a >=20 >=20 > On 22 September 2014 13:35, John Baldwin wrote: >> On Monday, September 22, 2014 12:42:34 PM Adrian Chadd wrote: >>> On 22 September 2014 12:20, John Baldwin wrote: >>>> On Friday, September 19, 2014 03:47:16 PM Warner Losh wrote: >>>>> I got rid of my pre-802.11 WaveLAN cards about 8 years go after = not >>>>> having >>>>> them in a system at all for 8 years. And they were about 4 years = obsolete >>>>> when I took them out of service=85 I=92m not even sure I have a = machine with >>>>> an >>>>> ISA slot to test the card, even if I still had it. >>>>>=20 >>>>> Sorry I can=92t help more :) >>>>=20 >>>> If no one tests them then I will happily toss the driver into the = dustbin, >>>> just giving folks a chance to test patches before I do so. (I'm = secretly >>>> hoping I can purge several old drivers during the current round of >>>> timeout() purging.) >>>=20 >>> The wavelan/prism driver no longer works out of the box and hasn't >>> since I took over the net80211 stack. >>>=20 >>> TL;DR - some changes from sam and others a few years ago to do raw >>> 802.11 frame transmit just doesn't work on all the wavelan cards = that >>> are in use. I've asked for someone interested to go through the >>> changelog and back out those changes, making the driver again a >>> straight 802.3 transmit driver - but noone has. :( >>>=20 >>> So yes, you have a +1 to disconnect the wavelan driver from the = build. >>=20 >> I think you are referring to wi(4)? >>=20 >> -- >> John Baldwin --Apple-Mail=_B0F5A67D-4AE1-49EF-A78A-496F6169D26D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIIq9AAoJEGwc0Sh9sBEAvdgP/A0zistx1pzCT/5g1w7nvv9u dJ7aLuNKrBw7jgUxjXLmI7+hrxwe4gfpABHirS4fb3p0iuzH+KTJ3ouzES/2ze3g 9zP/xJ4/n4mdlgG+t9d80jarSxQ66aBYkJf22OmZ6QNzG9lrNVHU4ARyc/KxDdFP 65RuW+olIMJn1KzcnvfNsULXNxz00XUrhR1jKwYfBmoQrWbCUpYq6QGYjkunNNqx Xm91a8raVhRGQpE+kzTj81GHYJQkomBxrc9dNpcOiFCnsDlZmP+dcvh+f3yITt1z UprdGckrUyN/QV0PQ95HAqNUTvpdEbkSG8KB3lR2E/eHy2BmZ4/fODso2/nPvUCZ i0uckX8bqrkBj3Y7+BhDbxGy6g+4vuhCEkvqXgwQbgLytWBibo3njlO3xsd/a77u aGwlt6KtNj6rjP9WsGndX7p8uLEG9U6R23e/xBsrcsaSFiYJ3sqFBCJFmeWc6mjA l36QdkxFSZ5TcW+zgmREpGwI+oLJgH5OVwyb46VSmuSCbFYZ64V7XBtBWt7X3Vyw vIBXFm99lQ4D9qLPgIREhzyUOQcwJDylME1wzRXjgthrRCANzI736wrpRKfKZo+b tJc87WMBam/VrzoXA0v2fa/LHD5Ls3pYN8rvjtG3MPQgsPGJwlzX8w1aPldsQNQJ hb5rPEbTkLMX/ydBOYOE =7MeH -----END PGP SIGNATURE----- --Apple-Mail=_B0F5A67D-4AE1-49EF-A78A-496F6169D26D-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 22:05:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23F569AD; Mon, 22 Sep 2014 22:05:29 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6699FE93; Mon, 22 Sep 2014 22:05:28 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id u57so2832093wes.20 for ; Mon, 22 Sep 2014 15:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RN83/oZxEri6xO86lmLM+b0sMbjCzP2NVp2L4pI36Xo=; b=RoJYww9MT2f2UwvzoIfNA3KIJ1fVf+EueGvDzISsUwHfHGbU8wYzJtVx/lwdz744XW L9xeBVdzfBe39vPkvr0C4HBtliFoN6EajYMCeLxL3ocDzmHcAV2lhYYg2ejEZMUTOuQW ypWqz93KfTZloRTNCqN7ZN8VlAqc3qYln9l0YjR3C10y9PorGUBsF0t107TsktGKldBG EwfnIDY9cmYVEOHtlhovw/ikz6sIFAMzyLX+OiKkvn6JUNNfJ5Bs4NbrXUwO5zBN8giq fh1me+JVrRCtFk3mQH+PdDlGNtbhssJys/xSKlbDlKaFBhjydXCg24Vn/orJOVyUI6Wh ENlw== MIME-Version: 1.0 X-Received: by 10.194.78.170 with SMTP id c10mr23573882wjx.22.1411423526660; Mon, 22 Sep 2014 15:05:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 15:05:26 -0700 (PDT) In-Reply-To: References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> Date: Mon, 22 Sep 2014 15:05:26 -0700 X-Google-Sender-Auth: zpdPqlD5vjupKySHyqMXkjhvEEM Message-ID: Subject: Re: [PATCH] Various fixes to wl(4) From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 22:05:29 -0000 On 22 September 2014 13:46, Warner Losh wrote: > I have a dozen I can bring to the next bafug I go to :) But, do you have the pentium class machines with ISA slots that we'd need to use em? :P -a From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 22:28:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D8FFF11 for ; Mon, 22 Sep 2014 22:28:44 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 5698311F for ; Mon, 22 Sep 2014 22:28:44 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 763E5346DE0F for ; Mon, 22 Sep 2014 15:28:38 -0700 (PDT) Message-ID: <5420A295.3030503@mu.org> Date: Mon, 22 Sep 2014 15:28:37 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [PATCH] Various fixes to wl(4) References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 22:28:44 -0000 On 9/22/14 3:05 PM, Adrian Chadd wrote: > On 22 September 2014 13:46, Warner Losh wrote: >> I have a dozen I can bring to the next bafug I go to :) > But, do you have the pentium class machines with ISA slots that we'd > need to use em? :P I have the pci card to pccard bridge cards. I'll bring those in, they'll be on your desk tomorrow AM. -Alfred From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 22:47:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4B315D4 for ; Mon, 22 Sep 2014 22:47:06 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B25D316 for ; Mon, 22 Sep 2014 22:47:06 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x48so2256578wes.4 for ; Mon, 22 Sep 2014 15:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ghkKTcYe7CgREmTBEO0qKWksir5to1EdkQDcJuO9gdQ=; b=UYFUOUJdNaXmGf8sVuOIfse3wj1KBMLUY5jgBaK8SisXUP1rdLFiLWxSPFCk1QGQEK kktxZttzyJmNRZ89zSS1MlJtyYITy2FHSjk2cuknb7P1syLUi/ZYl6MYFCrHNZysn9/i 8YnPOeafwHl+BYKLqB7Tm3Dx2IpDwtrwOfI/4GpepE3QhM/YQNaiwqzSBuydy3LMELMY lP2nFfq2Z2hk9kAhyVv1/L6GEgELxocYtjLto1ZTNnKejdftHyBqQXN21EEpGtWjxC7j 2Hc0DQ0o7iXGo2ubb/POq/rAIw+AoN0fNulYfmOLl41fVEoQHaep0hIp9d3Cy+1hlyO8 gVNw== MIME-Version: 1.0 X-Received: by 10.180.97.98 with SMTP id dz2mr16782218wib.26.1411426024355; Mon, 22 Sep 2014 15:47:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 15:47:04 -0700 (PDT) In-Reply-To: <5420A295.3030503@mu.org> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> <5420A295.3030503@mu.org> Date: Mon, 22 Sep 2014 15:47:04 -0700 X-Google-Sender-Auth: 3ltGPxk4ZBLfkcnJ8L57eTSXQrw Message-ID: Subject: Re: [PATCH] Various fixes to wl(4) From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 22 Sep 2014 22:47:06 -0000 On 22 September 2014 15:28, Alfred Perlstein wrote: > > On 9/22/14 3:05 PM, Adrian Chadd wrote: >> >> On 22 September 2014 13:46, Warner Losh wrote: >>> >>> I have a dozen I can bring to the next bafug I go to :) >> >> But, do you have the pentium class machines with ISA slots that we'd >> need to use em? :P > > > I have the pci card to pccard bridge cards. > > I'll bring those in, they'll be on your desk tomorrow AM. I have those. Because, well, Sam gave me his prism collection.. -a From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 03:01:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA9CDABC for ; Tue, 23 Sep 2014 03:01:22 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F970E4B for ; Tue, 23 Sep 2014 03:01:22 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id p10so5397797pdj.41 for ; Mon, 22 Sep 2014 20:01:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=eexDQbbpfTa70+3OBHaifQPKKPRn9xOGfGDsi8KIGZI=; b=FNwVIcjROhoLIgUR7IgAwWPhY8qgumMiAaYB+MPsDtOHXJhzACS+48hSdtPBsvKhk3 7iLeEQa2V7JhBVw/sANTdj8ELqnNdqpQV5DspQuskXwzRdTGkYOPPP8DHhcLc38orz3D mtnh/TuHFAUkpUuSYxZvbJARyLWiuue96irFulOjE0d9LbId0J2phXWlVy/Qoq+RiSJr 0Ft4ns9kMrI9J9SoWOeZv27UgJSqApBpbcTCKpzdkeGbLIYgJW+cuZa6nfAOBYbGURFR LpGgpBsjTG3dfpxUKlrS30n9RnSVqf7BGZ/eW48YJQYBiw8DOWNZ038kWwqy3NZHzQsR Itnw== X-Gm-Message-State: ALoCoQk+ZnJloJAMzoq85Gf6nxA9WFFDS9AnnLkS5ztTWTRhD+nW0RaZvjmCPjOD/KX3RqE37+uR X-Received: by 10.68.131.134 with SMTP id om6mr29252159pbb.41.1411441281556; Mon, 22 Sep 2014 20:01:21 -0700 (PDT) Received: from [10.1.10.70] ([50.253.99.174]) by mx.google.com with ESMTPSA id tx8sm10665793pac.42.2014.09.22.20.01.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 20:01:20 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_18B01BF2-EDDB-4757-9FEC-C91923EF7AFB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] Various fixes to wl(4) From: Warner Losh In-Reply-To: Date: Mon, 22 Sep 2014 21:01:09 -0600 Message-Id: <361E844F-6343-43BB-9D1D-8DB5E7355C9A@bsdimp.com> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 03:01:23 -0000 --Apple-Mail=_18B01BF2-EDDB-4757-9FEC-C91923EF7AFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 22, 2014, at 4:05 PM, Adrian Chadd wrote: > On 22 September 2014 13:46, Warner Losh wrote: >> I have a dozen I can bring to the next bafug I go to :) >=20 > But, do you have the pentium class machines with ISA slots that we'd > need to use em? :P For wi(4)? You can test that with any laptop with a CardBus slot=85 = Those I=92ve got :) Or a PCI machine with an adapter: Got one left. Of in an ISA adapter =85 hmmm, FreeBSD doesn=92t support that, but I = have a machine that can do that=85 I just don=92t have a network that doesn=92t have crypto enabled to try = it out, and I=92m too lazy to set that up. Warner --Apple-Mail=_18B01BF2-EDDB-4757-9FEC-C91923EF7AFB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIOJ2AAoJEGwc0Sh9sBEAbuQP/jU4onB7uyGAwDow+ViLTPbA jokw0bIGu5uHE2s/P9mUis0rtGrh4ytbOZpaMc6eGGxNgOhvyBVK9XiaE65kug8i ADR+DtVPYPdyZZ9M9rDzTn6Q+s3HKWObY59pb2xsTLI1ks9HFvKbpq4x5kBGHKHi enQ2BSTkKj2ZCz9hzJA6XSNJ+HTZpDNCWj/t74QcbM/++tzSzrgaiEGez8HX45Sv pTBvURFQWTD1BzQ8snfT3RU6TdNtOjB8l2rJtQhk1DwLHwVIMOxnjLXAmgLyyoWX eDExLUzuK5Jn3NRXEy4Bt9IR5+Ciil4wwtiepn1VPwIIqLzDrBdosL1HybbZs78p LTMFx9CwskIRSFr4pA8sJTK8Iloyo1PLEvNvX9CzeK6DeS7Vib6Q+a3+Wn+dYAdF T0iyELjk1S6+G9q9jM4ynNGUYEs2tqFOz63SEhEB4K9KA8jRUUuphqsRAcwwNBQp 5f1J4oqQmjXDZudCaaxW/aEOlDN4jcTiSZJYPHq8iEf9u9N49LRb0We6U4nh1MBR jTmLah5le2rTuJJqf2NeGtJKPaAJFkXUyW0ucfNW3dmim/Xim3Xz175Y6CTbSgoa 3V5MSe/QYmcEpo5iJdOa9ZUagoHC8LoItbT0i6dU+7WBKKEu/ArL8wPNffU62/iy c4ocNcar0hJyPFBrwYai =4wyb -----END PGP SIGNATURE----- --Apple-Mail=_18B01BF2-EDDB-4757-9FEC-C91923EF7AFB-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 04:45:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11454753; Tue, 23 Sep 2014 04:45:01 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75DEFA24; Tue, 23 Sep 2014 04:45:00 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id a1so3575056wgh.1 for ; Mon, 22 Sep 2014 21:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bEjLcPdqqEcN/N5dOjgMIoTElBoXP0a9+zHUc8sPYzs=; b=oClrVeoKCl+LENxs8SknnLjXK/TUbubVroo6L/Jir1omaDhcqjSzuWhVIhVITdDtkr +azgmU6DmEH4SeQIB9d1AM0jZ5Z4WRD8FWI5qaqwGG0At2x7NME/XFp3NhzqaXt6VP5o NK5cNy6+CeSwEab28frR+nPGRDA+UW5SGSXKve1CcrlDPn8fixmK7tRccHI6WJ9XPXFl RWW1EATSqcjMShG7fa11D48SxlhOVA8pto7k1JM+Kv0K41KiE4smUtfDouSTu4nGyo93 GSY49+M6IPoL7vE+tbJrlYS5Dl8zO3pEAKSl2Irz+MqKxqQOyexAjTtlqii/F9kgFyCc +MzQ== MIME-Version: 1.0 X-Received: by 10.180.9.144 with SMTP id z16mr19315406wia.26.1411447498608; Mon, 22 Sep 2014 21:44:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.199 with HTTP; Mon, 22 Sep 2014 21:44:58 -0700 (PDT) In-Reply-To: <361E844F-6343-43BB-9D1D-8DB5E7355C9A@bsdimp.com> References: <1815820.OytfPhNq3X@ralph.baldwin.cx> <2930763.7FbKMgYveJ@ralph.baldwin.cx> <9238703.p5asNz0dlH@ralph.baldwin.cx> <361E844F-6343-43BB-9D1D-8DB5E7355C9A@bsdimp.com> Date: Mon, 22 Sep 2014 21:44:58 -0700 X-Google-Sender-Auth: BdSYYXVBTiLPs_gNCnjYYkvDaCM Message-ID: Subject: Re: [PATCH] Various fixes to wl(4) From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 04:45:01 -0000 I have lots of wavelan/prism NICs. The driver just doesn't work with them. -a From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 06:13:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 996A320F for ; Tue, 23 Sep 2014 06:13:52 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 724BD1F4 for ; Tue, 23 Sep 2014 06:13:52 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.9/8.14.9) with ESMTP id s8N6Do1L096183 for ; Tue, 23 Sep 2014 02:13:50 -0400 (EDT) (envelope-from lidl@hydra.pix.net) Received: (from lidl@localhost) by hydra.pix.net (8.14.9/8.14.9/Submit) id s8N6Do31096182 for freebsd-current@freebsd.org; Tue, 23 Sep 2014 02:13:50 -0400 (EDT) (envelope-from lidl) Date: Tue, 23 Sep 2014 02:13:50 -0400 From: Kurt Lidl To: freebsd-current@freebsd.org Subject: 10.1-BETA2 ZFS boot failure on sparc64 Message-ID: <20140923061350.GA96111@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 06:13:52 -0000 I downloaded the 10.1-BETA disc1 iso image for sparc64, and burned it to media. I then used that media to attempt an installation onto a spare sparc64 machine that I have. Using UFS as the filesystem, and more or less just following the prompts, the system got installed OK, and boots off of ZFS OK. I then reinstalled onto a system that I manually configured for ZFS. This installation fails to boot from the hard disk, dying like this: ---- snip, snip ---- ok reset Res LOM event: +487d+12h37m31s host reset etting ... ? Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. Boot device: disk0 File and args: >> FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console Memory Address not Aligned ok ---- snip, snip ---- I have used my exact procedure in the past to install onto a ZFS only sparc without issue. Has anyone else tried booting a ZFS only sparc64 installation recently? -Kurt From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 09:24:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8CED16E; Tue, 23 Sep 2014 09:24:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0680F9AD; Tue, 23 Sep 2014 09:24:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8N9On33008808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2014 12:24:49 +0300 (EEST) (envelope-from kostik@tom.home) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8N9On33008808 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8N9Oncx008807; Tue, 23 Sep 2014 12:24:49 +0300 (EEST) (envelope-from kostik) Date: Tue, 23 Sep 2014 12:24:49 +0300 From: Konstantin Belousov To: Daniel Eischen Subject: Re: libthr and main thread stack size Message-ID: <20140923092449.GB8334@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> <541E31E0.8020108@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 09:24:57 -0000 On Mon, Sep 22, 2014 at 09:19:30AM -0400, Daniel Eischen wrote: > On Sun, 21 Sep 2014, Julian Elischer wrote: > > > On 9/20/14, 3:27 AM, John Baldwin wrote: > >> On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: > >>> On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: > >>>> On Aug 8, 2014, at 5:22 AM, Konstantin Belousov > >>>> wrote: > >>>> > >>>> ? > >>>> > >>>>> Below is the patch which adds environment variable > >>>>> LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the > >>>>> main thread stack left as is, and other threads allocate stack > >>>>> below the area of RLIMIT_STACK. Try it. I do not want to set this > >>>>> behaviour as default. > >>>> Is there a reason this should not be the default? Looking at the > >>>> getrlimit() page on the OpenGroup?s site they say: > >>>> > >>>> RLIMIT_STACK This is the maximum size of the initial thread's stack, > >>>> in bytes. The implementation does not automatically grow the stack > >>>> beyond this limit. If this limit is exceeded, SIGSEGV shall be > >>>> generated for the thread. If the thread is blocking SIGSEGV, or the > >>>> process is ignoring or catching SIGSEGV and has not made arrangements > >>>> to use an alternate stack, the disposition of SIGSEGV shall be set to > >>>> SIG_DFL before it is generated. > >>>> > >>>> Does posix say something different? > >>>> > >>>> I ran into this issue when debugging a segfault on Postgres when > >>>> running an (arguably quite bogus) query that should have fit within > >>>> both the configured stack rlimit and Postgres? configured stack limit. > >>>> The Postgres backend is really just single threaded, but happens > >>>> to pull in libpthread due to the threading support in some of the > >>>> libraries it uses. The segfault definitely violates POLA. > >>>> > >>>> ? Justin > >>> I am conservative to not disturb the address space layout in single go. > >>> If enough people test this setting, I can consider flipping the default > >>> to the reverse. > >>> > >>> I am still curious why the things were done in this way, but nobody > >>> replied. > >> I suspect it was done out of reasons of being overly conservative in > >> interpreting RLIMIT_STACK. I think it is quite surprising behavior though > >> and > >> would rather we make your option the default and implement what the Open > >> Group > >> says above. > >> > > that is my memory.. > > The transition from a non threaded app to a threaded app with one thread is > > sort of an undefined area. > > Feel free to change it if Dan agrees.. > > I'm all for adopting what POSIX specifies as the default. I > would shy away from adding another knob (LIBPTHREAD_BIGSTACK_MAIN) > if possible. In the patch, default behaviour is to provide RLIMIT_STACK sized stack for the main thread. The knobs are there to restore the old AS layout if my fears of the binary compatibility become real one day, and to keep the interface compat with the stable/10, which already got a knob merged. That said, below the patch with libthr.7 man page merged to libthr.3, and with the editing applied. diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3 index bfbebec..aa4572c 100644 --- a/lib/libthr/libthr.3 +++ b/lib/libthr/libthr.3 @@ -1,6 +1,11 @@ .\" Copyright (c) 2005 Robert N. M. Watson +.\" Copyright (c) 2014 The FreeBSD Foundation, Inc. .\" All rights reserved. .\" +.\" Part of this documentation was written by +.\" Konstantin Belousov under sponsorship +.\" from the FreeBSD Foundation. +.\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: @@ -24,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd October 19, 2007 +.Dd September 20, 2014 .Dt LIBTHR 3 .Os .Sh NAME @@ -45,8 +50,216 @@ has been optimized for use by applications expecting system scope thread semantics, and can provide significant performance improvements compared to .Lb libkse . +.Pp +The library is tightly integrated with the run-time link editor +.Xr ld-elf.so.1 1 +and +.Lb libc ; +all three components must be built from the same source tree. +Mixing +.Li libc +and +.Nm +libraries from different versions of +.Fx +is not supported. +The run-time linker +.Xr ld-elf.so.1 1 +has some code to ensure backward-compatibility with older versions of +.Nm . +.Pp +The man page documents the quirks and tunables of the +.Nm . +When linking with +.Li -lpthread , +the run-time dependency +.Li libthr.so.3 +is recorded in the produced object. +.Sh MUTEX ACQUISITION +A locked mutex (see +.Xr pthread_mutex_lock 3 ) +is represented by a volatile variable of type +.Dv lwpid_t , +which records the global system identifier of the thread +owning the lock. +.Nm +performs a contested mutex acquisition in three stages, each of which +is more resource-consuming than the previous. +.Pp +First, a spin loop +is performed, where the library attempts to acquire the lock by +.Xr atomic 9 +operations. +The loop count is controlled by the +.Ev LIBPTHREAD_SPINLOOPS +environment variable, with a default value of 2000. +.Pp +If the spin loop +was unable to acquire the mutex, a yeild loop +is executed, performing the same +.Xr atomic 9 +acquisition attempts as the spin loop, +but each attempt is followed by a yield of the CPU time +of the thread using the +.Xr sched_yield 2 +syscall. +By default, the yield loop +is not executed. +This is controlled by the +.Ev LIBPTHREAD_YIELDLOOPS +environment variable. +.Pp +If both the spin and yield loops +failed to acquire the lock, the thread is taken off the CPU and +put to sleep in the kernel with the +.Xr umtx 2 +syscall. +The kernel wakes up a thread and hands the ownership of the lock to +the woken thread when the lock becomes available. +.Sh THREAD STACKS +Each thread is provided with a private user-mode stack area +used by the C runtime. +The size of the main (initial) thread stack is set by the kernel, and is +controlled by the +.Dv RLIMIT_STACK +process resource limit (see +.Xr getrlimit 2 ) . +.Pp +By default, the main thread's stack size is equal to the value of +.Dv RLIMIT_STACK +for the process. +If the +.Ev LIBPTHREAD_SPLITSTACK_MAIN +environment variable is present in the process environment +(its value does not matter), +the main thread's stack is reduced to 4MB on 64bit architectures, and to +2MB on 32bit architectures, when the threading library is initialized. +The rest of the address space area which has been reserved by the +kernel for the initial process stack is used for non-initial thread stacks +in this case. +The presence of the +.Ev LIBPTHREAD_BIGSTACK_MAIN +environment variable overrides +.Ev LIBPTHREAD_SPLITSTACK_MAIN ; +it is kept for backward-compatibility. +.Pp +The size of stacks for threads created by the process at run-time +with the +.Xr pthread_create 3 +call is controlled by thread attributes: see +.Xr pthread_attr 3 , +in particular, the +.Xr pthread_attr_setstacksize 3 , +.Xr pthread_attr_setguardsize 3 +and +.Xr pthread_attr_setstackaddr 3 +functions. +If no attributes for the thread stack size are specified, the default +non-initial thread stack size is 2MB for 64bit architectures, and 1MB +for 32bit architectures. +.Sh RUN-TIME SETTINGS +The following environment variables are recognized by +.Nm +and adjust the operation of the library at run-time: +.Bl -tag -width LIBPTHREAD_SPLITSTACK_MAIN +.It Ev LIBPTHREAD_BIGSTACK_MAIN +Disables the reduction of the initial thread stack enabled by +.Ev LIBPTHREAD_SPLITSTACK_MAIN . +.It Ev LIBPTHREAD_SPLITSTACK_MAIN +Causes a reduction of the initial thread stack, as described in the +section +.Sx THREAD STACKS . +This was the default behaviour of +.Nm +before +.Fx 11.0 . +.It Ev LIBPTHREAD_SPINLOOPS +The integer value of the variable overrides the default count of +iterations in the +.Li spin loop +of the mutex acquisition. +The default count is 2000, set by the +.Dv MUTEX_ADAPTIVE_SPINS +constant in the +.Nm +sources. +.It Ev LIBPTHREAD_YIELDLOOPS +A non-zero integer value enables the yield loop +in the process of the mutex acquisition. +The value is the count of loop operations. +.It Ev LIBPTHREAD_QUEUE_FIFO +The integer value of the variable specifies how often blocked +threads are inserted at the head of the sleep queue, instead of its tail. +Bigger values reduce the frequency of the FIFO discipline. +The value must be between 0 and 255. +.El +.Sh INTERACTION WITH RUN-TIME LINKER +The +.Nm +library must appear before +.Li libc +in the global order of depended objects. +.Pp +Loading +.Nm +with the +.Xr dlopen 3 +call in the process after the program binary is activated +is not supported, and causes miscellaneous and hard-to-diagnose misbehaviour. +This is due to +.Nm +interposing several important +.Li libc +symbols to provide thread-safe services. +In particular, +.Dv errno +and the locking stubs from +.Li libc +are affected. +This requirement is currently not enforced. +.Pp +If the program loads any modules at run-time, and those modules may require +threading services, the main program binary must be linked with +.Li libpthread , +even if it does not require any services from the library. +.Pp +.Nm +cannot be unloaded; the +.Xr dlclose 3 +function does not perform any action when called with a handle for +.Nm . +One of the reasons is that the interposing of +.Li libc +functions cannot be undone. +.Sh SIGNALS +The implementation also interposes the user-installed +.Xr signal 3 +handlers. +This interposing is done to postpone signal delivery to threads which +entered (libthr-internal) critical sections, where the calling +of the user-provided signal handler is unsafe. +An example of such a situation is owning the internal library lock. +When a signal is delivered while the signal handler cannot be safely +called, the call is postponed and performed until after the exit from +the critical section. +This should be taken into account when interpreting +.Xr ktrace 1 +logs. .Sh SEE ALSO -.Xr pthread 3 +.Xr ktrace 1 , +.Xr ld-elf.so.1 1 , +.Xr getrlimit 2 , +.Xr umtx 2 , +.Xr dlclose 3 , +.Xr dlopen 3 , +.Xr errno 3 , +.Xr getenv 3 , +.Xr libc 3 , +.Xr pthread_attr 3 , +.Xr pthread_attr_setstacksize 3 , +.Xr pthread_create 3 , +.Xr signal 3 , +.Xr atomic 9 . .Sh AUTHORS .An -nosplit The diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c index 9bf0e29..72a067a 100644 --- a/lib/libthr/thread/thr_init.c +++ b/lib/libthr/thread/thr_init.c @@ -445,7 +445,7 @@ init_private(void) struct rlimit rlim; size_t len; int mib[2]; - char *env; + char *env, *env_bigstack, *env_splitstack; _thr_umutex_init(&_mutex_static_lock); _thr_umutex_init(&_cond_static_lock); @@ -473,8 +473,9 @@ init_private(void) len = sizeof (_usrstack); if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1) PANIC("Cannot get kern.usrstack from sysctl"); - env = getenv("LIBPTHREAD_BIGSTACK_MAIN"); - if (env != NULL) { + env_bigstack = getenv("LIBPTHREAD_BIGSTACK_MAIN"); + env_splitstack = getenv("LIBPTHREAD_SPLITSTACK_MAIN"); + if (bigstack != NULL || env_splitstack == NULL) { if (getrlimit(RLIMIT_STACK, &rlim) == -1) PANIC("Cannot get stack rlimit"); _thr_stack_initial = rlim.rlim_cur; From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 09:51:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71C634C0 for ; Tue, 23 Sep 2014 09:51:47 +0000 (UTC) Received: from nm16-vm4.access.bullet.mail.gq1.yahoo.com (nm16-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33F85D11 for ; Tue, 23 Sep 2014 09:51:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1411465900; bh=lFCK9DANOdgP8n8dBgLo6W+7qOCF5f4oT969mbZsSsY=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject:References:From:Subject; b=hviOHWgMwFLlRTRo2V0iMd3OfDOnGPlyIAFC65uTsw5uIZZIMp1yPyeuALV/0xcWTeHQ76cFAEqn50PyJPeRUSv5we6HiMmzH7gmKeh4pNbzNhwAE4PhvfyJJHYqGiMeyq/OeqMUYzPhFHpf8alRIE69i951YcBeIr2Atlc2K+w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=bellsouth.net; b=ophjabxsu69a1pbsS1yBp6+kWaKamZkQ40KXWelV5A3IJvWBVvtuR3mgbMA40mQakse9DyFLNlnxuri+HYMQ32rbnBC9XxsVMPFcmLBI7btPczLkf9+8vngq2Me66XG36iXcWliOaNDTELobVcbWkVfV/84vLAmCwBs86aWsdKY=; Received: from [216.39.60.165] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Sep 2014 09:51:40 -0000 Received: from [67.195.22.119] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Sep 2014 09:51:40 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.gq1.yahoo.com with NNFMP; 23 Sep 2014 09:51:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1411465900; bh=lFCK9DANOdgP8n8dBgLo6W+7qOCF5f4oT969mbZsSsY=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:From:To:Subject:References; b=uUtlLA92GDPKBPeNyRJfdQSqMqdkQCHM2QzW0jQoQtru/0hc3l7LE5Nf2IiU6bvk6pBZvA98MYRrJaMFJiMammaNh+xDqO5MUjraYHbUqKYuth/tEHnuRVD188LL3NuIR8dy9tIStVqHdh97BDZSl4OMeDXwH/sdzOwBffOB2n8= X-Yahoo-Newman-Id: 695091.68637.bm@smtp114.sbc.mail.gq1.yahoo.com Message-ID: <695091.68637.bm@smtp114.sbc.mail.gq1.yahoo.com> Date: Tue, 23 Sep 2014 02:51:40 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kBMeqwAVM1nV3IpsiEyW7MtVq_MlGMDf72b9U67FFXKQhzK j3laJUEnqF.KCKZc2gbbH3MPFFHlVnBJm8nOeTABuhoIlXyg_0N4CZMzmjpb i9S8puTS22jCMuui1kyiN.HaYfbPFBp7nK8A0Skv0iTMERh4ajnkNFgurJH4 xyRQV5gbFpbrivNk0EX_9F_HjdYAtd4wvvXE10RMfboWIQozrsVz.R2q2vvW qI_bpeJ0phOu2DNtFSV7KY_cwEN2FXJq.W_xVErAhJvdUEcT0DWXzE6uupIv PjYKTjZesDwk8H2BqoyOT8hkiut4NAjApK4b9WwdlGFS2LbSs_ATBCPxUozc LzVXnftS9jfyPZ8zJuMp06PYnQkAMMX7VHkCtZc9BN1ZMx.zFQS_V9rUrTrS ljfuYlkqrwt_OSFTfr3mcnVX_mFIwxRPcoVvy_sv4pXT9AoK3gcOSzF2mia6 KaS6zI_.xky__zNoujgKAz02wnkskQACP535XMmC59i30uvOPnb6m53Rpig1 HToZi82QXvCvlFPsYvxf2ys16vTzl0qp87S0J1fX7_8L2x807BYO.5bz1UFE RsGkjk.SZ5PpsAL3xpI2VPGshjUd54HwQie0T91J6lDzlBkwe1Mc- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: make installworld for i386 fails on Kyuafile References: <14666.10975.bm@smtp118.sbc.mail.ne1.yahoo.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 09:51:47 -0000 On Mon, Sep 22, 2014 at 11:15 AM, Thomas Mueller wrote: > I was successful on make buildworld and kernel, but make installworld failed on a missing file somewhere: > > /usr/share/man/man3/pmclog_read.3.gz -> /usr/share/man/man3/pmclog.3.gz > ===> lib/libproc (install) > install -C -o root -g wheel -m 444 libproc.a /usr/lib > install -C -o root -g wheel -m 444 libproc_p.a /usr/lib > install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib > install -l s libproc.so.2 /usr/lib/libproc.so > install -C -o root -g wheel -m 444 /BETA1/usr/src/lib/libproc/libproc.h /usr/include > ===> lib/libproc/tests (install) > install -o root -g wheel -m 444 Kyuafile.auto /usr/tests/lib/libproc/Kyuafile > install: /usr/tests/lib/libproc/Kyuafile: No such file or directory Julio Merino responded: > Fixed in r271950. Problem introduced in r271937 which seems to have > missed part of the change sent out for review in D710. Thanks for the response! Now I know it wasn't some fault at my end. I updated again with svn from NetBSD, and was successful on (FreeBSD) i386. Next is to build/update for amd64. Tom From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 10:02:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 774FA2FB; Tue, 23 Sep 2014 10:02:03 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFC8FEEB; Tue, 23 Sep 2014 10:02:02 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id u56so4257815wes.39 for ; Tue, 23 Sep 2014 03:02: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=ku6tY3bXOEEga3n9AEwK0QndVpZ8N/dCbEwXMCaKfrM=; b=M9k+WML0e85eL8MNNwdmrWQI6a2bA09NP60p3g96t/Djz5cL2ee08tyOBBBEEqKfQy 4LKXr25R8p6CgKVe7Zecc4ghyN9w7Zaf0wodkObnU3+0Ia6hBBhpJ0Z1BN+Gkvlix5xo Rookml/hEXBblTO5VWUPmOEwBzNGPBcOYDu287RJWvC+nXdPEq/M6kBmCONfxeazNR09 2tiTQHfAyBaAWwDMkQ+odGRFdyQAhbVCdmJdnU66hikLY4Heif3qgp0BVQxc5+Yoi8sb 5mWzffZv027pa5/kd8OE5OIr3JW6jwEP5OJGp6laKfdm+n2wUCqCqF27SAYbmpB+ojzn h0Kw== MIME-Version: 1.0 X-Received: by 10.180.74.227 with SMTP id x3mr1971277wiv.80.1411466521133; Tue, 23 Sep 2014 03:02:01 -0700 (PDT) Received: by 10.216.53.68 with HTTP; Tue, 23 Sep 2014 03:02:01 -0700 (PDT) In-Reply-To: <20140923092449.GB8334@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> <541E31E0.8020108@freebsd.org> <20140923092449.GB8334@kib.kiev.ua> Date: Tue, 23 Sep 2014 14:02:01 +0400 Message-ID: Subject: Re: libthr and main thread stack size From: Sergey Kandaurov To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: Daniel Eischen , "Ivan A. Kosarev" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 10:02:03 -0000 On 23 September 2014 13:24, Konstantin Belousov wrote: > In the patch, default behaviour is to provide RLIMIT_STACK sized stack > for the main thread. The knobs are there to restore the old AS layout > if my fears of the binary compatibility become real one day, and to > keep the interface compat with the stable/10, which already got a knob > merged. > > That said, below the patch with libthr.7 man page merged to libthr.3, > and with the editing applied. > > diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3 > index bfbebec..aa4572c 100644 > --- a/lib/libthr/libthr.3 > +++ b/lib/libthr/libthr.3 > @@ -1,6 +1,11 @@ > .\" Copyright (c) 2005 Robert N. M. Watson > +.\" Copyright (c) 2014 The FreeBSD Foundation, Inc. > .\" All rights reserved. > .\" > +.\" Part of this documentation was written by > +.\" Konstantin Belousov under sponsorship > +.\" from the FreeBSD Foundation. > +.\" > .\" Redistribution and use in source and binary forms, with or without > .\" modification, are permitted provided that the following conditions > .\" are met: > @@ -24,7 +29,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd October 19, 2007 > +.Dd September 20, 2014 > .Dt LIBTHR 3 > .Os > .Sh NAME > @@ -45,8 +50,216 @@ has been optimized for use by applications expecting system scope thread > semantics, and can provide significant performance improvements > compared to > .Lb libkse . > +.Pp > +The library is tightly integrated with the run-time link editor > +.Xr ld-elf.so.1 1 > +and > +.Lb libc ; > +all three components must be built from the same source tree. > +Mixing > +.Li libc > +and > +.Nm > +libraries from different versions of > +.Fx > +is not supported. > +The run-time linker > +.Xr ld-elf.so.1 1 > +has some code to ensure backward-compatibility with older versions of > +.Nm . > +.Pp > +The man page documents the quirks and tunables of the > +.Nm . > +When linking with > +.Li -lpthread , > +the run-time dependency > +.Li libthr.so.3 > +is recorded in the produced object. > +.Sh MUTEX ACQUISITION > +A locked mutex (see > +.Xr pthread_mutex_lock 3 ) > +is represented by a volatile variable of type > +.Dv lwpid_t , > +which records the global system identifier of the thread > +owning the lock. > +.Nm > +performs a contested mutex acquisition in three stages, each of which > +is more resource-consuming than the previous. > +.Pp > +First, a spin loop > +is performed, where the library attempts to acquire the lock by > +.Xr atomic 9 > +operations. > +The loop count is controlled by the > +.Ev LIBPTHREAD_SPINLOOPS > +environment variable, with a default value of 2000. > +.Pp > +If the spin loop > +was unable to acquire the mutex, a yeild loop typo: yield [...] > .Sh SEE ALSO > -.Xr pthread 3 > +.Xr ktrace 1 , > +.Xr ld-elf.so.1 1 , > +.Xr getrlimit 2 , > +.Xr umtx 2 , > +.Xr dlclose 3 , > +.Xr dlopen 3 , > +.Xr errno 3 , > +.Xr getenv 3 , > +.Xr libc 3 , > +.Xr pthread_attr 3 , > +.Xr pthread_attr_setstacksize 3 , > +.Xr pthread_create 3 , > +.Xr signal 3 , > +.Xr atomic 9 . no pediod there per mdoc > .Sh AUTHORS > .An -nosplit > The > diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c > index 9bf0e29..72a067a 100644 > --- a/lib/libthr/thread/thr_init.c > +++ b/lib/libthr/thread/thr_init.c > @@ -445,7 +445,7 @@ init_private(void) > struct rlimit rlim; > size_t len; > int mib[2]; > - char *env; > + char *env, *env_bigstack, *env_splitstack; > > _thr_umutex_init(&_mutex_static_lock); > _thr_umutex_init(&_cond_static_lock); > @@ -473,8 +473,9 @@ init_private(void) > len = sizeof (_usrstack); > if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1) > PANIC("Cannot get kern.usrstack from sysctl"); > - env = getenv("LIBPTHREAD_BIGSTACK_MAIN"); > - if (env != NULL) { > + env_bigstack = getenv("LIBPTHREAD_BIGSTACK_MAIN"); > + env_splitstack = getenv("LIBPTHREAD_SPLITSTACK_MAIN"); > + if (bigstack != NULL || env_splitstack == NULL) { looks like a typo: s/bigstack/env_bigstack/ > if (getrlimit(RLIMIT_STACK, &rlim) == -1) > PANIC("Cannot get stack rlimit"); > _thr_stack_initial = rlim.rlim_cur; -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 10:48:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43D9D1BF; Tue, 23 Sep 2014 10:48:22 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF15E655; Tue, 23 Sep 2014 10:48:21 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8NAmE1l009339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2014 13:48:14 +0300 (EEST) (envelope-from kostik@tom.home) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8NAmE1l009339 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8NAmEDE009338; Tue, 23 Sep 2014 13:48:14 +0300 (EEST) (envelope-from kostik) Date: Tue, 23 Sep 2014 13:48:14 +0300 From: Konstantin Belousov To: Sergey Kandaurov Subject: Re: libthr and main thread stack size Message-ID: <20140923104814.GB8870@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140916081324.GQ2737@kib.kiev.ua> <5242716.s4iaScq0Bu@ralph.baldwin.cx> <541E31E0.8020108@freebsd.org> <20140923092449.GB8334@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Daniel Eischen , "Ivan A. Kosarev" , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 10:48:22 -0000 On Tue, Sep 23, 2014 at 02:02:01PM +0400, Sergey Kandaurov wrote: > > + env_bigstack = getenv("LIBPTHREAD_BIGSTACK_MAIN"); > > + env_splitstack = getenv("LIBPTHREAD_SPLITSTACK_MAIN"); > > + if (bigstack != NULL || env_splitstack == NULL) { > looks like a typo: s/bigstack/env_bigstack/ Indeed, thank you for noting. This patch actually booted, and I verified all 5 conditions. diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3 index bfbebec..a5b75d4 100644 --- a/lib/libthr/libthr.3 +++ b/lib/libthr/libthr.3 @@ -1,6 +1,11 @@ .\" Copyright (c) 2005 Robert N. M. Watson +.\" Copyright (c) 2014 The FreeBSD Foundation, Inc. .\" All rights reserved. .\" +.\" Part of this documentation was written by +.\" Konstantin Belousov under sponsorship +.\" from the FreeBSD Foundation. +.\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: @@ -24,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd October 19, 2007 +.Dd September 20, 2014 .Dt LIBTHR 3 .Os .Sh NAME @@ -45,8 +50,216 @@ has been optimized for use by applications expecting system scope thread semantics, and can provide significant performance improvements compared to .Lb libkse . +.Pp +The library is tightly integrated with the run-time link editor +.Xr ld-elf.so.1 1 +and +.Lb libc ; +all three components must be built from the same source tree. +Mixing +.Li libc +and +.Nm +libraries from different versions of +.Fx +is not supported. +The run-time linker +.Xr ld-elf.so.1 1 +has some code to ensure backward-compatibility with older versions of +.Nm . +.Pp +The man page documents the quirks and tunables of the +.Nm . +When linking with +.Li -lpthread , +the run-time dependency +.Li libthr.so.3 +is recorded in the produced object. +.Sh MUTEX ACQUISITION +A locked mutex (see +.Xr pthread_mutex_lock 3 ) +is represented by a volatile variable of type +.Dv lwpid_t , +which records the global system identifier of the thread +owning the lock. +.Nm +performs a contested mutex acquisition in three stages, each of which +is more resource-consuming than the previous. +.Pp +First, a spin loop +is performed, where the library attempts to acquire the lock by +.Xr atomic 9 +operations. +The loop count is controlled by the +.Ev LIBPTHREAD_SPINLOOPS +environment variable, with a default value of 2000. +.Pp +If the spin loop +was unable to acquire the mutex, a yield loop +is executed, performing the same +.Xr atomic 9 +acquisition attempts as the spin loop, +but each attempt is followed by a yield of the CPU time +of the thread using the +.Xr sched_yield 2 +syscall. +By default, the yield loop +is not executed. +This is controlled by the +.Ev LIBPTHREAD_YIELDLOOPS +environment variable. +.Pp +If both the spin and yield loops +failed to acquire the lock, the thread is taken off the CPU and +put to sleep in the kernel with the +.Xr umtx 2 +syscall. +The kernel wakes up a thread and hands the ownership of the lock to +the woken thread when the lock becomes available. +.Sh THREAD STACKS +Each thread is provided with a private user-mode stack area +used by the C runtime. +The size of the main (initial) thread stack is set by the kernel, and is +controlled by the +.Dv RLIMIT_STACK +process resource limit (see +.Xr getrlimit 2 ) . +.Pp +By default, the main thread's stack size is equal to the value of +.Dv RLIMIT_STACK +for the process. +If the +.Ev LIBPTHREAD_SPLITSTACK_MAIN +environment variable is present in the process environment +(its value does not matter), +the main thread's stack is reduced to 4MB on 64bit architectures, and to +2MB on 32bit architectures, when the threading library is initialized. +The rest of the address space area which has been reserved by the +kernel for the initial process stack is used for non-initial thread stacks +in this case. +The presence of the +.Ev LIBPTHREAD_BIGSTACK_MAIN +environment variable overrides +.Ev LIBPTHREAD_SPLITSTACK_MAIN ; +it is kept for backward-compatibility. +.Pp +The size of stacks for threads created by the process at run-time +with the +.Xr pthread_create 3 +call is controlled by thread attributes: see +.Xr pthread_attr 3 , +in particular, the +.Xr pthread_attr_setstacksize 3 , +.Xr pthread_attr_setguardsize 3 +and +.Xr pthread_attr_setstackaddr 3 +functions. +If no attributes for the thread stack size are specified, the default +non-initial thread stack size is 2MB for 64bit architectures, and 1MB +for 32bit architectures. +.Sh RUN-TIME SETTINGS +The following environment variables are recognized by +.Nm +and adjust the operation of the library at run-time: +.Bl -tag -width LIBPTHREAD_SPLITSTACK_MAIN +.It Ev LIBPTHREAD_BIGSTACK_MAIN +Disables the reduction of the initial thread stack enabled by +.Ev LIBPTHREAD_SPLITSTACK_MAIN . +.It Ev LIBPTHREAD_SPLITSTACK_MAIN +Causes a reduction of the initial thread stack, as described in the +section +.Sx THREAD STACKS . +This was the default behaviour of +.Nm +before +.Fx 11.0 . +.It Ev LIBPTHREAD_SPINLOOPS +The integer value of the variable overrides the default count of +iterations in the +.Li spin loop +of the mutex acquisition. +The default count is 2000, set by the +.Dv MUTEX_ADAPTIVE_SPINS +constant in the +.Nm +sources. +.It Ev LIBPTHREAD_YIELDLOOPS +A non-zero integer value enables the yield loop +in the process of the mutex acquisition. +The value is the count of loop operations. +.It Ev LIBPTHREAD_QUEUE_FIFO +The integer value of the variable specifies how often blocked +threads are inserted at the head of the sleep queue, instead of its tail. +Bigger values reduce the frequency of the FIFO discipline. +The value must be between 0 and 255. +.El +.Sh INTERACTION WITH RUN-TIME LINKER +The +.Nm +library must appear before +.Li libc +in the global order of depended objects. +.Pp +Loading +.Nm +with the +.Xr dlopen 3 +call in the process after the program binary is activated +is not supported, and causes miscellaneous and hard-to-diagnose misbehaviour. +This is due to +.Nm +interposing several important +.Li libc +symbols to provide thread-safe services. +In particular, +.Dv errno +and the locking stubs from +.Li libc +are affected. +This requirement is currently not enforced. +.Pp +If the program loads any modules at run-time, and those modules may require +threading services, the main program binary must be linked with +.Li libpthread , +even if it does not require any services from the library. +.Pp +.Nm +cannot be unloaded; the +.Xr dlclose 3 +function does not perform any action when called with a handle for +.Nm . +One of the reasons is that the interposing of +.Li libc +functions cannot be undone. +.Sh SIGNALS +The implementation also interposes the user-installed +.Xr signal 3 +handlers. +This interposing is done to postpone signal delivery to threads which +entered (libthr-internal) critical sections, where the calling +of the user-provided signal handler is unsafe. +An example of such a situation is owning the internal library lock. +When a signal is delivered while the signal handler cannot be safely +called, the call is postponed and performed until after the exit from +the critical section. +This should be taken into account when interpreting +.Xr ktrace 1 +logs. .Sh SEE ALSO -.Xr pthread 3 +.Xr ktrace 1 , +.Xr ld-elf.so.1 1 , +.Xr getrlimit 2 , +.Xr umtx 2 , +.Xr dlclose 3 , +.Xr dlopen 3 , +.Xr errno 3 , +.Xr getenv 3 , +.Xr libc 3 , +.Xr pthread_attr 3 , +.Xr pthread_attr_setstacksize 3 , +.Xr pthread_create 3 , +.Xr signal 3 , +.Xr atomic 9 .Sh AUTHORS .An -nosplit The diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c index 9bf0e29..6d6a532 100644 --- a/lib/libthr/thread/thr_init.c +++ b/lib/libthr/thread/thr_init.c @@ -445,7 +445,7 @@ init_private(void) struct rlimit rlim; size_t len; int mib[2]; - char *env; + char *env, *env_bigstack, *env_splitstack; _thr_umutex_init(&_mutex_static_lock); _thr_umutex_init(&_cond_static_lock); @@ -473,8 +473,9 @@ init_private(void) len = sizeof (_usrstack); if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1) PANIC("Cannot get kern.usrstack from sysctl"); - env = getenv("LIBPTHREAD_BIGSTACK_MAIN"); - if (env != NULL) { + env_bigstack = getenv("LIBPTHREAD_BIGSTACK_MAIN"); + env_splitstack = getenv("LIBPTHREAD_SPLITSTACK_MAIN"); + if (env_bigstack != NULL || env_splitstack == NULL) { if (getrlimit(RLIMIT_STACK, &rlim) == -1) PANIC("Cannot get stack rlimit"); _thr_stack_initial = rlim.rlim_cur; From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 12:16:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FB7E115 for ; Tue, 23 Sep 2014 12:16:45 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A26119E for ; Tue, 23 Sep 2014 12:16:45 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XWP1O-002gW9-RY>; Tue, 23 Sep 2014 14:16:42 +0200 Received: from e179169208.adsl.alicedsl.de ([85.179.169.208] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XWP1O-002tRi-Pe>; Tue, 23 Sep 2014 14:16:42 +0200 Date: Tue, 23 Sep 2014 14:16:38 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: /boot/loader.efi and buildkernel Message-ID: <20140923141638.1b26bc4b.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/OzkckZ2M+=oq_GcABCVNLq1"; protocol="application/pgp-signature" X-Originating-IP: 85.179.169.208 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 12:16:45 -0000 --Sig_/OzkckZ2M+=oq_GcABCVNLq1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Modules and kernel are built when running "make buildkernel", but the other= contents of /boot/ aren't. How can I manually - and separately - build the loader, especially /boot/loader.efi? I realized that building loader.efi with any kind of optimization beyond de= bugging- or close-to-debugging level ends up in an unloadable loader.efi on Haswell CPU= s (IvyBridge and C2D seem to be unaffected). The system in question is the most recent C= URRENT, compiled with system's CLANG 3.4.1. Regards, Oliver --Sig_/OzkckZ2M+=oq_GcABCVNLq1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUIWSqAAoJEOgBcD7A/5N87egIAIx80cub9e5ZLBkCuAp9WMy8 hZoUA3geQOyogUjLDJNi2g4dMBFgmg8r6/oVtxcoTIohCzTXYsqmMQUilbQ3WD0A sQQ5ZQCU+u26rl9t0l5xuAeT++FB3jRuMI2EQr5kzHQU7KwHbTFosNY7xH6tzrui Ew/FOIUjGTHOrkm045ievaoHq5VkcirOffTIx8yNCzbGKViiJvrgYA6DkY6eFUZu 3dtxJHv6YzH5aFQePS/rYZMfzRFabub7KLL67K5UbzIU1kDe5CcwfWqwkoNXX9Vi z1GRLZM4j2WDoGK7NG/L0FwLT43NkoVqm9aYimp3b6hygNoS/lel1dzDlrT6Ttk= =od+4 -----END PGP SIGNATURE----- --Sig_/OzkckZ2M+=oq_GcABCVNLq1-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 14:29:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A5A969D; Tue, 23 Sep 2014 14:29:04 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9682666; Tue, 23 Sep 2014 14:29:03 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8NET1uE077434; Tue, 23 Sep 2014 16:29:01 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 0DEC23F83; Tue, 23 Sep 2014 16:29:00 +0200 (CEST) Message-ID: <542183A6.7060802@omnilan.de> Date: Tue, 23 Sep 2014 16:28:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C1B82019D26BBE92A0E8080" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Tue, 23 Sep 2014 16:29:01 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: Allan Jude , FreeBSD Current , Ed Maste , Nathan Whitehorn , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 14:29:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C1B82019D26BBE92A0E8080 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime): > =85 > The problem I reported about in the first place is triggered by a fault= y loader.efi that > arises, when optimisation level is -O3. -O2 works fine. I can confirm that this problem also shows up when using 'CPUTYPE?=3Dcore-avx2' Setting CPUTYPE to core-avx-i doesnt ehibit the problem. I could narrow down the cause to libefi.a (sys/boot/efi). But I don't understand the things going on there, so no clue how to fix besides maybe --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 +0200 +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.000000000 +0200 @@ -2,6 +2,10 @@ BINDIR?=3D /boot +.ifdef CPUTYPE +.undef CPUTYPE +.endif + =2Eif ${MACHINE_CPUARCH} =3D=3D "i386" CFLAGS+=3D -march=3Di386 =2Eendif -Harry --------------enig1C1B82019D26BBE92A0E8080 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQhg6wACgkQLDqVQ9VXb8hH/wCePPZzwlbpprEGI3r0h9i0+SSR NuYAoL7YEs30nnJMyNxOAD4lTvC9uyqO =MhBX -----END PGP SIGNATURE----- --------------enig1C1B82019D26BBE92A0E8080-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 14:51:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B99731D8; Tue, 23 Sep 2014 14:51:11 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 453F497A; Tue, 23 Sep 2014 14:51:11 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8NEp9ou077679; Tue, 23 Sep 2014 16:51:09 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id CE60D3F91; Tue, 23 Sep 2014 16:51:08 +0200 (CEST) Message-ID: <542188DC.8000307@omnilan.de> Date: Tue, 23 Sep 2014 16:51:08 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> In-Reply-To: <542183A6.7060802@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB7157B497E3520E5A72BD488" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 23 Sep 2014 16:51:09 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: Andriy Gapon , FreeBSD Current , Ed Maste , Nathan Whitehorn , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 14:51:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7157B497E3520E5A72BD488 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28 (localtime): > Bez=FCglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime): >> =85 >> The problem I reported about in the first place is triggered by a faul= ty loader.efi that >> arises, when optimisation level is -O3. -O2 works fine. > I can confirm that this problem also shows up when using > 'CPUTYPE?=3Dcore-avx2' > Setting CPUTYPE to core-avx-i doesnt ehibit the problem. > > I could narrow down the cause to libefi.a (sys/boot/efi). > But I don't understand the things going on there, so no clue how to fix= > besides maybe > > --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 +0200 > +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.000000000 +0200 > @@ -2,6 +2,10 @@ > > BINDIR?=3D /boot > > +.ifdef CPUTYPE > +.undef CPUTYPE > +.endif Sorry, forget the suggestion, it doesn't work since it leads to CFLAG -march=3D"" and the same problem occurs. For my case this works: --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 +02= 00 +++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.000000000 +0200 @@ -2,6 +2,10 @@ =20 BINDIR?=3D /boot =20 +.if ${CPUTYPE} =3D=3D "core-avx2" +CPUTYPE=3D core-avx-i +.endif + .if ${MACHINE_CPUARCH} =3D=3D "i386" CFLAGS+=3D -march=3Di386 .endif JFI -Harry --------------enigB7157B497E3520E5A72BD488 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQhiNwACgkQLDqVQ9VXb8j0BQCdGO5woe6j/207CqfcJWXyTkha mkoAoM85ffkzs+eK1+rW5ZnfgBEuEfxs =BxjJ -----END PGP SIGNATURE----- --------------enigB7157B497E3520E5A72BD488-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:00:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3E6941E; Tue, 23 Sep 2014 15:00:35 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2B21A02; Tue, 23 Sep 2014 15:00:35 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8NF0VxG000893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Sep 2014 08:00:32 -0700 Message-ID: <54218B0F.20707@freebsd.org> Date: Tue, 23 Sep 2014 08:00:31 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Harald Schmalzbauer , "O. Hartmann" Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> In-Reply-To: <542183A6.7060802@omnilan.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVYUGJmbG/M7QDx7t/346o+G2QFDP9MS6wG8nlnoaxfyoWm4jLU0gv4bT3uABuSWyRUWGznSLG0dpFOjTdYbtKrcVgAln9Rd16I= X-Sonic-ID: C;7lYgXTJD5BGoFTZXoK8kYw== M;4r6RXTJD5BGoFTZXoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: FreeBSD Current , Ed Maste , Allan Jude , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:00:35 -0000 Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? -Nathan On 09/23/14 07:28, Harald Schmalzbauer wrote: > Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime): >> … >> The problem I reported about in the first place is triggered by a faulty loader.efi that >> arises, when optimisation level is -O3. -O2 works fine. > I can confirm that this problem also shows up when using > 'CPUTYPE?=core-avx2' > Setting CPUTYPE to core-avx-i doesnt ehibit the problem. > > I could narrow down the cause to libefi.a (sys/boot/efi). > But I don't understand the things going on there, so no clue how to fix > besides maybe > > --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 +0200 > +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.000000000 +0200 > @@ -2,6 +2,10 @@ > > BINDIR?= /boot > > +.ifdef CPUTYPE > +.undef CPUTYPE > +.endif > + > .if ${MACHINE_CPUARCH} == "i386" > CFLAGS+= -march=i386 > .endif > > -Harry > From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:04:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11A9C67D for ; Tue, 23 Sep 2014 15:04:47 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id DEF29AD1 for ; Tue, 23 Sep 2014 15:04:46 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1A4B941FB4 for ; Tue, 23 Sep 2014 15:04:40 +0000 (UTC) Message-ID: <54218C11.3000702@freebsd.org> Date: Tue, 23 Sep 2014 11:04:49 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: 10.1-BETA2 ZFS boot failure on sparc64 References: <20140923061350.GA96111@pix.net> In-Reply-To: <20140923061350.GA96111@pix.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uXPX2g1cCtpAepkrOGUF9KKssfqTX934S" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:04:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uXPX2g1cCtpAepkrOGUF9KKssfqTX934S Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-09-23 02:13, Kurt Lidl wrote: > I downloaded the 10.1-BETA disc1 iso image for > sparc64, and burned it to media. I then used that > media to attempt an installation onto a spare > sparc64 machine that I have. >=20 > Using UFS as the filesystem, and more or less just > following the prompts, the system got installed OK, > and boots off of ZFS OK. >=20 > I then reinstalled onto a system that I manually > configured for ZFS. This installation fails to boot > from the hard disk, dying like this: >=20 > ---- snip, snip ---- > ok reset > Res > LOM event: +487d+12h37m31s host reset > etting ...=20 >=20 > ? > Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard > OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. > Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. >=20 > Boot device: disk0 File and args: =20 > =20 >>> FreeBSD/sparc64 ZFS boot block > Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a > Consoles: Open Firmware console =20 > Memory Address not Aligned > ok=20 >=20 > ---- snip, snip ---- >=20 > I have used my exact procedure in the past to install onto a ZFS > only sparc without issue. >=20 > Has anyone else tried booting a ZFS only sparc64 installation > recently? >=20 > -Kurt > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 If you have the entire drive to spare, have you tried the 'ZFS auto mode' script that Devin and I wrote? It is the bottom option in the installer partitioning menu. --=20 Allan Jude --uXPX2g1cCtpAepkrOGUF9KKssfqTX934S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUIYwTAAoJEJrBFpNRJZKfkrAQAJHzINGwdP1PGDvozNLkYx5g hIQQoBoAnc09bp8y/HC6J+PYmYor1cTO1omPM8ZxSqcntobPjxRnCWR1ejp+H9ad 6itjtAExc8cudmqDXe1TkwoK3ceiqEH/c6bi5L6QiPL/flf0pnH2e628Hod1/a1d G+stW91IEeo+jAAwQDxDB8Wg8LA3Wlz2Jgvv4JL5gb9qQ/qzdtjp052SUjDUJEmF 1DQKN0eEweXd1nIUKaZnXJCqHnFOk7qYI7qnBAht+SYHqDTMRRS15K2Uba/w3XK3 zNZMuKxcxwsykMlD4YOAAp35XY3yR3DTnNXaiyfKhfSz6stZFicUjkZ7jT1ob+Mn wP5L3sta/ws1nJgsneAFPyneoQeM/BzrivPjVQncKAg70wFcrmbh8j7lNVhnMsjm m7itn8i3TTZu2KPyREP+WvsbNCX3RPUJY3v7LozdUdzL6Q73+wYs3akglEYRP08A 2xchgqNDX5CJ4Y8MT0GFEztALQViiVMTW1enAamueyfYgrrgI9wP07QChYSwnzJz BfpWB6Tz51uoIoZ1e8tZPOQ5qEH2Kbm6ocGUIEvZ0O/EBZ7Nejxg4OsyC2UZzMTX 8stXE1GwgN9btLKwtmGhSyqDDWjucZVTa0a75uczZ09LeS+QdhY/neLcxnm3VmNd 5tDlaYWjFwao75BDUGca =/YvC -----END PGP SIGNATURE----- --uXPX2g1cCtpAepkrOGUF9KKssfqTX934S-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:08:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3BE0859 for ; Tue, 23 Sep 2014 15:08:31 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61532AFE for ; Tue, 23 Sep 2014 15:08:31 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8NF8TYI077864; Tue, 23 Sep 2014 17:08:29 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 0CD723FA0; Tue, 23 Sep 2014 17:08:28 +0200 (CEST) Message-ID: <54218CEC.8020904@omnilan.de> Date: Tue, 23 Sep 2014 17:08:28 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: /boot/loader.efi and buildkernel References: <20140923141638.1b26bc4b.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140923141638.1b26bc4b.ohartman@zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0352644EA633E80F202629FD" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 23 Sep 2014 17:08:29 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:08:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0352644EA633E80F202629FD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich O. Hartmann's Nachricht vom 23.09.2014 14:16 (localtime): > Modules and kernel are built when running "make buildkernel", but the o= ther contents > of /boot/ aren't. How can I manually - and separately - build the loade= r, > especially /boot/loader.efi? Simply cd to src/sys/boot and do 'make clean && make && make DESTDIR=3D/altroot', the latter only if you don't want to overwrite curdev's /boot/ files. For loader.efi only, it's enough to do 'make clean && make' in the following directories: src/sys/boot/ficl src/sys/boot/efi src/sys/boot/amd64/efi =46rom amd64/efi you can 'make install' to just copy loader.efi (or copy manually from obj/$src/sys/boot/amd64/efi/loader.efi) > I realized that building loader.efi with any kind of optimization beyon= d debugging- or > close-to-debugging level ends up in an unloadable loader.efi on Haswell= CPUs (IvyBridge > and C2D seem to be unaffected). The system in question is the most rece= nt CURRENT, > compiled with system's CLANG 3.4.1. This is confirmed for CPUTYPE=3Dcore-avx2, see my recent post. My test machine was haswell as well, but I haven't tested on anything else! -Harry --------------enig0352644EA633E80F202629FD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQhjOwACgkQLDqVQ9VXb8gFoACfdzhNB7X9lJnNOvuj5UUZdOel rx0AnRW5wMFxO856RXmJKeUK3AXUhiO2 =OY8y -----END PGP SIGNATURE----- --------------enig0352644EA633E80F202629FD-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:09:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D93A961 for ; Tue, 23 Sep 2014 15:09:07 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03921B0C for ; Tue, 23 Sep 2014 15:09:06 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8NF90aC020274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 23 Sep 2014 08:09:00 -0700 Message-ID: <54218D0C.4020505@freebsd.org> Date: Tue, 23 Sep 2014 08:09:00 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: 10.1-BETA2 ZFS boot failure on sparc64 References: <20140923061350.GA96111@pix.net> <54218C11.3000702@freebsd.org> In-Reply-To: <54218C11.3000702@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYgap8Nt9v4hoslpqtIZMX5r+b8qXjybqgwdBtfV4f2Z4jNSzg9gq9nPtVBLTpnXqsbXXTPFqE8uuJ+ZbS+4PSrTTLNMgdeezY= X-Sonic-ID: C;+B9ejDND5BGncQDu5Qupew== M;cgWajDND5BGncQDu5Qupew== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:09:07 -0000 On 09/23/14 08:04, Allan Jude wrote: > On 2014-09-23 02:13, Kurt Lidl wrote: >> I downloaded the 10.1-BETA disc1 iso image for >> sparc64, and burned it to media. I then used that >> media to attempt an installation onto a spare >> sparc64 machine that I have. >> >> Using UFS as the filesystem, and more or less just >> following the prompts, the system got installed OK, >> and boots off of ZFS OK. >> >> I then reinstalled onto a system that I manually >> configured for ZFS. This installation fails to boot >> from the hard disk, dying like this: >> >> ---- snip, snip ---- >> ok reset >> Res >> LOM event: +487d+12h37m31s host reset >> etting ... >> >> ? >> Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard >> OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. >> Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. >> >> Boot device: disk0 File and args: >> >>>> FreeBSD/sparc64 ZFS boot block >> Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a >> Consoles: Open Firmware console >> Memory Address not Aligned >> ok >> >> ---- snip, snip ---- >> >> I have used my exact procedure in the past to install onto a ZFS >> only sparc without issue. >> >> Has anyone else tried booting a ZFS only sparc64 installation >> recently? >> >> -Kurt >> _______________________________________________ >> 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" >> > If you have the entire drive to spare, have you tried the 'ZFS auto > mode' script that Devin and I wrote? It is the bottom option in the > installer partitioning menu. > Allan, that script doesn't work on sparc since it doesn't know about VTOC8 and can only install to GPT and MBR. As committed, the menu item is also disabled on anything other than i386 and amd64. The partition editor in -CURRENT likely works, since it is based on code Kurt submitted, but is untested on sparc since his original patch. I think the more likely issue is that the boot blocks have bitrotted somehow on SPARC. That's certainly consistent with the "Memory Address not Aligned" error. -Nathan From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:15:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0442BB5; Tue, 23 Sep 2014 15:15:04 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 643E3BFE; Tue, 23 Sep 2014 15:15:04 +0000 (UTC) Received: from [192.168.2.2] (unknown [77.243.161.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B1602B803; Tue, 23 Sep 2014 17:14:58 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_727A827C-2669-422C-830E-2BE6C29D66EC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: CURRENT: EFI boot failure From: Dimitry Andric In-Reply-To: <54218B0F.20707@freebsd.org> Date: Tue, 23 Sep 2014 17:14:46 +0200 Message-Id: <9F1F287F-751C-4456-BB5E-540824E1B4E8@FreeBSD.org> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> <54218B0F.20707@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Cc: Ed Maste , Andriy Gapon , Harald Schmalzbauer , FreeBSD Current , Allan Jude , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:15:04 -0000 --Apple-Mail=_727A827C-2669-422C-830E-2BE6C29D66EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 23 Sep 2014, at 17:00, Nathan Whitehorn = wrote: > On 09/23/14 07:28, Harald Schmalzbauer wrote: >> Bez=FCglich O. Hartmann's Nachricht vom 19.09.2014 15:22 = (localtime): >>> =85 >>> The problem I reported about in the first place is triggered by a = faulty loader.efi that >>> arises, when optimisation level is -O3. -O2 works fine. >> I can confirm that this problem also shows up when using >> 'CPUTYPE?=3Dcore-avx2' >> Setting CPUTYPE to core-avx-i doesnt ehibit the problem. >>=20 >> I could narrow down the cause to libefi.a (sys/boot/efi). >> But I don't understand the things going on there, so no clue how to = fix >> besides maybe >>=20 >> --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 = +0200 >> +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.000000000 +0200 >> @@ -2,6 +2,10 @@ >>=20 >> BINDIR?=3D /boot >>=20 >> +.ifdef CPUTYPE >> +.undef CPUTYPE >> +.endif >> + >> .if ${MACHINE_CPUARCH} =3D=3D "i386" >> CFLAGS+=3D -march=3Di386 >> .endif > Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? > -Nathan IMHO CPUTYPE should be ignored for any boot loader program, and the lowest common denominator should be used instead (i486 for 32-bit, plain x86_64 for 64-bit). It makes no sense to optimize boot loaders for e.g. core-avx2. :-) But indeed, it appears that we need to add more -mno-foo magic flags... -Dimitry --Apple-Mail=_727A827C-2669-422C-830E-2BE6C29D66EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEUEARECAAYFAlQhjmsACgkQsF6jCi4glqPGFQCdGvwbc2IBT34JsrsQelp+pAFI /00AmK3IqThnJ0l+FCPipuvSizxev2s= =yXB/ -----END PGP SIGNATURE----- --Apple-Mail=_727A827C-2669-422C-830E-2BE6C29D66EC-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:15:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BDA4D97; Tue, 23 Sep 2014 15:15:30 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69704C17; Tue, 23 Sep 2014 15:15:29 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8NFFRWE077973; Tue, 23 Sep 2014 17:15:27 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id CD4023FA7; Tue, 23 Sep 2014 17:15:26 +0200 (CEST) Message-ID: <54218E8E.70309@omnilan.de> Date: Tue, 23 Sep 2014 17:15:26 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> <54218B0F.20707@freebsd.org> In-Reply-To: <54218B0F.20707@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig48DCC40BE5368915F3FB4499" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 23 Sep 2014 17:15:27 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: Ed Maste , FreeBSD Current , "O. Hartmann" , Andriy Gapon , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:15:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig48DCC40BE5368915F3FB4499 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Nathan Whitehorn's Nachricht vom 23.09.2014 17:00 (localtime= ): > Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? = Done so, but it doesn't fix the problem with halting loader.efi when compiled with CPUTYPE=3Dcore-avx2. The whole -mno-xyz isn't applied to sys/boot/efi/libefi: cc -O2 -pipe -march=3Dcore-avx2 -fPIC -I/usr/src/sys/boot/efi/libefi/../include -I/usr/src/sys/boot/efi/libefi/../include/amd64 -I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand -I/usr/src/sys/boot/efi/libefi/../../common -DNO_PCI -fformat-extensions -ffreestanding -fshort-wchar -Wformat -std=3Dgnu99 -Qunused-arguments -c delay.c -o delay.o Thanks, -Harry --------------enig48DCC40BE5368915F3FB4499 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQhjo4ACgkQLDqVQ9VXb8hmMwCgqSeDYfjWQcFKM0kqGN137KwO LOAAn1EGRzMTLCOmK0nL6yavghEHAsc5 =Ifag -----END PGP SIGNATURE----- --------------enig48DCC40BE5368915F3FB4499-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 15:28:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 955CB6C0 for ; Tue, 23 Sep 2014 15:28:12 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 52D64D79 for ; Tue, 23 Sep 2014 15:28:11 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3531251162 for ; Tue, 23 Sep 2014 15:28:11 +0000 (UTC) Message-ID: <54219194.1070907@freebsd.org> Date: Tue, 23 Sep 2014 11:28:20 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: 10.1-BETA2 ZFS boot failure on sparc64 References: <20140923061350.GA96111@pix.net> <54218C11.3000702@freebsd.org> <54218D0C.4020505@freebsd.org> In-Reply-To: <54218D0C.4020505@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F1bhUWASuAW6VcqwOeo9IaS9wCBUrP3a9" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 15:28:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F1bhUWASuAW6VcqwOeo9IaS9wCBUrP3a9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-09-23 11:09, Nathan Whitehorn wrote: >=20 > On 09/23/14 08:04, Allan Jude wrote: >> On 2014-09-23 02:13, Kurt Lidl wrote: >>> I downloaded the 10.1-BETA disc1 iso image for >>> sparc64, and burned it to media. I then used that >>> media to attempt an installation onto a spare >>> sparc64 machine that I have. >>> >>> Using UFS as the filesystem, and more or less just >>> following the prompts, the system got installed OK, >>> and boots off of ZFS OK. >>> >>> I then reinstalled onto a system that I manually >>> configured for ZFS. This installation fails to boot >>> from the hard disk, dying like this: >>> >>> ---- snip, snip ---- >>> ok reset >>> Res >>> LOM event: +487d+12h37m31s host reset >>> etting ... >>> >>> ? >>> Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard >>> OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. >>> Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. >>> >>> Boot device: disk0 File and args: >>> =20 >>>>> FreeBSD/sparc64 ZFS boot block >>> Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a >>> Consoles: Open Firmware console >>> Memory Address not Aligned >>> ok >>> >>> ---- snip, snip ---- >>> >>> I have used my exact procedure in the past to install onto a ZFS >>> only sparc without issue. >>> >>> Has anyone else tried booting a ZFS only sparc64 installation >>> recently? >>> >>> -Kurt >>> _______________________________________________ >>> 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" >>> >> If you have the entire drive to spare, have you tried the 'ZFS auto >> mode' script that Devin and I wrote? It is the bottom option in the >> installer partitioning menu. >> >=20 > Allan, that script doesn't work on sparc since it doesn't know about > VTOC8 and can only install to GPT and MBR. As committed, the menu item > is also disabled on anything other than i386 and amd64. The partition > editor in -CURRENT likely works, since it is based on code Kurt > submitted, but is untested on sparc since his original patch. >=20 > I think the more likely issue is that the boot blocks have bitrotted > somehow on SPARC. That's certainly consistent with the "Memory Address > not Aligned" error. > -Nathan >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" Ahh yes, I remember consider supporting sparc64, but with no one to test, and what I can only imagine is a small userbase, of hardcore people who would rather do it manually, we decided against it. --=20 Allan Jude --F1bhUWASuAW6VcqwOeo9IaS9wCBUrP3a9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUIZGXAAoJEJrBFpNRJZKf5sUQAKUqhxkTgUHb8Wa/rD7k+sCh /VkEN5UXxKkP6W7V+0kG1GV0Jb6UuDPhft0sYkT1wqILmfJcGnfjc5JGOgTM2lea lUqDt7nKQlXZRj13H7Hcb3eLjNJR6EoCP1/JbJ4qrWvRxDhwXRxfaBdQ4ITQF7Wv JbbWdGPpN97Qd0S4vsd4DFYU+4q6402YXzv+psQMFO4FrxCoelj64BWLzpv2A2cS 4IUL8YfOKGEKk8npRFwPfVDzwbhT3J4HZ84lazpp1DjmUlIRyFdF+z3Xcj0g2Xgx FLVhqLCie6K4GBngXWkHwHA6cAKv69572EehHsotr2urbd6+RCWjENG7QxYlJ8pn XkrPPhRdmxyUgARwKD9RRkyS3Ljbx00g2RwBFu4eql3NTSLud/Xpq8DfL/bv+9BO d/HR5q8C0YCW3P1WXBSJSocmKJAx0bqdcGazsaN49dI7tjLg/trgUdv9DVNV5Olh dLOFzBZ+2/msHKNb1s9XCddvtgSk7zMkfEW0FHfVgL1/8I3RITEfkJXGfNEJZbJS Ha8ma5nKgT07QwBuGFMSAuoKCob/JbhxvS6Wr5SIlfy8a+bmIZtxPo8Z6kQZWGSS omqbmyDF8ZlMkOsbmYxz2Wk42oh8OJ1awT/wO/bkbB6u7Sfz5wIzB8Q3jk+6431c OyQM0FnTtPovMY3neIFs =Zfo1 -----END PGP SIGNATURE----- --F1bhUWASuAW6VcqwOeo9IaS9wCBUrP3a9-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 16:29:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E78217DF for ; Tue, 23 Sep 2014 16:29:57 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB0D66CB for ; Tue, 23 Sep 2014 16:29:57 +0000 (UTC) Received: from jaesungp-sslvpn-nc.jnpr.net ([66.129.239.11]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s8NGTsa3029566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 23 Sep 2014 09:29:55 -0700 (PDT) (envelope-from marcel@xcllnt.net) From: Marcel Moolenaar Content-Type: multipart/signed; boundary="Apple-Mail=_FE144C49-1625-4B8A-81A7-DDAADAF13556"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Poor state of the build infrastructure. Message-Id: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> Date: Tue, 23 Sep 2014 09:29:48 -0700 To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 23 Sep 2014 16:29:58 -0000 --Apple-Mail=_FE144C49-1625-4B8A-81A7-DDAADAF13556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Things have regressed from last I tried (which is a while). After a clean buildworld for PowerPC I can't install it: # make installworld TARGET_ARCH=3Dpowerpc TARGET=3Dpowerpc = __MAKE_CONF=3D/dev/null DESTDIR=3D/tank/scratch/powerpc mkdir -p /tmp/install.pjtGQ4J8 : make[2]: "/tank/scratch/marcelm/head/share/mk/bsd.compiler.mk" line 37: = Unable to determine compiler type for cc. Consider setting = COMPILER_TYPE. *** Error code 1 And look at share/mk/bsd.compiler.mk. Its comments with typos doesn't even fit 80 character. While technically speaking, not a problem, it does leave the impression of low quality. This has the unfortunate side-effect of deepening the low quality perception caused by not being able to do an installworld in the first place. So, ok. I add COMPILER_TYPE=3Dfuckthat to the command line and guess what: # make installworld TARGET_ARCH=3Dpowerpc TARGET=3Dpowerpc = __MAKE_CONF=3D/dev/null DESTDIR=3D/tank/scratch/powerpc = COMPILER_TYPE=3Dfuckthat mkdir -p /tmp/install.pFqalBOs : >>> Making hierarchy : >>> Installing everything : =3D=3D=3D> lib/csu/powerpc (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o = /tank/scratch/powerpc/usr/lib install: crt1.o: No such file or directory *** Error code 71 What??? Ok, let's check if things were build properly: % make buildenv __MAKE_CONF=3D/dev/null TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc $ cd lib/csu/powerpc $ make : cc -O2 -pipe ... -c crti.S crti.S:34:13: error: unexpected token in memory operand stwu 1,-16(1) ^ crti.S:35:2: error: invalid instruction mnemonic 'mflr' mflr 0 ^~~~ crti.S:36:12: error: unexpected token in memory operand stw 31,12(1) ^ crti.S:37:11: error: unexpected token in memory operand stw 0,20(1) ^ crti.S:38:2: error: invalid instruction mnemonic 'mr' mr 31,1 ^~ crti.S:45:13: error: unexpected token in memory operand stwu 1,-16(1) ^ crti.S:46:2: error: invalid instruction mnemonic 'mflr' mflr 0 ^~~~ crti.S:47:12: error: unexpected token in memory operand stw 31,12(1) ^ crti.S:48:11: error: unexpected token in memory operand stw 0,20(1) ^ crti.S:49:2: error: invalid instruction mnemonic 'mr' mr 31,1 ^~ *** Error code 1 Grrr... $ which cc /usr/bin/cc $ cc -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.1 Thread model: posix Selected GCC installation:=20 So, now even the very questionable but fundamentally non-broken make buildenv isn't working anymore. How is anyone going to develop for anything but the host this way. Granted we seriously sucked in this regard to begin with but we seem to have regressed to the point of having absolutely no working support whatsoever. What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_FE144C49-1625-4B8A-81A7-DDAADAF13556 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQhn/wACgkQpgWlLWHuifb4DgCfd79AuI8kcRs0Wctc5bYth4mb Fs0AnRZ2rS8wCFEfJERPystcVsMaBcUb =w7WC -----END PGP SIGNATURE----- --Apple-Mail=_FE144C49-1625-4B8A-81A7-DDAADAF13556-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 06:55:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45FD0E2D for ; Wed, 24 Sep 2014 06:55:06 +0000 (UTC) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8EBF92E for ; Wed, 24 Sep 2014 06:55:05 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id q5so6559073wiv.10 for ; Tue, 23 Sep 2014 23:54:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ORGV8sSbFZ+vry0jX+Sz4krl2adWAClhIjRNT6Yo5xM=; b=QE8SVdE5tosfKdfMDa6ZXTfJYs1a3t6hfeRDyxKxvR09k3EEWCGc62ESy691JA9/24 wMwiS/opFiEqRlt3LmGgcfVdN9qiYRe1s0VfTqMYZgRJ62rLMlUVfO6zKWBuHM7wsYGP gXJSBLnfQCm/AtHu3HIrJXl7J4UEI6A/VjMy2UHpWa313W5BsvZ+wCeJpIcWNJqf9GKT TZUt/Yf/VTpRLgfCK9gilzdOtMrnsLIgrkObaQxbzYe6pHmzUSza3BJC+jw64XxS+HXI 3qX8s+wUjkU17TW4HeV3VyAZqDQ/Xdwd6M9inDQhcTd54EtkQ+VELmo8ZRPkTaoDwiEk SKTA== X-Gm-Message-State: ALoCoQlR3YRyxO3CzLS1eTGWIXhthBqzXHLUZM++RC1vVPko5ZJlT4wT4KLumySKe/Lo9eIU1Z0N X-Received: by 10.180.187.47 with SMTP id fp15mr28671995wic.70.1411541266584; Tue, 23 Sep 2014 23:47:46 -0700 (PDT) Received: from localhost ([94.3.67.218]) by mx.google.com with ESMTPSA id cz3sm18306691wjb.23.2014.09.23.23.47.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Sep 2014 23:47:45 -0700 (PDT) Date: Wed, 24 Sep 2014 07:47:44 +0100 From: Matt Fleming To: Nathan Whitehorn Subject: Re: CURRENT: EFI boot failure Message-ID: <20140924064744.GL18635@console-pimps.org> References: <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> <54218B0F.20707@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54218B0F.20707@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ed Maste , Andriy Gapon , Harald Schmalzbauer , FreeBSD Current , Allan Jude , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 06:55:06 -0000 On Tue, 23 Sep, at 08:00:31AM, Nathan Whitehorn wrote: > Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? Do you pull the -mno-redzone flag anywhere? I'm looking through the loader sources now, and I see that switch in sys/conf/kern.mk, but it doesn't look like that's being pulled in for the boot loader source. Calling into EFI will trash the x86-64 redzone, if you've got it enabled. -- Matt Fleming, Intel Open Source Technology Center From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 15:48:28 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D94E2ADD for ; Wed, 24 Sep 2014 15:48:28 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B71DEF99 for ; Wed, 24 Sep 2014 15:48:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8OFmSLG098509 for ; Wed, 24 Sep 2014 15:48:28 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8OFmSOl098508 for current@FreeBSD.org; Wed, 24 Sep 2014 15:48:28 GMT (envelope-from bdrewery) Received: (qmail 70879 invoked from network); 24 Sep 2014 10:48:27 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 24 Sep 2014 10:48:27 -0500 Message-ID: <5422E7C4.8070801@FreeBSD.org> Date: Wed, 24 Sep 2014 10:48:20 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: Cam panic on r271170 References: <5418F1B9.2000903@FreeBSD.org> <5419AB24.9050809@FreeBSD.org> In-Reply-To: <5419AB24.9050809@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 15:48:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/17/2014 10:39 AM, Bryan Drewery wrote: > On 9/16/2014 9:28 PM, Bryan Drewery wrote: >> I've been getting this quite frequently on head recently. I have dumps= >> if anyone is interested in more information. >> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid =3D 10; Memory modified after free 0xfffff8003e0b0800(2040) >>> val=3Dffffffff @ 0xfffff8003e0b0808 >>> apanic: Most recently used by CAM CCB >>> >>> cpuid =3D 6 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe124735b4c0 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124735b570 >>> vpanic() at vpanic+0x189/frame 0xfffffe124735b5f0 >>> panic() at panic+0x43/frame 0xfffffe124735b650 >>> mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfffffe124735b680 >>> uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfffffe124735b6f0 >>> malloc() at malloc+0x192/frame 0xfffffe124735b740 >>> xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfffffe124735b780 >>> adastrategy() at adastrategy+0x117/frame 0xfffffe124735b7b0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b810 >>> g_part_start() at g_part_start+0x2b7/frame 0xfffffe124735b890 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b8f0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b950 >>> vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfffffe124735= b970 >>> zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfffffe124735b9= d0 >>> zio_execute() at zio_execute+0x204/frame 0xfffffe124735ba30 >>> vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfffffe124735= ba80 >>> zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfffffe124735bac0= >>> zio_execute() at zio_execute+0x204/frame 0xfffffe124735bb20 >>> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >>> 0xfffffe124735bb80 >>> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >>> 0xfffffe124735bbb0 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe124735bbf0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe124735bbf0 >>> --- trap 0, rip =3D 0, rsp =3D 0xfffffe124735bcb0, rbp =3D 0 --- >>> KDB: enter: panic >>> [ thread pid 0 tid 100571 ] >>> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> >> >=20 > I also had this one recently: >=20 >> #8 0xffffffff80d1a162 in calltrap () at /usr/src/sys/amd64/amd64/exce= ption.S:231 >> #9 0xffffffff802e52c4 in xpt_path_periph (path=3D0xdeadc0dedeadc0de) = at /usr/src/sys/cam/cam_xpt.c:3738 >> #10 0xffffffff802dfe62 in cam_periph_error (ccb=3D0xfffff8003e0b6000, = camflags=3DCAM_FLAG_NONE, sense_flags=3D0, save_ccb=3D0x0) at /usr/src/sy= s/cam/cam_periph.c:1602 >> #11 0xffffffff803057e4 in adadone (periph=3D0xfffff8003e09b700, done_c= cb=3D0xfffff8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 >> #12 0xffffffff802e6e44 in xpt_done_process (ccb_h=3D0xfffff8003e0b6000= ) at /usr/src/sys/cam/cam_xpt.c:5245 >> #13 0xffffffff80394d59 in ahci_ch_intr_direct (arg=3D) at /usr/src/sys/dev/ahci/ahci.c:1132 >> #14 0xffffffff80390ff1 in ahci_intr (data=3D) at = /usr/src/sys/dev/ahci/ahci.c:417 >> #15 0xffffffff808ea5d3 in intr_event_execute_handlers (p=3D, ie=3D0xfffff8000f725d00) at /usr/src/sys/kern/kern_intr.c:125= 2 >> #16 0xffffffff808eafb6 in ithread_loop (arg=3D0xfffff8000f6dea60) at /= usr/src/sys/kern/kern_intr.c:1265 >> #17 0xffffffff808e7fc4 in fork_exit (callout=3D0xffffffff808eaf10 , arg=3D0xfffff8000f6dea60, frame=3D0xfffffe1245083c00) at /usr= /src/sys/kern/kern_fork.c:977 >> #18 0xffffffff80d1a69e in fork_trampoline () at /usr/src/sys/amd64/amd= 64/exception.S:605 >=20 >=20 Another, with much more information here: https://people.freebsd.org/~bdrewery/cam.panic.txt This was with memguard (vm.memguard.desc=3D"CAM CCB") and a KASSERT in malloc(9) and uma_zalloc_arg() to prevent M_WAITOK in non-sleepable threads. Neither triggered. It seems to be when syncing to the SSD ZFS log I have. --=20 Regards, Bryan Drewery --PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUIufEAAoJEDXXcbtuRpfPhp4IAIo8L8c6/j/tFahivDBuXmAG IAfQgJ7EdXDdsRMEDqFK+4B10hwUkx1u685j6wKc+GDDKqsJsyV8TyNyiCPafDqN iLzjMYvwp67ir0VNy8v8MTeAMS5Cl/WSF96EgvqO6YIA2OHZdLn3psCHjZ5lJoJm rLl+UUK2Jo/zCtCY0TPy4RZFu2aPCDNhpiWaZM+Hj8/U3ay/wDpiehTXlaoTPNtE Z/eJht7vuA7/jiCurqo8TipqcgNqTMZ3XXzFt0rpClsVc5Br5KvRw/+uhevz44GL X9sZ7l5JmCDUw8rQaXavQMBZhSfjo9dbouU5XyoGCqh9ZT3NrWHmwFWitwUUvDA= =J9aq -----END PGP SIGNATURE----- --PaQh5Jrvt03dJs7Ub5bBEj0okIPdEhkuc-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 16:16:58 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A12316D; Wed, 24 Sep 2014 16:16:58 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B38B405; Wed, 24 Sep 2014 16:16:57 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id w7so5298088lbi.20 for ; Wed, 24 Sep 2014 09:16: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=OC618AHxT0MIxX+64RL7d5DHlQ3F+ePemptg182aHEA=; b=YHH0SsU/g40ySPB/C7uBQBB2ePRHDKKhC0BM7SNvIXdrb3Z6/cMDQjM2LckuzeQe5O EBpL6RAuMcPGm+CJYTq5QAHH2UPxmp0gYvYpgeUMZjjNB7x8ZTs/hByEtZrI293L6b8A Jb1Sjbeon52tABfXXRJ7oNeJ4FdGY4tyrHJhqw8+u1MlfQC9hI22PtP0osPAYDQwtOOe SU8WHKRy1/eB84hwZj/6cdjcahVM4Z4PL02yJRih2u+tR7qICs8zEwB6HbnOS4hhcqU4 SAMWTi37RVhSf6D7EqbX4wvBUxy9a22UkYwqQxgDUQpAg6Joi6pQ/VNhDcNFqAVEaeZL 73rQ== MIME-Version: 1.0 X-Received: by 10.112.198.131 with SMTP id jc3mr6907821lbc.42.1411575415080; Wed, 24 Sep 2014 09:16:55 -0700 (PDT) Received: by 10.25.21.166 with HTTP; Wed, 24 Sep 2014 09:16:55 -0700 (PDT) In-Reply-To: <5422E7C4.8070801@FreeBSD.org> References: <5418F1B9.2000903@FreeBSD.org> <5419AB24.9050809@FreeBSD.org> <5422E7C4.8070801@FreeBSD.org> Date: Wed, 24 Sep 2014 12:16:55 -0400 Message-ID: Subject: Re: Cam panic on r271170 From: Ryan Stone To: Bryan Drewery Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 16:16:58 -0000 On Wed, Sep 24, 2014 at 11:48 AM, Bryan Drewery wrote: > Another, with much more information here: > https://people.freebsd.org/~bdrewery/cam.panic.txt > > This was with memguard (vm.memguard.desc="CAM CCB") and a KASSERT in > malloc(9) and uma_zalloc_arg() to prevent M_WAITOK in non-sleepable > threads. Neither triggered. Well that's unfortunate. Are CCBs ever the target of DMA? Does your hardware have an Intel chipset and is it new enough to support an IOMMU? You might try enabling the IOMMU, which would catch out-of-bounds DMA by hardware: http://svnweb.freebsd.org/changeset/base/257251 One caveat is that while I understand that the busdma infrastructure for this is quite well tested, individual drivers and devices need to be well-behaved so it's possible that this won't work on your hardware right now. Also, don't enable this if you use BHyve with PCI Passthrough. From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 19:11:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00722546; Wed, 24 Sep 2014 19:11:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEBCACF1; Wed, 24 Sep 2014 19:11:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 05D3BB91A; Wed, 24 Sep 2014 15:11:46 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCHES] Convert various pc98 drivers from timeout() to callout() Date: Wed, 24 Sep 2014 15:11:13 -0400 Message-ID: <2960329.SjaRrui0Bt@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 24 Sep 2014 15:11:46 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 19:11:48 -0000 I have three patches to convert various pc98 drivers from timeout() to callout(). For the fdc driver I took a more drastic approach and have attempted to port the PC98 support into the main fdc driver: http://people.FreeBSD.org/~jhb/patches/pc98_fdc.patch The pckbd driver needs a similar change to what I recently comitted to atkbd: http://people.FreeBSD.org/~jhb/patches/pckbd_callout.patch For the olpt driver, I just did a simple conversion: http://people.FreeBSD.org/~jhb/patches/olpt_callout.patch These patches are against HEAD but likely apply to 9 and 10 as well. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 19:11:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84035561 for ; Wed, 24 Sep 2014 19:11:49 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F5B9CF5 for ; Wed, 24 Sep 2014 19:11:49 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5331AB99B for ; Wed, 24 Sep 2014 15:11:48 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Lock ncr(4) Date: Wed, 24 Sep 2014 14:58:49 -0400 Message-ID: <9421896.uQLFX2YF7i@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 24 Sep 2014 15:11:48 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 19:11:49 -0000 This patch adds locking to wds(4) and marks it MPSAFE. It also includes several other cleanups such as using bus_space instead of inb/outb. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/ncr_locking.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 19:11:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D0B25CE for ; Wed, 24 Sep 2014 19:11:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1679FCF6 for ; Wed, 24 Sep 2014 19:11:50 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F76FB9A0 for ; Wed, 24 Sep 2014 15:11:49 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Convert some timers in isp(4) from timeout(9) to callout(9) Date: Wed, 24 Sep 2014 14:56:52 -0400 Message-ID: <1657921.oKsRhx1py3@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 24 Sep 2014 15:11:49 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 19:11:50 -0000 This patch converts a few timers in isp(4) from timeout(9) to callout(9). It already used callout(9) for normal command timeouts. The patch is against HEAD but probably applies to 9 and 10 as well. http://people.freebsd.org/~jhb/patches/isp_callout.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 19:56:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 619CD4F5 for ; Wed, 24 Sep 2014 19:56:30 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38B1F28C for ; Wed, 24 Sep 2014 19:56:30 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F128B921; Wed, 24 Sep 2014 15:56:29 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Poor state of the build infrastructure. Date: Wed, 24 Sep 2014 15:54:54 -0400 Message-ID: <1643827.epFl9jnZN1@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 24 Sep 2014 15:56:29 -0400 (EDT) Cc: Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 19:56:30 -0000 On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: > What is going on here? > Are we still in some kind of flux and people aren't done yet or is > this the intended state by virtue of noone having anything left on > there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? I think if you haven't done a make buildworld/toolchain, then when you do make buildenv you will fall back to using the host tools: > make TARGET=sparc64 buildenv Entering world for sparc64:sparc64 $ echo $PATH /usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/sbin:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/usr/games:/usr/obj/sparc64.sparc64/usr/src/tmp/legacy/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/sbin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/bin:/usr/obj/sparc64.sparc64/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin $ which cc /usr/obj/sparc64.sparc64/usr/src/tmp/usr/bin/cc $ which cat /bin/cat -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 22:26:40 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DF5CA30; Wed, 24 Sep 2014 22:26:40 +0000 (UTC) Received: from m.saper.info (m.saper.info [IPv6:2a01:4f8:a0:7383::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "m.saper.info", Issuer "Marcin Cieslak 2011" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB82E672; Wed, 24 Sep 2014 22:26:39 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8OMQZj2000147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2014 22:26:36 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1411597596; bh=Wi54kjXeg/1jCFWXDCdRsataN4NFKWto3dSqd8AxElM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FjJyEHrlPZh8Wit1zs7G1G75CA+Ju3qK9QHw23j5Sp3NyiGMNaBcCjfXZU9dLX4pd 2y2v4ZxH27h3kRfgORzzHU5aDsncemWt1hJ0W7KUwtWqxJNbd3XfAiI5d2OQO+yBwv xUxAd1r+IaBIqNuj2rs19PdKa9HYwFFhQ4QCSfX8= Date: Wed, 24 Sep 2014 22:26:35 +0000 (UTC) From: Marcin Cieslak To: Benjamin Kaduk Subject: Re: Teach vidcontrol(1) and vt(4) to restore default font In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 22:26:40 -0000 On Sat, 13 Sep 2014, Benjamin Kaduk wrote: > On Sat, 13 Sep 2014, Marcin Cieslak wrote: > >> Hello, >> >> I tried loading gallant.fnt which I did not >> like and I was wondering how to come back to >> the nice default font. >> >> There does not seem to be the way to do this, >> so please find below a simple patch to add >> this functionality. >> >> It adds a new ioctl PIO_VDFFONT to the vt(4) >> driver. I hope I got the reference counting >> on the vt_font_default structure right. >> >> With this patch applied, "vidcontrol -f" restores >> the built-in font. > > Can you please submit this to our bug tracker so it doesn't get lost? > > https://bugs.freebsd.org/submit Sure, it lives under https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193910 now. //Marcin From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 23:33:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95DBE7AF; Wed, 24 Sep 2014 23:33:56 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C041C9D; Wed, 24 Sep 2014 23:33:55 +0000 (UTC) Received: from jaesungp-sslvpn-nc.jnpr.net ([66.129.239.11]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s8ONXp6Z036688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Sep 2014 16:33:53 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_835A7DAB-EEBE-41B7-A9FE-D711D66342E1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Poor state of the build infrastructure. From: Marcel Moolenaar In-Reply-To: <1643827.epFl9jnZN1@ralph.baldwin.cx> Date: Wed, 24 Sep 2014 16:33:46 -0700 Message-Id: References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> <1643827.epFl9jnZN1@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 23:33:56 -0000 --Apple-Mail=_835A7DAB-EEBE-41B7-A9FE-D711D66342E1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: >> What is going on here? >> Are we still in some kind of flux and people aren't done yet or is >> this the intended state by virtue of noone having anything left on >> there TODO list? > > Sorry to ask a dumb question, but are you sure you did the make buildworld > first? Shouldn't that have errored if it couldn't build crt1? The root cause problem was that MAKEOBJDIRPREFIX was not set to whatever it was set to during buildworld. That was easy enough to figure out when a bunch of things don't add up. But neither problem mentioned in the email had anything to do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE as part of an install is a bug. Entering a powerpc buildenv and having a compiler that builds for the host (or maybe just some default) is a regression. The only thing the FreeBSD build is good at, really, is building in /usr/src for the host. The rest is just not up to par and I think it harms FreeBSD beyond belief. -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_835A7DAB-EEBE-41B7-A9FE-D711D66342E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQjVNoACgkQpgWlLWHuifbU8QCfQHt6ZASZzczotxfNj6Hs+E7T vu8AmwU9e/ETjFK4+O4Bb0cKiaz4Pevn =2QJB -----END PGP SIGNATURE----- --Apple-Mail=_835A7DAB-EEBE-41B7-A9FE-D711D66342E1-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 23:47:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6B08A19; Wed, 24 Sep 2014 23:47:45 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E0E0D9A; Wed, 24 Sep 2014 23:47:45 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id x12so3894927qac.5 for ; Wed, 24 Sep 2014 16:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=UdfjkW8OutO/Fte21ClgcNF51zof/bVTmoM02yzQ6Mc=; b=HqpuqrVg4kcc/K4iC0He2i23dJlo/RNoqhRvYC4BnAq853Fbpl/mCuYiE4bRC4DQWK uvuEUE7WQCRI0S6QrgDHijWbnyAW+qyrL7wmQnG8jSGqiNHcn44wABhGIzCgrRW2sWbP xauf4A73Ulp3vmJ2jOs6k03Ogsetb5g07OnB427Tfwbt86jDxMQEsBzCMCLKvrjshl6b w7YdOEBzTIBzlWKxLiCMt2dvQyRhtXIZz8BafAuHRO3pXmKyjaSRfmPOSHIZh3AcPvWM yIMG/xslf6QgdogB/Xx6LxkpDACJCvj5cajam+ZX1US3GGaOPxStE18EVWE76xlTR+mQ FsJQ== X-Received: by 10.140.81.42 with SMTP id e39mr15163505qgd.60.1411602464713; Wed, 24 Sep 2014 16:47:44 -0700 (PDT) Received: from zhabar.attlocal.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id a3sm673153qaa.49.2014.09.24.16.47.42 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 16:47:43 -0700 (PDT) Date: Wed, 24 Sep 2014 16:47:31 -0700 From: Justin Hibbits To: Marcel Moolenaar Subject: Re: Poor state of the build infrastructure. Message-ID: <20140924164731.2c170ced@zhabar.attlocal.net> In-Reply-To: References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> <1643827.epFl9jnZN1@ralph.baldwin.cx> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/b7Jp_gUBr12UWY=ZDZK5=3="; protocol="application/pgp-signature" Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 24 Sep 2014 23:47:46 -0000 --Sig_/b7Jp_gUBr12UWY=ZDZK5=3= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 24 Sep 2014 16:33:46 -0700 Marcel Moolenaar wrote: >=20 > On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: >=20 > > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: > >> What is going on here? > >> Are we still in some kind of flux and people aren't done yet or is > >> this the intended state by virtue of noone having anything left on > >> there TODO list? > >=20 > > Sorry to ask a dumb question, but are you sure you did the make > > buildworld first? Shouldn't that have errored if it couldn't build > > crt1? >=20 > The root cause problem was that MAKEOBJDIRPREFIX was not set > to whatever it was set to during buildworld. That was easy > enough to figure out when a bunch of things don't add up. That's a very annoying problem, and even more annoying to track down. > But neither problem mentioned in the email had anything to > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE > as part of an install is a bug. Entering a powerpc buildenv > and having a compiler that builds for the host (or maybe > just some default) is a regression. When MAKEOBJDIRPREFIX isn't set, it takes whatever compiler it can find. It should probably error out instead, since the build environment isn't sane at this point. I ran into this probably a few weeks back. > The only thing the FreeBSD build is good at, really, is > building in /usr/src for the host. The rest is just not > up to par and I think it harms FreeBSD beyond belief. I have no problems building outside of /usr/src. - Justin --Sig_/b7Jp_gUBr12UWY=ZDZK5=3= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUI1gbAAoJEDDHhY43vi25yigIAJ+uvO30d5VA5zb4W0YWcJXT uT24hetiZN6h7dK9sLLMIr4jArf06sKHhK+Sy+uSGAijJWiYF4FzOWf+QAKy7kCL JhhJEBbfQM/ikDfUhJauIw432O9/3Fiv36zFYJDLvcGcLB+3OsfIM5/PQuxp+i6k tWPC23Ws+ogYwN3pdIhNTcB8GG6A8lGcQrzupdhmxMw0XuTLg/w6ZWCykD+XTkV9 xkJjusSqXUmyFqkCz5tb8ywbBXN8ak6gT1VjXx+LpmgJL9hVPzuyNMkVh/rM8D1b k3oPLJeMCC5JwiZZ4l4YRuVajPfSacdsSGFlTlvJTlNARHT48H7x2rvMBB5zBdM= =bGdM -----END PGP SIGNATURE----- --Sig_/b7Jp_gUBr12UWY=ZDZK5=3=-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 00:13:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16975D60; Thu, 25 Sep 2014 00:13:13 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98C28FF5; Thu, 25 Sep 2014 00:13:12 +0000 (UTC) Received: from jaesungp-sslvpn-nc.jnpr.net ([66.129.239.11]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s8P0D8Om036817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Sep 2014 17:13:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_135E2C64-62D2-432F-80DE-FA2E0FE7E1D7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Poor state of the build infrastructure. From: Marcel Moolenaar In-Reply-To: <20140924164731.2c170ced@zhabar.attlocal.net> Date: Wed, 24 Sep 2014 17:13:03 -0700 Message-Id: References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> <1643827.epFl9jnZN1@ralph.baldwin.cx> <20140924164731.2c170ced@zhabar.attlocal.net> To: Justin Hibbits X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 00:13:13 -0000 --Apple-Mail=_135E2C64-62D2-432F-80DE-FA2E0FE7E1D7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Sep 24, 2014, at 4:47 PM, Justin Hibbits wrote: > It should probably error out instead, since the build > environment isn't sane at this point. I ran into this probably a few > weeks back. > >> The only thing the FreeBSD build is good at, really, is >> building in /usr/src for the host. The rest is just not >> up to par and I think it harms FreeBSD beyond belief. > > I have no problems building outside of /usr/src. It's not a problem in the sense that it cannot be done, but just think about having to share a machine with a bunch of people and you don't own the machine. You quickly realize that without MAKEOBJDIRPREFIX or with files in /etc (like /etc/make.conf) that you can't tweak, you quick;y realize how error prone everything and how much time you end up wasting. -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_135E2C64-62D2-432F-80DE-FA2E0FE7E1D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQjXg8ACgkQpgWlLWHuifZbcACfe/rPr5pPCr0gNPyWYUo3jPog l2YAn0SvKLDBYOG/3zWTi4nU12t21PXT =vQhF -----END PGP SIGNATURE----- --Apple-Mail=_135E2C64-62D2-432F-80DE-FA2E0FE7E1D7-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 00:19:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ADB2EAE; Thu, 25 Sep 2014 00:19:31 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44A16A7; Thu, 25 Sep 2014 00:19:31 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id v10so8417534pde.6 for ; Wed, 24 Sep 2014 17:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7n1BqtG8fQwmq6QESAq6zqFwF0d/JkWVB1Od14emkhg=; b=VSrQbV/pohZrNrX5ZE+gwphZvLlmxYFAfskdnTPFh09VJqmSj92XoN+YxXKo9VjQq8 w9cRKxhNhRbz+340vZ0AV4wEkAWgiVlg+Ci5rPO/TkdTdPnCCa0g/xue7UbVTYjTjzrr O36Lovwgm1UwiL+vXlil+I0eOW0OzFjAtk9/8bkO3+1k99OhF0ckPaS9ja1hZRzzyNuu +ifDCFQuY/Je/HDSsLnoSK0DUwqcQ2HRG7PZxR2Ba3QatWvb033IvrlzWESqklYW5p0T XQPYmfL+jJAd5ZI0TcHXdVhNcdhmPqRK481I93NXuez6t9ci7KbD5phWVSuK5coS37cd HO8Q== X-Received: by 10.70.129.72 with SMTP id nu8mr18064376pdb.91.1411604370758; Wed, 24 Sep 2014 17:19:30 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id v16sm408252pdi.39.2014.09.24.17.19.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 17:19:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FDBFD575-A6B9-4282-8204-3E7E3BAF9E5C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Poor state of the build infrastructure. From: Garrett Cooper In-Reply-To: Date: Wed, 24 Sep 2014 17:19:27 -0700 Message-Id: <2AB53C65-8CBF-4076-B0E5-B69E7D31ED2D@gmail.com> References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> <1643827.epFl9jnZN1@ralph.baldwin.cx> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 00:19:31 -0000 --Apple-Mail=_FDBFD575-A6B9-4282-8204-3E7E3BAF9E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014, at 16:33, Marcel Moolenaar wrote: >=20 > On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: >=20 >> On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: >>> What is going on here? >>> Are we still in some kind of flux and people aren't done yet or is >>> this the intended state by virtue of noone having anything left on >>> there TODO list? >>=20 >> Sorry to ask a dumb question, but are you sure you did the make = buildworld=20 >> first? Shouldn't that have errored if it couldn't build crt1? >=20 > The root cause problem was that MAKEOBJDIRPREFIX was not set > to whatever it was set to during buildworld. That was easy > enough to figure out when a bunch of things don't add up. >=20 > But neither problem mentioned in the email had anything to > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE > as part of an install is a bug. Entering a powerpc buildenv > and having a compiler that builds for the host (or maybe > just some default) is a regression. >=20 > The only thing the FreeBSD build is good at, really, is > building in /usr/src for the host. The rest is just not > up to par and I think it harms FreeBSD beyond belief. I agree with Marcel. COMPILER_TYPE showed up before 10.0-CURRENT = dealing with the gcc->clang cutover and caused some minor issues when = integrating with some FreeBSD makefiles unless using the top-level make = rules. It would be nice if it defaulted to something sane now that the = build knobs work has been moved out to src.opts.mk . Thanks! -Garrett --Apple-Mail=_FDBFD575-A6B9-4282-8204-3E7E3BAF9E5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUI1+PAAoJEMZr5QU6S73eg5oH/1OYoLHnSJhZk/I1F1whFMp5 keF657BIZ0iicCDyTnkFsUs9HeWiDMEjSA2XZzszS1PG6UoghyFzLuVHF1SAIdrR d9W5poppSHitm4OSYNyu+pew/+BECz4MRKfeEMMPlpx8Sb58vqPmgeMBRwlpS66Q JcqkZTaOTNlBNEjmHE46W4cqg+EsDslLHXJ+clWUVfqXWlOco/JL729R+Ch2Sx2v bU4CayskaOy42TWxSwEr56+ixbodwJI9R9NOrlQIYmznI6+0MfbGQWi9C215WOG0 QalQGW0reryC826a+IOPubr/TLP0UJ0uO2oKt9rl5zUt1Hl4dgo5iXqjBe+08Js= =tsdz -----END PGP SIGNATURE----- --Apple-Mail=_FDBFD575-A6B9-4282-8204-3E7E3BAF9E5C-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 01:24:51 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4020769D for ; Thu, 25 Sep 2014 01:24:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 208FF8E8 for ; Thu, 25 Sep 2014 01:24:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8P1OpIb003577 for ; Thu, 25 Sep 2014 01:24:51 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8P1Oo20003576 for current@FreeBSD.org; Thu, 25 Sep 2014 01:24:50 GMT (envelope-from bdrewery) Received: (qmail 43933 invoked from network); 24 Sep 2014 20:24:49 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 24 Sep 2014 20:24:49 -0500 Message-ID: <54236ED9.5040005@FreeBSD.org> Date: Wed, 24 Sep 2014 20:24:41 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: current@FreeBSD.org Subject: memguard(9) panics in proc_reap with vm.memguard.options=3 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sSU653x32KFDOGHvIcDsswV0KF29w8wmD" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 01:24:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sSU653x32KFDOGHvIcDsswV0KF29w8wmD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > #11 0xffffffff80976e12 in vmem_xfree (vm=3D0xffffffff816d2200, addr=3D1= 8446741889258000384, size=3D0) at /usr/src/sys/kern/subr_vmem.c:1237 > #12 0xffffffff80bafbe0 in memguard_free (ptr=3D) a= t /usr/src/sys/vm/memguard.c:421 > #13 0xffffffff80904191 in free (addr=3D0xfffffe03648a9000, mtp=3D) at /usr/src/sys/kern/kern_malloc.c:554 > #14 0xffffffff808e733f in proc_reap (td=3D, p=3D0x= fffff80bf043c000, status=3D, options=3D) at /usr/src/sys/kern/kern_exit.c:882 > #15 0xffffffff808e784a in proc_to_reap (td=3D0xfffff8021d499000, p=3D0x= fffff80bf043c000, idtype=3D, id=3D, status=3D0xfffffe35559bc914, options=3D55, The assert is "size > 0". I enabled vm.memguard.options=3D3 while the system was running. From reading is_memguard_addr() I assume it should be safe to do so. Only new allocations should be passed through memguard_free(). This panic seems to happen easily. This comment in sys/vm/memguard.c memguard_free() makes me think something is stale: > /* > * This requires carnal knowledge of the implementation of > * kmem_free(), but since we've already replaced kmem_malloc() > * above, it's not really any worse. We want to use the > * vm_map lock to serialize updates to memguard_wasted, since > * we had the lock at increment. > */ > kmem_unback(kmem_object, addr, size); > if (sizev > size) > addr -=3D PAGE_SIZE; > vmem_xfree(memguard_arena, addr, sizev); By the way, I can't get the kernel to even boot with vm.memguard.options=3D3. It panics very early in device probing IIRC. --=20 Regards, Bryan Drewery --sSU653x32KFDOGHvIcDsswV0KF29w8wmD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUI27ZAAoJEDXXcbtuRpfP02MH+wTIaIYWKq5ZgmDH4coZgJAQ oJLyskOl9Im97CHakXrE2whcrLvTtEtSr8bhWPVKmuSGZLTZsevgAt4d1UEhzJA/ 86WjHgNJmRJWQzdUidvpxlKJFCmmuwUgxBKMq0sa8TlNfrq2NcX1+zGXX4TZYaM7 7hQY91xUmQldYZ9UoJJ6T1mB/63/ZKAV+jqaw8mwhlyEsU7XZDcZ828k7/ipIZdx 42HzKYh8SsI3nWraTqMGvYLjV6sZu7AR+F90ftSnCn1l+GMFBFaSwr16JYnea4I2 HXE0KGx8KEXxSL27rJkqa3oenwqAhBlGRZ/C4FQwjvYVqbd7fIjA/qa3dqbxcUc= =an3J -----END PGP SIGNATURE----- --sSU653x32KFDOGHvIcDsswV0KF29w8wmD-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 06:20:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2908E5DF for ; Thu, 25 Sep 2014 06:20:05 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A185894 for ; Thu, 25 Sep 2014 06:20:05 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XX2PM-00024C-Bq for freebsd-current@freebsd.org; Wed, 24 Sep 2014 23:20:04 -0700 Date: Wed, 24 Sep 2014 23:20:04 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1411626004347-5951793.post@n5.nabble.com> In-Reply-To: <1408005331438-5938162.post@n5.nabble.com> References: <1408005331438-5938162.post@n5.nabble.com> Subject: Re: shmget (No space left on device) issue with firefox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 06:20:05 -0000 All 3 mozilla-based ports that I have installed (Firefox, Seamonkey, Thunderbird) crash immediately. * Does anyone else on 11 have this problem or is it just me? * I had been merging the linux-c6 ports into my tree for some time (now part of the official tree) - could this have any relation to the problem (due to flash-player)? This does not explain Thunderbird however. Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/shmget-No-space-left-on-device-issue-with-firefox-tp5938162p5951793.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 09:19:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1AB7386 for ; Thu, 25 Sep 2014 09:19:14 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B957CF2 for ; Thu, 25 Sep 2014 09:19:13 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s8P9JBY4039887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Sep 2014 13:19:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8P9JBFN039886; Thu, 25 Sep 2014 13:19:11 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 25 Sep 2014 13:19:11 +0400 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: Panic - uma_zfree_arg - zone argument is NULL Message-ID: <20140925091911.GZ884@FreeBSD.org> References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541ACA20.5030805@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 09:19:14 -0000 On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: H> #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, item=0xfffff800114ee000, H> udata=0xffffffff81484760) udata here is uma_slab_t. Can you look at it? btw, is that reproducible on stable/10 or head? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 15:15:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3D10F05; Thu, 25 Sep 2014 15:15:59 +0000 (UTC) Received: from sakura.ccs.furiru.org (sakura.ccs.furiru.org [IPv6:2001:2f0:104:8060::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E593C3A; Thu, 25 Sep 2014 15:15:59 +0000 (UTC) Received: from localhost (authenticated bits=0) by sakura.ccs.furiru.org (unknown) with ESMTP id s8PFFqeo011017; Fri, 26 Sep 2014 00:15:55 +0900 (JST) (envelope-from nyan@FreeBSD.org) Date: Fri, 26 Sep 2014 00:15:51 +0900 (JST) Message-Id: <20140926.001551.953617267291100361.nyan@FreeBSD.org> To: jhb@freebsd.org Subject: Re: [PATCHES] Convert various pc98 drivers from timeout() to callout() From: TAKAHASHI Yoshihiro In-Reply-To: <2960329.SjaRrui0Bt@ralph.baldwin.cx> References: <2960329.SjaRrui0Bt@ralph.baldwin.cx> X-Mailer: Mew version 6.3 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 15:15:59 -0000 In article <2960329.SjaRrui0Bt@ralph.baldwin.cx> John Baldwin writes: > I have three patches to convert various pc98 drivers from timeout() to > callout(). For the fdc driver I took a more drastic approach and have > attempted to port the PC98 support into the main fdc driver: Great! Unfortunately, I don't have enough time to review and test your patches so please feel free to commit them. When I have time, I'll check. Thanks for your work. --- TAKAHASHI Yoshihiro From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 16:05:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE4953EE for ; Thu, 25 Sep 2014 16:05:00 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E873269 for ; Thu, 25 Sep 2014 16:04:59 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8PFmIK9059105 for ; Thu, 25 Sep 2014 15:48:18 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: freebsd-current@freebsd.org Subject: AHCI after 271145 does not work for me Date: Thu, 25 Sep 2014 17:48:13 +0200 Message-Id: <20140925153725.M29130@beckpeccoz.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 16:05:01 -0000 Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 16:13:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0188A348; Thu, 25 Sep 2014 16:13:01 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BB3B9A6; Thu, 25 Sep 2014 16:13:01 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id fb4so8656106wid.5 for ; Thu, 25 Sep 2014 09:12: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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vZrC8KaMpaUrQhTlCzr8doybW8OZPe+MHMkIkrdgq6k=; b=yBwsDMS5WusVouYavNAolQkFQ+ssILVr/r+/yT82u0lOOj5RPV5eKiQgT0W9YQ6soo SsTE4Qvu0Hfmzrms1NJgBjNFqq8jTL9B607IB1mF73p7Czgra6figyE4351fk2KELbcj X/sRIaK4VZAN74VzWeG9ZqNbfAEjH1z+8OE9qVkjs3j5/hImIlk4J6LHCKBK4ZTa0lVc vJ96fhmb4vMg7uUSpHL6LaUnVOLLu7t2R6QXReXpSJZ2ww7WZL7CmtowP88RJiF0Fi76 zQTckUm+rJR2NarOKC6jJTU7qLvPYTocgJMbndE6l7InkzAyOA7GLrAMkC+eGfmrOnAm gGgg== MIME-Version: 1.0 X-Received: by 10.194.157.230 with SMTP id wp6mr17145791wjb.15.1411661579597; Thu, 25 Sep 2014 09:12:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 25 Sep 2014 09:12:59 -0700 (PDT) In-Reply-To: <20140925153725.M29130@beckpeccoz.com> References: <20140925153725.M29130@beckpeccoz.com> Date: Thu, 25 Sep 2014 09:12:59 -0700 X-Google-Sender-Auth: xZtT94fMucRP5fq15QRjKK8-_P8 Message-ID: Subject: Re: AHCI after 271145 does not work for me From: Adrian Chadd To: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= , Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 16:13:02 -0000 Hi! 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas.= :) Warner? -a On 25 September 2014 08:48, Jos=C3=A9 P=C3=A9rez Arauzo wrot= e: > Hi, > on my Acer Aspire V5, AHCI does not complete device_attach after 271145. > > Am I the only one experiencing this? Can I help fixing it? Thank you. > > BR, > > -- > Jos=C3=A9 P=C3=A9rez Arauzo > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 16:27:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 394375D3 for ; Thu, 25 Sep 2014 16:27:09 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 050D5AF7 for ; Thu, 25 Sep 2014 16:27:08 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s8PGQuPr039445; Thu, 25 Sep 2014 09:26:56 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s8PGQux8039444; Thu, 25 Sep 2014 09:26:56 -0700 (PDT) (envelope-from david) Date: Thu, 25 Sep 2014 09:26:56 -0700 From: David Wolfskill To: =?iso-8859-1?Q?Jos=E9_P=E9rez?= Arauzo Subject: Re: AHCI after 271145 does not work for me Message-ID: <20140925162656.GT1221@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , =?iso-8859-1?Q?Jos=E9_P=E9rez?= Arauzo , freebsd-current@freebsd.org References: <20140925153725.M29130@beckpeccoz.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x3ENEa1yd42KAyDQ" Content-Disposition: inline In-Reply-To: <20140925153725.M29130@beckpeccoz.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 16:27:09 -0000 --x3ENEa1yd42KAyDQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 25, 2014 at 05:48:13PM +0200, Jos=E9 P=E9rez Arauzo wrote: > Hi, > on my Acer Aspire V5, AHCI does not complete device_attach after 271145. >=20 > Am I the only one experiencing this? Can I help fixing it? Thank you. > ... Well, I am not experiencing such a problem on my Dell M4400; you can see nearly a year's worth of (mostly daily) "uname -vp" entries for head at . Today's "uname -a" is: FreeBSD g1-235.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1378 r272= 099M/272101:1100036: Thu Sep 25 06:30:23 PDT 2014 root@g1-235.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 As for 271145, I bracketed that one in early September: FreeBSD 11.0-CURRENT #1360 r271089M/271091:1100030: Thu Sep 4 06:31:23 PD= T 2014 root@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i3= 86 FreeBSD 11.0-CURRENT #1361 r271156M/271156:1100030: Fri Sep 5 07:47:32 PD= T 2014 root@localhost:/common/S4/obj/usr/src/sys/CANARY i386 (Second one was recorded while I was on the train during my commute to work.) As for debugging, a start will be to collect the AHCI controller information for "pciconf -lv", as well as dmesg information -- e.g.: ahci0@pci0:0:31:2: class=3D0x010601 card=3D0x02501028 chip=3D0x29298086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'ICH9M/M-E SATA AHCI Controller' class =3D mass storage subclass =3D SATA 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 ahciem0: on ahci0 But you'll undoubtedly get better information from folks who are more familiar with the hardware and the code than I am. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --x3ENEa1yd42KAyDQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUJEJOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7qr8QAKAbOZGJ4TEjY/mlo241VjyK HPDoizMKqR9LUmpO6NtVuZnuEoaN5FNS9pLYudUQjkPz+pLsHvA3GavrtIxddxSk x9tWcX3yKwoRne/6MCIJf/8uQ+yDziUjpXVTM7DrroecSsImLvnIx5gwGYr/yQSL FUNLPLlnXyhkAhz5mmL6vMb3hk+0Px68A+f7Dm4OmJiNsYwKM1QmF4ZKCKtOJ8xy AIs6cJa2FYcuYZtxLL/jaULDG+fpqUJ+ybaN5cr2vzNMupoTCxXw7fTx5HoB1h1h E0homRqDtlVZukxKwQP3zmurKqJGFSf1Q7m3yRX3uXc7oP6IQQkWbKy66c9j4rrN c/6LQIFGsO6E7cBEpFk414SQxiK1wXoKhFFblTG5WASO3aYRezBcGv+lIS+fTTYG 8oSM7fmCwJXnPAeLs9cCT52MHvJTaFOTxrRkZhc1HxCh7KGW2YPTf7LgFgRK/OPa Ru8I6xGnnqLux1uT++a5xQybVBiteoTEgpgMO3hdDI30e8u3ST2umlZFLYmxXH52 5Ig7c6sg+lCJPBThycJPUmB5TvRpMODzzw6JBy/fXeCRN1HKIxBsNYw43gudknTB FF2jK9rueODdYYeXnrlclj08jFEhzuucIcmFImKfsLgysc/H28NGLIxTHa9wUh66 9Xla9DSm7AZF2YpNTleJ =d1bY -----END PGP SIGNATURE----- --x3ENEa1yd42KAyDQ-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 16:57:28 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76671EAA; Thu, 25 Sep 2014 16:57:28 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F22FFE3E; Thu, 25 Sep 2014 16:57:27 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8PGvOqR005802; Thu, 25 Sep 2014 18:57:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 5C97A34D1; Thu, 25 Sep 2014 18:57:24 +0200 (CEST) Message-ID: <54244973.8040907@omnilan.de> Date: Thu, 25 Sep 2014 18:57:23 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: installworld broken - osreldate.h: permission denied References: <20130928130920.GA1318@devbox.vnode.local> <1380388791.1197.335.camel@revolution.hippie.lan> In-Reply-To: <1380388791.1197.335.camel@revolution.hippie.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig78AD1C38E19CE8E311537F2C" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 25 Sep 2014 18:57:24 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: current@freebsd.org, Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 16:57:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig78AD1C38E19CE8E311537F2C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Ian Lepore's Nachricht vom 28.09.2013 19:19 (localtime): > On Sat, 2013-09-28 at 15:09 +0200, Joel Dahl wrote: >> Hi, >> >> Fresh HEAD. installworld from read-only /usr/obj and /usr/src: >> >> /usr/src/include/iconv.h osreldate.h /usr/include >> install: osreldate.h: Permission denied >> *** Error code 71 >> >> Stop. >> make[4]: stopped in /usr/src/include >> *** Error code 1 >> >> Everything was working fine 2 weeks ago, so it's a recent breakage. >> > Okay, I just accidentally created conditions for this error on my > system... I checked in a change to newvers.sh while a buildworld was > running, which led to a situation where newvers.sh was newer than > osreldate.h at the end of the buildworld. Then an installworld tried t= o > regenerate osreldate.h due to its dependency on newvers.sh, which would= > fail if the obj was readonly at that point. > > I think we could see if something similar applies for you if you use > this command: > > make -dm installworld SUBDIR_OVERRIDE=3Dinclude > > And we'd be looking for the end of the output to be something like: > > Examining _libiconv_compat.h... > modified 10:51:18 Sep 28, 2013...up-to-date > Make_Update: _libiconv_compat.h > inspect parent buildincludes: flags 0, type 18001, made 0, unmade 95 - = not needed > inspect parent _INCSINS: flags 9, type b000001, made 1, unmade 1 - unma= de children > Examining osreldate.h... > modified 10:39:21 Sep 28, 2013...modified before source /local/build/st= aging/freebsd/head/src/include/../sys/conf/newvers.sh...out-of-date > env ECHO=3D"echo" MAKE=3D"/local/build/staging/freebsd/head/obj/local/= build/staging/freebsd/head/src/make.i386/bmake" NEWVERS_SH=3D/local/buil= d/staging/freebsd/head/src/include/../sys/conf/newvers.sh PARAM_H=3D/loc= al/build/staging/freebsd/head/src/include/../sys/sys/param.h SYSDIR=3D/l= ocal/build/staging/freebsd/head/src/include/../sys sh /local/build/stagi= ng/freebsd/head/src/include/mk-osreldate.sh > env: not found > *** [osreldate.h] Error code 127 > > The "env: not found" is what I got instead of a permission denied, and > probably has something to do with me cross-building amd64 10.0 from an > i386 8.x machine. I think that's where you'd see the permission error.= > > If the same sort of thing is happening for you, then all that's left is= > to figure out why osreldate.h is out of date at install time, and how t= o > handle things if that's the case. Thanks for your suggestion how to best find out what's going on. I have the same problem you observed (env: not found), not the permission problem the thread opener had. For any reason, not relevant at this point, my ${src}/sys/conf/newvers.sh is newer than 'include/osreldate.h' under $OBJDIRPREFIX/i386.i386/=85. Now in 'include/Makefile', "sh ${MK_OSRELDATE_SH}" should be called by 'env' in target 'osreldate.h vers.c:'. Problem is, that PATH has sevaral bin-sbin directories under "$OBJDIRPREFIX/=85/tmp/" _and_ "$INSTALLTMP", and none of them provides '= env'. The latter is filled with target 'distributeworld installworld:' in Makefile.inc1, with $ITOOLS. The following additional tools are missing in ITOOLS to make recreating osreldate.h work at installworld stage: env, hostname, mktemp and touch So a patch to work arround that issue looks like this: --- src/Makefile.inc1.orig 2014-09-25 17:36:16.000000000 +0200 +++ src/Makefile.inc1 2014-09-25 17:47:14.000000000 +0200 @@ -697,9 +697,9 @@ =2Eendif ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown \ - date echo egrep find grep id install ${_install-info} \ - ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \ - rm sed sh sysctl test true uname wc ${_zoneinfo} + date echo egrep env find grep hostname id install ${_install-info} \ + ln lockf make mkdir mktemp mtree ${_nmtree_itools} mv pwd_mkdb \ + rm sed sh sysctl test touch true uname wc ${_zoneinfo} # # distributeworld I have no idea if there's a better way, but if these tools are not to be added, the check for outdated osreldate.h should be disabled because recreation at install stage is not possible without. At least this is true for compiling 9.3-i386 on 10-stable-amd64. -Harry --------------enig78AD1C38E19CE8E311537F2C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQkSXMACgkQLDqVQ9VXb8grkgCfW100EBv7TJLxsa4ac3UYhJe2 MnEAn2E0EVb9LuO+uCkfUJfgJdGA0SBS =IPPy -----END PGP SIGNATURE----- --------------enig78AD1C38E19CE8E311537F2C-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 19:55:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D79D7A2 for ; Thu, 25 Sep 2014 19:55:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 748067FB for ; Thu, 25 Sep 2014 19:55:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ECA5AB97C; Thu, 25 Sep 2014 15:55:15 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Subject: Re: Poor state of the build infrastructure. Date: Thu, 25 Sep 2014 14:50:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> <1643827.epFl9jnZN1@ralph.baldwin.cx> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201409251450.18627.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 25 Sep 2014 15:55:16 -0400 (EDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 19:55:17 -0000 On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote: > > On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: > > > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: > >> What is going on here? > >> Are we still in some kind of flux and people aren't done yet or is > >> this the intended state by virtue of noone having anything left on > >> there TODO list? > > > > Sorry to ask a dumb question, but are you sure you did the make buildworld > > first? Shouldn't that have errored if it couldn't build crt1? > > The root cause problem was that MAKEOBJDIRPREFIX was not set > to whatever it was set to during buildworld. That was easy > enough to figure out when a bunch of things don't add up. Ok. > But neither problem mentioned in the email had anything to > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE > as part of an install is a bug. Entering a powerpc buildenv > and having a compiler that builds for the host (or maybe > just some default) is a regression. Agreed on COMPILER_TYPE, but I think the path thing has always been true in make buildenv because we don't build cross-tools for things like 'cp'. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 19:55:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581937A4; Thu, 25 Sep 2014 19:55:18 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F71E7FC; Thu, 25 Sep 2014 19:55:18 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 29445B939; Thu, 25 Sep 2014 15:55:17 -0400 (EDT) From: John Baldwin To: TAKAHASHI Yoshihiro Subject: Re: [PATCHES] Convert various pc98 drivers from timeout() to callout() Date: Thu, 25 Sep 2014 14:51:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <2960329.SjaRrui0Bt@ralph.baldwin.cx> <20140926.001551.953617267291100361.nyan@FreeBSD.org> In-Reply-To: <20140926.001551.953617267291100361.nyan@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201409251451.37168.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 25 Sep 2014 15:55:17 -0400 (EDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 19:55:18 -0000 On Thursday, September 25, 2014 11:15:51 am TAKAHASHI Yoshihiro wrote: > In article <2960329.SjaRrui0Bt@ralph.baldwin.cx> > John Baldwin writes: > > > I have three patches to convert various pc98 drivers from timeout() to > > callout(). For the fdc driver I took a more drastic approach and have > > attempted to port the PC98 support into the main fdc driver: > > Great! > > Unfortunately, I don't have enough time to review and test your > patches so please feel free to commit them. When I have time, I'll > check. > > Thanks for your work. Ok. I'm mostly nervous about the fdc(4) patch, but I will move forward. Thanks! -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 20:10:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48EC6E97; Thu, 25 Sep 2014 20:10:00 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3BD951; Thu, 25 Sep 2014 20:09:59 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XXFMU-0002I7-0n; Thu, 25 Sep 2014 20:09:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8PK9uWC003830; Thu, 25 Sep 2014 14:09:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Jzgl9TdkOrO6rAUQOzNGX X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Poor state of the build infrastructure. From: Ian Lepore To: John Baldwin In-Reply-To: <201409251450.18627.jhb@freebsd.org> References: <4496BEA3-9F6C-4F09-B8F6-68D97A331A60@xcllnt.net> <1643827.epFl9jnZN1@ralph.baldwin.cx> <201409251450.18627.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Sep 2014 14:09:56 -0600 Message-ID: <1411675796.66615.252.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marcel Moolenaar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 20:10:00 -0000 On Thu, 2014-09-25 at 14:50 -0400, John Baldwin wrote: > On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote: > > > > On Sep 24, 2014, at 12:54 PM, John Baldwin wrote: > > > > > On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: > > >> What is going on here? > > >> Are we still in some kind of flux and people aren't done yet or is > > >> this the intended state by virtue of noone having anything left on > > >> there TODO list? > > > > > > Sorry to ask a dumb question, but are you sure you did the make buildworld > > > first? Shouldn't that have errored if it couldn't build crt1? > > > > The root cause problem was that MAKEOBJDIRPREFIX was not set > > to whatever it was set to during buildworld. That was easy > > enough to figure out when a bunch of things don't add up. > > Ok. > > > But neither problem mentioned in the email had anything to > > do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE > > as part of an install is a bug. Entering a powerpc buildenv > > and having a compiler that builds for the host (or maybe > > just some default) is a regression. > > Agreed on COMPILER_TYPE, but I think the path thing has always been true in > make buildenv because we don't build cross-tools for things like 'cp'. > Just to be clear, all the problems in the original mail, including failure to detect COMPILER_TYPE automatically and building the wrong type of binaries, were fallout from the original problem of not setting MAKEOBJDIRPREFIX correctly. It turns out if you use the build system correctly, it works! (Unfortunately, using it correctly requires knowing about a whole lotta knobs to be set these days if your needs are not vanilla.) -- Ian From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 21:00:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33D06655 for ; Thu, 25 Sep 2014 21:00:18 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE6D4ED0 for ; Thu, 25 Sep 2014 21:00:17 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8PKxla9066699; Thu, 25 Sep 2014 20:59:47 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: David Wolfskill Subject: Re: AHCI after 271145 does not work for me Date: Thu, 25 Sep 2014 22:59:42 +0200 Message-Id: <20140925205042.M30895@aoek.com> In-Reply-To: <20140925162656.GT1221@albert.catwhisker.org> References: <20140925153725.M29130@beckpeccoz.com> <20140925162656.GT1221@albert.catwhisker.org> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 21:00:18 -0000 On Thu, 25 Sep 2014 09:26:56 -0700, David Wolfskill wrote > On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote: > > Hi, > > on my Acer Aspire V5, AHCI does not complete device_attach after 271145. > > > > Am I the only one experiencing this? Can I help fixing it? Thank you. [...] > As for debugging, a start will be to collect the AHCI controller > information for "pciconf -lv", as well as dmesg information -- e.g.: Thank you David, here are pciconf and dmesg: ahci0@pci0:0:17:0: class=0x01018f card=0x080d1025 chip=0x78001022 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson SATA Controller [IDE mode]' class = mass storage subclass = ATA > dmesg | fgrep -i ahci ahci0: port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ahci0: port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ahci0: port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 For the sake of completeness: there's a BIOS option to either set the hw to present itself as legacy ISA or AHCI, but the kernel hangs in any case. BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 21:50:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94AF67C7 for ; Thu, 25 Sep 2014 21:50:21 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 616CA6BE for ; Thu, 25 Sep 2014 21:50:21 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id x19so13964044ier.8 for ; Thu, 25 Sep 2014 14:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ls1QDXMziSycZACRKX13iCppCRFo56iCRaiDcZn+aW0=; b=XVK8IJUs4lGYBDaOYWX/n1eZsVbzy3/NIp9g1rg2bIkRhTY2nHCeWWuP54qspOp77O hXZvB328Z63IjBw0ygS7wBoeKYnbtjdX1t/i3RbguK4sFXwFOfelH1tjWAEksAt/5BiS knitP7h/hb1ubDqeXDVs3yzpMy+MsDUkzJ3k+2axfZBMPIFjRauSjuYduNSyTrZKP2ww 9RsVipZEaSGXAg3/Py0S85oulvpC+LWM094MVipcfNi+sKe3J1s629W3U0JL95eO+pkR kvaLWudarulSNhW/ABdCYGWhht7bZgAi5CPnhLGwos2r0WHfEFnIxMeJzLryS8jkOcUI SjSw== X-Received: by 10.50.138.194 with SMTP id qs2mr8466004igb.4.1411681820754; Thu, 25 Sep 2014 14:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.32.143 with HTTP; Thu, 25 Sep 2014 14:50:00 -0700 (PDT) In-Reply-To: <531457FF.3080005@citrix.com> References: <531457FF.3080005@citrix.com> From: Yuriy Taraday Date: Fri, 26 Sep 2014 01:50:00 +0400 Message-ID: Subject: Re: IXP700 AHCI fails to initialize To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 25 Sep 2014 21:50:21 -0000 On Mon, Mar 3, 2014 at 2:22 PM, Roger Pau Monn=C3=A9 wrote: > On 01/03/14 19:00, Yuriy Taraday wrote: > > Hello. > > > > I currently have FreeBSD 8.3 on my home server and it works fine but it= 's > > time to upgrade at last (new ath and new ipfw especially allure me). I'= ve > > decided to go straight to 10.0 and reinstall system from scratch to pur= ge > > all legacy unrelated configs and other stuff. > > > > The problem I faced is as follows. I have a (rather old) motherboard wi= th > > integrated SATA controller that presents in the OS as IXP700. In 8.3 it > > works fine. I have 2 disks attached to it: one with all my data and > another > > one destined to be new system disk. I also have one IDE disk installed > that > > is currently used as system disk. > > > > When I booted from USB stick with 10.0, I couldn't see any SATA disks i= n > > the system. I dug into dmesg and found this: > http://pastebin.com/wv2A0MUE > > As it seems AHCI controller or disks are not responding to commands and > > timeouts eventually. > > > > A friend suggested to try CURRENT image. I went > > with FreeBSD-11.0-CURRENT-amd64-VT-20140222-r262336-mini-memstick.img a= nd > > got almost the same error: http://pastebin.com/0iGaSWUD > > The error repeats and never stops (looks like CURRENT images have > different > > config) but it is essentially the same. > > > > I've googled the problem but found only notes about how IXP700 is reall= y > > bad and pointers that cabling might be the problem. But I have absolute= ly > > no problems with 8.3, so it looks like some regression during further > > development (shift to CAM, maybe?). > > > > Please help me to identify and fix the problem. > > This is just a shot in the dark, I'm not familiar with the AHCI driver, > but since you seem to be loosing interrupts (or I would say so based on > the timeout messages), you could try to disable MSI/MSI-X and fallback > to PCI intline IRQs. Could you try to boot with > hw.pci.enable_msix=3D0,hw.pci.enable_msi=3D0? > A flood of RC news in my feed forced me to get back to upgrading my homeserver. I've tried out 10.1-BETA2 image and got the same results. Then I've tried to provide these options you suggested, and although there were some hickup (HDDs didn't respond well at first, I guess), I got to bsdinstall prompt. Thank you very much for suggestion! Now I wonder what would be the impact of having these options disabled permanently. Will there be a huge slowdown of all PCI cards? Or should it be negligible? --=20 Kind regards, Yuriy. From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 00:20:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEDDC18C for ; Fri, 26 Sep 2014 00:20:24 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACE7379D for ; Fri, 26 Sep 2014 00:20:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8Q0KOxk067912 for ; Fri, 26 Sep 2014 00:20:24 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8Q0KOJC067911 for freebsd-current@freebsd.org; Fri, 26 Sep 2014 00:20:24 GMT (envelope-from bdrewery) Received: (qmail 15125 invoked from network); 25 Sep 2014 19:20:23 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 25 Sep 2014 19:20:23 -0500 Message-ID: <5424B13D.6010104@FreeBSD.org> Date: Thu, 25 Sep 2014 19:20:13 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Cam panic on r271170 References: <5418F1B9.2000903@FreeBSD.org> <5419AB24.9050809@FreeBSD.org> In-Reply-To: <5419AB24.9050809@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ia4nqqhiVQ2gtppHTjh5bGp1iXVMNlAAX" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 00:20:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ia4nqqhiVQ2gtppHTjh5bGp1iXVMNlAAX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/17/2014 10:39 AM, Bryan Drewery wrote: > On 9/16/2014 9:28 PM, Bryan Drewery wrote: >> I've been getting this quite frequently on head recently. I have dumps= >> if anyone is interested in more information. >> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid =3D 10; Memory modified after free 0xfffff8003e0b0800(2040) >>> val=3Dffffffff @ 0xfffff8003e0b0808 >>> apanic: Most recently used by CAM CCB >>> >>> cpuid =3D 6 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe124735b4c0 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124735b570 >>> vpanic() at vpanic+0x189/frame 0xfffffe124735b5f0 >>> panic() at panic+0x43/frame 0xfffffe124735b650 >>> mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfffffe124735b680 >>> uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfffffe124735b6f0 >>> malloc() at malloc+0x192/frame 0xfffffe124735b740 >>> xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfffffe124735b780 >>> adastrategy() at adastrategy+0x117/frame 0xfffffe124735b7b0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b810 >>> g_part_start() at g_part_start+0x2b7/frame 0xfffffe124735b890 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b8f0 >>> g_io_request() at g_io_request+0x3b7/frame 0xfffffe124735b950 >>> vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfffffe124735= b970 >>> zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfffffe124735b9= d0 >>> zio_execute() at zio_execute+0x204/frame 0xfffffe124735ba30 >>> vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfffffe124735= ba80 >>> zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfffffe124735bac0= >>> zio_execute() at zio_execute+0x204/frame 0xfffffe124735bb20 >>> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >>> 0xfffffe124735bb80 >>> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >>> 0xfffffe124735bbb0 >>> fork_exit() at fork_exit+0x84/frame 0xfffffe124735bbf0 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe124735bbf0 >>> --- trap 0, rip =3D 0, rsp =3D 0xfffffe124735bcb0, rbp =3D 0 --- >>> KDB: enter: panic >>> [ thread pid 0 tid 100571 ] >>> Stopped at kdb_enter+0x3e: movq $0,kdb_why >> >> Not sure about this one. We've been getting it at work as well based on a stable/10ish tree. >=20 > I also had this one recently: >=20 >> #8 0xffffffff80d1a162 in calltrap () at /usr/src/sys/amd64/amd64/exce= ption.S:231 >> #9 0xffffffff802e52c4 in xpt_path_periph (path=3D0xdeadc0dedeadc0de) = at /usr/src/sys/cam/cam_xpt.c:3738 >> #10 0xffffffff802dfe62 in cam_periph_error (ccb=3D0xfffff8003e0b6000, = camflags=3DCAM_FLAG_NONE, sense_flags=3D0, save_ccb=3D0x0) at /usr/src/sy= s/cam/cam_periph.c:1602 >> #11 0xffffffff803057e4 in adadone (periph=3D0xfffff8003e09b700, done_c= cb=3D0xfffff8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 >> #12 0xffffffff802e6e44 in xpt_done_process (ccb_h=3D0xfffff8003e0b6000= ) at /usr/src/sys/cam/cam_xpt.c:5245 >> #13 0xffffffff80394d59 in ahci_ch_intr_direct (arg=3D) at /usr/src/sys/dev/ahci/ahci.c:1132 >> #14 0xffffffff80390ff1 in ahci_intr (data=3D) at = /usr/src/sys/dev/ahci/ahci.c:417 >> #15 0xffffffff808ea5d3 in intr_event_execute_handlers (p=3D, ie=3D0xfffff8000f725d00) at /usr/src/sys/kern/kern_intr.c:125= 2 >> #16 0xffffffff808eafb6 in ithread_loop (arg=3D0xfffff8000f6dea60) at /= usr/src/sys/kern/kern_intr.c:1265 >> #17 0xffffffff808e7fc4 in fork_exit (callout=3D0xffffffff808eaf10 , arg=3D0xfffff8000f6dea60, frame=3D0xfffffe1245083c00) at /usr= /src/sys/kern/kern_fork.c:977 >> #18 0xffffffff80d1a69e in fork_trampoline () at /usr/src/sys/amd64/amd= 64/exception.S:605 >=20 This one however (and all subsequent traces I posted) was resolved by r271201. --=20 Regards, Bryan Drewery --ia4nqqhiVQ2gtppHTjh5bGp1iXVMNlAAX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUJLE9AAoJEDXXcbtuRpfP3qsIAKJ1qW2IHGQ79AWeC9hZa5qN 2lt7DT4BQqzB9XtC+VkXdRlesVv3BriU8P3N3TlpbzLU8Z/T6A49peNSItItdO1e zDBAYO7/JaZDqbTpB8zIzm+jTc200FKMXTqyE1kqDB6ONRph59aIGF0/DH4yb/IU n0NFC8n0W8Ad7FnbCx71LZWi0430EWqK5bB/ENuprbjDs8FklaFleWIg01QXys3y aDDnRkLaTdZxfCgKLoLy4/ceCJgDzeUkq62ah5HZbAN/hjpiQNrKlZ4iDfkoPDf3 hOHloGnHvyjGF/ameafUs9kaEhqXdgMEPcFPpRhIktXc6Dh79cfva01WJvOVpGY= =NSh+ -----END PGP SIGNATURE----- --ia4nqqhiVQ2gtppHTjh5bGp1iXVMNlAAX-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 00:55:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5E69602 for ; Fri, 26 Sep 2014 00:55:18 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DED5AD1 for ; Fri, 26 Sep 2014 00:55:18 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id bj1so1336699pad.15 for ; Thu, 25 Sep 2014 17:55:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LknPI9F1/NXjaw28TsliGmyfF1E76MexChsNHYF7eAs=; b=GLuksArroFxdSYWXdcF3F10niAfvaRr7v+krRYoh7YLas9SuQlFiDAK+0GeDFQ2t1X x64LRY5SirsmDOJW1SoB4PCXskBcsdIZhrp4RU7zdn15gD+8A4ArwTkJ16k6mmSChDXw tnUoqfuvlER7x85hcZWz7z+UWGiaYg159rVFdnsqmMkGX9FCwww/v/j7cgK3VjrT9EKM 2orJcJ4t49cK0GMX/ILJTzy8NdP10RCEjHQjh9HU6WNFurphhNcsVtKv4DDMw/FnU9OS XZgkQ4uksgzsORAnz46SpPis0geytKb0y/bK1432SEPHvSazV+sj+D7oDIx2Fj9gqKdP 5shA== X-Gm-Message-State: ALoCoQmW96zD3AYxKHwecV3SZ6gbnO4Rz7Kj0Gl2eaWWj2klKsVvPrkKWLMmE8LSg3LfgWsHjHI8 X-Received: by 10.68.220.105 with SMTP id pv9mr25431291pbc.8.1411692912021; Thu, 25 Sep 2014 17:55:12 -0700 (PDT) Received: from [172.20.12.175] ([12.145.98.24]) by mx.google.com with ESMTPSA id ad6sm3112250pac.30.2014.09.25.17.55.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 17:55:11 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_18096F33-637A-4C11-9282-EFC12E78C7C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: AHCI after 271145 does not work for me From: Warner Losh In-Reply-To: Date: Thu, 25 Sep 2014 17:55:09 -0700 Message-Id: References: <20140925153725.M29130@beckpeccoz.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: =?iso-8859-1?Q?Jos=E9_P=E9rez_Arauzo?= , freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 00:55:18 -0000 --Apple-Mail=_18096F33-637A-4C11-9282-EFC12E78C7C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m afraid I have no clue. I=92ll need hardware to debug this, since I = don=92t have any, or someone that can provide some feedback or even = probe messages with it going off the rails (before/after). Warner On Sep 25, 2014, at 9:12 AM, Adrian Chadd wrote: > Hi! >=20 > 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some = ideas. :) >=20 > Warner? >=20 >=20 > -a >=20 >=20 > On 25 September 2014 08:48, Jos=E9 P=E9rez Arauzo = wrote: >> Hi, >> on my Acer Aspire V5, AHCI does not complete device_attach after = 271145. >>=20 >> Am I the only one experiencing this? Can I help fixing it? Thank you. >>=20 >> BR, >>=20 >> -- >> Jos=E9 P=E9rez Arauzo >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" --Apple-Mail=_18096F33-637A-4C11-9282-EFC12E78C7C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJLltAAoJEGwc0Sh9sBEACgMP/Rgot3WsQfsTA5FpOwqgNG7P 3si/a79FFAN7bGyDXNkeIxWrI7hQcPJaiFlOQ0KK5sAer2FrA+lTvgOIkfoeDDKg NvjKhl5jqqHWmBWXmLjGDMLBoPs9qa+4/ahuqEbJZFgbDC0XT7jKHatJw7IWZzOf 2igziZbgRh1ZRHfBT4nSbKDtW+pbQ1ZN7A8IiCDNTlPzMT4s/UsdopHs6zVXAa37 kWuZMfGRp3iP+VbRF7tDj5JR64ksJuVmSGi0gOlgCsa+1PIXNj1TnyaC1ou2HFb5 XtcST7D8X+xnjjQVMJFQ9kfp4XURWnc+bitTNyL5dV5GCDi0d1h12YOcReCuPxJw UuA7Bwsv+oGLOIXrnBYrcBXAeSmOBl1MYhTzeA+y4/ZJHfC/sy6pVkFDRFwP8PUw 3BUInCJ1V/OnjpjHcO/ocxovZYVDCPsHnrGJtNCHW5T7oHAyZ/bSI7az+9g1ss/5 j/JS3m6uzwiNPKWLJwedish/zpIGKR7TSOIpdhIA5JEDZf6l9yHmJXYri1xiV/EE eJg4BEO/VytgZQ2zn+layYqRFfzKqR7ckIOzjEwf0KmlknXyKIwxATqbdDyKQZl5 vtFZrFGmVlDekbXIATk3Mr5bC+uTiwGxgudJwsHypy9Q081K10qEqPwmgbBM3RuQ Uf7NuwFz6Hnp1P5v89MQ =bfmM -----END PGP SIGNATURE----- --Apple-Mail=_18096F33-637A-4C11-9282-EFC12E78C7C4-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 00:59:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6940A8FF for ; Fri, 26 Sep 2014 00:59:58 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 35C46B51 for ; Fri, 26 Sep 2014 00:59:58 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id r10so11844550pdi.39 for ; Thu, 25 Sep 2014 17:59:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rDLvWIZs9/wiHlGxchwKC1oH0TR1w/qj087c6SJVCr8=; b=DrAUxpkTJrnKBJufhgWUL1n9fthLPvW8S9hoCVvh9pqld8S1Ii73nOrkePyim5HuCD n+bHapUyzZDsDCcjbNW/zWGUhW7ZgL367b1uHA0YT2JVuq0LPkuhhel4nZ86B9bG5qw0 Vnoh2OhSliBWbaERiPdYmaTxh6JmfmbEt4fm5lTuzrTN23z56WxYqYStuFhbyJRCdq2O U8weTDk9qluWoumd/+tKAh/EY0j+IJhJAjJmVlFNglTSXgG0JI0sbk8XBNapyuXgEYL7 pBM/CIZ27+yIMLuN5pMFF5utfOF/3qJoWsL4HyENB5Y/fjLbDuuGVJwtqh4OUuQNsgDT GHSA== X-Gm-Message-State: ALoCoQlBZUfLSDgprBxZomwOjL/Oi9OMsgoUUIBQBhfgIfHMXCIf7OePpnfC1+IhDLcoshxAasoF X-Received: by 10.69.20.33 with SMTP id gz1mr25501004pbd.84.1411693190913; Thu, 25 Sep 2014 17:59:50 -0700 (PDT) Received: from [172.20.12.175] ([69.63.206.125]) by mx.google.com with ESMTPSA id ny7sm3292174pab.38.2014.09.25.17.59.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 17:59:50 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_34A297B2-7F8D-4094-8070-6E878E03E8DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: AHCI after 271145 does not work for me From: Warner Losh In-Reply-To: Date: Thu, 25 Sep 2014 17:59:49 -0700 Message-Id: References: <20140925153725.M29130@beckpeccoz.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: =?iso-8859-1?Q?Jos=E9_P=E9rez_Arauzo?= , freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 00:59:58 -0000 --Apple-Mail=_34A297B2-7F8D-4094-8070-6E878E03E8DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Also r271201 fixes an issue with interrupts. Have you tried anything = newer? Warner On Sep 25, 2014, at 9:12 AM, Adrian Chadd wrote: > Hi! >=20 > 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some = ideas. :) >=20 > Warner? >=20 >=20 > -a >=20 >=20 > On 25 September 2014 08:48, Jos=E9 P=E9rez Arauzo = wrote: >> Hi, >> on my Acer Aspire V5, AHCI does not complete device_attach after = 271145. >>=20 >> Am I the only one experiencing this? Can I help fixing it? Thank you. >>=20 >> BR, >>=20 >> -- >> Jos=E9 P=E9rez Arauzo >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" --Apple-Mail=_34A297B2-7F8D-4094-8070-6E878E03E8DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJLqFAAoJEGwc0Sh9sBEAi2MP/RErE726IheKPa4GzaFsOyE7 YU4gr673l6L8MJfTtN1pCIfag5zAg6VlRlJLZiGa78fK1iF4xB6yJUFqrlChTfSd Yc3fMkAvvCTaoMckIsepfewqPELk94rzxgcHs8b5qspYeayZCs9xSkv1zB8nQycG ntc8+iszS8q8CUEGMR02FyuhHcwxyzDpz8QpyUi7bZmlWfAzmb4qsmOM6oWORfzd iIH51aBti4ERpfXa/JI9GsCLsFHsx3x52YaQkfQWTQ5Dx73d/ZnD24KYT5fPcAur 3eW7g8b5pm2ZlttOvM2NDh6PqX4B7/ARKk4S/2UkXLX/6XRAjLh9I2dw7mD8tPDL k4n7ci+WNamz6uz5joYDfR+GhUzj3W7hBBWbmdwA42o1HId7QE/VGLZj6kVY5VuK /wH2hG5hOlGdqxvjfLZvtrFn38IfEkJXCAO7zJZlSPWdFa6dT6pJWz8DVRQbTw9/ pPKjhjMckReXsxXZ70oPgtc6F/Xk8x5kF6JFHNicuaHeRbD8+IE+KezFnBqqGEh/ 1goY9oMkZUBiToYfBbUPvkQc7dsY/R1XQemM6E2dFtG3Z7Zj/kQzlAUTVFzJ4qon C6KNP4GKa9jHaOV7X2uaUe/NRpINcQ+qM7yTO51gJmq6bsowotJCZ6GytdEB9tSZ N1sYvxhSw/LfallXxySj =rfdE -----END PGP SIGNATURE----- --Apple-Mail=_34A297B2-7F8D-4094-8070-6E878E03E8DB-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 01:04:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D70B6E3F for ; Fri, 26 Sep 2014 01:04:32 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A46EDC76 for ; Fri, 26 Sep 2014 01:04:32 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id hz1so11829986pad.26 for ; Thu, 25 Sep 2014 18:04:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=01VHLu66S/BHBhsmYRXhda4Eu45gtm56sYlCn1T9VS0=; b=FQgeBNFQxqekjIuVb1VsKpu4iz8LH4dsMpXWqS4ZymZbd2zCksV5/lD+Rz0tNdItCq v1bvBPyi9Yct70OwfcSI/IHQsC9y+kIAPcPV10cdKNUQDRUefI5NusWQ1eOtrU4J0aOk I/v9Iq/UNP3lT/Yq6HYFkZecSqZDiJ/+KHlxzvoCUyc8ZBFvIJidvJGPtghn6BlCVWuN CH8K6+yo2BS1vTOtZ2hSs+uQAIpp1CfJkxVgN9m3vaZu9F3KuOqNFBP1TtiSPVNJcH4t WlIkiTxrkQXqxgjyq7JAa7wnciUcBlVFEddSJu37eRxwxOIMGqK6SxjUroWHK4Fyq74O iTIQ== X-Gm-Message-State: ALoCoQlUqDSOZQ7A+BoSfbhkgHjfedAHUbdynrX1Am6s2Wk2kPt+tgGnaTcO6A4wupWSPxY4VI44 X-Received: by 10.66.102.68 with SMTP id fm4mr24991592pab.46.1411692977263; Thu, 25 Sep 2014 17:56:17 -0700 (PDT) Received: from [172.20.12.175] ([12.145.98.24]) by mx.google.com with ESMTPSA id yt3sm3263359pbc.34.2014.09.25.17.56.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 17:56:16 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_3268408A-115E-4732-955D-3D516C342F91"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: AHCI after 271145 does not work for me From: Warner Losh In-Reply-To: <20140925205042.M30895@aoek.com> Date: Thu, 25 Sep 2014 17:56:14 -0700 Message-Id: <200F2AFD-ACEB-438F-8213-96F4805AA073@bsdimp.com> References: <20140925153725.M29130@beckpeccoz.com> <20140925162656.GT1221@albert.catwhisker.org> <20140925205042.M30895@aoek.com> To: =?iso-8859-1?Q?Jos=E9_P=E9rez_Arauzo?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 01:04:32 -0000 --Apple-Mail=_3268408A-115E-4732-955D-3D516C342F91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 25, 2014, at 1:59 PM, Jos=E9 P=E9rez Arauzo wrote: > On Thu, 25 Sep 2014 09:26:56 -0700, David Wolfskill wrote >> On Thu, Sep 25, 2014 at 05:48:13PM +0200, Jos=E9 P=E9rez Arauzo = wrote: >>> Hi, >>> on my Acer Aspire V5, AHCI does not complete device_attach after = 271145. >>>=20 >>> Am I the only one experiencing this? Can I help fixing it? Thank = you. > [...] >> As for debugging, a start will be to collect the AHCI controller >> information for "pciconf -lv", as well as dmesg information -- e.g.: >=20 > Thank you David, here are pciconf and dmesg: >=20 > ahci0@pci0:0:17:0: class=3D0x01018f card=3D0x080d1025 = chip=3D0x78001022 > rev=3D0x40 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D 'Hudson SATA Controller [IDE mode]' > class =3D mass storage > subclass =3D ATA >=20 >> dmesg | fgrep -i ahci > ahci0: port > 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f = mem > 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with = FBS > ahcich0: at channel 0 on ahci0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ahci0: port > 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f = mem > 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with = FBS > ahcich0: at channel 0 on ahci0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ahci0: port > 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f = mem > 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with = FBS > ahcich0: at channel 0 on ahci0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >=20 >=20 > For the sake of completeness: there's a BIOS option to either set the = hw to > present itself as legacy ISA or AHCI, but the kernel hangs in any = case. Do you have before messages too? Warner --Apple-Mail=_3268408A-115E-4732-955D-3D516C342F91 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJLmvAAoJEGwc0Sh9sBEAc/MP/1PXWk9/eNpB58zC5eNaBiDo 5e7S7mxXDqNHQk7l24ZaD7GUlgF3F50n2THcmjxzd3tsoivj3qG9ZSUTGh1EeI9v RSq4WtbFG+GQD695Fkerpgrm88Q3Bh4jICIQQgWwNstS/0Vqz6p0sucTpNLESP2B BiiCT+AySLMB8OWfZzrhtYWtjft61Wo2ZYRaFPvp8xg9r7CSQEUkdTiiuVSLRBO4 ATvEF8Ql51uCBQF3ln8Wjp95W4+2VuShvWiaNI4PI4IHsLWzgiIT2AEZbpJR/+ba /Or9CByRMZ+CKdQM+FxJUJJyKgqxFTcDSMrB9S8rgDJS2OM3mLGvpFSP9GzhsYqg Dq3ofmd5ha3D4J0JgR0Ul+EcO7lZJ+IwogvXJAP1na3nIgQH6EonhYCctgZ+r2R9 aaoDZoG1ziIWBGLX+NtW87sd/vWNq9iMPvsvmVrOl6imvXdyF8fOiQfMFm58ok4C 3doQPcHT1bCpdKZcmnGrRlcUDuPCZ8F/3OG5ULAkAjNeOSj70UJgJM5pBDlGRALW 6L10avKLHgeP2s2sShiOvnwbCCa22J9o+uNHHj+xbSu3Fv9EqOPyjjdoMORnVq9d Cja3Zl9ohVap5mS5J5H/PQiibPvCbm4FshZ6stObFzjgBXnuAS0xdxDGl861PsQZ Xcwmwb+XnDFlAkTfRJHn =xK5P -----END PGP SIGNATURE----- --Apple-Mail=_3268408A-115E-4732-955D-3D516C342F91-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 03:41:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAE9D27D; Fri, 26 Sep 2014 03:41:00 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8853BF50; Fri, 26 Sep 2014 03:41:00 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id c9so6159459qcz.1 for ; Thu, 25 Sep 2014 20:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type; bh=c+mHIlKO+fCjdIvgFJgO5wfac7BK08uWkNWf3HmKEdQ=; b=Eg1SPc6jD6H1xUbhiMVNzAMQHilyxw+sljOXKDkgRfXKtpkLHu8EqMjU+4I90UgjXk w/P5rZ2MMffB0BpQh18k0eOcsjuNBgHUPLsE9F1FxtpJq5Xc91iDDPUZvcj2CC0k8hs3 voma3tfVke2RoeVrvmlzgtDd4F9DTy8D+a8EsByXg+/F5wX3zLqszDjnK7vVe4iSVhfs 1tg9T60fviLVxniI+GEjhqFs8jVEzgUd8JuvdhH0HjKhZJg7X89ZZ3p6U20lNIIgj2v9 DwDSHB7X31WvwIfA2Br1ZapivcSo5wuZ/h3tIYoEpvXus8rt5DGJqA/VBOYaF/duyo6h w5kw== X-Received: by 10.224.32.138 with SMTP id c10mr11780687qad.1.1411702858643; Thu, 25 Sep 2014 20:40:58 -0700 (PDT) Received: from zhabar.attlocal.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id l46sm3745705qgd.27.2014.09.25.20.40.57 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 20:40:57 -0700 (PDT) Date: Thu, 25 Sep 2014 20:40:52 -0700 From: Justin Hibbits To: FreeBSD Current , FreeBSD PowerPC ML Subject: Boot failure with r272146 Message-ID: <20140925204052.6f4c1d60@zhabar.attlocal.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/eteFzjDwiVP0p.yFwS3DpcI" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 03:41:01 -0000 --MP_/eteFzjDwiVP0p.yFwS3DpcI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline With r272146 my SATA controller fails to attach, preventing the kernel from mounting root. I've attached a log of as much as dconschat would allow. The relevant portion is pcib10: atapci0: mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0xffffffff,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 pcib10: allocated memory range (0xfa400000-0xfa400fff) for rid 10 of pci1:3:14:0 atapci0: mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0xffffffff,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 ata0: mem 0xfa404000-0xfa407fff at device 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 ata0: unable to allocate interrupt device_attach: ata0 attach returned 6 It works fine with r271697 kernel (latest I have booting). I haven't yet tried bisecting. Hardware is a PowerMac G5 (last generation). - Justin --MP_/eteFzjDwiVP0p.yFwS3DpcI Content-Type: application/octet-stream; name=kernel_boot.fail Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=kernel_boot.fail W2Rjb25zIGNvbm5lY3RlZF0NCmUgMzIsIGJhc2UgMHhmYTIwMDAwMCwgc2l6ZSAyMSwgbWVtb3J5 IGRpc2FibGVkDQpwY2liODogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmYTIwMDAwMC0weGZh M2ZmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTE6MjoxNTowDQpnZW0wOiA8QXBwbGUgU2hhc3RhIEdN QUMgRXRoZXJuZXQ+IG1lbSAweGZhMjAwMDAwLTB4ZmEzZmZmZmYgYXQgZGV2aWNlIDE1LjAgb24g cGNpOA0KcGNpYjg6IHNsb3QgMTUgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDQNCm9md19wY2kgbWFw ZGV2OiBzdGFydCBmYTIwMDAwMCwgbGVuIDIwOTcxNTINCmdlbTA6IGludmFsaWQgTUFDIGFkZHJl c3MNCmRldmljZV9hdHRhY2g6IGdlbTAgYXR0YWNoIHJldHVybmVkIDYNCnBjaWI5OiA8T0ZXIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgOC4wIG9uIHBjaTENCnBjaWI5OiAgIGRvbWFpbiAgICAg ICAgICAgIDENCnBjaWI5OiAgIHNlY29uZGFyeSBidXMgICAgIDENCnBjaWI5OiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDENCnBjaWI5OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ODAwMDAwMDAtMHg4MDBm ZmZmZg0KcGNpOTogPE9GVyBQQ0kgYnVzPiBvbiBwY2liOQ0KcGNpOTogZG9tYWluPTEsIHBoeXNp Y2FsIGJ1cz0xDQpmb3VuZC0+CXZlbmRvcj0weDEwNmIsIGRldj0weDAwNGYsIHJldmlkPTB4MDAN Cglkb21haW49MSwgYnVzPTEsIHNsb3Q9NywgZnVuYz0wDQoJY2xhc3M9ZmYtMDAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjAwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDEwICg0ODAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQ0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwg YmFzZSAweDgwMDAwMDAwLCBzaXplIDE5LCBlbmFibGVkDQpwY2liOTogYWxsb2NhdGVkIG1lbW9y eSByYW5nZSAoMHg4MDAwMDAwMC0weDgwMDdmZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTE6MTo3OjAN CmZvdW5kLT4JdmVuZG9yPTB4MTAzMywgZGV2PTB4MDAzNSwgcmV2aWQ9MHg0Mw0KCWRvbWFpbj0x LCBidXM9MSwgc2xvdD0xMSwgZnVuYz0wDQoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MQ0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MTYgKGR3 b3JkcykNCglsYXR0aW1lcj0weDEwICg0ODAgbnMpLCBtaW5nbnQ9MHgwMSAoMjUwIG5zKSwgbWF4 bGF0PTB4MmEgKDEwNTAwIG5zKQ0KCWludHBpbj1hLCBpcnE9MA0KCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5n ZSAzMiwgYmFzZSAweDgwMDgyMDAwLCBzaXplIDEyLCBtZW1vcnkgZGlzYWJsZWQNCnBjaWI5OiBh bGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweDgwMDgyMDAwLTB4ODAwODJmZmYpIGZvciByaWQgMTAg b2YgcGNpMToxOjExOjANCmZvdW5kLT4JdmVuZG9yPTB4MTAzMywgZGV2PTB4MDAzNSwgcmV2aWQ9 MHg0Mw0KCWRvbWFpbj0xLCBidXM9MSwgc2xvdD0xMSwgZnVuYz0xDQoJY2xhc3M9MGMtMDMtMTAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMjEwLCBj YWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDEwICg0ODAgbnMpLCBtaW5nbnQ9MHgw MSAoMjUwIG5zKSwgbWF4bGF0PTB4MmEgKDEwNTAwIG5zKQ0KCWludHBpbj1iLCBpcnE9MA0KCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KCW1hcFsxMF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweDgwMDgxMDAwLCBzaXplIDEyLCBtZW1vcnkgZGlz YWJsZWQNCnBjaWI5OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweDgwMDgxMDAwLTB4ODAwODFm ZmYpIGZvciByaWQgMTAgb2YgcGNpMToxOjExOjENCmZvdW5kLT4JdmVuZG9yPTB4MTAzMywgZGV2 PTB4MDBlMCwgcmV2aWQ9MHgwNA0KCWRvbWFpbj0xLCBidXM9MSwgc2xvdD0xMSwgZnVuYz0yDQoJ Y2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDQsIHN0 YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDEwICg0ODAg bnMpLCBtaW5nbnQ9MHgxMCAoNDAwMCBucyksIG1heGxhdD0weDIyICg4NTAwIG5zKQ0KCWludHBp bj1jLCBpcnE9MA0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBE MA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweDgwMDgwMDAwLCBzaXpl ICA4LCBtZW1vcnkgZGlzYWJsZWQNCnBjaWI5OiBhbGxvY2F0ZWQgbWVtb3J5IHJhbmdlICgweDgw MDgwMDAwLTB4ODAwODAwZmYpIGZvciByaWQgMTAgb2YgcGNpMToxOjExOjINCm1hY2lvMDogPFNo YXN0YSBJL08gQ29udHJvbGxlcj4gbWVtIDB4ODAwMDAwMDAtMHg4MDA3ZmZmZiBhdCBkZXZpY2Ug Ny4wIG9uIHBjaTkNCm9md19wY2kgbWFwZGV2OiBzdGFydCA4MDAwMDAwMCwgbGVuIDUyNDI4OA0K bWFjZ3BpbzA6IDxNYWNJTyBHUElPIENvbnRyb2xsZXI+IG1lbSAweDUwLTB4OGEgb24gbWFjaW8w DQptYWNncGlvMDogPGdwaW8sIHNtdS1pbnRlcnJ1cHQ+IGdwaW8gMTMgaXJxIDQ4IChubyBkcml2 ZXIgYXR0YWNoZWQpDQptYWNncGlvMDogPGdwaW8sIHByb2dyYW1tZXItc3dpdGNoPiBncGlvIDEy IGlycSA0NyAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KbWFjZ3BpbzA6IDxncGlvLCBjaGlwLWZhdWx0 PiBncGlvIDE0IGlycSA0OSAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KbWFjZ3BpbzA6IDxncGlvLCBz bGV3aW5nLWRvbmU+IGdwaW8gNTYgaXJxIDkxIChubyBkcml2ZXIgYXR0YWNoZWQpDQptYWNncGlv MDogPGdwaW8sIG1sYi1nb29kPiBncGlvIDE5IChubyBkcml2ZXIgYXR0YWNoZWQpDQptYWNncGlv MDogPGdwaW8sIHZkbmFwMD4gZ3BpbyAyMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KbWFjZ3BpbzA6 IDxncGlvLCB0aW1lYmFzZS1lbmFibGU+IGdwaW8gMzggaXJxIDczIChubyBkcml2ZXIgYXR0YWNo ZWQpDQptYWNncGlvMDogPGdwaW8sIGRpZy1ody1yZXNldC1jPiBncGlvIDkgKG5vIGRyaXZlciBh dHRhY2hlZCkNCm1hY2dwaW8wOiA8Z3BpbywgY29kZWMtZXJyb3ItaXJxPiBncGlvIDUwIGlycSA4 NSAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KbWFjZ3BpbzA6IDxncGlvLCBjb2RlYy1jbG9jay1tdXg+ IGdwaW8gNDkgKG5vIGRyaXZlciBhdHRhY2hlZCkNCm1hY2dwaW8wOiA8Z3BpbywgbGluZWluLWRl dGVjdD4gZ3BpbyA0MiBpcnEgNzcgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnNjYzA6IDxaaWxvZyBa ODUzMCBkdWFsIGNoYW5uZWwgU0NDPiBtZW0gMHgxMzAwMC0weDEzZmZmLDB4ODQwMC0weDg0ZmYs MHg4NTAwLTB4ODVmZiwweDg2MDAtMHg4NmZmLDB4ODcwMC0weDg3ZmYgaXJxIDIzLDE3LDE4LDI0 LDE5LDIwIG9uIG1hY2lvMA0Kc2NjMDogcmVzZXR0aW5nIGhhcmR3YXJlDQp1YXJ0MDogPHo4NTMw LCBjaGFubmVsIEE+IG9uIHNjYzANCnVhcnQwOiBmYXN0IGludGVycnVwdA0KdWFydDE6IDx6ODUz MCwgY2hhbm5lbCBCPiBvbiBzY2MwDQp1YXJ0MTogZmFzdCBpbnRlcnJ1cHQNCnNjYzA6IGZhc3Qg aW50ZXJydXB0DQppaWNoYjE6IDxLZXl3ZXN0IEkyQyBjb250cm9sbGVyPiBtZW0gMHgxODAwMC0w eDE4ZmZmIGlycSAyNyBvbiBtYWNpbzANCmlpY2hiMTogUmV2aXNpb246IEExDQppaWNidXMxOiA8 T0ZXIEkyQyBidXM+IG9uIGlpY2hiMQ0Kb255eDA6IDxUZXhhcyBJbnN0cnVtZW50cyBQQ00zMDUy IEF1ZGlvIENvZGVjPiBhdCBhZGRyIDB4OGMgb24gaWljYnVzMQ0KaWljYnVzMTogPHVua25vd24g Y2FyZD4gYXQgYWRkciAweDI0DQpwY20wOiA8QXBwbGUgSTJTIEF1ZGlvIENvbnRyb2xsZXI+IG1l bSAweDEwMDAwLTB4MTBmZmYsMHg4MDAwLTB4ODBmZiwweDgxMDAtMHg4MWZmIGlycSAyOCwxMSwx MiwzMCwxNSwxNiBvbiBtYWNpbzANCm9oY2kwOiA8TkVDIHVQRCA5MjEwIFVTQiBjb250cm9sbGVy PiBtZW0gMHg4MDA4MjAwMC0weDgwMDgyZmZmIGlycSA3MCBhdCBkZXZpY2UgMTEuMCBvbiBwY2k5 DQpvZndfcGNpIG1hcGRldjogc3RhcnQgODAwODIwMDAsIGxlbiA0MDk2DQp1c2J1czAgb24gb2hj aTANCm9oY2kwOiB1c2JwZjogQXR0YWNoZWQNCm9oY2kxOiA8TkVDIHVQRCA5MjEwIFVTQiBjb250 cm9sbGVyPiBtZW0gMHg4MDA4MTAwMC0weDgwMDgxZmZmIGlycSA3MCBhdCBkZXZpY2UgMTEuMSBv biBwY2k5DQpvZndfcGNpIG1hcGRldjogc3RhcnQgODAwODEwMDAsIGxlbiA0MDk2DQp1c2J1czEg b24gb2hjaTENCm9oY2kxOiB1c2JwZjogQXR0YWNoZWQNCmVoY2kwOiA8TkVDIHVQRCA3MjAxMDAg VVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHg4MDA4MDAwMC0weDgwMDgwMGZmIGlycSA3MCBhdCBk ZXZpY2UgMTEuMiBvbiBwY2k5DQpvZndfcGNpIG1hcGRldjogc3RhcnQgODAwODAwMDAsIGxlbiAy NTYNCnVzYnVzMjogRUhDSSB2ZXJzaW9uIDEuMA0KdXNidXMyIG9uIGVoY2kwDQplaGNpMDogdXNi cGY6IEF0dGFjaGVkDQpwY2liMTA6IDxPRlcgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA5LjAg b24gcGNpMQ0KcGNpYjEwOiAgIGRvbWFpbiAgICAgICAgICAgIDENCnBjaWIxMDogICBzZWNvbmRh cnkgYnVzICAgICAzDQpwY2liMTA6ICAgc3Vib3JkaW5hdGUgYnVzICAgMw0KcGNpYjEwOiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4ZmE0MDAwMDAtMHhmYTRmZmZmZg0KcGNpMTA6IDxPRlcgUENJIGJ1 cz4gb24gcGNpYjEwDQpwY2kxMDogZG9tYWluPTEsIHBoeXNpY2FsIGJ1cz0zDQpmb3VuZC0+CXZl bmRvcj0weDExNjYsIGRldj0weDAyNDAsIHJldmlkPTB4MDANCglkb21haW49MSwgYnVzPTMsIHNs b3Q9MTIsIGZ1bmM9MA0KCWNsYXNzPTAxLTAxLThmLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCglj bWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDIyMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0 aW1lcj0weDEwICg0ODAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQ0KCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDAsIHNpemUgIDMsIHBv cnQgZGlzYWJsZWQNCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAwLCBz aXplICAyLCBwb3J0IGRpc2FibGVkDQoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMCwgc2l6ZSAgMywgcG9ydCBkaXNhYmxlZA0KCW1hcFsxY106IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDAsIHNpemUgIDIsIHBvcnQgZGlzYWJsZWQNCgltYXBbMjBdOiB0eXBl IEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAwLCBzaXplICA0LCBwb3J0IGRpc2FibGVkDQoJbWFw WzI0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmE0MDIwMDAsIHNpemUgMTMsIGVu YWJsZWQNCnBjaWIxMDogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAoMHhmYTQwMjAwMC0weGZhNDAz ZmZmKSBmb3IgcmlkIDI0IG9mIHBjaTE6MzoxMjowDQpmb3VuZC0+CXZlbmRvcj0weDEwNmIsIGRl dj0weDAwNTAsIHJldmlkPTB4MDANCglkb21haW49MSwgYnVzPTMsIHNsb3Q9MTMsIGZ1bmM9MA0K CWNsYXNzPWZmLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA0LCBz dGF0cmVnPTB4ODIwMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHgyMCAoOTYw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCgltYXBbMTBdOiB0 eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmYTQwNDAwMCwgc2l6ZSAxNCwgbWVtb3J5IGRp c2FibGVkDQpwY2liMTA6IGFsbG9jYXRlZCBtZW1vcnkgcmFuZ2UgKDB4ZmE0MDQwMDAtMHhmYTQw N2ZmZikgZm9yIHJpZCAxMCBvZiBwY2kxOjM6MTM6MA0KZm91bmQtPgl2ZW5kb3I9MHgxMDZiLCBk ZXY9MHgwMDUyLCByZXZpZD0weDAwDQoJZG9tYWluPTEsIGJ1cz0zLCBzbG90PTE0LCBmdW5jPTAN CgljbGFzcz0wYy0wMC0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwMCwg c3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4ZjggKDc0 NDAgbnMpLCBtaW5nbnQ9MHgwYyAoMzAwMCBucyksIG1heGxhdD0weDE4ICg2MDAwIG5zKQ0KCWlu dHBpbj1hLCBpcnE9MA0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVu dCBEMA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZhNDAwMDAwLCBz aXplIDEyLCBtZW1vcnkgZGlzYWJsZWQNCnBjaWIxMDogYWxsb2NhdGVkIG1lbW9yeSByYW5nZSAo MHhmYTQwMDAwMC0weGZhNDAwZmZmKSBmb3IgcmlkIDEwIG9mIHBjaTE6MzoxNDowDQphdGFwY2kw OiA8U2VydmVyV29ya3MgSzIgU0FUQTE1MCBjb250cm9sbGVyPiBtZW0gMHhmYTQwMjAwMC0weGZh NDAzZmZmIGF0IGRldmljZSAxMi4wIG9uIHBjaTEwDQpwY2liMTogZmFpbGVkIHRvIHJlc2VydmUg cmVzb3VyY2UgZm9yIHBjaWIxMA0KcGNpYjEwOiBmYWlsZWQgdG8gYWxsb2NhdGUgaW5pdGlhbCBJ L08gcG9ydCB3aW5kb3cgKDAtMHhmZmZmZmZmZiwweDEwKQ0KYXRhcGNpMDogMHgxMCBieXRlcyBv ZiByaWQgMHgyMCByZXMgNCBmYWlsZWQgKDAsIDB4ZmZmZmZmZmZmZmZmZmZmZikuDQphdGFwY2kw OiB1bmFibGUgdG8gbWFwIGludGVycnVwdA0KZGV2aWNlX2F0dGFjaDogYXRhcGNpMCBhdHRhY2gg cmV0dXJuZWQgNg0KYXRhMDogPFNoYXN0YSBLYXVhaSBBVEEgQ29udHJvbGxlcj4gbWVtIDB4ZmE0 MDQwMDAtMHhmYTQwN2ZmZiBhdCBkZXZpY2UgMTMuMCBvbiBwY2kxMA0Kb2Z3X3BjaSBtYXBkZXY6 IHN0YXJ0IGZhNDA0MDAwLCBsZW4gMTYzODQNCmF0YTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBpbnRl cnJ1cHQNCmRldmljZV9hdHRhY2g6IGF0YTAgYXR0YWNoIHJldHVybmVkIDYNCmZ3b2hjaTA6IHZl bmRvcj0xMDZiLCBkZXY9NTINCmZ3b2hjaTA6IHZlbmRvcj0xMDZiLCBkZXY9NTINCmZ3b2hjaTA6 IDwxMzk0IE9wZW4gSG9zdCBDb250cm9sbGVyIEludGVyZmFjZT4gbWVtIDB4ZmE0MDAwMDAtMHhm YTQwMGZmZiBpcnEgMzkgYXQgZGV2aWNlIDE0LjAgb24gcGNpMTANCm9md19wY2kgbWFwZGV2OiBz dGFydCBmYTQwMDAwMCwgbGVuIDQwOTYNCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjAgKFJPTT0w KQ0KZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDguDQpmd29oY2kwOiBF VUk2NCAwMDoxNDo1MTpmZjpmZTozMzpjYTpiNg0KZndvaGNpMDogaW52YWxpZCBzcGVlZCA3IChm aXhlZCB0byAzKS4NCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzgwMCwgMyBwb3J0cy4N CmZ3b2hjaTA6IExpbmsgUzgwMCwgbWF4X3JlYyA0MDk2IGJ5dGVzLg0KZmlyZXdpcmUwOiA8SUVF RTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMA0KZGNvbnNfY3JvbTA6IDxkY29ucyBjb25m aWd1cmF0aW9uIFJPTT4gb24gZmlyZXdpcmUwDQpkY29uc19jcm9tMDogYnVzX2FkZHIgMHgxNzI0 MDAwDQpmd2UwOiA8RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwDQppZl9md2Uw OiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAyOjE0OjUxOjMzOmNhOmI2DQpmd2UwOiBicGYgYXR0 YWNoZWQNCmZ3ZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAyOjE0OjUxOjMzOmNhOmI2DQpzYnAwOiA8 U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTANCmZ3b2hjaTA6IEluaXRpYXRl IGJ1cyByZXNldA0KZndvaGNpMDogZndvaGNpX2ludHJfY29yZTogQlVTIHJlc2V0DQpmd29oY2kw OiBmd29oY2lfaW50cl9jb3JlOiBub2RlX2lkPTB4MDAwMDAwMDAsIFNlbGZJRCBDb3VudD0xLCBu b24gQ1lDTEVNQVNURVIgbW9kZQ0Kc211MDogPEFwcGxlIFN5c3RlbSBNYW5hZ2VtZW50IFVuaXQ+ IG9uIG9md2J1czANCnNtdTA6IEZhbjogRFJJVkUgQkFZIEEgSU5UQUtFIHR5cGU6IDANCnNtdTA6 IEZhbjogQkFDS1NJREUgdHlwZTogMA0Kc211MDogRmFuOiBDUFUgQSBJTlRBS0UgdHlwZTogMA0K c211MDogRmFuOiBDUFUgQiBJTlRBS0UgdHlwZTogMA0Kc211MDogRmFuOiBDUFUgQSBFWEhBVVNU IHR5cGU6IDANCnNtdTA6IEZhbjogQ1BVIEIgRVhIQVVTVCB0eXBlOiAwDQpzbXUwOiBGYW46IEVY UEFOU0lPTiBTTE9UUyBJTlRBS0UgdHlwZTogMA0Kc211MDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUt b2YtZGF5IGNsb2NrIChyZXNvbHV0aW9uIDEwMDB1cywgYWRqdXN0bWVudCAwLjAwMDUwMDAwMHMp DQppaWNoYjI6IDxTTVUgSTJDIGNvbnRyb2xsZXI+IG9uIHNtdTANCmlpY2J1czI6IDxPRlcgSTJD IGJ1cz4gb24gaWljaGIyDQpzbXVzYXQwOiA8U01VIFNhdGVsbGl0ZSBTZW5zb3JzPiBhdCBhZGRy IDB4YjAgb24gaWljYnVzMg0KaWljYnVzMjogPHVua25vd24gY2FyZD4gYXQgYWRkciAweGQ0DQpp aWNoYjM6IDxTTVUgSTJDIGNvbnRyb2xsZXI+IG9uIHNtdTANCmlpY2J1czM6IDxPRlcgSTJDIGJ1 cz4gb24gaWljaGIzDQpwcm9jZnMgcmVnaXN0ZXJlZA0KVGltZWNvdW50ZXIgInRpbWViYXNlIiBm cmVxdWVuY3kgMzMzMzMzMzMgSHogcXVhbGl0eSAwDQpFdmVudCB0aW1lciAiZGVjcmVtZW50ZXIi IGZyZXF1ZW5jeSAzMzMzMzMzMyBIeiBxdWFsaXR5IDEwMDANClRpbWVjb3VudGVycyB0aWNrIGV2 ZXJ5IDEuMDAwIG1zZWMNCnZsYW46IGZpcmV3aXJlMDogMyBub2RlcywgbWF4aG9wIDw9IDIgY2Fi bGUgSVJNIGlybSgyKSANCmluaXRpYWxpemVkLCB1c2luZyBoYXNoIHRhYmxlcyB3aXRoIGNoYWlu aW5nDQp0Y3BfaW5pdDogbmV0LmluZXQudGNwLnRjYmhhc2hzaXplIGF1dG8gdHVuZWQgdG8gMTMx MDcyDQpsbzA6IGJwZiBhdHRhY2hlZA0KbWF4NjY5MDA6IDIgc2Vuc29ycyBkZXRlY3RlZC4NCm1h eDY2OTAwOiBTZW5zb3JzDQptYXg2NjkwMDogTG9jYXRpb24gOiBCQUNLU0lERSBJRDogNg0KbWF4 NjY5MDA6IExvY2F0aW9uIDogS09ESUFLIERJT0RFIElEOiA3DQptYXg2NjkwMTogMiBzZW5zb3Jz IGRldGVjdGVkLg0KbWF4NjY5MDE6IFNlbnNvcnMNCm1heDY2OTAxOiBMb2NhdGlvbiA6IFRVTk5F TCBJRDogMQ0KbWF4NjY5MDE6IExvY2F0aW9uIDogVFVOTkVMIEhFQVRTSU5LIElEOiAyDQpiZ2Ux OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKW2Rjb25zY2hhdCBleGl0aW5nLi4uXQo= --MP_/eteFzjDwiVP0p.yFwS3DpcI-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 05:51:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F053E6DE; Fri, 26 Sep 2014 05:51:42 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2B38D9D; Fri, 26 Sep 2014 05:51:42 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4515D1FE022; Fri, 26 Sep 2014 07:51:40 +0200 (CEST) Message-ID: <5424FEE4.3050504@selasky.org> Date: Fri, 26 Sep 2014 07:51:32 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Panic - uma_zfree_arg - zone argument is NULL References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> <20140925091911.GZ884@FreeBSD.org> In-Reply-To: <20140925091911.GZ884@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 05:51:43 -0000 On 09/25/14 11:19, Gleb Smirnoff wrote: > On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: > H> #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, item=0xfffff800114ee000, > H> udata=0xffffffff81484760) > > udata here is uma_slab_t. Can you look at it? > > btw, is that reproducible on stable/10 or head? > Yes, it is reproducible. I have not tried stable/10 or head yet. (kgdb) print *(uma_slab_t)udata $3 = { us_keg = 0xfffff8085696d680, us_type = { _us_link = { le_next = 0xfffff80856970a80, le_prev = 0x3 }, _us_size = 18446735313429006976 }, us_hlink = { sle_next = 0x0 }, us_data = 0xffffffff81484778 "", us_free = { __bits = {0, 0, -2125969520, 0} }, us_freecount = 0, us_flags = 0 '\0', us_pad = 0 '\0' } --HPS From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 05:59:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A04093B; Fri, 26 Sep 2014 05:59:19 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1393DF2; Fri, 26 Sep 2014 05:59:18 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 130041FE022; Fri, 26 Sep 2014 07:59:17 +0200 (CEST) Message-ID: <542500AD.2020708@selasky.org> Date: Fri, 26 Sep 2014 07:59:09 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Panic - uma_zfree_arg - zone argument is NULL References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> <20140925091911.GZ884@FreeBSD.org> <5424FEE4.3050504@selasky.org> In-Reply-To: <5424FEE4.3050504@selasky.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 05:59:19 -0000 On 09/26/14 07:51, Hans Petter Selasky wrote: > On 09/25/14 11:19, Gleb Smirnoff wrote: >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: >> H> #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, >> item=0xfffff800114ee000, >> H> udata=0xffffffff81484760) >> >> udata here is uma_slab_t. Can you look at it? >> >> btw, is that reproducible on stable/10 or head? >> > > Yes, it is reproducible. I have not tried stable/10 or head yet. > > (kgdb) print *(uma_slab_t)udata > $3 = { > us_keg = 0xfffff8085696d680, > us_type = { > _us_link = { > le_next = 0xfffff80856970a80, > le_prev = 0x3 > }, > _us_size = 18446735313429006976 > }, > us_hlink = { > sle_next = 0x0 > }, > us_data = 0xffffffff81484778 "", > us_free = { > __bits = {0, 0, -2125969520, 0} > }, > us_freecount = 0, > us_flags = 0 '\0', > us_pad = 0 '\0' > } > BTW: I don't rule out that this might be an indirect error of some other kernel modules which I am experimenting with currently. But if you see something which is obvious then please let me know. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 06:06:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16B43D10 for ; Fri, 26 Sep 2014 06:06:51 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D5ABEE5 for ; Fri, 26 Sep 2014 06:06:49 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s8Q66e8X045325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Sep 2014 10:06:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8Q66efF045324; Fri, 26 Sep 2014 10:06:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 26 Sep 2014 10:06:40 +0400 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: Panic - uma_zfree_arg - zone argument is NULL Message-ID: <20140926060640.GE884@glebius.int.ru> References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> <20140925091911.GZ884@FreeBSD.org> <5424FEE4.3050504@selasky.org> <542500AD.2020708@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542500AD.2020708@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 06:06:51 -0000 On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote: H> On 09/26/14 07:51, Hans Petter Selasky wrote: H> > On 09/25/14 11:19, Gleb Smirnoff wrote: H> >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: H> >> H> #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, H> >> item=0xfffff800114ee000, H> >> H> udata=0xffffffff81484760) H> >> H> >> udata here is uma_slab_t. Can you look at it? H> >> H> >> btw, is that reproducible on stable/10 or head? H> >> H> > H> > Yes, it is reproducible. I have not tried stable/10 or head yet. H> > H> > (kgdb) print *(uma_slab_t)udata H> > $3 = { H> > us_keg = 0xfffff8085696d680, Can you print the us_keg, please? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 06:30:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A24002EC; Fri, 26 Sep 2014 06:30:15 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 648BC15B; Fri, 26 Sep 2014 06:30:15 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8ECE81FE022; Fri, 26 Sep 2014 08:30:13 +0200 (CEST) Message-ID: <542507EE.5050704@selasky.org> Date: Fri, 26 Sep 2014 08:30:06 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Panic - uma_zfree_arg - zone argument is NULL References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> <20140925091911.GZ884@FreeBSD.org> <5424FEE4.3050504@selasky.org> <542500AD.2020708@selasky.org> <20140926060640.GE884@glebius.int.ru> In-Reply-To: <20140926060640.GE884@glebius.int.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 06:30:15 -0000 On 09/26/14 08:06, Gleb Smirnoff wrote: > On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote: > H> On 09/26/14 07:51, Hans Petter Selasky wrote: > H> > On 09/25/14 11:19, Gleb Smirnoff wrote: > H> >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: > H> >> H> #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, > H> >> item=0xfffff800114ee000, > H> >> H> udata=0xffffffff81484760) > H> >> > H> >> udata here is uma_slab_t. Can you look at it? > H> >> > H> >> btw, is that reproducible on stable/10 or head? > H> >> > H> > > H> > Yes, it is reproducible. I have not tried stable/10 or head yet. > H> > > H> > (kgdb) print *(uma_slab_t)udata > H> > $3 = { > H> > us_keg = 0xfffff8085696d680, > > Can you print the us_keg, please? > (kgdb) print *(*(uma_slab_t)udata).us_keg $5 = { uk_lock = { lock_object = { lo_name = 0xfffff8085696fd80 "\200\n\227V\b???\200?\226V\b???", lo_flags = 2168997728, lo_data = 4294967295, lo_witness = 0x0 }, mtx_lock = 0 }, uk_hash = { uh_slab_hash = 0x0, uh_hashsize = 0, uh_hashmask = 0 }, uk_zones = { lh_first = 0x0 }, uk_part_slab = { lh_first = 0x224821000 }, uk_free_slab = { lh_first = 0x0 }, uk_full_slab = { lh_first = 0xfffff8085696d720 }, uk_align = 0, uk_pages = 6, uk_free = 0, uk_reserve = 1, uk_size = 131072, uk_rsize = 67044352, uk_maxpages = 269, uk_init = 0, uk_fini = 0xffffffff81484760 , uk_allocf = 0xfffff8085696d7b8, uk_freef = 0xfffff80854307748, uk_offset = 18446744071584084984, uk_kva = 36435, uk_slabzone = 0x224822000, uk_slabsize = 0, uk_pgoff = 0, uk_ppera = 0, uk_ipers = 0, uk_flags = 1452726152, uk_name = 0x600000000
, uk_link = { le_next = 0x100000001, le_prev = 0x3ff040000000000 } } --HPS From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 06:44:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31740BE9 for ; Fri, 26 Sep 2014 06:44:24 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A670735B for ; Fri, 26 Sep 2014 06:44:23 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s8Q6iLk1045621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Sep 2014 10:44:21 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8Q6iLpO045620; Fri, 26 Sep 2014 10:44:21 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 26 Sep 2014 10:44:21 +0400 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: Panic - uma_zfree_arg - zone argument is NULL Message-ID: <20140926064421.GF884@glebius.int.ru> References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> <20140925091911.GZ884@FreeBSD.org> <5424FEE4.3050504@selasky.org> <542500AD.2020708@selasky.org> <20140926060640.GE884@glebius.int.ru> <542507EE.5050704@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542507EE.5050704@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 06:44:24 -0000 On Fri, Sep 26, 2014 at 08:30:06AM +0200, Hans Petter Selasky wrote: H> On 09/26/14 08:06, Gleb Smirnoff wrote: H> > On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote: H> > H> On 09/26/14 07:51, Hans Petter Selasky wrote: H> > H> > On 09/25/14 11:19, Gleb Smirnoff wrote: H> > H> >> On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: H> > H> >> H> #7 0xffffffff80b07863 in uma_zfree_arg (zone=0x0, H> > H> >> item=0xfffff800114ee000, H> > H> >> H> udata=0xffffffff81484760) H> > H> >> H> > H> >> udata here is uma_slab_t. Can you look at it? H> > H> >> H> > H> >> btw, is that reproducible on stable/10 or head? H> > H> >> H> > H> > H> > H> > Yes, it is reproducible. I have not tried stable/10 or head yet. H> > H> > H> > H> > (kgdb) print *(uma_slab_t)udata H> > H> > $3 = { H> > H> > us_keg = 0xfffff8085696d680, H> > H> > Can you print the us_keg, please? H> H> (kgdb) print *(*(uma_slab_t)udata).us_keg It is trash. This means that vtoslab() returned us bad pointer. Either this mean the address passed to free() is invalid, and belongs to a page not under UMA control, or someone else have mangled the page belonging to UMA. Can you please print *(struct vm_page *)0xffffffff81484760 ? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 07:05:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1161B499; Fri, 26 Sep 2014 07:05:07 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C65AA7ED; Fri, 26 Sep 2014 07:05:06 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 070691FE022; Fri, 26 Sep 2014 09:05:04 +0200 (CEST) Message-ID: <54251019.7030106@selasky.org> Date: Fri, 26 Sep 2014 09:04:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Panic - uma_zfree_arg - zone argument is NULL References: <541AC8A4.3000306@selasky.org> <541ACA20.5030805@selasky.org> <20140925091911.GZ884@FreeBSD.org> <5424FEE4.3050504@selasky.org> <542500AD.2020708@selasky.org> <20140926060640.GE884@glebius.int.ru> <542507EE.5050704@selasky.org> <20140926064421.GF884@glebius.int.ru> In-Reply-To: <20140926064421.GF884@glebius.int.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 07:05:07 -0000 On 09/26/14 08:44, Gleb Smirnoff wrote: > print *(struct vm_page *)0xffffffff81484760 (kgdb) print *(struct vm_page *)0xffffffff81484760 $4 = { plinks = { q = { tqe_next = 0xfffff8085696d680, tqe_prev = 0xfffff80856970a80 }, s = { ss = { sle_next = 0xfffff8085696d680 }, pv = 0xfffff80856970a80 }, memguard = { p = 18446735313428993664, v = 18446735313429006976 } }, listq = { tqe_next = 0x3, tqe_prev = 0x0 }, object = 0xffffffff81484778, pindex = 0, phys_addr = 0, md = { pv_list = { tqh_first = 0xffffffff81484790, tqh_last = 0x0 }, pv_gen = 0, pat_mode = 0 }, wire_count = 2168997800, busy_lock = 4294967295, hold_count = 0, flags = 0, aflags = 0 '\0', oflags = 0 '\0', queue = 0 '\0', segind = 0 '\0', order = 0 '\0', pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0' } --HPS From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 13:59:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BA1D170; Fri, 26 Sep 2014 13:59:06 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B271E6C; Fri, 26 Sep 2014 13:59:05 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XXW35-0006VN-8G; Fri, 26 Sep 2014 13:59:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8QDx2JU005485; Fri, 26 Sep 2014 07:59:02 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+MdRM3i6ybimFyBtngM1LE X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Boot failure with r272146 From: Ian Lepore To: Justin Hibbits In-Reply-To: <20140925204052.6f4c1d60@zhabar.attlocal.net> References: <20140925204052.6f4c1d60@zhabar.attlocal.net> Content-Type: multipart/mixed; boundary="=-CpXzZj/3atU4iGQ0CvjO" Date: Fri, 26 Sep 2014 07:59:01 -0600 Message-ID: <1411739941.66615.257.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 13:59:06 -0000 --=-CpXzZj/3atU4iGQ0CvjO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote: > With r272146 my SATA controller fails to attach, preventing the kernel > from mounting root. I've attached a log of as much as dconschat would > allow. The relevant portion is pcib10: > > atapci0: mem 0xfa402000-0xfa403fff > at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 > pcib10: failed to allocate initial I/O port window (0-0xffffffff,0x10) > atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). > atapci0: unable to map interrupt > device_attach: atapci0 attach returned 6 > > pcib10: allocated memory range (0xfa400000-0xfa400fff) for rid 10 of > pci1:3:14:0 atapci0: mem > 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve > resource for pcib10 pcib10: failed to allocate initial I/O port window > (0-0xffffffff,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, > 0xffffffffffffffff). atapci0: unable to map interrupt > device_attach: atapci0 attach returned 6 > ata0: mem 0xfa404000-0xfa407fff at device > 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 > ata0: unable to allocate interrupt > device_attach: ata0 attach returned 6 > > > It works fine with r271697 kernel (latest I have booting). I haven't > yet tried bisecting. > > Hardware is a PowerMac G5 (last generation). > > - Justin Ooops, I think a paste-o in my r272109 caused it. See if this fixes it. -- Ian --=-CpXzZj/3atU4iGQ0CvjO Content-Disposition: inline; filename="ofw_pcibus_fix.diff" Content-Type: text/x-patch; name="ofw_pcibus_fix.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/powerpc/ofw/ofw_pcibus.c =================================================================== --- sys/powerpc/ofw/ofw_pcibus.c (revision 272109) +++ sys/powerpc/ofw/ofw_pcibus.c (working copy) @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain * resource list. */ if (dinfo->opd_dinfo.cfg.intpin == 0) - ofw_bus_intr_to_rl(dev, node, &dinfo->opd_dinfo.resources); + ofw_bus_intr_to_rl(dev, child, &dinfo->opd_dinfo.resources); } } --=-CpXzZj/3atU4iGQ0CvjO-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 14:40:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 885CD8CA; Fri, 26 Sep 2014 14:40:14 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97C30368; Fri, 26 Sep 2014 14:40:13 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z11so2790334lbi.41 for ; Fri, 26 Sep 2014 07:40: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 :cc:content-type; bh=b74g8tESPrTXpd7weVSAxofU5M3A+h6wxFuW1NDfDf0=; b=K9k15wUnbqtX7Z9CGDKVovCNECuljsd/2mNUNATfToZYZ2BoqpRxhMS05VGThbDlhZ 4/KFEjvhKHVtJ3azw5J3UuaW6k5HJSL56F+9MryGhkVc7HIRa22VogelG96h02yttZjb sGzJ0ktk3x+WOhLlMpONKBu6ok2bJsVHVdBmQ1efOCoYh6TgF8Wlgns7o1ERS0gXJ32R WU1iCSGrxhdfHA/RzU0lLKLdv2sZ/EIjEsovSm0xQFH6++W0At1vqoZf5OT8yr/VWjQU Vfs6c5XIG/v09cSja6u058Nm93A5uHh30KX2SlJklWIMwcn6EUyiv4fOw6Flkm26+pYt 8jcg== MIME-Version: 1.0 X-Received: by 10.152.170.167 with SMTP id an7mr3510119lac.94.1411742409879; Fri, 26 Sep 2014 07:40:09 -0700 (PDT) Received: by 10.25.15.29 with HTTP; Fri, 26 Sep 2014 07:40:09 -0700 (PDT) Received: by 10.25.15.29 with HTTP; Fri, 26 Sep 2014 07:40:09 -0700 (PDT) In-Reply-To: <1411739941.66615.257.camel@revolution.hippie.lan> References: <20140925204052.6f4c1d60@zhabar.attlocal.net> <1411739941.66615.257.camel@revolution.hippie.lan> Date: Fri, 26 Sep 2014 07:40:09 -0700 Message-ID: Subject: Re: Boot failure with r272146 From: Justin Hibbits To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 14:40:14 -0000 That fixed it, thanks! -Justin On Sep 26, 2014 6:59 AM, "Ian Lepore" wrote: > On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote: > > With r272146 my SATA controller fails to attach, preventing the kernel > > from mounting root. I've attached a log of as much as dconschat would > > allow. The relevant portion is pcib10: > > > > atapci0: mem 0xfa402000-0xfa403fff > > at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 > > pcib10: failed to allocate initial I/O port window (0-0xffffffff,0x10) > > atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). > > atapci0: unable to map interrupt > > device_attach: atapci0 attach returned 6 > > > > pcib10: allocated memory range (0xfa400000-0xfa400fff) for rid 10 of > > pci1:3:14:0 atapci0: mem > > 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve > > resource for pcib10 pcib10: failed to allocate initial I/O port window > > (0-0xffffffff,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, > > 0xffffffffffffffff). atapci0: unable to map interrupt > > device_attach: atapci0 attach returned 6 > > ata0: mem 0xfa404000-0xfa407fff at device > > 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 > > ata0: unable to allocate interrupt > > device_attach: ata0 attach returned 6 > > > > > > It works fine with r271697 kernel (latest I have booting). I haven't > > yet tried bisecting. > > > > Hardware is a PowerMac G5 (last generation). > > > > - Justin > > Ooops, I think a paste-o in my r272109 caused it. See if this fixes it. > > -- Ian > > > > > Index: sys/powerpc/ofw/ofw_pcibus.c > =================================================================== > --- sys/powerpc/ofw/ofw_pcibus.c (revision 272109) > +++ sys/powerpc/ofw/ofw_pcibus.c (working copy) > @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain > * resource list. > */ > if (dinfo->opd_dinfo.cfg.intpin == 0) > - ofw_bus_intr_to_rl(dev, node, > &dinfo->opd_dinfo.resources); > + ofw_bus_intr_to_rl(dev, child, > &dinfo->opd_dinfo.resources); > } > } > > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 15:17:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10DCD529; Fri, 26 Sep 2014 15:17:24 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5758A34; Fri, 26 Sep 2014 15:17:23 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XXXGr-0000Lt-Kv; Fri, 26 Sep 2014 15:17:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8QFHKYa005634; Fri, 26 Sep 2014 09:17:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18VybkOjjGaUPFt38DkMj3x X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Boot failure with r272146 From: Ian Lepore To: Justin Hibbits In-Reply-To: References: <20140925204052.6f4c1d60@zhabar.attlocal.net> <1411739941.66615.257.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Sep 2014 09:17:19 -0600 Message-ID: <1411744639.66615.270.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 15:17:24 -0000 On Fri, 2014-09-26 at 07:40 -0700, Justin Hibbits wrote: > That fixed it, thanks! > > -Justin Fix committed as r272181, sorry for the glitch. -- Ian > On Sep 26, 2014 6:59 AM, "Ian Lepore" wrote: > > > On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote: > > > With r272146 my SATA controller fails to attach, preventing the kernel > > > from mounting root. I've attached a log of as much as dconschat would > > > allow. The relevant portion is pcib10: > > > > > > atapci0: mem 0xfa402000-0xfa403fff > > > at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 > > > pcib10: failed to allocate initial I/O port window (0-0xffffffff,0x10) > > > atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff). > > > atapci0: unable to map interrupt > > > device_attach: atapci0 attach returned 6 > > > > > > pcib10: allocated memory range (0xfa400000-0xfa400fff) for rid 10 of > > > pci1:3:14:0 atapci0: mem > > > 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve > > > resource for pcib10 pcib10: failed to allocate initial I/O port window > > > (0-0xffffffff,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, > > > 0xffffffffffffffff). atapci0: unable to map interrupt > > > device_attach: atapci0 attach returned 6 > > > ata0: mem 0xfa404000-0xfa407fff at device > > > 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 > > > ata0: unable to allocate interrupt > > > device_attach: ata0 attach returned 6 > > > > > > > > > It works fine with r271697 kernel (latest I have booting). I haven't > > > yet tried bisecting. > > > > > > Hardware is a PowerMac G5 (last generation). > > > > > > - Justin > > > > Ooops, I think a paste-o in my r272109 caused it. See if this fixes it. > > > > -- Ian > > > > > > > > > > Index: sys/powerpc/ofw/ofw_pcibus.c > > =================================================================== > > --- sys/powerpc/ofw/ofw_pcibus.c (revision 272109) > > +++ sys/powerpc/ofw/ofw_pcibus.c (working copy) > > @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain > > * resource list. > > */ > > if (dinfo->opd_dinfo.cfg.intpin == 0) > > - ofw_bus_intr_to_rl(dev, node, > > &dinfo->opd_dinfo.resources); > > + ofw_bus_intr_to_rl(dev, child, > > &dinfo->opd_dinfo.resources); > > } > > } > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 26 18:52:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75668459 for ; Fri, 26 Sep 2014 18:52:04 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C986667 for ; Fri, 26 Sep 2014 18:52:04 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5D57BB987; Fri, 26 Sep 2014 14:52:03 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy) Date: Fri, 26 Sep 2014 14:47:02 -0400 Message-ID: <6194383.JuC2mSLzHG@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <282186928.pUbQA97aum@ralph.baldwin.cx> References: <54140711.7020001@gmx.com> <282186928.pUbQA97aum@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 26 Sep 2014 14:52:03 -0400 (EDT) Cc: dt71@gmx.com, Marcin Cieslak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 26 Sep 2014 18:52:04 -0000 On Monday, September 15, 2014 11:25:47 AM John Baldwin wrote: > On Saturday, September 13, 2014 10:57:53 AM dt71@gmx.com wrote: > > John Baldwin wrote on 09/12/2014 23:06: > > > X loaded i915kms automatically and > > > i915 and i915kms do not get along. i915 had already allocated the IRQ > > > when i915kms tried to alloc the same IRQ causing the issue. > > > > Who is to blame? The user who tried to manually load an unsupported > > combination of modules, or the system, which should have handled things > > gracefully (whether by automatically unloading the first driver, or > > producing a soft-error upon loading the 2nd driver)? > > > > On a side-note, I also had a "resource_list_alloc: resource entry is busy" > > panic right after switching from the 10.0-supported Xorg to the "new" > > Xorg; > > I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran > > "startx", and got the panic. Surely this wasn't my fault! > > I can turn the panic into a resource allocation failure, but specifically > with KMS I am unsure if it will actually be better. FYI, I wrote a test for the patch I sent to make this not panic and verified it worked ok and committed it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 01:02:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BD22219; Sat, 27 Sep 2014 01:02:34 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 886A214B; Sat, 27 Sep 2014 01:02:34 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 439F683A; Sat, 27 Sep 2014 01:02:34 +0000 (UTC) Date: Sat, 27 Sep 2014 01:02:32 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, np@FreeBSD.org, delphij@FreeBSD.org Message-ID: <2134951248.1.1411779753111.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1534 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 01:02:34 -0000 See Changes: [np] cxgbe(4): explicitly set various if_hw_tso* values. MFC after:=093 days [delphij] Add libuutil to dependency list. Noticed by:=09sef MFC after:=093 days ------------------------------------------ [...truncated 86223 lines...] :2543:50: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot fault %llu"), guid); ~~~~ ^~~~ %lu :2578:52: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot degrade %llu"), guid); ~~~~ ^~~~ %lu :3247:6: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] guid); ^~~~ :3841:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, ":<0x%llx>", obj); ~~~~ ^~~ %lx :3852:7: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~~~ :3852:14: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~ :3873:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, "%s:<0x%llx>", dsname, obj); ~~~~ ^~~ %lx --- kerberos5/lib__L --- --- crypto.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o crypto.o --- lib__L --- --- depend_subdir_clang --- --- depend_subdir_libclangarcmigrate --- =3D=3D=3D> lib/clang/libclangarcmigrate (depend) --- kerberos5/lib__L --- --- delete_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o delet= e_sec_context.o --- lib__L --- --- AttrParsedAttrList.inc.h --- clang-tblgen -gen-clang-attr-parsed-attr-list -I -d AttrParsedAttrList.inc.d -o AttrParsedAttrL= ist.inc.h --- depend_subdir_ncurses --- echo libpanel.so.5: /usr/obj >> .depend =3D=3D=3D> lib/ncurses/ncursesw (depend) --- depend_subdir_clang --- --- Attrs.inc.h --- clang-tblgen -gen-clang-attr-classes -I -d Attrs.inc.d -o Attrs.inc.h --- DiagnosticGroups.inc.h --- clang-tblgen -gen-clang-diag-groups -I -d DiagnosticGroups.inc.d -o DiagnosticGrou= ps.inc.h --- DiagnosticSemaKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DSema -I -d DiagnosticSemaKind= s.inc.d -o DiagnosticSemaKinds.inc.h --- depend_subdir_ncurses --- =3D=3D=3D> lib/ncurses/formw (depend) --- cddl/lib__L --- 13 warnings generated. --- kerberos5/lib__L --- --- display_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_nam= e.o --- lib__L --- --- ncurses_def.h --- AWK=3Dawk sh > ncurses_def.h --- depend_subdir_clang --- --- AttrList.inc.h --- clang-tblgen -gen-clang-attr-list -I -d AttrList.inc.d -o AttrList.inc.h --- cddl/lib__L --- --- libzfs_sendrecv.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_sendrecv.o --- lib__L --- --- depend_subdir_ncurses --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -= I. -I/usr/obj -I -I -I -I -DNDEBUG -DHAVE_CONFIG_= H -I -I -std=3D= gnu99 <= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/ncurses/formw/.= ./../../contrib/ncurses/form/frm_def.c> = --- depend_subdir_clang --- --- CommentCommandList.inc.h --- clang-tblgen -gen-clang-comment-command-list -d CommentCommandList.inc.d -= o CommentCommandList.inc.h --- CommentNodes.inc.h --- clang-tblgen -gen-clang-comment-nodes -d CommentNodes.inc.d -o CommentNode= s.inc.h --- DeclNodes.inc.h --- clang-tblgen -gen-clang-decl-nodes -d DeclNodes.inc.d -o DeclNodes.inc.h = --- DiagnosticCommonKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DCommon -I -d DiagnosticCommon= Kinds.inc.d -o DiagnosticCommonKinds.inc.h --- StmtNodes.inc.h --- clang-tblgen -gen-clang-stmt-nodes -d StmtNodes.inc.d -o StmtNodes.inc.h = --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__ST= DC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABL= E_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"= x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd1= 1.0\" -DDEFAULT_SYSROOT=3D\"\" =20 --- kerberos5/lib__L --- --- display_status.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_s= tatus.o --- duplicate_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o duplicate= _name.o --- export_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o export_name.= o --- cddl/lib__L --- --- libzfs_status.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_status.o --- kerberos5/lib__L --- --- export_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o expor= t_sec_context.o --- cddl/lib__L --- --- libzfs_util.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_util.o --- kerberos5/lib__L --- --- external.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o external.o --- cddl/lib__L --- :590:40: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu", n); ~~~~ ^ %lu :596:42: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu%c", n, u); ~~~~ ^ %lu 2 warnings generated. --- zfeature_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfeature_common.o --- kerberos5/lib__L --- --- import_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o import_name.= o --- cddl/lib__L --- --- zfs_comutil.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_comutil.o --- zfs_deleg.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_deleg.o --- kerberos5/lib__L --- --- import_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o impor= t_sec_context.o --- cddl/lib__L --- --- zfs_fletcher.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_fletcher.o --- kerberos5/lib__L --- --- indicate_mechs.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o indicate_= mechs.o --- cddl/lib__L --- --- zfs_ioctl_compat.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_ioctl_compat.o --- lib__L --- --- depend_subdir_ncurses --- echo libformw.so.5: /usr/obj >> .depend =3D=3D=3D> lib/ncurses/menuw (depend) --- ncurses_def.h --- AWK=3Dawk sh > ncurses_def.h --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -= I. -I/usr/obj -I -I -I -I -DNDEBUG -DHAVE_CONFIG_= H -I -std=3Dgnu99 = --- kerberos5/lib__L --- --- init_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o init_se= c_context.o --- cddl/lib__L --- --- zfs_namecheck.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_namecheck.o --- zfs_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_prop.o --- kerberos5/lib__L --- --- inquire_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inquire_= context.o --- cddl/lib__L --- --- zpool_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zpool_prop.o --- kerberos5/lib__L --- --- inquire_cred_by_mech.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inq= uire_cred_by_mech.o --- cddl/lib__L --- --- zprop_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zprop_common.o --- kerberos5/lib__L --- --- inquire_mechs_for_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o i= nquire_mechs_for_name.o --- cddl/lib__L --- --- libzfs.so.2 --- building shared library libzfs.so.2 --- kerberos5/lib__L --- --- inquire_names_for_mech.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o i= nquire_names_for_mech.o --- cddl/lib__L --- /usr/obj: cannot find -luutil cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [libzfs.so.2] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- kerberos5/lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- lib__L --- echo libmenuw.so.5: /usr/obj >> .depend A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.depend] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [depend_subdir_ncurses] Error code 2 make[4]: stopped in --- depend_subdir_clang --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [depend_subdir_libclangarcmigrate] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [depend_subdir_clang] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 04:26:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9104B347; Sat, 27 Sep 2014 04:26:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7964D85E; Sat, 27 Sep 2014 04:26:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7935985F; Sat, 27 Sep 2014 04:26:53 +0000 (UTC) Date: Sat, 27 Sep 2014 04:26:42 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, np@FreeBSD.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, delphij@FreeBSD.org Message-ID: <1917063527.3.1411792012432.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2134951248.1.1411779753111.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2134951248.1.1411779753111.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1535 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 04:26:54 -0000 See Changes: [kevlo] Remove a bogus AIC. Reviewed by:=09imp [grehan] Allow the PIC's IMR register to be read before ICW initialisation. As of git submit e179f6914152eca9, the Linux kernel does a simple probe of the PIC by writing a pattern to the IMR and then reading it back, prior to the init sequence of ICW words. The bhyve PIC emulation wasn't allowing the IMR to be read until the ICW sequence was complete. This limitation isn't required so relax the test. With this change, Linux kernels 3.15-rc2 and later won't hang on boot when calibrating the local APIC. Reviewed by:=09tychon MFC after:=093 days ------------------------------------------ [...truncated 89694 lines...] ~~~~ ^~~~~~ %lu --- lib__L --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- cddl/lib__L --- :1493:8: wa= rning: format specifies type 'long long' but the argument has type 'long' [= -Wformat] (loss + 30) / 60); ^~~~~~~~~~~~~~~~ :1499:48: w= arning: format specifies type 'long long' but the argument has type 'int64_= t' (aka 'long') [-Wformat] dryrun ? "Would discard" : "Discarded", loss); ^~~~ :1553:48: w= arning: format specifies type 'long long' but the argument has type 'long' = [-Wformat] "\tmust be discarded, irreversibly. "), (loss + 30) / = 60); ^~~~~~~~~~~~~~= ~~ :1557:48: w= arning: format specifies type 'long long' but the argument has type 'int64_= t' (aka 'long') [-Wformat] "\tmust be discarded, irreversibly. "), loss); ^~~~ --- lib__L --- --- depend_subdir_libmd --- =3D=3D=3D> lib/libmd (depend) --- cddl/lib__L --- :2543:50: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot fault %llu"), guid); ~~~~ ^~~~ %lu :2578:52: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot degrade %llu"), guid); ~~~~ ^~~~ %lu :3247:6: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] guid); ^~~~ :3841:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, ":<0x%llx>", obj); ~~~~ ^~~ %lx :3852:7: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~~~ :3852:14: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~ :3873:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, "%s:<0x%llx>", dsname, obj); ~~~~ ^~~ %lx --- kerberos5/lib__L --- --- delete_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o delet= e_sec_context.o --- lib__L --- --- depend_subdir_libmilter --- =3D=3D=3D> lib/libmilter (depend) --- sm_os.h --- --- cddl/lib__L --- 13 warnings generated. --- kerberos5/lib__L --- --- display_name.o --- --- lib__L --- ln -sf sm_os.h --- kerberos5/lib__L --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_nam= e.o --- cddl/lib__L --- --- libzfs_sendrecv.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_sendrecv.o --- lib__L --- --- depend_subdir_libmemstat --- echo libmemstat.so.3: /usr/obj >> .depend --- depend_subdir_libmilter --- --- .depend --- --- cddl/lib__L --- --- libzfs_status.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_status.o --- lib__L --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I -I. -DNOT_SENDMAIL -Dsm_snprintf=3Dsnprintf -D_THREAD_SAFE -= DSM_CONF_POLL -DNETINET6 -std=3Dgnu99 --- kerberos5/lib__L --- --- display_status.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_s= tatus.o --- lib__L --- --- depend_subdir_libmp --- =3D=3D=3D> lib/libmp (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -std=3Dgnu99 --- kerberos5/lib__L --- --- duplicate_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o duplicate= _name.o --- cddl/lib__L --- --- libzfs_util.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_util.o --- lib__L --- echo libmp.so.7: /usr/obj >> .depend --- cddl/lib__L --- --- zfeature_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfeature_common.o --- kerberos5/lib__L --- --- export_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o export_name.= o --- cddl/lib__L --- --- libzfs_util.o --- :590:40: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu", n); ~~~~ ^ %lu :596:42: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu%c", n, u); ~~~~ ^ %lu --- lib__L --- --- depend_subdir_libnetbsd --- =3D=3D=3D> lib/libnetbsd (depend) --- cddl/lib__L --- 2 warnings generated. --- kerberos5/lib__L --- --- export_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o expor= t_sec_context.o --- cddl/lib__L --- --- zfs_comutil.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_comutil.o --- lib__L --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -std=3Dgnu99 --- cddl/lib__L --- --- zfs_deleg.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_deleg.o --- kerberos5/lib__L --- --- external.o --- --- cddl/lib__L --- --- zfs_fletcher.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_fletcher.o --- kerberos5/lib__L --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o external.o --- import_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o import_name.= o --- import_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o impor= t_sec_context.o --- cddl/lib__L --- --- zfs_ioctl_compat.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_ioctl_compat.o --- lib__L --- --- depend_subdir_libnetgraph --- =3D=3D=3D> lib/libnetgraph (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- cddl/lib__L --- --- zfs_namecheck.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_namecheck.o --- kerberos5/lib__L --- --- indicate_mechs.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o indicate_= mechs.o --- cddl/lib__L --- --- zfs_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_prop.o --- kerberos5/lib__L --- --- init_sec_context.o --- --- cddl/lib__L --- --- zpool_prop.o --- --- kerberos5/lib__L --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o init_se= c_context.o --- cddl/lib__L --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zpool_prop.o --- kerberos5/lib__L --- --- inquire_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inquire_= context.o --- cddl/lib__L --- --- zprop_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zprop_common.o --- lib__L --- --- depend_subdir_libngatm --- =3D=3D=3D> lib/libngatm (depend) --- kerberos5/lib__L --- --- inquire_cred_by_mech.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inq= uire_cred_by_mech.o --- lib__L --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I/usr/obj -I -std=3Dgnu99 = --- cddl/lib__L --- --- libzfs.so.2 --- building shared library libzfs.so.2 --- kerberos5/lib__L --- --- inquire_mechs_for_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o i= nquire_mechs_for_name.o --- cddl/lib__L --- --- libzfs.a --- building static zfs library --- libzfs.so.2 --- /usr/obj: cannot find -luutil cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [libzfs.so.2] Error code 1 make[5]: stopped in --- kerberos5/lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- cddl/lib__L --- --- libzfs.a --- ranlib -D libzfs.a 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [depend_subdir_libngatm] Error code 2 make[4]: stopped in 1 error make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 06:50:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAD74188; Sat, 27 Sep 2014 06:50:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C4E3F666; Sat, 27 Sep 2014 06:50:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 208488BD; Sat, 27 Sep 2014 06:50:20 +0000 (UTC) Date: Sat, 27 Sep 2014 06:50:18 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, np@FreeBSD.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, neel@FreeBSD.org, delphij@FreeBSD.org, adrian@FreeBSD.org, marcel@FreeBSD.org Message-ID: <2083005937.4.1411800620089.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1917063527.3.1411792012432.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1917063527.3.1411792012432.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1536 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 06:50:20 -0000 See Changes: [np] cxgbe(4): implement if_get_counter. [adrian] Remove an un-needed bit of pre-processor work - it all lives insid= e #ifdef RSS. [marcel] Add 3 long options for getting information about mkimg itself: --version=09print the version of mkimg and also whether it's =09=0964- or 32-bit. --formats=09list the supported output formats separated by space. --schemes=09list the supported partitioning schemes separated by =09=09space. Inspired by a patch from: gjb@ MFC after:=091 week Relnotes:=09yes [neel] After r271635 mmap(2) requires either MAP_PRIVATE or MAP_SHARED for non-anonymous mappings. This gets 'bhyvectl --get-all' working again. Reported by:=09Anish Gupta (akgupt3@gmail.com) ------------------------------------------ [...truncated 88369 lines...] ^~~~~~~~~~~~~~~~ :1499:48: w= arning: format specifies type 'long long' but the argument has type 'int64_= t' (aka 'long') [-Wformat] dryrun ? "Would discard" : "Discarded", loss); ^~~~ :1553:48: w= arning: format specifies type 'long long' but the argument has type 'long' = [-Wformat] "\tmust be discarded, irreversibly. "), (loss + 30) / = 60); ^~~~~~~~~~~~~~= ~~ :1557:48: w= arning: format specifies type 'long long' but the argument has type 'int64_= t' (aka 'long') [-Wformat] "\tmust be discarded, irreversibly. "), loss); ^~~~ --- lib__L --- --- Options.inc.h --- tblgen -gen-opt-parser-defs -I -I = -d Option= s.inc.d -o Options.inc.h --- cddl/lib__L --- :2543:50: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot fault %llu"), guid); ~~~~ ^~~~ %lu :2578:52: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot degrade %llu"), guid); ~~~~ ^~~~ %lu :3247:6: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] guid); ^~~~ :3841:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, ":<0x%llx>", obj); ~~~~ ^~~ %lx :3852:7: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~~~ :3852:14: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~ :3873:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, "%s:<0x%llx>", dsname, obj); ~~~~ ^~~ %lx --- kerberos5/lib__L --- --- delete_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o delet= e_sec_context.o --- lib__L --- --- StmtNodes.inc.h --- clang-tblgen -gen-clang-stmt-nodes -d StmtNodes.inc.d -o StmtNodes.inc.h = --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I= -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_M= ACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER= -DCLANG_ENABLE_STATIC_ANALYZER -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unk= nown-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DDE= FAULT_SYSROOT=3D\"\" = = =20 --- kerberos5/lib__L --- --- display_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_nam= e.o --- display_status.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_s= tatus.o --- cddl/lib__L --- 13 warnings generated. --- libzfs_sendrecv.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_sendrecv.o --- kerberos5/lib__L --- --- duplicate_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o duplicate= _name.o --- export_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o export_name.= o --- export_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o expor= t_sec_context.o --- external.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o external.o --- cddl/lib__L --- --- libzfs_status.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_status.o --- kerberos5/lib__L --- --- import_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o import_name.= o --- cddl/lib__L --- --- libzfs_util.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_util.o :590:40: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu", n); ~~~~ ^ %lu :596:42: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu%c", n, u); ~~~~ ^ %lu --- kerberos5/lib__L --- --- import_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o impor= t_sec_context.o --- cddl/lib__L --- 2 warnings generated. --- kerberos5/lib__L --- --- indicate_mechs.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o indicate_= mechs.o --- cddl/lib__L --- --- zfeature_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfeature_common.o --- zfs_comutil.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_comutil.o --- lib__L --- --- depend_subdir_libprocstat --- =3D=3D=3D> lib/libprocstat (depend) --- cddl/lib__L --- --- zfs_deleg.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_deleg.o --- lib__L --- --- _sub.depend --- =3D=3D=3D> lib/libprocstat/zfs (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I= -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_= BOOLEAN -std=3Dgnu99 --- kerberos5/lib__L --- --- init_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o init_se= c_context.o --- cddl/lib__L --- --- zfs_fletcher.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_fletcher.o --- lib__L --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I. -I -D_KVM_VNODE -DLIBPROCSTAT_ZFS -std= =3Dgnu99 --- cddl/lib__L --- --- zfs_ioctl_compat.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_ioctl_compat.o --- kerberos5/lib__L --- --- inquire_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inquire_= context.o --- cddl/lib__L --- --- zfs_namecheck.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_namecheck.o --- kerberos5/lib__L --- --- inquire_cred_by_mech.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inq= uire_cred_by_mech.o --- cddl/lib__L --- --- zfs_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_prop.o --- lib__L --- echo libprocstat.so.1: /usr/obj /usr/obj /usr/obj >> .depend --- kerberos5/lib__L --- --- inquire_mechs_for_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o i= nquire_mechs_for_name.o --- lib__L --- --- depend_subdir_clang --- --- depend_subdir_libclangfrontendtool --- =3D=3D=3D> lib/clang/libclangfrontendtool (depend) --- DiagnosticFrontendKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DFrontend -I -d DiagnosticFr= ontendKinds.inc.d -o DiagnosticFrontendKinds.inc.h --- cddl/lib__L --- --- zpool_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zpool_prop.o --- lib__L --- --- DiagnosticCommonKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DCommon -I -d DiagnosticComm= onKinds.inc.d -o DiagnosticCommonKinds.inc.h --- Options.inc.h --- tblgen -gen-opt-parser-defs -I = -I -= d Options.inc.d -o Options.inc.h --- kerberos5/lib__L --- --- inquire_names_for_mech.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o i= nquire_names_for_mech.o --- cddl/lib__L --- --- zprop_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zprop_common.o --- lib__L --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_FREE= BSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DC= LANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DLLVM_DEFAULT_TARGET_T= RIPLE=3D\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-unknow= n-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" =20 --- kerberos5/lib__L --- --- inquire_sec_context_by_oid.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c = -o inquire_sec_context_by_oid.o --- lib__L --- --- depend_subdir_libclanglex --- =3D=3D=3D> lib/clang/libclanglex (depend) --- cddl/lib__L --- --- libzfs.so.2 --- building shared library libzfs.so.2 --- lib__L --- --- DiagnosticLexKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DLex -I -d DiagnosticLexKinds.inc.d = -o DiagnosticLexKinds.inc.h --- AttrSpellings.inc.h --- clang-tblgen -gen-clang-attr-spelling-list -I -d AttrSpellings.inc.d -o AttrSpellings.inc.h --- DiagnosticCommonKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DCommon -I -d DiagnosticCommonKinds.i= nc.d -o DiagnosticCommonKinds.inc.h --- cddl/lib__L --- /usr/obj: cannot find -luutil cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [libzfs.so.2] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- lib__L --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [depend_subdir_libclanglex] Error code 2 make[5]: stopped in --- kerberos5/lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- lib__L --- --- depend_subdir_libclangfrontend --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [depend_subdir_libclangfrontend] Error code 2 make[5]: stopped in 2 errors make[5]: stopped in *** [depend_subdir_clang] Error code 2 make[4]: stopped in 1 error make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 10:03:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3011DF2; Sat, 27 Sep 2014 10:03:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id CB740A01; Sat, 27 Sep 2014 10:03:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 07A6E8FA; Sat, 27 Sep 2014 10:03:04 +0000 (UTC) Date: Sat, 27 Sep 2014 10:03:01 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, np@FreeBSD.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, sbruno@FreeBSD.org, melifaro@FreeBSD.org, neel@FreeBSD.org, delphij@FreeBSD.org, adrian@FreeBSD.org, cperciva@FreeBSD.org, marcel@FreeBSD.org Message-ID: <1530752109.5.1411812184846.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2083005937.4.1411800620089.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2083005937.4.1411800620089.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1537 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-Mailman-Approved-At: Sat, 27 Sep 2014 11:27:04 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 10:03:05 -0000 See Changes: [cperciva] Switch primes(6) from using unsigned long to using uint64_t. Th= is fixes 'limited range of type' warnings about comparisons on 32-bit systems, and allows 32-bit systems to compute the full range of primes. [sbruno] Add kernel support for the TP-LINK MR3020 Atheros MIPS 24k router. AR9331 based system. Phabric:=09https://reviews.freebsd.org/D780 Reviewed by:=09adrian [melifaro] * Split tcp_signature_compute() into 2 pieces: - tcp_get_sav() - SADB key lookup - tcp_signature_do_compute() - actual computation * Fix TCP signature case for listening socket: do not assume EVERY connection coming to socket with TCP_SIGNATURE set to be md5 signed regardless of SADB key existance for particular address. This fixes the case for routing software having _some_ BGP sessions secured by md5. * Simplify TCP_SIGNATURE handling in tcp_input() MFC after:=092 weeks ------------------------------------------ [...truncated 87458 lines...] %lu :2578:52: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, "cannot degrade %llu"), guid); ~~~~ ^~~~ %lu :3247:6: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] guid); ^~~~ :3841:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, ":<0x%llx>", obj); ~~~~ ^~~ %lx :3852:7: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~~~ :3852:14: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~ :3873:57: w= arning: format specifies type 'unsigned long long' but the argument has typ= e 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, "%s:<0x%llx>", dsname, obj); ~~~~ ^~~ %lx --- kerberos5/lib__L --- --- crypto.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o crypto.o --- delete_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o delet= e_sec_context.o --- cddl/lib__L --- 13 warnings generated. --- libzfs_sendrecv.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_sendrecv.o --- kerberos5/lib__L --- --- display_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_nam= e.o --- lib__L --- echo libformw.so.5: /usr/obj >> .depend =3D=3D=3D> lib/ncurses/menuw (depend) --- ncurses_def.h --- AWK=3Dawk sh > ncurses_def.h --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -= I. -I/usr/obj -I -I -I -I -DNDEBUG -DHAVE_CONFIG_= H -I -std=3Dgnu99 = --- cddl/lib__L --- --- libzfs_status.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_status.o --- kerberos5/lib__L --- --- display_status.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o display_s= tatus.o --- cddl/lib__L --- --- libzfs_util.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o libzfs_util.o --- kerberos5/lib__L --- --- duplicate_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o duplicate= _name.o --- cddl/lib__L --- :590:40: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu", n); ~~~~ ^ %lu :596:42: wa= rning: format specifies type 'unsigned long long' but the argument has type= 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(buf, buflen, "%llu%c", n, u); ~~~~ ^ %lu --- kerberos5/lib__L --- --- export_name.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o export_name.= o --- cddl/lib__L --- 2 warnings generated. --- zfeature_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfeature_common.o --- zfs_comutil.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_comutil.o --- kerberos5/lib__L --- --- export_sec_context.o --- --- cddl/lib__L --- --- zfs_deleg.o --- --- kerberos5/lib__L --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o expor= t_sec_context.o --- cddl/lib__L --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_deleg.o --- lib__L --- --- depend_subdir_clang --- --- depend_subdir_libclangast --- =3D=3D=3D> lib/clang/libclangast (depend) --- AttrImpl.inc.h --- clang-tblgen -gen-clang-attr-impl -I -d AttrImpl.inc.d -o AttrImpl.inc.h --- cddl/lib__L --- --- zfs_fletcher.o --- --- lib__L --- --- AttrList.inc.h --- --- cddl/lib__L --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_fletcher.o --- lib__L --- clang-tblgen -gen-clang-attr-list -I -d AttrList.inc.d -o AttrList.inc.h --- kerberos5/lib__L --- --- external.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o external.o --- lib__L --- --- Attrs.inc.h --- clang-tblgen -gen-clang-attr-classes -I -d Attrs.inc.d -o Attrs.inc.h --- CommentCommandList.inc.h --- clang-tblgen -gen-clang-comment-command-list -d CommentCommandList.inc.d -= o CommentCommandList.inc.h --- CommentHTMLTagsProperties.inc.h --- clang-tblgen -gen-clang-comment-html-tags-properties -d CommentHTMLTagsPro= perties.inc.d -o CommentHTMLTagsProperties.inc.h --- DiagnosticCommentKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DComment -I -d DiagnosticCommentKinds= .inc.d -o DiagnosticCommentKinds.inc.h --- DiagnosticCommonKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DCommon -I -d DiagnosticCommonKinds.i= nc.d -o DiagnosticCommonKinds.inc.h --- cddl/lib__L --- --- zfs_ioctl_compat.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_ioctl_compat.o --- lib__L --- --- DiagnosticSemaKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DSema -I -d DiagnosticSemaKinds.inc.d= -o DiagnosticSemaKinds.inc.h --- AttrDump.inc.h --- clang-tblgen -gen-clang-attr-dump -I -d AttrDump.inc.d -o AttrDump.inc.h --- CommentCommandInfo.inc.h --- clang-tblgen -gen-clang-comment-command-info -d CommentCommandInfo.inc.d -= o CommentCommandInfo.inc.h --- depend_subdir_ncurses --- echo libmenuw.so.5: /usr/obj >> .depend --- depend_subdir_clang --- --- CommentHTMLNamedCharacterReferences.inc.h --- clang-tblgen -gen-clang-comment-html-named-character-references -d Comment= HTMLNamedCharacterReferences.inc.d -o CommentHTMLNamedCharacterReferences.i= nc.h --- depend_subdir_ncurses --- =3D=3D=3D> lib/ncurses/panelw (depend) --- depend_subdir_clang --- --- CommentHTMLTags.inc.h --- clang-tblgen -gen-clang-comment-html-tags -d CommentHTMLTags.inc.d -o Comm= entHTMLTags.inc.h --- CommentNodes.inc.h --- clang-tblgen -gen-clang-comment-nodes -d CommentNodes.inc.d -o CommentNode= s.inc.h --- depend_subdir_ncurses --- --- ncurses_def.h --- --- kerberos5/lib__L --- --- import_name.o --- --- lib__L --- AWK=3Dawk sh > ncurses_def.h --- depend_subdir_clang --- --- DeclNodes.inc.h --- --- kerberos5/lib__L --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o import_name.= o --- lib__L --- clang-tblgen -gen-clang-decl-nodes -d DeclNodes.inc.d -o DeclNodes.inc.h = --- DiagnosticASTKinds.inc.h --- clang-tblgen -gen-clang-diags-defs -clang-component=3DAST -I -d DiagnosticASTKinds.inc.d = -o DiagnosticASTKinds.inc.h --- depend_subdir_ncurses --- --- .depend --- rm -f .depend --- cddl/lib__L --- --- zfs_namecheck.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_namecheck.o --- lib__L --- CC=3D'cc ' mkdep -f .depend -a -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -= I. -I/usr/obj -I -I -I -I -DNDEBUG -DHAVE_CO= NFIG_H -I -std=3Dgnu99 --- depend_subdir_clang --- --- StmtNodes.inc.h --- clang-tblgen -gen-clang-stmt-nodes -d StmtNodes.inc.d -o StmtNodes.inc.h = --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -I -I -I. -I= -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_M= ACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_AN= ALYZER -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DLLVM= _HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" = = <= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/clang/libclanga= st/../../../contrib/llvm/tools/clang/lib/AST/Expr.cpp> =20 --- cddl/lib__L --- --- zfs_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zfs_prop.o --- kerberos5/lib__L --- --- import_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o impor= t_sec_context.o --- cddl/lib__L --- --- zpool_prop.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zpool_prop.o --- kerberos5/lib__L --- --- indicate_mechs.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o indicate_= mechs.o --- cddl/lib__L --- --- zprop_common.o --- cc -O2 -pipe -DZFS_NO_ACL -I -I -I -I -I -I -I -I -I -I -I -I -I -I -I -DNEED_SOLARIS_BOOLEAN -s= td=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unknown-pragmas = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa= rameter -Wno-parentheses -Qunused-arguments -c -o zprop_common.o --- kerberos5/lib__L --- --- init_sec_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o init_se= c_context.o --- cddl/lib__L --- --- libzfs.so.2 --- building shared library libzfs.so.2 --- lib__L --- --- depend_subdir_ncurses --- echo libpanelw.so.5: /usr/obj >> .depend --- kerberos5/lib__L --- --- inquire_context.o --- cc -O2 -pipe -I -I -I -I -I= -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o inquire_= context.o --- cddl/lib__L --- /usr/obj: cannot find -luutil cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [libzfs.so.2] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- kerberos5/lib__L --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- lib__L --- --- depend_subdir_clang --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [depend_subdir_libclangast] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [depend_subdir_clang] Error code 2 make[4]: stopped in 1 error make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 12:38:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D399C859 for ; Sat, 27 Sep 2014 12:38:44 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E8119AA for ; Sat, 27 Sep 2014 12:38:44 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XXrGm-000CIm-F2>; Sat, 27 Sep 2014 14:38:36 +0200 Received: from g224249072.adsl.alicedsl.de ([92.224.249.72] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XXrGm-00170h-D5>; Sat, 27 Sep 2014 14:38:36 +0200 Date: Sat, 27 Sep 2014 14:38:30 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , freebsd-hardware@freebd.org Subject: WiFi 802.11/ac PCIe supported adaptor Message-ID: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/tL=Kwh14hhKAm7uKR1Vx/zU"; protocol="application/pgp-signature" X-Originating-IP: 92.224.249.72 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 12:38:44 -0000 --Sig_/tL=Kwh14hhKAm7uKR1Vx/zU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want= to replace it with an 802.11ac adaptor. Since I made very bad experiences with CURRENT and support of modest modern= hardware (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. I found this PCIe adaptor card attractive: GigaByte Gigabyte GC-WB867D-I I can not find ad hoc the WLAN chip used on that specific card, but maybe s= omeone has experiences with that litte board. Thanks in advance, Oliver --Sig_/tL=Kwh14hhKAm7uKR1Vx/zU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJq/LAAoJEOgBcD7A/5N80McIALtkbLHTzhBYVXu66FIJH1DL KRIMsiaCWj4w7vSNmhlwqsJUiEBfDwFdXR2pFYtW4lQtb3Mk+3WvyXZIWU+GViiK 3dsUmsjrcKfG3rh6KMhG14wq4Z65YlyoXJCrbm1zHIXUsj6Ej2gmMCjhlGXH+V7k SYS7bJBt0IEtfrQ+RKNiw1dAtCJ8+gejaqiEewcfmo3nmgH3h6hM8J5m8K0y2PPh mROIWL9zVdvuHtJgU9BTQUfsCSkxjGc6b9rtUFabHjhRJ3etnq1VFvDsUbfHbaYv 0U0ypQxECnQzGNx4HqEHajaCcy7vlweY64RQNgw9kLSNFl9ZQ/+Ewu+HQKZsK34= =fMin -----END PGP SIGNATURE----- --Sig_/tL=Kwh14hhKAm7uKR1Vx/zU-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 13:41:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82D114FB; Sat, 27 Sep 2014 13:41:50 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6D973F1A; Sat, 27 Sep 2014 13:41:50 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id AB27898C; Sat, 27 Sep 2014 13:41:50 +0000 (UTC) Date: Sat, 27 Sep 2014 13:41:47 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, np@FreeBSD.org, andrew@FreeBSD.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, sbruno@FreeBSD.org, melifaro@FreeBSD.org, neel@FreeBSD.org, delphij@FreeBSD.org, adrian@FreeBSD.org, cperciva@FreeBSD.org, marcel@FreeBSD.org Message-ID: <1912950043.6.1411825310296.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1530752109.5.1411812184846.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1530752109.5.1411812184846.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1538 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Sat, 27 Sep 2014 14:01:34 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 13:41:50 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 14:42:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39F816AC for ; Sat, 27 Sep 2014 14:42:00 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E0D5B6F1 for ; Sat, 27 Sep 2014 14:41:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8REfvIG095597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Sep 2014 08:41:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8REfuWX095555; Sat, 27 Sep 2014 08:41:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 27 Sep 2014 08:41:56 -0600 (MDT) From: Warren Block To: "O. Hartmann" Subject: Re: WiFi 802.11/ac PCIe supported adaptor In-Reply-To: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 27 Sep 2014 08:41:57 -0600 (MDT) Cc: freebsd-hardware@freebd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 14:42:00 -0000 On Sat, 27 Sep 2014, O. Hartmann wrote: > > I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to replace it > with an 802.11ac adaptor. > > Since I made very bad experiences with CURRENT and support of modest modern hardware > (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. > > I found this PCIe adaptor card attractive: > > GigaByte Gigabyte GC-WB867D-I > > I can not find ad hoc the WLAN chip used on that specific card, but maybe someone has > experiences with that litte board. Newegg reviews say this is an Intel 7260HMW: http://www.newegg.com/Product/Product.aspx?Item=N82E16813995032&Tpk=N82E16813995032 I don't know if that is supported on FreeBSD yet. PCIe to mini-PCIe adapters like that can be found separately, allowing the use of any mini-PCIe card. I've successfully tested an Atheros AR9280 card in one. From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 14:50:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A518B882; Sat, 27 Sep 2014 14:50:52 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DE2B78E; Sat, 27 Sep 2014 14:50:51 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XXtKc-000Vgm-2u>; Sat, 27 Sep 2014 16:50:42 +0200 Received: from g224249072.adsl.alicedsl.de ([92.224.249.72] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XXtKb-001JrD-Vu>; Sat, 27 Sep 2014 16:50:42 +0200 Date: Sat, 27 Sep 2014 16:50:37 +0200 From: "O. Hartmann" To: Larry Rosenman Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140927165037.15a9607c.ohartman@zedat.fu-berlin.de> In-Reply-To: <65cfbb363809ee6e1078c28390d02603@thebighonker.lerctr.org> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <65cfbb363809ee6e1078c28390d02603@thebighonker.lerctr.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/L6EeeT2OvcSqYkcU30EtBkj"; protocol="application/pgp-signature" X-Originating-IP: 92.224.249.72 X-ZEDAT-Hint: A Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT , owner-freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 14:50:52 -0000 --Sig_/L6EeeT2OvcSqYkcU30EtBkj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 09:21:34 -0500 Larry Rosenman schrieb: > On 2014-09-20 09:10, O. Hartmann wrote: > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > Warren Block schrieb: > >=20 > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > >>=20 > >> > nVidia's BLOB from port x11/nvidia-driver seems to have problems in = FreeBSD > >> > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Len= ovo ThinkPad > >> > Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 = Intel iGPU and > >> > dedicated nVidia GT 740M (Optimus) working correctly. > >>=20 > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > >> extra GPU uses the same display memory and can be enabled to speed up > >> the Intel graphics or disabled for power saving. I don't know if > >> versions where the Nvidia section is a full discrete video adapter=20 > >> that > >> can be used alone are still called "Optimus". > >>=20 > >> Some Optimus owners have reported being able to use the Intel drivers > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > >> disable the Nvidia GPU is not present, some people have reported=20 > >> success > >> with an xorg.conf that uses only the intel driver and ignores the=20 > >> Nvidia > >> hardware. > >=20 > > Thanks Warren. > >=20 > > But this sounds even more frustrating now. I look around the web even > > at Lenovo's support > > forum. Many people report the GT 740M nVidia adaptor as a discrete > > adaptor with Optimus > > technology and everything sounds to me like it can be selected > > exclusively. What you > > describes is that I definitely need to use the HD4600 iGPU on FreeBSD > > in the first place > > since the nVidia hardware is a kind of "appendix" to the HD4600. > >=20 > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't > > work properly: it > > doesn't even start up and loading the "intel" driver complains about a > > missing device - > > preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv > > manner, that this > > HD4600 isn't recodnized by the kernel, either. I do not see any kind > > of vga0: entry in > > the kernel log when enabling "Integrated Graphics" only in the > > laptop's UEFI/Firmware. > > When enabling "nVidia Optimus", a recognized vga0: device shows up. > >=20 > > From my server, equipted with a IvyBridge i3-class CPU with integrated > > iGPU, I even get > > this message from 11.0-CURRENT: > >=20 > > vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x01521849 chip=3D0x015= 28086 > > rev=3D0x09 hdr=3D0x00 > > vendor =3D 'Intel Corporation' > > device =3D 'Xeon E3-1200 v2/3rd Gen Core processor Graphics=20 > > Controller' > > class =3D display > > subclass =3D VGA > > bar [10] =3D type Memory, range 64, base 0xf7800000, size 4194304= ,=20 > > enabled > > bar [18] =3D type Prefetchable Memory, range 64, base 0xe0000000, > > size 268435456, > > enabled bar [20] =3D type I/O Port, range 32, base 0xf000, size 64,=20 > > enabled > > cap 05[90] =3D MSI supports 1 message > > cap 01[d0] =3D powerspec 2 supports D0 D3 current D0 > > cap 13[a4] =3D PCI Advanced Features: FLR TP > >=20 > >=20 > > The very same CURRENT (most recent as I built world on all system=20 > > today) doesn't > > recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems > > impossible to me that people > > can report having this GPU working if even the most recent FreeBSD > > CURRENT doesn't > > recognize it. > for the record, on my Thinkpad W520+Docking Station, I get two HDMI /=20 > DVI outputs off the Nvidia GPU, in addition to the > Intel graphics on the local LCD. This is under Windows, but..... >=20 >=20 Just for the record. Another box, running as a server with CURRENT on-top of a Intel(R) Core(TM)= i3-3220 CPU with Ivy-Bridge HD2500 graphics, crashes/blanks screen when going into grap= hics mode with vt() (having kernel modules drm2 and i915kms already loaded via loader.conf= ). This hardware is now for two years in use and the CPU is much older. The CPU is about to be replaced by a XEON E3-1245 v2 with P4000 iGPU graphi= cs (only). At this moment, I'm highly afraid of having hardware that is not working even = with CURRENT. --Sig_/L6EeeT2OvcSqYkcU30EtBkj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJs7BAAoJEOgBcD7A/5N8Oh8H/0tkOFXpYYgWHynVPQh413pX aGlzC8i88Y64AFFlFd/hfLge5hSgmCBabC9FCpRzMqGq6QXgkvbycybB5bchZESr j/VVQqXjGiafGiMuAa5WhQePoaJaTRWPJ+rshhC17MaXFgSPJ9cLzN7h6ed2z5ce adz5ltkLruEXFh1O5L89eI2R+K1O6fUlKtMI9tj+bE755aOi8yNCWfC1wlxY95p0 DuxuIWeUPJgltg66SotPVWbI9p05eqcS0+3HGSPZW5//Rza9OCmy6Zu+YqtIvWXb rFzc0VfnMNCxgyRhLp9TExasgYLWCLrDN7Ij5KLL+AWLkJdM7z5qJ2s7x+Atcww= =ufS0 -----END PGP SIGNATURE----- --Sig_/L6EeeT2OvcSqYkcU30EtBkj-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 14:55:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB016BA7; Sat, 27 Sep 2014 14:55:55 +0000 (UTC) Received: from m.saper.info (m.saper.info [IPv6:2a01:4f8:a0:7383::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "m.saper.info", Issuer "Marcin Cieslak 2011" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DBBF85D; Sat, 27 Sep 2014 14:55:55 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8REtonL085528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Sep 2014 14:55:52 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1411829752; bh=5EQwMoFa6f5KCK7OeMonWYP6N62LOXn/LQqqv5st8C4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NP6GmA87szsysioK4MHdtjvO5Q1YgDEU158pZ2e6DdgINuIGKzStzD1Rm9DVnciuk crhYEGpjPmrJkfImMx7pOR565r/SmRq1fhALNkc6UvcPY02IfDvf3zVAsA9Migm1l3 GF5No1z2ahhXZiEFwgsKF4WAxQp1vF8u17g/S1Jo= Date: Sat, 27 Sep 2014 14:55:50 +0000 (UTC) From: Marcin Cieslak To: "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT In-Reply-To: <20140927165037.15a9607c.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <65cfbb363809ee6e1078c28390d02603@thebighonker.lerctr.org> <20140927165037.15a9607c.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT , owner-freebsd-current@freebsd.org, Larry Rosenman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 14:55:55 -0000 On Sat, 27 Sep 2014, O. Hartmann wrote: > Am Sat, 20 Sep 2014 09:21:34 -0500 > Just for the record. > > Another box, running as a server with CURRENT on-top of a Intel(R) Core(TM) i3-3220 CPU > with Ivy-Bridge HD2500 graphics, crashes/blanks screen when going into graphics mode with > vt() (having kernel modules drm2 and i915kms already loaded via loader.conf). Seems to be a known problem. Can you try to start X without having i915kms loaded by the third stage loader? This workaround works for me (i915kms gets loaded by X) //Marcin From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 16:17:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF88B10A for ; Sat, 27 Sep 2014 16:17:18 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7795CF99 for ; Sat, 27 Sep 2014 16:17:18 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XXugN-000hI2-LL>; Sat, 27 Sep 2014 18:17:15 +0200 Received: from g224249072.adsl.alicedsl.de ([92.224.249.72] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XXugN-001SVR-J7>; Sat, 27 Sep 2014 18:17:15 +0200 Date: Sat, 27 Sep 2014 18:17:14 +0200 From: "O. Hartmann" To: Warren Block Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-ID: <20140927181714.67692816.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Z7.=unoGS+IutWFPWrSsaRL"; protocol="application/pgp-signature" X-Originating-IP: 92.224.249.72 X-ZEDAT-Hint: A Cc: freebsd-hardware@freebd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 16:17:18 -0000 --Sig_/Z7.=unoGS+IutWFPWrSsaRL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 27 Sep 2014 08:41:56 -0600 (MDT) Warren Block schrieb: > On Sat, 27 Sep 2014, O. Hartmann wrote: >=20 > > > > I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and = want to > > replace it with an 802.11ac adaptor. > > > > Since I made very bad experiences with CURRENT and support of modest mo= dern hardware > > (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. > > > > I found this PCIe adaptor card attractive: > > > > GigaByte Gigabyte GC-WB867D-I > > > > I can not find ad hoc the WLAN chip used on that specific card, but may= be someone has > > experiences with that litte board. >=20 > Newegg reviews say this is an Intel 7260HMW: > http://www.newegg.com/Product/Product.aspx?Item=3DN82E16813995032&Tpk=3DN= 82E16813995032 >=20 > I don't know if that is supported on FreeBSD yet. >=20 > PCIe to mini-PCIe adapters like that can be found separately, allowing=20 > the use of any mini-PCIe card. I've successfully tested an Atheros=20 > AR9280 card in one. Thats a pity. I have already this WiFi adaptor in a Lenovo E540 laptop and = it isn't supported by CURRENT. Some rumours say it is supposed to be supported by iw= l() in the future.=20 --Sig_/Z7.=unoGS+IutWFPWrSsaRL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJuMLAAoJEOgBcD7A/5N8rIMH/iP2+OIr+ApbOlJQabq0/mSo kz0y1tgmU4yLA3e5IF5wDF1tywnOPvLjnPuHwtV7gMqkYv7XTlqGrElUyFi10xSC uT7xKgNKHLMsoaLOZA4RJWayZ25xZ9+Lv/ZwjEE4hZco6X2NArTDARSIv1+SjcBb DLVMItc8Omb5z+0C8uNjIovEuuvgvdl1tfZjbXqpnEEq4CiZctlaxYFjCF4KMLEg icte5qdjanUeX3vp80BDOcufkRcVhNWSJUbiwUzZABWLnLBSEjSpU4kU3deGiD6z fxtZEEBHZytvNOkGwVulFiSutD39tYzmJAeQ2VYUZYfTHjbRNdqZEUirkA3XZwU= =4MHV -----END PGP SIGNATURE----- --Sig_/Z7.=unoGS+IutWFPWrSsaRL-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 22:22:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 770767CC for ; Sat, 27 Sep 2014 22:22:13 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E3ABAAA for ; Sat, 27 Sep 2014 22:22:12 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id AFFAC6A6002; Sun, 28 Sep 2014 00:22:09 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s8RMM9U1021194; Sun, 28 Sep 2014 00:22:09 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s8RMM96f019914; Sun, 28 Sep 2014 00:22:09 +0200 (CEST) (envelope-from lars) Date: Sun, 28 Sep 2014 00:22:09 +0200 From: Lars Engels To: "O. Hartmann" Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-ID: <20140927222208.GA20243@e-new.0x20.net> Mail-Followup-To: Lars Engels , "O. Hartmann" , FreeBSD CURRENT , freebsd-hardware@freebd.org References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p16 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hardware@freebd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 22:22:13 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: >=20 > I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and wa= nt to replace it > with an 802.11ac adaptor. >=20 > Since I made very bad experiences with CURRENT and support of modest mode= rn hardware > (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. >=20 > I found this PCIe adaptor card attractive: >=20 > GigaByte Gigabyte GC-WB867D-I >=20 > I can not find ad hoc the WLAN chip used on that specific card, but maybe= someone has > experiences with that litte board. FreeBSD doensn't support 802.11ac, yet. --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUJziQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tv+UIAKgeRzOI31wPE+LHXn7Y7sN1 CilCjpXKgpwfybcjgDd9XEQO3nLXyAPRbeEWulySkg+g078J95xIOejGJufR9GEp T3nn1gpw+9/CRPcyb5H/AXZTLxy6LfGyong2l+3RiqDTRbdE+zFGeCqHGKSMpgNs 8OMKeqG356opC1380S4Hk6dCtmAUQ+oXi6KShbZE10O0hE8mcSyVRGaEV0gwdVWR 7jJ+8MNQRsA9z+q5F3ZvaoaiUVXIhMhpijDBXSWwM3a3S0VuXU/CnRLNgT0JA9zc zYzDixw/mAOv3EEeJSFnbiHKdxGycYfY4IPu6rZBWqieqqOewt2lluGMVxzSDek= =HTjA -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 23:22:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60DC1F0E; Sat, 27 Sep 2014 23:22:41 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 364ECF26; Sat, 27 Sep 2014 23:22:40 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8RNMo8L073840; Sat, 27 Sep 2014 16:22:56 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8RNMi0A073839; Sat, 27 Sep 2014 16:22:44 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 27 Sep 2014 16:22:44 -0700 (PDT) Message-ID: Date: Sat, 27 Sep 2014 16:22:44 -0700 (PDT) Subject: dmesg seems broken From: "Chris H" To: "freebsd amd64" , "freebsd current" , "freebsd stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 23:22:41 -0000 Greetings, I'm building RELENG_9 recently. I installed, and updated source, last night. I've just built world, and kernel. After (and before) kernel install. I've found I'm missing from 14 to 40 lines from the top of the dmesg(8) output. In either /var/log/messages, and in /var/run/dmesg.boot. Where can I get that information? Where was it sent? Why am I not allowed to view it? Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 23:29:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BC182E2; Sat, 27 Sep 2014 23:29:57 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D1F7F6D; Sat, 27 Sep 2014 23:29:56 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8RNU4I4074495; Sat, 27 Sep 2014 16:30:10 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8RNTxBs074489; Sat, 27 Sep 2014 16:29:59 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sat, 27 Sep 2014 16:29:59 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Sat, 27 Sep 2014 16:29:59 -0700 (PDT) Subject: Re: dmesg seems broken From: "Chris H" To: "Brandon Allbery" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd current , freebsd stable , freebsd amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 23:29:57 -0000 > On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: > >> Where can I get that information? Where was it sent? Why am I >> not allowed to view it? >> > > Sounds to me like the kernel ring buffer is now too small for all the early > boot messages? Odd. I'm only using GENERIC modified to not contain any hardware I'm not using. I've made zero changes to alter buffer(s). As I also mentioned; this too was the case from GENERIC that came on the install media. Thanks for the reply, Brandon. --Chris > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Sep 27 23:24:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5DDD1CE; Sat, 27 Sep 2014 23:24:15 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0941AF51; Sat, 27 Sep 2014 23:24:14 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id z2so1327603wiv.2 for ; Sat, 27 Sep 2014 16:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CAenBsjdh42J9mdaUXmiroC1QPBZMgq9CWLAtAt7TWo=; b=uBEud711i7muAQ35o3pEUvqovrMmuAVobLG4FOu9ugRBljyC4N58m+GjmKgR5Wn1Z1 chHeAlfHH40INqF0++70J7U7zazWeBO99sHqm9fMek611GrbnEG/D0iU6qd08zANPgz7 Ac6EeJ5PtQBY3FFu1NtUdIEVyrteG144wKon2AKT2GzOGF3pwA1tvqRY/yxLN1piZ5Vk qBIln+QmLGQq5jnmopBSCDcL+WpvUdctVy75Wh+T5VcR9rDps1hps5uwaIgIXi4+0tAW jl3ln/juT4veWKISr8S/yQweBzOg6f4ahaJ35ZOMOIP8oMX1tjfJXtKpLRCYM63N+yhv Ei7g== MIME-Version: 1.0 X-Received: by 10.194.142.209 with SMTP id ry17mr34131323wjb.57.1411860253273; Sat, 27 Sep 2014 16:24:13 -0700 (PDT) Received: by 10.217.127.70 with HTTP; Sat, 27 Sep 2014 16:24:13 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Sep 2014 19:24:13 -0400 Message-ID: Subject: Re: dmesg seems broken From: Brandon Allbery To: Chris H X-Mailman-Approved-At: Sat, 27 Sep 2014 23:54:08 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd current , freebsd stable , freebsd amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: 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, 27 Sep 2014 23:24:15 -0000 On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: > Where can I get that information? Where was it sent? Why am I > not allowed to view it? > Sounds to me like the kernel ring buffer is now too small for all the early boot messages? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net