From owner-freebsd-current@freebsd.org Sun Jun 28 15:12:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19C4898F7EA for ; Sun, 28 Jun 2015 15:12:00 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9AB1AF4; Sun, 28 Jun 2015 15:12:00 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9BCC5C95; Sun, 28 Jun 2015 15:11:57 +0000 (UTC) Date: Sun, 28 Jun 2015 15:11:52 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1257120266.55.1435504313039.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1141 - Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 15:12:00 -0000 FreeBSD_HEAD-tests - Build #1141 - Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1141/ to view the results. From owner-freebsd-current@freebsd.org Sun Jun 28 17:48:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A879598F26C; Sun, 28 Jun 2015 17:48:33 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 778E8116A; Sun, 28 Jun 2015 17:48:33 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igblr2 with SMTP id lr2so40036831igb.0; Sun, 28 Jun 2015 10:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=u5RlyckRMUYJ0NAqDnkorW1TG4FoiLwDGI9Pt9lvt/A=; b=S3H2NSPaRVRkZI25O6lr4imusZBbdanKUrYr54iMpHk/q2V+gih65ReKjRrxsDDZet iasgpL8Q5j47FC0oBcohQoaLhZSHaRZgYaV9ZGjVEKQmpRPyrPNJWWg8Oq9G22ZloA6u 3d8q8glGdJhvb9x7Ua9uLgboM6Du7rNEa1UAp2x9uEcpicFucO6DHAVI2ytdsHTOvYc3 Xb9rPk3lwHAmOzLU4mluRQCxEY7lF1QEGYZSnN0P6Pc2p4rY2oI6f5g2BimOUw+IjlTp pxIVqZv1wy1KA1sonLUecnTsGXG5Zh0E+SOpSHPKj8kVw7fl1fd3cWNboq+5bJvyg5kh dUKA== MIME-Version: 1.0 X-Received: by 10.107.129.228 with SMTP id l97mr14834386ioi.32.1435513712907; Sun, 28 Jun 2015 10:48:32 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Sun, 28 Jun 2015 10:48:32 -0700 (PDT) Date: Sun, 28 Jun 2015 10:48:32 -0700 X-Google-Sender-Auth: TwciF3gCPaZJTWAAMnUM7sA0gbw Message-ID: Subject: powerpc and powerpc64 builds broken From: Justin Hibbits To: FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 17:48:33 -0000 Both powerpc and powerpc64 builds are broken in the same way, in usr.bin/mkesdb. It was working correctly as of just before BSDCan, I successfully built world and kernel on June 6. The error seen at this point is: cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc -o mkesdb lex.o yacc.o /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: could not read symbols: Bad value I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. - Justin From owner-freebsd-current@freebsd.org Sun Jun 28 18:36:41 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2936A98F405; Sun, 28 Jun 2015 18:36:41 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8CA31171; Sun, 28 Jun 2015 18:36:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pactm7 with SMTP id tm7so93177021pac.2; Sun, 28 Jun 2015 11:36:40 -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 :content-transfer-encoding:message-id:references:to; bh=BWl6GvSVGg1MFJicVwI9S2YIa+A2UOi8+Kt81uIUe2A=; b=f7aCBaYW1zl84drad2c6H/VydOZozd4hvxk9Bvm1MNSIA/2Yecz1AOFKdLULadmZ/v 473xQpRzT6AEosxCa5xdsJfDK3HhXnfJDUKhKbN7qI8fQxcMRE4xRq9wcyn6PKRWR49L uq46qiUdqKGiVivVP2xYSzDZouS39AB1YUtgNU7+4dOvXqutOauaO9j3gLSfYIcxyFIA PlkkngP/c1bZJLLIiqz8kowqhNuce8Vcgftc0XvPkmK10OAakzOHK/sMmsT21+AvugyA C1BwmEv01c459ddJI2sBWitEUx7QXXV77GhyMaOkotN7N++lFonD0ZpjkiykASzniOan Y1eg== X-Received: by 10.70.119.73 with SMTP id ks9mr13170561pdb.131.1435516600326; Sun, 28 Jun 2015 11:36:40 -0700 (PDT) Received: from [192.168.20.7] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ud3sm39661891pbc.10.2015.06.28.11.36.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jun 2015 11:36:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: powerpc and powerpc64 builds broken From: Garrett Cooper X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Sun, 28 Jun 2015 11:36:38 -0700 Cc: FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> References: To: Justin Hibbits X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 18:36:41 -0000 > On Jun 28, 2015, at 10:48, Justin Hibbits wrote: >=20 > Both powerpc and powerpc64 builds are broken in the same way, in > usr.bin/mkesdb. It was working correctly as of just before BSDCan, I > successfully built world and kernel on June 6. >=20 > The error seen at this point is: >=20 > cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb > -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb > -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv > -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign > -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../= lib/libc > -o mkesdb lex.o yacc.o > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: > undefined reference to symbol `_end' (try adding -lc) > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: > could not read symbols: Bad value >=20 > I've seen this both locally on my G5, and on the Power8 in the FreeBSD clu= ster. - What does file say when you run it on libc.so.7? - What's your current revision? - Does it work when SRCCONF/__MAKECONF are set to /dev/null? Thanks!= From owner-freebsd-current@freebsd.org Sun Jun 28 19:09:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C23C998F882; Sun, 28 Jun 2015 19:09:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85D15203F; Sun, 28 Jun 2015 19:09:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igcsj18 with SMTP id sj18so65132333igc.1; Sun, 28 Jun 2015 12:09:25 -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=xCSdENmHoO9YaObJY7h8vrHL3P1wRkaoEwyRHvZch90=; b=Ho6JSObG84kHZ9m6DayPNGCEsrKzgB9gum8TE5Bb0NP1VmaAL4LvKPZwtEerVSac+r gy1PFEURNpICBKTa3FCeFmXq51ouIAznAQ81qMUlQDVfhVcZYt9n3bnJUEREedpOVcHW jdX+QiQswdwHmGvFTUO0zQUM/Aa6co4HJJZGrhc85WTL0LvA41oie2cFjd9D/moAD6Vm PKw8c9QM8vDjYmsCGYQtyUY+Eo/yG74k/TVnOs6c8zIt/oBd6uTGNmusasEILmXtvMgx Vu/4TiTiFgLdHc9qodIn6G6aW3F0vpNDbrqA69RnoR2ug+GYnFyl2VJ/Afx42+6RHN0z y6AA== MIME-Version: 1.0 X-Received: by 10.42.170.74 with SMTP id e10mr13413350icz.71.1435518565762; Sun, 28 Jun 2015 12:09:25 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Sun, 28 Jun 2015 12:09:25 -0700 (PDT) In-Reply-To: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> Date: Sun, 28 Jun 2015 12:09:25 -0700 X-Google-Sender-Auth: uCoJOiIOlLzkwanWbP7kvuA7BnQ Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Justin Hibbits To: Garrett Cooper Cc: FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 19:09:26 -0000 On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: > >> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: >> >> Both powerpc and powerpc64 builds are broken in the same way, in >> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I >> successfully built world and kernel on June 6. >> >> The error seen at this point is: >> >> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb >> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb >> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv >> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall >> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign >> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc >> -o mkesdb lex.o yacc.o >> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: >> undefined reference to symbol `_end' (try adding -lc) >> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: >> could not read symbols: Bad value >> >> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. > > - What does file say when you run it on libc.so.7? /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, not stripped > - What's your current revision? r284893 > - Does it work when SRCCONF/__MAKECONF are set to /dev/null? No, the problem remains. > > Thanks! - Justin From owner-freebsd-current@freebsd.org Sun Jun 28 19:19:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C48C98FAAA for ; Sun, 28 Jun 2015 19:19:47 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3672E25C4; Sun, 28 Jun 2015 19:19:47 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 622CED22; Sun, 28 Jun 2015 19:19:45 +0000 (UTC) Date: Sun, 28 Jun 2015 19:19:44 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <706039240.57.1435519184205.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1257120266.55.1435504313039.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1257120266.55.1435504313039.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1142 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 19:19:47 -0000 FreeBSD_HEAD-tests - Build #1142 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1142/ to view the results. From owner-freebsd-current@freebsd.org Sun Jun 28 19:32:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F5E898FD71; Sun, 28 Jun 2015 19:32:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 319152B60; Sun, 28 Jun 2015 19:32:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5SJWNW2007285 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 28 Jun 2015 22:32:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5SJWNW2007285 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5SJWMSZ007284; Sun, 28 Jun 2015 22:32:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 28 Jun 2015 22:32:22 +0300 From: Konstantin Belousov To: Justin Hibbits Cc: Garrett Cooper , FreeBSD Current , FreeBSD PowerPC ML Subject: Re: powerpc and powerpc64 builds broken Message-ID: <20150628193222.GP2080@kib.kiev.ua> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> 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=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 19:32:33 -0000 On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: > On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: > > > >> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: > >> > >> Both powerpc and powerpc64 builds are broken in the same way, in > >> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I > >> successfully built world and kernel on June 6. > >> > >> The error seen at this point is: > >> > >> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb > >> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb > >> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv > >> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > >> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > >> -Wold-style-definition -Wno-pointer-sign > >> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc > >> -o mkesdb lex.o yacc.o > >> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: > >> undefined reference to symbol `_end' (try adding -lc) > >> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: > >> could not read symbols: Bad value > >> > >> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. > > > > - What does file say when you run it on libc.so.7? > > /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, > 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, > not stripped I think a libc linker could try for that command line lives in /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so or in /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so But, the reason for your troubles seems to come from the usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point to objdir/.../libc, I have no idea. > > > - What's your current revision? > > r284893 > > > - Does it work when SRCCONF/__MAKECONF are set to /dev/null? > > No, the problem remains. > > > > > Thanks! > > - Justin > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Jun 28 20:33:25 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2AF398F597; Sun, 28 Jun 2015 20:33:25 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (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 64E571101; Sun, 28 Jun 2015 20:33:24 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id t5SKWjX2081954; Sun, 28 Jun 2015 22:33:06 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <559059ED.80104@fgznet.ch> Date: Sun, 28 Jun 2015 22:32:45 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov , Justin Hibbits CC: Garrett Cooper , FreeBSD Current , FreeBSD PowerPC ML Subject: Re: powerpc and powerpc64 builds broken References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> In-Reply-To: <20150628193222.GP2080@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 20:33:26 -0000 On 28.06.15 21:32, Konstantin Belousov wrote: > On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: >> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: >>> >>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: >>>> >>>> Both powerpc and powerpc64 builds are broken in the same way, in >>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I >>>> successfully built world and kernel on June 6. >>>> >>>> The error seen at this point is: >>>> >>>> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv >>>> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall >>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >>>> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >>>> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >>>> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >>>> -Wold-style-definition -Wno-pointer-sign >>>> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc >>>> -o mkesdb lex.o yacc.o >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: >>>> undefined reference to symbol `_end' (try adding -lc) >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: >>>> could not read symbols: Bad value >>>> >>>> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. >>> >>> - What does file say when you run it on libc.so.7? >> >> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, >> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, >> not stripped > I think a libc linker could try for that command line lives in > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so > or in > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so > > But, the reason for your troubles seems to come from the > usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point > to objdir/.../libc, I have no idea. Neither me. Here with this mods it compiles: Either: --- Makefile (revision 284911) +++ Makefile (working copy) @@ -3,7 +3,7 @@ .PATH: ${.CURDIR}/../../lib/libc/iconv PROG= mkesdb -LDFLAGS+= -L${.OBJDIR}/../../lib/libc +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc NO_WMISSING_VARIABLE_DECLARATIONS= Or: Index: Makefile =================================================================== --- Makefile (revision 284911) +++ Makefile (working copy) @@ -3,7 +3,7 @@ .PATH: ${.CURDIR}/../../lib/libc/iconv PROG= mkesdb -LDFLAGS+= -L${.OBJDIR}/../../lib/libc +LDFLAGS+= -L${.CURDIR}/../../lib/libc NO_WMISSING_VARIABLE_DECLARATIONS= Andreas From owner-freebsd-current@freebsd.org Sun Jun 28 22:53:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F4A398FD10; Sun, 28 Jun 2015 22:53:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D990114BE; Sun, 28 Jun 2015 22:53:32 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id BB23F25D3891; Sun, 28 Jun 2015 22:53:28 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id EA41DC76FE2; Sun, 28 Jun 2015 22:53:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id icpsIrF5DfSE; Sun, 28 Jun 2015 22:53:26 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:6581:7ae0:f735:4b0f] (unknown [IPv6:fde9:577b:c1a9:4410:6581:7ae0:f735:4b0f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 53692C76FE0; Sun, 28 Jun 2015 22:53:24 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: powerpc and powerpc64 builds broken From: "Bjoern A. Zeeb" In-Reply-To: Date: Sun, 28 Jun 2015 22:52:52 +0000 Cc: FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> To: Justin Hibbits X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 22:53:33 -0000 > On 28 Jun 2015, at 19:09 , Justin Hibbits = wrote: >=20 > On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper = wrote: >>=20 >>> On Jun 28, 2015, at 10:48, Justin Hibbits = wrote: >>>=20 >>> Both powerpc and powerpc64 builds are broken in the same way, in >>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, = I >>> successfully built world and kernel on June 6. >>>=20 >>> The error seen at this point is: >>=20 >> - What does file say when you run it on libc.so.7? >=20 > /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, > 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, > not stripped >=20 >> - What's your current revision? >=20 > r284893 >=20 >> - Does it work when SRCCONF/__MAKECONF are set to /dev/null? >=20 > No, the problem remains. I have not see this problem in my endless tinderbox run; I know the crossbuilds succeeded with r284913. =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend." From owner-freebsd-current@freebsd.org Sun Jun 28 22:59:31 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4095998FD8B; Sun, 28 Jun 2015 22:59:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DD491646; Sun, 28 Jun 2015 22:59:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcur8 with SMTP id ur8so24091506igc.0; Sun, 28 Jun 2015 15:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qc71xw1UiBgf8+UHCApLyL/un9TOU1yy0CffLRNd4fc=; b=KlNKx9r2FZPityjkXqmDNsRFcSxmw6xQhqeXP2451h3xS0HYVkn0PSVhnN2hAEnjSh yhWdmk6KDi1/JoQvtQ9eNzlkBew4Mm1ObgHU49pzhkysBnTD+vh9XMTqGadIBQcl1gEL STXFJenURftSsvR3jsCdXJX+H5E3cbTZ+Gz9lckPojLkj4fO10M+F9wPyJn3HSJODe4S D+lYgZ7QFS1cX3B+kXRlXxf512uTcu2i+c6ht5QJZ/BzyXbyX1vGN3dky7x+Dpt6zOFh RrC6EqtNitDQwhrcV8U/JGLqvu8b7Vrx86OhS1Uu6JTLi5p8QAdg3WEgbNgyyjAkLi7K T4YA== MIME-Version: 1.0 X-Received: by 10.50.79.129 with SMTP id j1mr11343356igx.32.1435532370538; Sun, 28 Jun 2015 15:59:30 -0700 (PDT) Received: by 10.36.38.133 with HTTP; Sun, 28 Jun 2015 15:59:30 -0700 (PDT) In-Reply-To: References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> Date: Sun, 28 Jun 2015 15:59:30 -0700 Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Adrian Chadd To: "Bjoern A. Zeeb" Cc: Justin Hibbits , FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 28 Jun 2015 22:59:31 -0000 On 28 June 2015 at 15:52, Bjoern A. Zeeb w= rote: > >> On 28 Jun 2015, at 19:09 , Justin Hibbits wrote: >> >> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper = wrote: >>> >>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote= : >>>> >>>> Both powerpc and powerpc64 builds are broken in the same way, in >>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I >>>> successfully built world and kernel on June 6. >>>> >>>> The error seen at this point is: >>> >>> - What does file say when you run it on libc.so.7? >> >> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, >> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, >> not stripped >> >>> - What's your current revision? >> >> r284893 >> >>> - Does it work when SRCCONF/__MAKECONF are set to /dev/null? >> >> No, the problem remains. > > I have not see this problem in my endless tinderbox run; > I know the crossbuilds succeeded with r284913. Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit that doesn't. (powerpc64 runs fine in qemu-devel; people should try it!) -adrian > > > =E2=80=94 > Bjoern A. Zeeb Charles Haddon Spurgeon: > "Friendship is one of the sweetest joys of life. Many might have failed > beneath the bitterness of their trial had they not found a friend." > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jun 29 03:32:25 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91E1198F833; Mon, 29 Jun 2015 03:32:25 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 520BD195B; Mon, 29 Jun 2015 03:32:25 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igrv9 with SMTP id v9so32426683igr.1; Sun, 28 Jun 2015 20:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FuSisPRAN+dbXaYrmFUBWvjqmRped7LtdvQ/epuO07U=; b=JkipCTJjKomE0Kf3wz5L3nSe5cSt2rNPeOWBcgOKEHZ09bxOcu107Hx4oMlvZGDtDI kHMwUhwXfcXaVND8c9N8R6K6qK2s0N4yAbRjwYU1d72/EHUUxhzly5wdhS3AtTmvjFTG JofcXQxa83k+cJePOlTwRkJ5b5JVXDEYXwyunL7dprCgIWiQHyCUvo3WsmJ0bmnJbPO+ b0Uv2rgMR43FeR4A/hNIRf/TSaAT+ZxtUP7rYaEWKzXgMAuFkvkjmYb5cAyxQv8uQW+c jA4lgZGMEHt8kSi81srNKanHzEi4yLNyzt6y+5Bgk1Rf+icSfAU4gpNwRrWJ1NeAMqIZ Gqzw== MIME-Version: 1.0 X-Received: by 10.42.170.74 with SMTP id e10mr14757900icz.71.1435548744698; Sun, 28 Jun 2015 20:32:24 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Sun, 28 Jun 2015 20:32:24 -0700 (PDT) In-Reply-To: References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> Date: Sun, 28 Jun 2015 20:32:24 -0700 X-Google-Sender-Auth: EVvBVW-yUSrVxierEISihzRWZTE Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Justin Hibbits To: Adrian Chadd Cc: "Bjoern A. Zeeb" , FreeBSD Current , FreeBSD PowerPC ML , "sjg@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 03:32:25 -0000 On Sun, Jun 28, 2015 at 3:59 PM, Adrian Chadd wrote: > On 28 June 2015 at 15:52, Bjoern A. Zeeb wrote: >> >>> On 28 Jun 2015, at 19:09 , Justin Hibbits wrote: >>> >>> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: >>>> >>>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: >>>>> >>>>> Both powerpc and powerpc64 builds are broken in the same way, in >>>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I >>>>> successfully built world and kernel on June 6. >>>>> >>>>> The error seen at this point is: >>>> >>>> - What does file say when you run it on libc.so.7? >>> >>> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, >>> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, >>> not stripped >>> >>>> - What's your current revision? >>> >>> r284893 >>> >>>> - Does it work when SRCCONF/__MAKECONF are set to /dev/null? >>> >>> No, the problem remains. >> >> I have not see this problem in my endless tinderbox run; >> I know the crossbuilds succeeded with r284913. > > Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit > that doesn't. > > (powerpc64 runs fine in qemu-devel; people should try it!) r284345 (introduction of metamode) is the problem. I bisected it on the power8 and it reliably fails this way. Andreas tested it on his G4 (32-bit hardware) and it worked fine, so there's something introduced that just doesn't like powerpc64. - Justin From owner-freebsd-current@freebsd.org Mon Jun 29 05:33:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02A8198DB10; Mon, 29 Jun 2015 05:33:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 79B97166C; Mon, 29 Jun 2015 05:33:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5T5Wn65047358 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 08:32:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5T5Wn65047358 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5T5Wn9C047357; Mon, 29 Jun 2015 08:32:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 29 Jun 2015 08:32:48 +0300 From: Konstantin Belousov To: Andreas Tobler Cc: Justin Hibbits , Garrett Cooper , FreeBSD Current , FreeBSD PowerPC ML Subject: Re: powerpc and powerpc64 builds broken Message-ID: <20150629053248.GQ2080@kib.kiev.ua> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> <559059ED.80104@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559059ED.80104@fgznet.ch> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 05:33:17 -0000 On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote: > On 28.06.15 21:32, Konstantin Belousov wrote: > > On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: > >> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: > >>> > >>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: > >>>> > >>>> Both powerpc and powerpc64 builds are broken in the same way, in > >>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I > >>>> successfully built world and kernel on June 6. > >>>> > >>>> The error seen at this point is: > >>>> > >>>> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb > >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb > >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv > >>>> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > >>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > >>>> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > >>>> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > >>>> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > >>>> -Wold-style-definition -Wno-pointer-sign > >>>> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc > >>>> -o mkesdb lex.o yacc.o > >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: > >>>> undefined reference to symbol `_end' (try adding -lc) > >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: > >>>> could not read symbols: Bad value > >>>> > >>>> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. > >>> > >>> - What does file say when you run it on libc.so.7? > >> > >> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, > >> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, > >> not stripped > > I think a libc linker could try for that command line lives in > > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so > > or in > > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so > > > > But, the reason for your troubles seems to come from the > > usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point > > to objdir/.../libc, I have no idea. > > > Neither me. > > Here with this mods it compiles: > > Either: > > --- Makefile (revision 284911) > +++ Makefile (working copy) > @@ -3,7 +3,7 @@ > .PATH: ${.CURDIR}/../../lib/libc/iconv > > PROG= mkesdb > -LDFLAGS+= -L${.OBJDIR}/../../lib/libc > +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc > > NO_WMISSING_VARIABLE_DECLARATIONS= > > > Or: > > Index: Makefile > =================================================================== > --- Makefile (revision 284911) > +++ Makefile (working copy) > @@ -3,7 +3,7 @@ > .PATH: ${.CURDIR}/../../lib/libc/iconv > > PROG= mkesdb > -LDFLAGS+= -L${.OBJDIR}/../../lib/libc > +LDFLAGS+= -L${.CURDIR}/../../lib/libc > > NO_WMISSING_VARIABLE_DECLARATIONS= No, I mean that LDFLAGS explicitely listing supposed location for libc is wrong, too much wrong. If mkesd is special, it might need to become a bootstrap tool. But the hackery above is too fragile and it is surprising that it went unnoticed for such long time (after the citrus enablement). From owner-freebsd-current@freebsd.org Mon Jun 29 08:33:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2272098D040; Mon, 29 Jun 2015 08:33:49 +0000 (UTC) (envelope-from julian@freebsd.org) 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 D99F42C28; Mon, 29 Jun 2015 08:33:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-104.lns20.per4.internode.on.net [121.45.252.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5T8Xb1M088031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2015 01:33:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <559102DB.4050902@freebsd.org> Date: Mon, 29 Jun 2015 16:33:31 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "hackers@freebsd.org" , freebsd-current Subject: libc compile failure with new syscall. Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 08:33:49 -0000 Hi all, At $JOB we have a few extra syscalls that we have added to our kernel. After generating the new sysent files in /sys/kern, libc fails to compile with: ===> lib/libc (obj,depend,all,install) building shared library libc.so.7 [...] /usr/bin/ld: rlk_check_offline.So: relocation R_X86_64_32 against `SYS_rlk_check_offline' can not be used when making a shared object; recompile with -fPIC rlk_check_offline.So: could not read symbols: Bad value *** [libc.so.7] Error code 1 this suggests that the code that generates the libc syscall stubs is generating something the linker doesn't like. the definition of the syscall is: 588 AUE_NULL NOSTD { int rlk_check_offline(char *localfs, char *path, \ int *is_offline, int rlk_flags, \ int *cache_status); } ------ which generates (in various files): { AS(rlk_check_offline_args), (sy_call_t *)lkmressys, AUE_NULL, NULL, 0, 0, 0, SY_THR_ABSENT }, /* 588 = rlk_check_offline */ ------ "rlk_check_offline", /* 588 = rlk_check_offline */ ------ /* rlk_check_offline */ case 588: { struct rlk_check_offline_args *p = params; uarg[0] = (intptr_t) p->localfs; /* char * */ uarg[1] = (intptr_t) p->path; /* char * */ uarg[2] = (intptr_t) p->is_offline; /* int * */ iarg[3] = p->rlk_flags; /* int */ uarg[4] = (intptr_t) p->cache_status; /* int * */ *n_args = 5; break; } ------- #define SYS_rlk_check_offline 588 ------- struct rlk_check_offline_args { char localfs_l_[PADL_(char *)]; char * localfs; char localfs_r_[PADR_(char *)]; char path_l_[PADL_(char *)]; char * path; char path_r_[PADR_(char *)]; char is_offline_l_[PADL_(int *)]; int * is_offline; char is_offline_r_[PADR_(int *)]; char rlk_flags_l_[PADL_(int)]; int rlk_flags; char rlk_flags_r_[PADR_(int)]; char cache_status_l_[PADL_(int *)]; int * cache_status; char cache_status_r_[PADR_(int *)]; }; int sys_rlk_check_offline(struct thread *, struct rlk_check_offline_args *); #define SYS_AUE_rlk_check_offline AUE_NULL ------- the generated stub looks like: $ cat /usr/obj/usr/src/lib/libc/rlk_check_offline.S #include "compat.h" #include "SYS.h" RSYSCALL(rlk_check_offline) .section .note.GNU-stack,"",%progbits -------- nothing in this definition looks special, So I'm surprised that the libc build doesn't like it. This is a (just) post 10.1 10-stable. But we plan to move to 11 soon too. Any suggestions as to what I should change would be greatly appreciated.. I'm running out of ideas. From owner-freebsd-current@freebsd.org Mon Jun 29 08:43:27 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7E6298D294; Mon, 29 Jun 2015 08:43:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 742C610D8; Mon, 29 Jun 2015 08:43:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5T8hGfr091821 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 11:43:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5T8hGfr091821 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5T8hGct091820; Mon, 29 Jun 2015 11:43:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 29 Jun 2015 11:43:16 +0300 From: Konstantin Belousov To: Julian Elischer Cc: "hackers@freebsd.org" , freebsd-current Subject: Re: libc compile failure with new syscall. Message-ID: <20150629084316.GS2080@kib.kiev.ua> References: <559102DB.4050902@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559102DB.4050902@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 08:43:27 -0000 On Mon, Jun 29, 2015 at 04:33:31PM +0800, Julian Elischer wrote: > Hi all, > > At $JOB we have a few extra syscalls that we have added to our kernel. > > After generating the new sysent files in /sys/kern, libc fails to > compile with: > > ===> lib/libc (obj,depend,all,install) > building shared library libc.so.7 > [...] > /usr/bin/ld: rlk_check_offline.So: relocation R_X86_64_32 against > `SYS_rlk_check_offline' can not be used when making a shared object; > recompile with -fPIC > rlk_check_offline.So: could not read symbols: Bad value > *** [libc.so.7] Error code 1 > > this suggests that the code that generates the libc syscall stubs is > generating something the linker doesn't like. No, this suggests that the symbol SYS_rlk_check_offline was undefined when assembling your rlk_check_offline.S. Check the way you generated the stuff from syscalls.master. Most likely, sys/sys/syscall.h update was lost. > > > the definition of the syscall is: > > 588 AUE_NULL NOSTD { int rlk_check_offline(char *localfs, > char *path, \ > int *is_offline, int rlk_flags, \ > int *cache_status); } > ------ > which generates (in various files): > { AS(rlk_check_offline_args), (sy_call_t *)lkmressys, > AUE_NULL, NULL, 0, 0, 0, SY_THR_ABSENT }, /* 588 = rlk_check_offline */ > ------ > "rlk_check_offline", /* 588 = > rlk_check_offline */ > ------ > /* rlk_check_offline */ > case 588: { > struct rlk_check_offline_args *p = params; > uarg[0] = (intptr_t) p->localfs; /* char * */ > uarg[1] = (intptr_t) p->path; /* char * */ > uarg[2] = (intptr_t) p->is_offline; /* int * */ > iarg[3] = p->rlk_flags; /* int */ > uarg[4] = (intptr_t) p->cache_status; /* int * */ > *n_args = 5; > break; > } > ------- > #define SYS_rlk_check_offline 588 ^^^^^ This must be seen by asm. Note that in the stock sources, lib/libc/amd64/SYS.h includes syscall.h. > ------- > struct rlk_check_offline_args { > char localfs_l_[PADL_(char *)]; char * localfs; char > localfs_r_[PADR_(char *)]; > char path_l_[PADL_(char *)]; char * path; char > path_r_[PADR_(char *)]; > char is_offline_l_[PADL_(int *)]; int * is_offline; char > is_offline_r_[PADR_(int *)]; > char rlk_flags_l_[PADL_(int)]; int rlk_flags; char > rlk_flags_r_[PADR_(int)]; > char cache_status_l_[PADL_(int *)]; int * cache_status; char > cache_status_r_[PADR_(int *)]; > }; > int sys_rlk_check_offline(struct thread *, struct > rlk_check_offline_args *); > #define SYS_AUE_rlk_check_offline AUE_NULL > > ------- > > > > the generated stub looks like: > $ cat /usr/obj/usr/src/lib/libc/rlk_check_offline.S > > #include "compat.h" > #include "SYS.h" > RSYSCALL(rlk_check_offline) > .section .note.GNU-stack,"",%progbits > > -------- > > > nothing in this definition looks special, So I'm surprised that the > libc build doesn't like it. > This is a (just) post 10.1 10-stable. But we plan to move to 11 soon too. > > Any suggestions as to what I should change would be greatly > appreciated.. I'm running out of ideas. > > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Jun 29 09:04:12 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EAE598C59C; Mon, 29 Jun 2015 09:04:12 +0000 (UTC) (envelope-from julian@freebsd.org) 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 19BE310D9; Mon, 29 Jun 2015 09:04:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-104.lns20.per4.internode.on.net [121.45.252.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5T947gZ088144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2015 02:04:10 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55910A01.60206@freebsd.org> Date: Mon, 29 Jun 2015 17:04:01 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "hackers@freebsd.org" , freebsd-current Subject: Re: libc compile failure with new syscall. References: <559102DB.4050902@freebsd.org> In-Reply-To: <559102DB.4050902@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 09:04:12 -0000 On 6/29/15 4:33 PM, Julian Elischer wrote: > Hi all, > > At $JOB we have a few extra syscalls that we have added to our kernel. > > After generating the new sysent files in /sys/kern, libc fails to > compile with: > > ===> lib/libc (obj,depend,all,install) > building shared library libc.so.7 > [...] > /usr/bin/ld: rlk_check_offline.So: relocation R_X86_64_32 against > `SYS_rlk_check_offline' can not be used when making a shared object; > recompile with -fPIC > rlk_check_offline.So: could not read symbols: Bad value > *** [libc.so.7] Error code 1 > > this suggests that the code that generates the libc syscall stubs is > generating something the linker doesn't like. > > > the definition of the syscall is: > > 588 AUE_NULL NOSTD { int rlk_check_offline(char > *localfs, char *path, \ > int *is_offline, int rlk_flags, \ > int *cache_status); } > ------ > which generates (in various files): > { AS(rlk_check_offline_args), (sy_call_t *)lkmressys, > AUE_NULL, NULL, 0, 0, 0, SY_THR_ABSENT }, /* 588 = rlk_check_offline */ > ------ > "rlk_check_offline", /* 588 = > rlk_check_offline */ > ------ > /* rlk_check_offline */ > case 588: { > struct rlk_check_offline_args *p = params; > uarg[0] = (intptr_t) p->localfs; /* char * */ > uarg[1] = (intptr_t) p->path; /* char * */ > uarg[2] = (intptr_t) p->is_offline; /* int * */ > iarg[3] = p->rlk_flags; /* int */ > uarg[4] = (intptr_t) p->cache_status; /* int * */ > *n_args = 5; > break; > } > ------- > #define SYS_rlk_check_offline 588 > ------- > struct rlk_check_offline_args { > char localfs_l_[PADL_(char *)]; char * localfs; char > localfs_r_[PADR_(char *)]; > char path_l_[PADL_(char *)]; char * path; char > path_r_[PADR_(char *)]; > char is_offline_l_[PADL_(int *)]; int * is_offline; char > is_offline_r_[PADR_(int *)]; > char rlk_flags_l_[PADL_(int)]; int rlk_flags; char > rlk_flags_r_[PADR_(int)]; > char cache_status_l_[PADL_(int *)]; int * cache_status; char > cache_status_r_[PADR_(int *)]; > }; > int sys_rlk_check_offline(struct thread *, struct > rlk_check_offline_args *); > #define SYS_AUE_rlk_check_offline AUE_NULL > > ------- > > > > the generated stub looks like: > $ cat /usr/obj/usr/src/lib/libc/rlk_check_offline.S > > #include "compat.h" > #include "SYS.h" > RSYSCALL(rlk_check_offline) > .section .note.GNU-stack,"",%progbits > > -------- > > > nothing in this definition looks special, So I'm surprised that the > libc build doesn't like it. > This is a (just) post 10.1 10-stable. But we plan to move to 11 soon > too. > > Any suggestions as to what I should change would be greatly > appreciated.. I'm running out of ideas. Having looked at it I'm guessing it's to do with the NOSTD , which generates lkmressys and RSYSCALL which generates the code, but I'm still not seeing the part that causes the error. I will admit my understanding of the linking process is not extensive. I do have other syscall that are NOSTD and do not give the error. > > > > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Mon Jun 29 10:14:09 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1A7098FD71; Mon, 29 Jun 2015 10:14:09 +0000 (UTC) (envelope-from julian@freebsd.org) 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 7D8B01A90; Mon, 29 Jun 2015 10:14:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-252-104.lns20.per4.internode.on.net [121.45.252.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5TADxgv088656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2015 03:14:02 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55911A65.9090600@freebsd.org> Date: Mon, 29 Jun 2015 18:13:57 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: "hackers@freebsd.org" , freebsd-current Subject: Re: libc compile failure with new syscall. References: <559102DB.4050902@freebsd.org> <20150629084316.GS2080@kib.kiev.ua> In-Reply-To: <20150629084316.GS2080@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 10:14:09 -0000 On 6/29/15 4:43 PM, Konstantin Belousov wrote: > On Mon, Jun 29, 2015 at 04:33:31PM +0800, Julian Elischer wrote: >> Hi all, >> >> At $JOB we have a few extra syscalls that we have added to our kernel. >> >> After generating the new sysent files in /sys/kern, libc fails to >> compile with: >> >> ===> lib/libc (obj,depend,all,install) >> building shared library libc.so.7 >> [...] >> /usr/bin/ld: rlk_check_offline.So: relocation R_X86_64_32 against >> `SYS_rlk_check_offline' can not be used when making a shared object; >> recompile with -fPIC >> rlk_check_offline.So: could not read symbols: Bad value >> *** [libc.so.7] Error code 1 >> >> this suggests that the code that generates the libc syscall stubs is >> generating something the linker doesn't like. > No, this suggests that the symbol SYS_rlk_check_offline was undefined > when assembling your rlk_check_offline.S. > > Check the way you generated the stuff from syscalls.master. Most likely, > sys/sys/syscall.h update was lost. /sys/sys/syscall.h: #define SYS_pz_openat_ex 587 #define SYS_rlk_check_offline 588 <---- #define SYS_MAXSYSCALL 589 as shown below.. > >> >> the definition of the syscall is: >> >> 588 AUE_NULL NOSTD { int rlk_check_offline(char *localfs, >> char *path, \ >> int *is_offline, int rlk_flags, \ >> int *cache_status); } >> ------ >> which generates (in various files): >> { AS(rlk_check_offline_args), (sy_call_t *)lkmressys, >> AUE_NULL, NULL, 0, 0, 0, SY_THR_ABSENT }, /* 588 = rlk_check_offline */ >> ------ >> "rlk_check_offline", /* 588 = >> rlk_check_offline */ >> ------ >> /* rlk_check_offline */ >> case 588: { >> struct rlk_check_offline_args *p = params; >> uarg[0] = (intptr_t) p->localfs; /* char * */ >> uarg[1] = (intptr_t) p->path; /* char * */ >> uarg[2] = (intptr_t) p->is_offline; /* int * */ >> iarg[3] = p->rlk_flags; /* int */ >> uarg[4] = (intptr_t) p->cache_status; /* int * */ >> *n_args = 5; >> break; >> } >> ------- >> #define SYS_rlk_check_offline 588 > ^^^^^ This must be seen by asm. > > Note that in the stock sources, lib/libc/amd64/SYS.h includes syscall.h. and it does here too.. otherwise all the other syscalls would fail.... hmmm wonder if I need to install the new one into /usr/include/sys/first. ah that's it I'm doing "make libraries" and it requires the new syscall.h to be in /usr/include. thanks for that.. now for the next problem... > >> ------- >> struct rlk_check_offline_args { >> char localfs_l_[PADL_(char *)]; char * localfs; char >> localfs_r_[PADR_(char *)]; >> char path_l_[PADL_(char *)]; char * path; char >> path_r_[PADR_(char *)]; >> char is_offline_l_[PADL_(int *)]; int * is_offline; char >> is_offline_r_[PADR_(int *)]; >> char rlk_flags_l_[PADL_(int)]; int rlk_flags; char >> rlk_flags_r_[PADR_(int)]; >> char cache_status_l_[PADL_(int *)]; int * cache_status; char >> cache_status_r_[PADR_(int *)]; >> }; >> int sys_rlk_check_offline(struct thread *, struct >> rlk_check_offline_args *); >> #define SYS_AUE_rlk_check_offline AUE_NULL >> >> ------- >> >> >> >> the generated stub looks like: >> $ cat /usr/obj/usr/src/lib/libc/rlk_check_offline.S >> >> #include "compat.h" >> #include "SYS.h" >> RSYSCALL(rlk_check_offline) >> .section .note.GNU-stack,"",%progbits >> >> -------- >> >> >> nothing in this definition looks special, So I'm surprised that the >> libc build doesn't like it. >> This is a (just) post 10.1 10-stable. But we plan to move to 11 soon too. >> >> Any suggestions as to what I should change would be greatly >> appreciated.. I'm running out of ideas. >> >> >> >> >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Jun 29 11:31:17 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 502F498FDC9; Mon, 29 Jun 2015 11:31:17 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09FA41E74; Mon, 29 Jun 2015 11:31:16 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1Z9WxH-0004pm-VA; Mon, 29 Jun 2015 13:10:28 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1Z9WxI-0006i4-2Y; Mon, 29 Jun 2015 13:10:28 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Mon, 29 Jun 2015 11:10:28 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "freebsd-current" CC: "current" Subject: "proper way" or "unworkable idea" ? Date: Mon, 29 Jun 2015 04:10:28 -0700 (PDT) X-Mailer: RMM6 Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 11:31:17 -0000 If I've a spare /mnt/usr/src , it seems buildworld quite soon fails, where it otherwise may succeed in /usr/src. Any CLI parameters = or=20 the build system is hardcoded enough so that there will always be problems?= =20 From owner-freebsd-current@freebsd.org Mon Jun 29 23:58:12 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3EDF98F4A5; Mon, 29 Jun 2015 23:58:11 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC5172412; Mon, 29 Jun 2015 23:58:11 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igrv9 with SMTP id v9so40238928igr.1; Mon, 29 Jun 2015 16:58:11 -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=pkTAehlFilclZtTXoqAg5W14KIChE+O9rkmo8zH2PJA=; b=H/w2XC5I00hP9fRwvndARkp3/XTGfPOZ4lViLOyWnjZ4egMtkKNlQ6NE9A2P2K12Qe WBD9UAybGCUv/NYpl3aKW2PKxsDjL0MMNPBg9FEzMTIFknm1Bk61g/2JO45dbYzv+GG0 0E+uxj8Y9Xi9rG5vRUnVSshsvdA0pDbhMtlIBRyWYy8p/SmtQZaCcUiOIaZqEdS89A7v 7wd3jLgaNYRXKmLHFvS/qVWyc1OGFZtW0CGAw122s5w97xL4vOZDl2u7ciNo+ejVIBRZ yRHM2g5mY3s/3EKcTHOnmQ/dQzjcmMVzMhAZXPAwjxT03hJRQVQ+1BE2qMb+9RyA10Rb VUNw== MIME-Version: 1.0 X-Received: by 10.42.170.74 with SMTP id e10mr20453765icz.71.1435622291216; Mon, 29 Jun 2015 16:58:11 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Mon, 29 Jun 2015 16:58:11 -0700 (PDT) In-Reply-To: <20150629053248.GQ2080@kib.kiev.ua> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> <559059ED.80104@fgznet.ch> <20150629053248.GQ2080@kib.kiev.ua> Date: Mon, 29 Jun 2015 16:58:11 -0700 X-Google-Sender-Auth: 25NJ8VbXkpxY4i1gVSOCQ_rMyVQ Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Justin Hibbits To: Konstantin Belousov Cc: Andreas Tobler , Garrett Cooper , FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 29 Jun 2015 23:58:12 -0000 On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov wrote: > On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote: >> On 28.06.15 21:32, Konstantin Belousov wrote: >> > On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: >> >> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: >> >>> >> >>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: >> >>>> >> >>>> Both powerpc and powerpc64 builds are broken in the same way, in >> >>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I >> >>>> successfully built world and kernel on June 6. >> >>>> >> >>>> The error seen at this point is: >> >>>> >> >>>> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb >> >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb >> >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv >> >>>> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall >> >>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> >>>> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> >>>> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> >>>> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> >>>> -Wold-style-definition -Wno-pointer-sign >> >>>> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc >> >>>> -o mkesdb lex.o yacc.o >> >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: >> >>>> undefined reference to symbol `_end' (try adding -lc) >> >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: >> >>>> could not read symbols: Bad value >> >>>> >> >>>> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. >> >>> >> >>> - What does file say when you run it on libc.so.7? >> >> >> >> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, >> >> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, >> >> not stripped >> > I think a libc linker could try for that command line lives in >> > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so >> > or in >> > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so >> > >> > But, the reason for your troubles seems to come from the >> > usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point >> > to objdir/.../libc, I have no idea. >> >> >> Neither me. >> >> Here with this mods it compiles: >> >> Either: >> >> --- Makefile (revision 284911) >> +++ Makefile (working copy) >> @@ -3,7 +3,7 @@ >> .PATH: ${.CURDIR}/../../lib/libc/iconv >> >> PROG= mkesdb >> -LDFLAGS+= -L${.OBJDIR}/../../lib/libc >> +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc >> >> NO_WMISSING_VARIABLE_DECLARATIONS= >> >> >> Or: >> >> Index: Makefile >> =================================================================== >> --- Makefile (revision 284911) >> +++ Makefile (working copy) >> @@ -3,7 +3,7 @@ >> .PATH: ${.CURDIR}/../../lib/libc/iconv >> >> PROG= mkesdb >> -LDFLAGS+= -L${.OBJDIR}/../../lib/libc >> +LDFLAGS+= -L${.CURDIR}/../../lib/libc >> >> NO_WMISSING_VARIABLE_DECLARATIONS= > > No, I mean that LDFLAGS explicitely listing supposed location for libc > is wrong, too much wrong. If mkesd is special, it might need to become > a bootstrap tool. But the hackery above is too fragile and it is surprising > that it went unnoticed for such long time (after the citrus enablement). Would anyone object to me simply removing that line? This fixes the build on powerpc64, and I highly doubt it would impact any other build. - Justin From owner-freebsd-current@freebsd.org Tue Jun 30 03:43:33 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C083990CFB for ; Tue, 30 Jun 2015 03:43:33 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3DECB1C48; Tue, 30 Jun 2015 03:43:33 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1CED4122; Tue, 30 Jun 2015 03:43:26 +0000 (UTC) Date: Tue, 30 Jun 2015 03:43:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <909601584.60.1435635801559.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1148 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 03:43:33 -0000 FreeBSD_HEAD-tests - Build #1148 - Failure: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1148/ to view the results. From owner-freebsd-current@freebsd.org Tue Jun 30 04:05:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB0CF990FAA; Tue, 30 Jun 2015 04:05:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DB1412D7; Tue, 30 Jun 2015 04:05:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igblr2 with SMTP id lr2so66681556igb.0; Mon, 29 Jun 2015 21: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=tHXT1L2sq+WjzVC5B6zm1/+OQQygUYkwdZtCiE1YIwU=; b=L/KVyFajbSg8Ch06rTzZiQJCrrnTy0uG2SIbD39z35oW4eK0sSVIF+Ejui9TgmWqKi gzg0E+IRZs14uVRmXUIKg+0ivkNAzQDnvpXNNXT/XfJIyagbnIQaOesP6o8ZtuXLYoF+ TxLPasrCFdqggYjDaJjYU1TC6V19woZmZATA6O8K/2SWGkbDK3txfH1XfwuniPztfovf mU7A/PleH8+TpALBmKM2oxtqyWGGkIKXliXBcnM5fnx6t/Rc5ZNAIJJg7I/DdnRsNH9n CckzSxrrH/UGm5r9e9Jwpm7rRHQaVDPIRQ0EV+DBqPYoZoMFCJWlJeyBpENevDPBuE40 V96A== MIME-Version: 1.0 X-Received: by 10.42.226.8 with SMTP id iu8mr22848417icb.17.1435637126029; Mon, 29 Jun 2015 21:05:26 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Mon, 29 Jun 2015 21:05:25 -0700 (PDT) In-Reply-To: References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> <559059ED.80104@fgznet.ch> <20150629053248.GQ2080@kib.kiev.ua> Date: Mon, 29 Jun 2015 21:05:25 -0700 X-Google-Sender-Auth: GM0n6Je48Ut9lKo1LFHMbgW9tRw Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Justin Hibbits To: Konstantin Belousov Cc: Andreas Tobler , Garrett Cooper , FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 04:05:26 -0000 On Mon, Jun 29, 2015 at 4:58 PM, Justin Hibbits wrote: > On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov > wrote: >> On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote: >>> On 28.06.15 21:32, Konstantin Belousov wrote: >>> > On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: >>> >> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: >>> >>> >>> >>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: >>> >>>> >>> >>>> Both powerpc and powerpc64 builds are broken in the same way, in >>> >>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I >>> >>>> successfully built world and kernel on June 6. >>> >>>> >>> >>>> The error seen at this point is: >>> >>>> >>> >>>> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb >>> >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb >>> >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv >>> >>>> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall >>> >>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >>> >>>> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >>> >>>> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >>> >>>> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >>> >>>> -Wold-style-definition -Wno-pointer-sign >>> >>>> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc >>> >>>> -o mkesdb lex.o yacc.o >>> >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: >>> >>>> undefined reference to symbol `_end' (try adding -lc) >>> >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: >>> >>>> could not read symbols: Bad value >>> >>>> >>> >>>> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. >>> >>> >>> >>> - What does file say when you run it on libc.so.7? >>> >> >>> >> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, >>> >> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, >>> >> not stripped >>> > I think a libc linker could try for that command line lives in >>> > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so >>> > or in >>> > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so >>> > >>> > But, the reason for your troubles seems to come from the >>> > usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point >>> > to objdir/.../libc, I have no idea. >>> >>> >>> Neither me. >>> >>> Here with this mods it compiles: >>> >>> Either: >>> >>> --- Makefile (revision 284911) >>> +++ Makefile (working copy) >>> @@ -3,7 +3,7 @@ >>> .PATH: ${.CURDIR}/../../lib/libc/iconv >>> >>> PROG= mkesdb >>> -LDFLAGS+= -L${.OBJDIR}/../../lib/libc >>> +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc >>> >>> NO_WMISSING_VARIABLE_DECLARATIONS= >>> >>> >>> Or: >>> >>> Index: Makefile >>> =================================================================== >>> --- Makefile (revision 284911) >>> +++ Makefile (working copy) >>> @@ -3,7 +3,7 @@ >>> .PATH: ${.CURDIR}/../../lib/libc/iconv >>> >>> PROG= mkesdb >>> -LDFLAGS+= -L${.OBJDIR}/../../lib/libc >>> +LDFLAGS+= -L${.CURDIR}/../../lib/libc >>> >>> NO_WMISSING_VARIABLE_DECLARATIONS= >> >> No, I mean that LDFLAGS explicitely listing supposed location for libc >> is wrong, too much wrong. If mkesd is special, it might need to become >> a bootstrap tool. But the hackery above is too fragile and it is surprising >> that it went unnoticed for such long time (after the citrus enablement). > > Would anyone object to me simply removing that line? This fixes the > build on powerpc64, and I highly doubt it would impact any other > build. > > - Justin A universe build on the cluster passed, I'm nuking it. - Justin From owner-freebsd-current@freebsd.org Tue Jun 30 05:43:56 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC6AA990BDD; Tue, 30 Jun 2015 05:43:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 7246016F2; Tue, 30 Jun 2015 05:43:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5U5hmGJ015151 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jun 2015 08:43:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5U5hmGJ015151 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5U5hmtH015150; Tue, 30 Jun 2015 08:43:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 Jun 2015 08:43:48 +0300 From: Konstantin Belousov To: Justin Hibbits Cc: Andreas Tobler , Garrett Cooper , FreeBSD Current , FreeBSD PowerPC ML Subject: Re: powerpc and powerpc64 builds broken Message-ID: <20150630054348.GX2080@kib.kiev.ua> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> <559059ED.80104@fgznet.ch> <20150629053248.GQ2080@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=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 05:43:56 -0000 On Mon, Jun 29, 2015 at 09:05:25PM -0700, Justin Hibbits wrote: > On Mon, Jun 29, 2015 at 4:58 PM, Justin Hibbits wrote: > > On Sun, Jun 28, 2015 at 10:32 PM, Konstantin Belousov > > wrote: > >> On Sun, Jun 28, 2015 at 10:32:45PM +0200, Andreas Tobler wrote: > >>> On 28.06.15 21:32, Konstantin Belousov wrote: > >>> > On Sun, Jun 28, 2015 at 12:09:25PM -0700, Justin Hibbits wrote: > >>> >> On Sun, Jun 28, 2015 at 11:36 AM, Garrett Cooper wrote: > >>> >>> > >>> >>>> On Jun 28, 2015, at 10:48, Justin Hibbits wrote: > >>> >>>> > >>> >>>> Both powerpc and powerpc64 builds are broken in the same way, in > >>> >>>> usr.bin/mkesdb. It was working correctly as of just before BSDCan, I > >>> >>>> successfully built world and kernel on June 6. > >>> >>>> > >>> >>>> The error seen at this point is: > >>> >>>> > >>> >>>> cc -O2 -pipe -I/home/chmeee/freebsd/head/usr.bin/mkesdb > >>> >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../mkesdb > >>> >>>> -I/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc/iconv > >>> >>>> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > >>> >>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > >>> >>>> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > >>> >>>> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > >>> >>>> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > >>> >>>> -Wold-style-definition -Wno-pointer-sign > >>> >>>> -L/home/chmeee/world/zhabar/home/chmeee/freebsd/head/usr.bin/mkesdb/../../lib/libc > >>> >>>> -o mkesdb lex.o yacc.o > >>> >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/usr/bin/ld: > >>> >>>> undefined reference to symbol `_end' (try adding -lc) > >>> >>>> /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so.7: > >>> >>>> could not read symbols: Bad value > >>> >>>> > >>> >>>> I've seen this both locally on my G5, and on the Power8 in the FreeBSD cluster. > >>> >>> > >>> >>> - What does file say when you run it on libc.so.7? > >>> >> > >>> >> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit MSB shared object, > >>> >> 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), dynamically linked, > >>> >> not stripped > >>> > I think a libc linker could try for that command line lives in > >>> > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/lib/libc/libc.so > >>> > or in > >>> > /home/chmeee/world/zhabar/home/chmeee/freebsd/head/tmp/lib/libc.so > >>> > > >>> > But, the reason for your troubles seems to come from the > >>> > usr.bin/mkesdb/Makefile. Why does it explicitely adds LDFLAGS to point > >>> > to objdir/.../libc, I have no idea. > >>> > >>> > >>> Neither me. > >>> > >>> Here with this mods it compiles: > >>> > >>> Either: > >>> > >>> --- Makefile (revision 284911) > >>> +++ Makefile (working copy) > >>> @@ -3,7 +3,7 @@ > >>> .PATH: ${.CURDIR}/../../lib/libc/iconv > >>> > >>> PROG= mkesdb > >>> -LDFLAGS+= -L${.OBJDIR}/../../lib/libc > >>> +LDFLAGS+= -L${.OBJDIR}/../../lib/libc/libc > >>> > >>> NO_WMISSING_VARIABLE_DECLARATIONS= > >>> > >>> > >>> Or: > >>> > >>> Index: Makefile > >>> =================================================================== > >>> --- Makefile (revision 284911) > >>> +++ Makefile (working copy) > >>> @@ -3,7 +3,7 @@ > >>> .PATH: ${.CURDIR}/../../lib/libc/iconv > >>> > >>> PROG= mkesdb > >>> -LDFLAGS+= -L${.OBJDIR}/../../lib/libc > >>> +LDFLAGS+= -L${.CURDIR}/../../lib/libc > >>> > >>> NO_WMISSING_VARIABLE_DECLARATIONS= > >> > >> No, I mean that LDFLAGS explicitely listing supposed location for libc > >> is wrong, too much wrong. If mkesd is special, it might need to become > >> a bootstrap tool. But the hackery above is too fragile and it is surprising > >> that it went unnoticed for such long time (after the citrus enablement). > > > > Would anyone object to me simply removing that line? This fixes the > > build on powerpc64, and I highly doubt it would impact any other > > build. > > > > - Justin > > A universe build on the cluster passed, I'm nuking it. Fine with me. I think trying to understand why the hack was added is not possible. From owner-freebsd-current@freebsd.org Tue Jun 30 06:37:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E69169902E8 for ; Tue, 30 Jun 2015 06:37:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB0AA1E0B for ; Tue, 30 Jun 2015 06:37:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t5U6atsS081235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2015 23:36:55 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t5U6ason081234; Mon, 29 Jun 2015 23:36:54 -0700 (PDT) (envelope-from jmg) Date: Mon, 29 Jun 2015 23:36:54 -0700 From: John-Mark Gurney To: Jeffrey Bouquet Cc: freebsd-current Subject: Re: "proper way" or "unworkable idea" ? Message-ID: <20150630063654.GV96349@funkthat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 29 Jun 2015 23:36:55 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 06:37:02 -0000 Jeffrey Bouquet wrote this message on Mon, Jun 29, 2015 at 04:10 -0700: > If I've a spare /mnt/usr/src , it seems buildworld quite > soon fails, where it otherwise may succeed in /usr/src. Any CLI parameters or > the build system is hardcoded enough so that there will always be problems? Doing a buildworld from a source tree not located in /usr/src works and I do it all the time... There is nothing special, simple buildworld just works... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Tue Jun 30 08:11:08 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5EBC9905E5 for ; Tue, 30 Jun 2015 08:11:08 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (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 B59EB1D08; Tue, 30 Jun 2015 08:11:08 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id t5U89twu056570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Jun 2015 01:09:55 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id t5U89sH1056569; Tue, 30 Jun 2015 01:09:54 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08307; Tue, 30 Jun 15 00:12:23 PDT Date: Tue, 30 Jun 2015 00:12:21 -0700 From: perryh@pluto.rain.com (Perry Hutchison) To: kostikbel@gmail.com, jhibbits@freebsd.org Cc: yaneurabeya@gmail.com, freebsd-current@freebsd.org, andreast-list@fgznet.ch Subject: Re: powerpc and powerpc64 builds broken Message-Id: <55924155.C5CZ0z4FGBeLJpUa%perryh@pluto.rain.com> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> <559059ED.80104@fgznet.ch> <20150629053248.GQ2080@kib.kiev.ua> <20150630054348.GX2080@kib.kiev.ua> In-Reply-To: <20150630054348.GX2080@kib.kiev.ua> User-Agent: nail 11.25 7/29/05 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.20 Precedence: 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, 30 Jun 2015 08:11:08 -0000 Konstantin Belousov wrote: > I think trying to understand why the hack was added is not > possible. In an ideal world, "svn blame" would identify the commit in which it was added, and that commit's log entry would explain why :) From owner-freebsd-current@freebsd.org Tue Jun 30 12:24:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 190DA990DC3 for ; Tue, 30 Jun 2015 12:24:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 BD1371AAE for ; Tue, 30 Jun 2015 12:24:45 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-f796f6d000005314-b4-55928a8bb276 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 00.4B.21268.B8A82955; Tue, 30 Jun 2015 08:24:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t5UCOgtI025785; Tue, 30 Jun 2015 08:24:43 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5UCOee3030760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Jun 2015 08:24:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t5UCOeaQ002115; Tue, 30 Jun 2015 08:24:40 -0400 (EDT) Date: Tue, 30 Jun 2015 08:24:39 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Bouquet cc: freebsd-current Subject: Re: "proper way" or "unworkable idea" ? In-Reply-To: <20150630063654.GV96349@funkthat.com> Message-ID: References: <20150630063654.GV96349@funkthat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6notvdNSnU4McVcYs5bz4wWXz98JXZ gcljxqf5LB7XX3YyBjBFcdmkpOZklqUW6dslcGXsOruUteAZa8WySw8YGxjPsXQxcnJICJhI vJ39kBXCFpO4cG89WxcjF4eQwGImiY2LnzJBOBsZJVqmr2CEcA4xSdxffo4VwmlglJj6/TJY P4uAtsTGhwsZQWw2ARWJmW82soHYIgL6Es9u7gOzmQUMJV6uu8cOYgsLGEhMXX6FGcTmFDCS WNh8GSzOK+Ao8b7nLNgcIYFoickXO8BuFRXQkVi9fwoLRI2gxMmZT1ggZmpJLJ++jWUCo+As JKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW6KWmlG5iBAUrpyTvDsZ3B5UO MQpwMCrx8CY8nRgqxJpYVlyZe4hRkoNJSZR3S+6kUCG+pPyUyozE4oz4otKc1OJDjBIczEoi vD1NQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQneZZ1AjYJFqemp FWmZOSUIaSYOTpDhPEDDXUFqeIsLEnOLM9Mh8qcYdTkW/Li9lkmIJS8/L1VKnFcVpEgApCij NA9uDizJvGIUB3pLmNcJpIoHmKDgJr0CWsIEtOSlPdiSkkSElFQDo07Zt4M3G3ZfV/tYkuvz 8G7XyfOmD85L3Xg0Y9f9Qzp8T2z+1xfvMj491cXzoV83E+8KvYXsuRcrcl+r7p/sWbHvunvE +2h3tSduwcui7i5g2Vf7N8M6Zd05OznRz4cY5CtP7BNTMVp0S9JG6mSy6alet90v93F/tJoi JrzLjpXbNPbLRaG6XCWW4oxEQy3mouJEAEEg2moNAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 12:24:47 -0000 On Tue, 30 Jun 2015, John-Mark Gurney wrote: > Jeffrey Bouquet wrote this message on Mon, Jun 29, 2015 at 04:10 -0700: > > If I've a spare /mnt/usr/src , it seems buildworld quite > > soon fails, where it otherwise may succeed in /usr/src. Any CLI parameters or > > the build system is hardcoded enough so that there will always be problems? > > Doing a buildworld from a source tree not located in /usr/src works > and I do it all the time... There is nothing special, simple > buildworld just works... Indeed. There is a slight catch if you want to perform installworld and the upgrade procedure from that location, namely that the -m argument to mergemaster is needed, but the buildworld itself just works. -Ben Kaduk From owner-freebsd-current@freebsd.org Tue Jun 30 12:28:45 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26AE2990E91 for ; Tue, 30 Jun 2015 12:28:45 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 18B021D90; Tue, 30 Jun 2015 12:28:45 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C853F23A; Tue, 30 Jun 2015 12:28:43 +0000 (UTC) Date: Tue, 30 Jun 2015 12:28:41 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <2051173247.63.1435667322267.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <909601584.60.1435635801559.JavaMail.jenkins@jenkins-9.freebsd.org> References: <909601584.60.1435635801559.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1149 - Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 12:28:45 -0000 FreeBSD_HEAD-tests - Build #1149 - Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1149/ to view the results. From owner-freebsd-current@freebsd.org Tue Jun 30 14:05:23 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A5D698E348 for ; Tue, 30 Jun 2015 14:05:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F57D1BF4 for ; Tue, 30 Jun 2015 14:05:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by ieqy10 with SMTP id y10so12991385ieq.0 for ; Tue, 30 Jun 2015 07:05:22 -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=Qz8efxFS4vQ7+dxJlbdB5eRWroHoAwGLIiB+q7QjEEk=; b=yXog0CodAwID7tDk4wjKOCQBOZss6AKgFolNWPLNnygds2/GRlQZPY0uWjB83i6i+p Kn2mKNniizth1clm8VkPZ8xuScJFqDRdDc6zJh8kUHZjIT97bn3KCpXiE1l7eHKgiPEk ecSiL9mMOltQydpO8kH4B1UvGWambOfHrvlzisBHDnx1xMViTYTfPmaNFNmwDvZ+/3Sj 7t5iKFavrmk9YCbCnK23j3vS3A7gCrZXCEwprbaL6usQNPDlZnGGSsM2kd0vYFlOLH/9 0NpkhBy92WYDkjDjH/F7JaZIbz7P93Oao6hkGjDMWMuCE/HH1r191SC/Fj76ikztRVr7 btbQ== MIME-Version: 1.0 X-Received: by 10.107.134.16 with SMTP id i16mr30296727iod.6.1435673122579; Tue, 30 Jun 2015 07:05:22 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Tue, 30 Jun 2015 07:05:22 -0700 (PDT) Received: by 10.36.69.80 with HTTP; Tue, 30 Jun 2015 07:05:22 -0700 (PDT) In-Reply-To: <55924155.C5CZ0z4FGBeLJpUa%perryh@pluto.rain.com> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <20150628193222.GP2080@kib.kiev.ua> <559059ED.80104@fgznet.ch> <20150629053248.GQ2080@kib.kiev.ua> <20150630054348.GX2080@kib.kiev.ua> <55924155.C5CZ0z4FGBeLJpUa%perryh@pluto.rain.com> Date: Tue, 30 Jun 2015 07:05:22 -0700 X-Google-Sender-Auth: nmCoEwfs9DRelEtgmdJ5W5-prgI Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Justin Hibbits To: Perry Hutchison Cc: Garrett Cooper , Konstantin Belousov , andreast-list@fgznet.ch, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 14:05:23 -0000 On Jun 30, 2015 1:11 AM, "Perry Hutchison" wrote: > > Konstantin Belousov wrote: > > > I think trying to understand why the hack was added is not > > possible. > > In an ideal world, "svn blame" would identify the commit in which > it was added, and that commit's log entry would explain why :) The line existed from the beginning. My guess is to bootstrap on non-iconv freebsd. As Konstantin said, though, it's very fragile. -Justin From owner-freebsd-current@freebsd.org Tue Jun 30 16:15:05 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 190D298DA3D; Tue, 30 Jun 2015 16:15:05 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4DB02555; Tue, 30 Jun 2015 16:15:04 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igcsj18 with SMTP id sj18so111138631igc.1; Tue, 30 Jun 2015 09:15: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=W6pHeoUK0wuJDdHmYy2etMZ9gKcVLFfDYuVhacnBmq4=; b=tV0Xrk8SCdO/2jjYRS0OCTGCCPqPmo8UbLdHpLVZFbHtJS5wv2LBMOvFmd3FbyOEQl +fKycgHoMACo8o4piRr1cCWmNNAZR0rLQcQPJZ6LGFfzpmScFT8R1bnxUJt0C7VRnpPb ZqqtY/tINOlN0k4sUn1GGnwfd4ABnOljXliuP5Oh39vsKv4qokD9kuURPDSTiKRHh3yk MsV34iyOjFZ4Azy9uFpL43/1TngNtYaY+ROiyxga5qJWZASUnO8xOUgcGxNagAd6sdtv Ue4OKTstZhEgg/Tktu16PqVnrx+jmQNbXzXoldqcXciUBp1LTsVsfzivR7eYmsqpeXNB LkLQ== MIME-Version: 1.0 X-Received: by 10.50.61.241 with SMTP id t17mr25679385igr.34.1435680904158; Tue, 30 Jun 2015 09:15:04 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.69.80 with HTTP; Tue, 30 Jun 2015 09:15:04 -0700 (PDT) In-Reply-To: <21894.1435679323@chaos> References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> <21894.1435679323@chaos> Date: Tue, 30 Jun 2015 09:15:04 -0700 X-Google-Sender-Auth: -Uqm8jRsYCQXar2k-Y1ZcBvNU68 Message-ID: Subject: Re: powerpc and powerpc64 builds broken From: Justin Hibbits To: "Simon J. Gerraty" Cc: Adrian Chadd , "Bjoern A. Zeeb" , FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 16:15:05 -0000 On Tue, Jun 30, 2015 at 8:48 AM, Simon J. Gerraty wrote: > Justin Hibbits wrote: >> > Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit >> > that doesn't. >> > >> > (powerpc64 runs fine in qemu-devel; people should try it!) >> >> r284345 (introduction of metamode) is the problem. I bisected it on >> the power8 and it reliably fails this way. Andreas tested it on his >> G4 (32-bit hardware) and it worked fine, so there's something >> introduced that just doesn't like powerpc64. > > Hmm, didn't touch usr.bin/mkesdb so must be something indirect. > Is this with[out] NO_CLEAN ? Tried it both ways, with the same result. I don't think metamode necessarily is the cause of the problem, merely unmasking the latent problem. Though I've committed a fix for this, it would still be nice to understand what in r284345 exposed this. - Justin From owner-freebsd-current@freebsd.org Tue Jun 30 15:51:12 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96D7098D558; Tue, 30 Jun 2015 15:51:12 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0148.outbound.protection.outlook.com [157.56.111.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 498731AE8; Tue, 30 Jun 2015 15:51:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0035.namprd05.prod.outlook.com (10.255.226.35) by BLUPR05MB772.namprd05.prod.outlook.com (10.141.209.27) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 30 Jun 2015 15:50:38 +0000 Received: from BN1AFFO11FD053.protection.gbl (2a01:111:f400:7c10::139) by BL2PR05CA0035.outlook.office365.com (2a01:111:e400:c04::35) with Microsoft SMTP Server (TLS) id 15.1.201.16 via Frontend Transport; Tue, 30 Jun 2015 15:50:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD053.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Tue, 30 Jun 2015 15:50:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jun 2015 08:48:45 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t5UFmiD59102; Tue, 30 Jun 2015 08:48:44 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id CDD03580AA; Tue, 30 Jun 2015 08:48:43 -0700 (PDT) To: Justin Hibbits CC: Adrian Chadd , "Bjoern A. Zeeb" , FreeBSD Current , FreeBSD PowerPC ML Subject: Re: powerpc and powerpc64 builds broken In-Reply-To: References: <8C09575A-B885-4F41-BFF8-46FEC028E755@gmail.com> Comments: In-reply-to: Justin Hibbits message dated "Sun, 28 Jun 2015 20:32:24 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 30 Jun 2015 08:48:43 -0700 Message-ID: <21894.1435679323@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD053; 1:LwbSuEzGGQRSvCDU2qCwByUyIrlAqGYx8+gVYAYf4hAJPZFb0TSh5KP6s7n2M/v7il/96Pn7RrQJuvfakXG/gbZDb9ZYCyTtxjUbEdHNFDSGQKRuF9exqJPrjHeYeKRFd7A5fwnXcH9m78fLnZz0qPe9mLANmzwhpzRV7LT9/MUAxD1bWnO4pUaEpDzDZDhbZAkTp0Qczz3fT/2f1IO74of1IMOtY22mfhKo0RlCaOpHSpumHxKJsbJVQ9Rloji8JsJzMya84CNC/EFQwy8MhA== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(51704005)(189002)(199003)(24454002)(77156002)(117636001)(62966003)(92566002)(6806004)(50226001)(46102003)(86362001)(87936001)(50986999)(76176999)(105596002)(48376002)(50466002)(33716001)(57986006)(19580395003)(19580405001)(76506005)(106466001)(93886004)(5001960100002)(47776003)(2950100001)(110136002)(189998001)(77096005)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB772; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB772; 2:U9qVckiWIr0Yx1DTSs2CBg8orlnSoxR0wk3kT4KCgAGE7JmZfhYH/bVUQ2KJzo9d; 3:vTJmwr6i9qw+4faZSn9EuBHD8bfu8RUoXiXeeqUYrCBYNrtGSYULui9zxCJXdAJNMtg5WEreiPedjCaDqJQXHWIVZkINEauGhalLWxxjzGieCBo2ivlt6RAaxm5y+2IOMTd7lZ1bITeiC5Rng0TSkheloasWeE412c1kW7v60YoizoSSltG1Vnw8j8UPnZ3xZW9MoiqAErsKMiMxR/kS6nTmqNV1tCpj9DTc0ZwCa5s=; 20:JF2/vJp+V7IDid8nLI7myDgt7+8jBc8COEzvFK9mbQf3iKhOSyO4GHHzZMj5r8IeG35CS8MvIpJG2an7kz8RSSCgEtX38OYVO/u3aRJhmbA6vhEdn7paYg0u30CoD5q10x1HTwvzOLQQc5i3tiyPTQUrr8DfGgCiS8MuHQ1qy0+3fvOBngnYLAbq96rQyo+q5NEaDur92Tprd/0aBz3GdHdI97oWIExIEYPIOs4gK6pV2lw6muzbBFv2oceioiYeKKClSTw+fZ5MzRrEKKtLHQVdIw41tEvA5vxmMLDciazShYmnA6HowCoTovOxKy821vXf9RVjl8DTVlS3ckcOFm34R+RM9iVTyEcAg9xcNucv4Tf0OkqJRHFYb4feWzKIivtSpI166mPrKJvEyMyo9l8O8VvEhQh8x+3Vy6SfcLZSRM1CMKkGEJD0YQ78tlgNJrUXJC4wP+4EfEu/pylxAORZQxBv3fYxz8BM3S718EK0Gxby5QnV2R0/v1gyuXUs X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB772; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB772; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB772; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB772; 4:Cs6N5TMMP0SbdA1eGUbS+UksgWnn77D5qqdiKZon2fhfOl8QEJ/tDEJlqjA91QFZ9A5PsvV65PiWP8NZ4PMyWeqO52feg/wtEcy+BzPpX9VqXz6Gzo6LlH02J+OnmZJUOUSwIdhzQgdSER8j+9SRdVLrVUWlhPv7ljHfo+Mu2sit3kd3Pbh2PxiamZfaebKOFb0gYBWtwFVNNyVD9TZVaeCaN6AC22rBZlYG4+YP1mAmg58c6FGVRKkXRful2RKEw6hzX/rIdhE3+B69Ko4f8C+Q926nOKlSxBj6iXatLEo= X-Forefront-PRVS: 06237E4555 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB772; 23:0tWrgIKqKDITP32wtz/YJu6a6N7JVQqIDsdiW2jXC8zdyCaAMMrAnJzFsiTB9q9HhnNhKMiUK8RtstcI4EBeMXMBUhQXcVmJHeok9Mei5bI3hadrPj05Y/RDZ0Z4DQLxlSoQAtu4aKvat2dZYAFuqaKa9JL2uQilO4O39bO1Ps6acLxnWEm6uKuYqNPcM3s5JF/dd60T9vlbz4ZI8AORSR3JwwpQh+Pwntj9TaMVYYNlnKm0cqXPoGnvyru346YvzLFMkCyfBaCJlN2iI7yqmgY+FBrc9tgF+3PkjpZEXFW6BWaqYBLKRh3rnfd7/KGYIqeT+9kMbcu3Sjy6xE4dsyS5ZoktEyi9x3fs7trD9llw8CgicnV0t9UOdeK+VUAS6jBten5b4G5tkDwv9J3xCMcMbvkOzOGUGAXrTsQHs7nySdeuCPJZtVVZv55HK0nyr+2dKXCCAVsNvMTW15yS6EnTdtdP8zg8segIO9PcM721P7N1SF6JSEyKtZtI1Itu7g2PsgtcAwOrDuDEY/52bSIIRA1CE3rcZnKq7kKdvJobLWpR8R46uGT4VSf8JyFBVqZn7CEdGiu3IiVZO7H8MgVmho7bZQqAFPjHVb6yAyFfvKXx6qj5wTMVRSD4sY/4ws5ZPUEuTX1PGggtS0DeVSL5uSA0eOI0PzslGJoi4Yw/VlzmG9NRS0kl0/5A8DcFAXglLttGNcCCEdeY/dBxUNorDOZCE+ZprXa7pJcEPZpkYIZsFI8onuX71L+MA437HFu17f++/u/0Bd5FqpG7I6DYAi6HvtFrcIJiGSCxhZwTS65ORojH5lilqJr5vU/keOovMQCu9jIhQki6rIjOfPOgkg37ZobcrcCgYBB9UdoQ5zUfAnteYwh2E20SKClMqbBv160glIY4Kd4ErhGBkk4Nd0wuats4eYBKgV5tHfU= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB772; 5:fUXaSFcYILKnqdYQM+Seifild5T7Hl1qi5yUj0XLPdR9Z8geDJ7OF3JPfLd0idDkmUeWI8W1b2ObwmcpYZpohA4cVxVamqL3nMxGg8Nk8tNjPxlB5UjTXmpLnkl/v8shXr7EtHbyXh5RkLBgeDIPlQ==; 24:Ee4arpgDJZM1lvFex9qEU7oOp81jtvmEr7i6TOGuLiJzBjoDFp7ZWLFAjsA/QTsz/86Lakw37kTUxSSAhHcF4g71kd1s2nC7aJSUoGA/Ko0=; 20:PvE5ZKNk0f2sp1ao/qyDUeJVMEKI7QvKNO/t6/up4JF8lCd8TSL0ADQN8qOSu/LBbGaGe/mYRFhJAvH8vub9Sg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2015 15:50:35.8809 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB772 X-Mailman-Approved-At: Tue, 30 Jun 2015 16:40:37 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 15:51:12 -0000 Justin Hibbits wrote: > > Yeah, crossbuilds work fine. It's the actual run-on-real-hardware bit > > that doesn't. > > > > (powerpc64 runs fine in qemu-devel; people should try it!) > > r284345 (introduction of metamode) is the problem. I bisected it on > the power8 and it reliably fails this way. Andreas tested it on his > G4 (32-bit hardware) and it worked fine, so there's something > introduced that just doesn't like powerpc64. Hmm, didn't touch usr.bin/mkesdb so must be something indirect. Is this with[out] NO_CLEAN ? From owner-freebsd-current@freebsd.org Tue Jun 30 16:09:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A63C98D8CD; Tue, 30 Jun 2015 16:09:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43A6221EA; Tue, 30 Jun 2015 16:09:36 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BLUPR05CA0057.namprd05.prod.outlook.com (10.141.20.27) by DM2PR05MB781.namprd05.prod.outlook.com (10.141.179.139) with Microsoft SMTP Server (TLS) id 15.1.201.16; Tue, 30 Jun 2015 15:35:13 +0000 Received: from BY2FFO11FD032.protection.gbl (2a01:111:f400:7c0c::140) by BLUPR05CA0057.outlook.office365.com (2a01:111:e400:855::27) with Microsoft SMTP Server (TLS) id 15.1.201.16 via Frontend Transport; Tue, 30 Jun 2015 15:35:13 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BY2FFO11FD032.mail.protection.outlook.com (10.1.14.210) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Tue, 30 Jun 2015 15:35:12 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jun 2015 08:32:30 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t5UFWTD52722; Tue, 30 Jun 2015 08:32:29 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id DE50D580AA; Tue, 30 Jun 2015 08:32:28 -0700 (PDT) To: CC: freebsd-current , current Subject: Re: "proper way" or "unworkable idea" ? In-Reply-To: References: Comments: In-reply-to: Jeffrey Bouquet message dated "Mon, 29 Jun 2015 04:10:28 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 30 Jun 2015 08:32:28 -0700 Message-ID: <20845.1435678348@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD032; 1:0WGEz6KvGAeTkNtAdiF9Vf6a0FlToxH7FRafWTSVNUg54TfbD1/k7zr5c9x0LIxAMImgqQrXBxgx/YpwebGP7H4+AaFo7vEGw9Gdw7emeZeYTSmo+0futtPZSrOvu+oLkn1yiFUI1h/za/8FbXdQtkPlKpY4MazLhi3y7aim3D+3AQFeXIl4qQGMPuQkbb/A0mJ5knCNTNMKGup6Jzvdkcd2E3VGj7Wq/QIjJwpcSBx+O+wnx0sj3KIm39h6DRUkga2eDDtvT8FBlKy3lQhSjA5Xn0gfi/rvmr3+xfB41wmNS7IF9jGgVl9t2rtIl87+ X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(24454002)(189002)(199003)(48376002)(106466001)(87936001)(76176999)(50986999)(62966003)(77156002)(19580395003)(19580405001)(117636001)(33716001)(86362001)(47776003)(6806004)(105596002)(2351001)(46102003)(57986006)(76506005)(92566002)(189998001)(2950100001)(110136002)(5001960100002)(77096005)(50466002)(50226001)(62816006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB781; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 2:VIJ1iFXdK4CtMnTDbL4KjQsRNWyN/1TdxygvZlvUqYBoHH/VNBcWvRseis9op0Tv; 3:e04vh7FSXCzMHNcPz+YAasP3WcTV7jZwFBJoEi7B48T+GDL78k32CF+2EGlKwfIkMgiAZsA48RjRxAu6pj+U97q16EUOkMX/wphx+kgEklZr5QJIRRY51agAsc9StLS0R62+CPnh/4+qdoYJgCLnP3FtcKzWk5/ydAVywL4n1GbSrMtu2nUM124mxZ846OMQGR6aZnyVxyoupuGJeJtHehgBw5tV/Vwobi41PZN4m9M=; 25:b+vBbU24ccFQ7XGESx5oYs+VK38VrthctA2HAxOjevm6BD/ldft08IZswabHfmHYvrS9bu8mm4TehT4r8fSBbW7IzOvKpe8Hg+RHxqOnSTFMbVsdy0S7V6B/LGSlrTOdauYnKLCXVXpfMz/ngAcul2O4jFzSeiFVZc7SGU8roN0sUe2GlGbkEsd3Tu6P1JP4911WD8p6tSrnD3nvfVgptrTjzJTGK8nMt5IQjvPdG9nsocIPo2iPEdKYCKALc1rcqXm7CN5/pK8P4WK/4Tdjug== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB781; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 20:tIzZfPCJhADlMJJhBzzCUF4mDz3Gfr90nkI5Qpb+TQ/4zxB7+2Y+x+AYqbmzaJhaltsy1ysDaukKp9ip7CBOcSPSUYdJm1gicx0kFXdMmnKxPKcxfBISD0WpgxuRzBk/GDjPUX+WNm2za35CYh1XpnH9zE+tGuG2GWT4LyFCkeiPk3+hcUXodLcMM/1+gvhKZOWGD8HReZvR5N6xb4gcDXxvosKD1t2Xxhmjzfu3j5aEkoMM/ZkuYbl6n+pjst+/0vLxLcgiZAzlRG32uIr9cxmdrsPpKhF7+Xrd6HaAEvB92iCUHv35cggL7rxWaWru0gfIAMnxs3Q/5RhEpycxx994vXxU/aE/J/CYOAEeGZTd0UAvJYbot5tBQsy1gZgt2QXouUFsp466vJ6qaQmN5gQRP6czuupwkiPikHIcBYsN5xpZVNRwjoDFqErepRv5/Gm81di3/j8Fwdbb5sc/mJwYXX/g05BIIdfWa6D4QdBafHa48Ql58z5nqI/j5vyE; 4:R8cZT3dzuwgmyNag5i/AVlqMDM2u2bJhdG33zUMe8HU8d0jTCQ8Y9Mj1PlMU2I3YAaogLJfLER2d+b9WLdTu2iNgktTeGHzr6OE/whT3lRCVw2sfvGUPyswKiYj0rAk5UeR6DrkneJK+mqrvRrgYSuS2x0li0EB1hC+EJg1w//5JTR5YjxiAAxf1PcCHbsHp/25P9X8JIpJnjhac9ayGtec1r57scpxEQQ75qQA3JAMURWKqyoDLQKdm+oHcf7K+X9aH2CX615ghfiVxXolYBF80FsoqSFZ0IIoU8OhfyjI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DM2PR05MB781; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB781; X-Forefront-PRVS: 06237E4555 X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 23:kI0H9dbUaaxjk5eU1AXlIW9yLEB3HDBzztiStxeyWLggtp40tzFFQ2b/5wCmnMNhQlGcgfFw1o3Ke4ori88ipgZly4Zi9WVZ7O1rKK8npcSpkQB7Vy8cEStQtiP4ZeF3yNt5F5Fzb1q8E4fG6UCLBctyxH8Yzm7pAxsT1knkCAuHggXjCtUFYp3X+tiAqMoklC8ho1/5HyE4K1y/9Nj1KRbTTvKNr++lm9U1I6FVlnfZmP2IAVINhwvscZkUdQ2XVzGVp4q4WscnxDGLd7njfnP/oJSFcS76JFqMWmMaV/ZiGnxjyev6Zuh2ECcV21xdgAXvFmn2Nfb/kFoGSe02WnD24we5yRt14ohOXXU0wbO9iiBHFCeckKm7LVkz6heZRCd9fSXtSlDOMhQhXksExW08dozkUzkQ+YxWEVJa/pORP7/BHxa6oAE6xsNh44qZ/7cV/d0LG6SShC0NhJu96NwJc5IfqawUpwB+WQ0mzFvLKQwiJ/RH+cbdb62pVQWi8zs8lb1Hhb+67d6jGFw6Wl3rhhj5VP67WCGyvQR8jVjat3JsDBfcQP5pc7zE/Ds4WGzdBTVxWu2a31OxB0z71XX7c43Xe0Y3QXmeYjqrFjNTB48s69JFmMIrKAb6K50l3CoJzFPqeTOFzXr9dSwS1MxDavMS268pIfuvh92oBM3JymwzWMlm0oG4pNdW9ZasfBY1a3UGLSNW/w9USMJRwXHGGDDDmOcAo+QIevj6Tya1oWnZtxhBoqpTEFg4WgNqjH5OXga1LZYbUwdsiBUUpLXrxyssNc0umP4bnCC6NlIjXaKR+Nr8GFizg3YXCqBtibdslFQJZVSo2LqiS1hJTiSpVKJH/OzzZY/y5T78lg52ojo/JXrX7WIKZReQf5088UfKQ4l7+SIErSOw3SzSDA== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 5:JjIJCU+xZfSIrenhw5jPMmOOzDn2oSZayL8shXnuBZpjDbZ9HA32llbizBkuS+4kRKyZvl7ZqdfVEpdy71Z/6nk5NmXuklNmuQf/ATfBFc/ZNh19vOwu6LbbuX41yaEF3qZZOn+0OVrlLYCtj2zUNA==; 24:hVflJI8M4sFN1XPfASDO7YRUqsYUcua5zV0fidhf1Rn8tkr9qwcG/B8aD2v6a8fyTnXgYm7e9v2F5TWfmReDYESECyA9l02p2LbOtVGJPf8=; 20:zfTU4ISH0pPbWhdoVIrZt+XVyF4QcWISfYkeQjA71KF3SREsZ6WVz4xasGG4LrD1sss7N4OMxa3LlzTshoF2Nw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2015 15:35:12.3542 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB781 X-Mailman-Approved-At: Tue, 30 Jun 2015 18:09:35 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 16:09:39 -0000 Jeffrey Bouquet wrote: > If I've a spare /mnt/usr/src , it seems buildworld quite soon fails, > where it otherwise may succeed in /usr/src. Any CLI parameters or> the > build system is hardcoded enough so that there will always be > problems? The only thing hard coded is the default MAKEOBJDIRPREFIX (it isn't called that but it works the same way), but even that should work for any location. I always have MAKEOBJDIRPREFIX when doing buildworld etc, and have never used /usr/src. Is there perhaps something interesting about /mnt/usr/src (like ancient?) From owner-freebsd-current@freebsd.org Tue Jun 30 18:52:48 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4390990462 for ; Tue, 30 Jun 2015 18:52:48 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.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 18A242ABA for ; Tue, 30 Jun 2015 18:52:47 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 0AF7724286 for ; Tue, 30 Jun 2015 20:52:37 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AzJACz5JJVPD5e5VVbgxFUZYMYsGRPAYphhXwCgVI9EAEBAQEBAQEGAQEBAUE/QQWDXAEBAQECASMECwEjKAsLGAICJgICLQwKFIhADAGyJpcAAQEIAgEfgSGKKYQuX4JogUMFkSmCXgGBA4wNhx+HYXKFWYE4gQmBKRyBVDyBNYFEAQEB X-IPAS-Result: A2AzJACz5JJVPD5e5VVbgxFUZYMYsGRPAYphhXwCgVI9EAEBAQEBAQEGAQEBAUE/QQWDXAEBAQECASMECwEjKAsLGAICJgICLQwKFIhADAGyJpcAAQEIAgEfgSGKKYQuX4JogUMFkSmCXgGBA4wNhx+HYXKFWYE4gQmBKRyBVDyBNYFEAQEB X-IronPort-AV: E=Sophos;i="5.15,379,1432591200"; d="scan'208";a="917221847" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb3.telenor.se with ESMTP; 30 Jun 2015 20:52:38 +0200 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1ZA0e4-000DMD-Ld for freebsd-current@freebsd.org; Tue, 30 Jun 2015 20:52:36 +0200 Received: from 85.229.92.85 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Tue, 30 Jun 2015 20:52:36 +0200 (CEST) Message-ID: <24273.85.229.92.85.1435690356.squirrel@webmail.alvermark.net> In-Reply-To: References: <20876.213.113.68.53.1419950410.squirrel@webmail.alvermark.net> <54A2CC2D.3040105@freebsd.org> <42818.213.113.68.53.1420039470.squirrel@webmail.alvermark.net> Date: Tue, 30 Jun 2015 20:52:36 +0200 (CEST) Subject: Re: UEFI boot fail on higher resolutions (Re: Acer E3-112 and UEFI) From: "Jakob Alvermark" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 18:52:48 -0000 On Wed, February 4, 2015 15:04, Jakob Alvermark wrote: > > On 31 dec 2014, at 16:24, Jakob Alvermark wrote: > > >> On Tue, December 30, 2014 17:00, Nathan Whitehorn wrote: >> >>> >> >>> On 12/30/14 06:40, Jakob Alvermark wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> Have been playing with this machine for a while now. >>>> It is a quad core Pentium N3540 (ValleyView/Bay Trail), 8 GB RAM. It >>>> came with a Broadcom WiFi card which I swapped for an Intel which >>>> is supported by FreeBSD. Also swapped the hard drive for an SSD. >>>> >>>> When first trying to boot FreeBSD with UEFI it would not boot. >>>> It stops after the loader is trying to start the kernel. >>>> My workaround now is using refind, http://www.rodsbooks.com/refind/ >>>> to set the screen resolution to 800x600. (Native is 1366x768) Only >>>> then will it boot using UEFI. I tried setting it to 1024x768, then >>>> it crashes. If it helps I can get the backtrace. >>> >>> [Not sure what's going on here] >>> >>> > > > A follow up on this: > > > I tried this on my desktop machine (AMD FX-8350, Radeon HD 5450) to see > if it has the issue, and it has! I went on to try it on my desktop machine > at work (Core i3-4130, Radeon HD 4350) and it boots! > > On the Acer, resolution set to 1024x768: > > >>> FreeBSD EFI boot block >>> > Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0x7502f000 > EFI version: 2.40 > EFI Firmware: INSYDE Corp. (rev 21522.39) > > > --- > Start @ 0xffffffff802e1000 ... > EFI framebuffer information: > addr, size 0x80000000, 0x300000 dimensions 1024 x 768 stride > 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > --- > > > kernel trap12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 fault virtual address = 0x13 fault code > = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80a20834 stack pointer > = 0x28:0xffffffff81604170 > frame pointer = 0x28:0xffffffff81604290 code segment > = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 current process = 0 > () > [ thread pid 0 tid 0] > Stopped at kvprintf+0xd4: movzbl (%r14),%eax > > > .... > > > > > On the home desktop resolution 1024x768: > > >>> FreeBSD EFI boot block >>> > Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0xb08ac000 > EFI version: 2.31 > EFI Firmware: American Megatrends (rev 4.653) > > > --- > Start @ 0xffffffff802e1000 ... > EFI framebuffer information: > addr, size 0xc0000000, 0x300000 dimensions 1024 x 768 stride > 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > --- > kernel trap12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 fault virtual address = 0x13 fault code > = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80a20654 stack pointer > = 0x28:0xffffffff81603d70 > frame pointer = 0x28:0xffffffff81603e90 code segment > = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 current process = 0 > () > [ thread pid 0 tid 0] > Stopped at kvprintf+0xd4: movzbl (%r14),%eax > > > ---- > > > On the work desktop: > > >>> FreeBSD EFI boot block >>> > Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0xbb7aa000 > EFI version: 2.31 > EFI Firmware: American Megatrends (rev 4.654) > > > --- > Start @ 0xffffffff802e1000 ... > EFI framebuffer information: > addr, size 0xe0000000, 0x300000 dimensions 1024 x 768 stride > 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > And then it boots normally. > > > > Does anyone have any clues on what's going on here? > > > (This all typed manually from screenshots taken with my phone, there > might be typos.) Another update! As I found out the EFI loader has the capability to change screen modes I dumped refind and started playing with this again. "mode 5" gives me 1024x768 and a panic: --- kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1f2d0ec fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8030003d stack pointer = 0x28:0xffffffff81616f70 frame pointer = 0x28:0x0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () --- What struck me then was this line: instruction pointer = 0x20:0xffffffff8030003d and the fact that: EFI framebuffer information: addr, size 0x80000000, 0x300000 Coincidence? Maybe not. In sys/dev/vt/hw/efifb/efifb.c I changed this line: info->fb_vbase = PHYS_TO_DMAP(efifb->fb_addr); Into this hack: info->fb_vbase = PHYS_TO_DMAP(0x90000000); Recompile kernel and now it boots at native resolution (1366x768)! Any thoughts on this? Thanks, Jakob From owner-freebsd-current@freebsd.org Tue Jun 30 18:54:30 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A064799054D; Tue, 30 Jun 2015 18:54:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::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 67DDD2D27; Tue, 30 Jun 2015 18:54:30 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id D2FE2153413; Tue, 30 Jun 2015 20:54:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XEEGBEW1eq9; Tue, 30 Jun 2015 20:54:08 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:e001:6323:460e:56a5] (unknown [IPv6:2001:4cb8:3:1:e001:6323:460e:56a5]) by smtp.digiware.nl (Postfix) with ESMTPA id 97679153416; Tue, 30 Jun 2015 20:54:08 +0200 (CEST) Message-ID: <5592E5CF.6020509@digiware.nl> Date: Tue, 30 Jun 2015 20:54:07 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Simon J. Gerraty" , jbtakk@iherebuywisely.com CC: freebsd-current , current Subject: Re: "proper way" or "unworkable idea" ? References: <20845.1435678348@chaos> In-Reply-To: <20845.1435678348@chaos> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 30 Jun 2015 18:54:30 -0000 On 30/06/2015 17:32, Simon J. Gerraty wrote: > Jeffrey Bouquet wrote: > >> If I've a spare /mnt/usr/src , it seems buildworld quite soon fails, >> where it otherwise may succeed in /usr/src. Any CLI parameters or> the >> build system is hardcoded enough so that there will always be >> problems? > > The only thing hard coded is the default MAKEOBJDIRPREFIX (it isn't > called that but it works the same way), but even that should work for any > location. I always have MAKEOBJDIRPREFIX when doing buildworld etc, > and have never used /usr/src. > > Is there perhaps something interesting about /mnt/usr/src (like > ancient?) On some of the systems where I use different versions, I have /usr/srcs mounted of the NFS-server. in which I have. /usr/srcs/src8/src /usr/srcs/src9/src /usr/srcs/src10/src /usr/srcs/head/src Then also have /usr/objs mounted, with the same setup And on the remote systems link /usr/src -> /usr/srcs/src??/src and same for obj.... I have yet to run into trouble when I do the normal things. It gets messy if I'd like to build both i386 and amd64 in the same obj-tree. That does not always work, but adding a differentiating i386 and amd64 to the hierarchy seemed to fix it. But I retired all but one i386, and that is soon to follow. --WjW From owner-freebsd-current@freebsd.org Tue Jun 30 19:24:48 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EA30990146 for ; Tue, 30 Jun 2015 19:24:48 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8082A1689; Tue, 30 Jun 2015 19:24:48 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 34FC82CF; Tue, 30 Jun 2015 19:24:46 +0000 (UTC) Date: Tue, 30 Jun 2015 19:24:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <301529573.67.1435692285918.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2051173247.63.1435667322267.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2051173247.63.1435667322267.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1150 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:24:48 -0000 FreeBSD_HEAD-tests - Build #1150 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1150/ to view the results. From owner-freebsd-current@freebsd.org Wed Jul 1 02:41:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C297C991240 for ; Wed, 1 Jul 2015 02:41:34 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B67E416EA; Wed, 1 Jul 2015 02:41:34 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1A4CB37F; Wed, 1 Jul 2015 02:41:33 +0000 (UTC) Date: Wed, 1 Jul 2015 02:41:32 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <667784454.73.1435718492481.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1151 - Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 02:41:34 -0000 FreeBSD_HEAD-tests - Build #1151 - Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1151/ to view the results. From owner-freebsd-current@freebsd.org Wed Jul 1 10:39:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62AAC991449 for ; Wed, 1 Jul 2015 10:39:36 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0161BA7; Wed, 1 Jul 2015 10:39:36 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 98DCC4E6; Wed, 1 Jul 2015 10:39:31 +0000 (UTC) Date: Wed, 1 Jul 2015 10:39:23 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1880188576.78.1435747165254.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <667784454.73.1435718492481.JavaMail.jenkins@jenkins-9.freebsd.org> References: <667784454.73.1435718492481.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1152 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 10:39:36 -0000 FreeBSD_HEAD-tests - Build #1152 - Failure: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1152/ to view the results. From owner-freebsd-current@freebsd.org Wed Jul 1 11:35:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFC4C98D664 for ; Wed, 1 Jul 2015 11:35:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9C33E2BE6 for ; Wed, 1 Jul 2015 11:35:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9B3E298D65A; Wed, 1 Jul 2015 11:35:22 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A9AA98D659; Wed, 1 Jul 2015 11:35:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.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 B59362BDD; Wed, 1 Jul 2015 11:35:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 62F2E1FE022; Wed, 1 Jul 2015 13:35:12 +0200 (CEST) Message-ID: <5593D0AE.2010205@selasky.org> Date: Wed, 01 Jul 2015 13:36:14 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Slawa Olhovchenkov , Baptiste Daroussin CC: ports@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org Subject: Re: pkg 1.5.0 is out References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> In-Reply-To: <20150421103454.GR1394@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 11:35:22 -0000 On 04/21/15 12:34, Slawa Olhovchenkov wrote: > On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: > >> Hi all, >> >> Final pkg 1.5.0 has been released. > Hi, Is there a way the external SAT solver functionality can be memory optimised? When trying to use this feature having +750 packages installed, the memory usage starts growing and growing beyond 4GBytes until PKG segfaults, even before the CNF export has started. env SAT_SOLVER=mysolver pkg upgrade --HPS From owner-freebsd-current@freebsd.org Wed Jul 1 11:38:53 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1502F98D82B for ; Wed, 1 Jul 2015 11:38:53 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E64322CA4 for ; Wed, 1 Jul 2015 11:38:52 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E373498D828; Wed, 1 Jul 2015 11:38:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2AA698D827; Wed, 1 Jul 2015 11:38:52 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C2102CA3; Wed, 1 Jul 2015 11:38:52 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wgqq4 with SMTP id q4so34262769wgq.1; Wed, 01 Jul 2015 04:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SusvODW+FylsPA6+ygNgxTSMIUHLWkggiRirT1PkJOQ=; b=g//nNNhkm8OdAIdtlQL0P2QpXPLKsZ4fHeC4NEzp9mTrzZFH0qN5/vh2yVLvdwLOLA rZTFebDA3LJKNBYy/uHCInSaagt/rg+5VBRg4p7944d6IvDsM5GRprjbb+IXst70dEVI RDYE921p2Dsi1hGWnGrGNAKu/AvaXGkekgwwSEbXJpclYJazs3MTp4cEenW/R/J+48PK CTj6IBwR5iC+6f0Sf41G3wr4Oh/yknmuFeM1cHJxzEj6r1RKgpwJP94qGtwnSMsKgmqS 3CxyUYEaTFpnvEslEQvS56EvcBY6nUgjSNxVX+l9APIOAeDN4Sq1PbsbuxV9aeZh2Bm4 cSjg== X-Received: by 10.180.74.210 with SMTP id w18mr5606812wiv.77.1435750731029; Wed, 01 Jul 2015 04:38:51 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n8sm2983231wiy.19.2015.07.01.04.38.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 04:38:49 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 1 Jul 2015 13:38:47 +0200 From: Baptiste Daroussin To: Hans Petter Selasky Cc: Slawa Olhovchenkov , ports@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org Subject: Re: pkg 1.5.0 is out Message-ID: <20150701113847.GA15161@ivaldir.etoilebsd.net> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <5593D0AE.2010205@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 11:38:53 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 01, 2015 at 01:36:14PM +0200, Hans Petter Selasky wrote: > On 04/21/15 12:34, Slawa Olhovchenkov wrote: > > On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: > > > >> Hi all, > >> > >> Final pkg 1.5.0 has been released. > > >=20 > Hi, >=20 > Is there a way the external SAT solver functionality can be memory=20 > optimised? When trying to use this feature having +750 packages=20 > installed, the memory usage starts growing and growing beyond 4GBytes=20 > until PKG segfaults, even before the CNF export has started. >=20 > env SAT_SOLVER=3Dmysolver pkg upgrade Probably, but given the little amount of time pkg developers has we will gr= eatly appreciate patches :) AKA this would be greatly appreciated, but very low on the priority list :( Best regards, Bapt --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWT0UcACgkQ8kTtMUmk6Ex8/gCeMHpS4q0e9V6xVa8aCj9uSPLO U1kAoLiweMzu0Lz1lZYjC9Vr4lxOCJuN =4AiX -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-freebsd-current@freebsd.org Wed Jul 1 19:16:09 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31BCC99182B for ; Wed, 1 Jul 2015 19:16:09 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1F88023F6; Wed, 1 Jul 2015 19:16:09 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EA3CF5AC; Wed, 1 Jul 2015 19:16:07 +0000 (UTC) Date: Wed, 1 Jul 2015 19:16:06 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <39422495.82.1435778167308.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1880188576.78.1435747165254.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1880188576.78.1435747165254.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1153 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:16:09 -0000 FreeBSD_HEAD-tests - Build #1153 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1153/ to view the results. From owner-freebsd-current@freebsd.org Wed Jul 1 19:45:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80201991D8D for ; Wed, 1 Jul 2015 19:45:00 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8E9100B for ; Wed, 1 Jul 2015 19:45:00 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by igblr2 with SMTP id lr2so105298573igb.0 for ; Wed, 01 Jul 2015 12:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+nvl8c/A0NvkoIveEVZhud++dFf6YesOp9I4Gzfokmg=; b=hgh1tAGrB/9fQaRLK1Yuxxp+WE16ED6ol9giWgcxIEp4UvTUnmIt6k0KZgSfuwN6pf dPVkDKafe6Box7/DofZZVxQdsT/o0PiDMadafi/MeazzIMkpuaiSq1ss8AXcUqqg7/ww GeM0xHAQZZARHayfUBo8qcMyvzASmQVE5/TY+IL0dRNNNll1HI+Q41aOqf4s2GiZYp2P L2r3QhLxxrlSoLSLJZx7bQ2HjaR/Ukfloc5jomToNN7+eKL47YPskxjgcVOkv4fRrp6M L1lJvEuYgjeZd70jFKII61IIb8YxVlTRuApmLB2OMblcTJoOm02trz7lz5M67IfN3/2s DLdQ== MIME-Version: 1.0 X-Received: by 10.107.33.146 with SMTP id h140mr41502428ioh.1.1435779899614; Wed, 01 Jul 2015 12:44:59 -0700 (PDT) Received: by 10.107.145.68 with HTTP; Wed, 1 Jul 2015 12:44:59 -0700 (PDT) Date: Wed, 1 Jul 2015 15:44:59 -0400 Message-ID: Subject: How should a driver shutdown a taskqueue on detach? From: Ryan Stone To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 19:45:00 -0000 I'm trying to figure out how a driver is supposed to shut down its interrupt-handling taskqueue when it detaches. taskqueue(9) recommends disabling interrupts, draining each task and then freeing the taskqueue. The problem that I have is the interrupt-handling tasks will sometimes re-enable interrupts on the device. Is there a better way than using some kind of flag internally in the driver to note that a detach is in progress that the interrupt handlers will have to check before enabling interrupts? From owner-freebsd-current@freebsd.org Wed Jul 1 20:58:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8162D9929F3 for ; Wed, 1 Jul 2015 20:58:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D5421690 for ; Wed, 1 Jul 2015 20:58:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by widjy10 with SMTP id jy10so68195413wid.1 for ; Wed, 01 Jul 2015 13:58: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:date:message-id:subject:from:to :cc:content-type; bh=nQDk1pTjyGhMpu0OjnCebxhPkcbeRrvutYaO2t+yt9I=; b=wOdAPrWOzaxn82I3pQ62BzRo9O9y13tsyd28oztIyoSDKCDjo1MYAgrhgX8LX4JnpE GmOnjxirEH6efUUhJzwm1c3eVX6LN1JMNXGUHUNkq3LiJuHiF+ly/xNChjbXAiTsMm4E 1BHERY036dDomyucGByfCBEvSVjS0WlsF4TvrLngzUP0Pa8N4WuZoBrDicUcmW1PFYXx 8I2hJYhz2zQgGrwQ8TnEcTQjm3KRYGKRJlIMNiOGRbtn585j1l7ePGhYyXFQjMdKHecy sm/4S6UUjBIJJKlbu2c1fKAuvokmVEil7FWZwsYNY5L9Fgnu16YVDPE4cI6OV6PS+5l+ /WgQ== MIME-Version: 1.0 X-Received: by 10.194.243.230 with SMTP id xb6mr52704014wjc.13.1435784300558; Wed, 01 Jul 2015 13:58:20 -0700 (PDT) Received: by 10.194.248.163 with HTTP; Wed, 1 Jul 2015 13:58:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jul 2015 13:58:20 -0700 Message-ID: Subject: Re: How should a driver shutdown a taskqueue on detach? From: Jack Vogel To: Ryan Stone Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 20:58:22 -0000 But if you've disabled interrupts why would an "interrupt-handling task" even run?? Jack On Wed, Jul 1, 2015 at 12:44 PM, Ryan Stone wrote: > I'm trying to figure out how a driver is supposed to shut down its > interrupt-handling taskqueue when it detaches. taskqueue(9) recommends > disabling interrupts, draining each task and then freeing the taskqueue. > The problem that I have is the interrupt-handling tasks will sometimes > re-enable interrupts on the device. Is there a better way than using some > kind of flag internally in the driver to note that a detach is in progress > that the interrupt handlers will have to check before enabling interrupts? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Wed Jul 1 21:09:28 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53479992C8A for ; Wed, 1 Jul 2015 21:09:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CF0D1E01 for ; Wed, 1 Jul 2015 21:09:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by ieqy10 with SMTP id y10so43733588ieq.0 for ; Wed, 01 Jul 2015 14:09:27 -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=1U6AHL46UFUp9fKYG5VydAOiF3y5VXjqyccjQjOviFU=; b=JEBbL62ijs9zLZ7RLeGv6CLtR6eQnQdvUbFQ6Q5psS7YFk9ONwDlmugA0cpWZbrlFj 2o5x7HLKpVp5LQL6QKF+nDDOQzwh45ZUoaD436Drluv+73vtQ6H7hc/0/9FC2WLgBUkO +C3sHyQHsp08vymKei45QRd+DcPhe+bbGLRKJ3DLSMvexCXawefzcaJy6phNCYRIFMBo 8uNMNygc71WCW0ol/QU2ny46+khxDEjHuTdwx4msSp2J9eXuAM8JMOP4UoElwJebQGwy suoZgqvEi/y9FCWdv+lkfdgNs7qq1w7TzKJz6HXPUKPuPePlJLw6tM6KjpS8PWIm76vH mUnA== MIME-Version: 1.0 X-Received: by 10.107.10.212 with SMTP id 81mr32905167iok.89.1435784967482; Wed, 01 Jul 2015 14:09:27 -0700 (PDT) Received: by 10.107.145.68 with HTTP; Wed, 1 Jul 2015 14:09:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jul 2015 17:09:27 -0400 Message-ID: Subject: Re: How should a driver shutdown a taskqueue on detach? From: Ryan Stone To: Jack Vogel Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 21:09:28 -0000 On Wed, Jul 1, 2015 at 4:58 PM, Jack Vogel wrote: > But if you've disabled interrupts why would an "interrupt-handling task" > even run?? > > Jack > There's a race. The task could have already have been scheduled by a previous interrupt and could be running while I am trying to disable interrupts and drain the taskqueue. From owner-freebsd-current@freebsd.org Wed Jul 1 21:32:47 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FC4B9920E2 for ; Wed, 1 Jul 2015 21:32:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 E5E432B88 for ; Wed, 1 Jul 2015 21:32:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t61LWfmh000961 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 00:32:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t61LWfmh000961 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t61LWfeR000960; Thu, 2 Jul 2015 00:32:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Jul 2015 00:32:41 +0300 From: Konstantin Belousov To: Ryan Stone Cc: Jack Vogel , FreeBSD Current Subject: Re: How should a driver shutdown a taskqueue on detach? Message-ID: <20150701213241.GG2080@kib.kiev.ua> References: 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=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 21:32:47 -0000 On Wed, Jul 01, 2015 at 05:09:27PM -0400, Ryan Stone wrote: > On Wed, Jul 1, 2015 at 4:58 PM, Jack Vogel wrote: > > > But if you've disabled interrupts why would an "interrupt-handling task" > > even run?? > > > > Jack > > > > There's a race. The task could have already have been scheduled by a > previous interrupt and could be running while I am trying to disable > interrupts and drain the taskqueue. Do you mean, you want some KPI like boolean taskqueue_is_draining(struct taskqueue *p); so that e.g. executed task could see if it is executing in the shutdown state ? From owner-freebsd-current@freebsd.org Wed Jul 1 21:50:11 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 006F39923EA for ; Wed, 1 Jul 2015 21:50:10 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B940B1156 for ; Wed, 1 Jul 2015 21:50:10 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by igcur8 with SMTP id ur8so103238175igc.0 for ; Wed, 01 Jul 2015 14:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=jUfXpogWmlZs5Xe9lz5UyhkkDvkLJv/0DxpuiOLaxi0=; b=wdz9LSHKwhNkMcg8M5zrCVF8/8Yjn3qmq6wsWbxe6TW9zkfsqkml3vugE4QOsXbvPd uU+h8WXbvt3X5/vnXTKw0nzY7Lns8Bnx0Ydp98W6lSjxBHdQTZmEy+FoWIvYKjlRduiM LvLRBQsKc2gTrgRAQa2GdUmYm3fs2tA0zt1o3ki0LZr1zdEh02jlpvYwCvnJTbZ1N27h fDY0jL8Mb7RQzrqJQd5esafNP2FRxJKhFdml9SxObCaGBLlfmg4k9hVfB1h7Zz7+CjpX G/PLIzukP0ifKGp1+B+40fbRJIVPn20K6TbQ2fxSeKtNlCQxxCgL1LyUGI7fwZ0erLUW Q7kg== X-Received: by 10.50.143.104 with SMTP id sd8mr36216147igb.14.1435787410124; Wed, 01 Jul 2015 14:50:10 -0700 (PDT) MIME-Version: 1.0 References: <20150701213241.GG2080@kib.kiev.ua> In-Reply-To: <20150701213241.GG2080@kib.kiev.ua> From: Eric Joyner Date: Wed, 01 Jul 2015 21:50:00 +0000 Message-ID: Subject: Re: How should a driver shutdown a taskqueue on detach? To: Konstantin Belousov , Ryan Stone Cc: Jack Vogel , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 21:50:11 -0000 Or like, "taskqueue_enqueue_if_not_draining()" ? :p On Wed, Jul 1, 2015 at 2:32 PM Konstantin Belousov wrote: > On Wed, Jul 01, 2015 at 05:09:27PM -0400, Ryan Stone wrote: > > On Wed, Jul 1, 2015 at 4:58 PM, Jack Vogel wrote: > > > > > But if you've disabled interrupts why would an "interrupt-handling > task" > > > even run?? > > > > > > Jack > > > > > > > There's a race. The task could have already have been scheduled by a > > previous interrupt and could be running while I am trying to disable > > interrupts and drain the taskqueue. > > Do you mean, you want some KPI like > boolean taskqueue_is_draining(struct taskqueue *p); > so that e.g. executed task could see if it is executing in the > shutdown state ? > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Wed Jul 1 22:28:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA305992A04 for ; Wed, 1 Jul 2015 22:28:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92D0C24A9 for ; Wed, 1 Jul 2015 22:28:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by iecuq6 with SMTP id uq6so44617265iec.2 for ; Wed, 01 Jul 2015 15:28:49 -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=7cbsL2cobg+B0lvAN9Ae/DS31GPLQg6Hx7Y2wV3/m4g=; b=rlpZUGGP/iHg9+YCLRyfDncSE3Vc8Lc7xshEoLAspVanIOwSBO2HjOV2WP9/unavmo FlKWAFaLT9a5RHcw8Rsn1aibMER4qtta7a/w0kir6If/zLfzzt1d+8cbcO4FRgKUh0WB 6qV2nsw/r4C52x++XY/UlSIImntqA/hoSgDXIYh1uln1qMd+o0aQiW2cb3wfubccYA0l kl3NXsi/RBoVwk/wuN0smfEGh+IhEQJzipficDJUD7a/jg/G39MapsaV+L8kGsSzW4Qu 0zfYR2CnjcAFeWmJuiIrAH/LW1mk+5u5OJNGT4lkPTxPs1T3JVAWQRlHqio4/tY/d1Pn pADA== MIME-Version: 1.0 X-Received: by 10.50.87.74 with SMTP id v10mr9008588igz.37.1435789729083; Wed, 01 Jul 2015 15:28:49 -0700 (PDT) Received: by 10.107.145.68 with HTTP; Wed, 1 Jul 2015 15:28:49 -0700 (PDT) In-Reply-To: <20150701213241.GG2080@kib.kiev.ua> References: <20150701213241.GG2080@kib.kiev.ua> Date: Wed, 1 Jul 2015 18:28:49 -0400 Message-ID: Subject: Re: How should a driver shutdown a taskqueue on detach? From: Ryan Stone To: Konstantin Belousov Cc: Jack Vogel , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 22:28:49 -0000 On Wed, Jul 1, 2015 at 5:32 PM, Konstantin Belousov wrote: > Do you mean, you want some KPI like > boolean taskqueue_is_draining(struct taskqueue *p); > so that e.g. executed task could see if it is executing in the > shutdown state ? I'd prefer a KPI that stops a taskqueue from accepting new tasks (and drops attempts to enqueue on the floor). Then I could do something like: taskqueue_stop() disable_interrupts() taskqueue_drain_all() taskqueue_free() From owner-freebsd-current@freebsd.org Wed Jul 1 22:30:00 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20FC0992A4B for ; Wed, 1 Jul 2015 22:30:00 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC70C25B6 for ; Wed, 1 Jul 2015 22:29:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wiga1 with SMTP id a1so137608179wig.0 for ; Wed, 01 Jul 2015 15:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tOwHJmMXdz5qreXlSLeD4CPDzSgkFVU/oaQdXS8RBIY=; b=Pc075jvaVyKAah9yyS1PyeZj5TUqafg5c5GJmOPDxwcd1BKZE5Ruvg32MY+noEkx0F gv+eusLHHTHnkCuOOFi8xO1r0rdIF/dH00iqC4jr9mOUfc8mNwB09K7H0h0byuvBBchq shS9noiPXy49UFOE/jxHgFLOedgQ/tO06TByiKeUsQADWGXm/pg8W0zVe18s7m2t86O0 XE09WGXcsNwQwWilhqeimzjdzcwnb26CDo6IR9vJn2FIhQqzJXKzZtdUn+T+OP4k1dI3 Wz7engzMNizYKP3dom2IYsGy9hDOUvSrSV1jOdcdaOhSvczmAtVF074bp6v08dBKG3yh Xiuw== MIME-Version: 1.0 X-Received: by 10.180.20.15 with SMTP id j15mr10619513wie.76.1435789797925; Wed, 01 Jul 2015 15:29:57 -0700 (PDT) Received: by 10.194.248.163 with HTTP; Wed, 1 Jul 2015 15:29:57 -0700 (PDT) In-Reply-To: References: <20150701213241.GG2080@kib.kiev.ua> Date: Wed, 1 Jul 2015 15:29:57 -0700 Message-ID: Subject: Re: How should a driver shutdown a taskqueue on detach? From: Jack Vogel To: Ryan Stone Cc: Konstantin Belousov , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 22:30:00 -0000 Ya, that seems elegant. Jack On Wed, Jul 1, 2015 at 3:28 PM, Ryan Stone wrote: > On Wed, Jul 1, 2015 at 5:32 PM, Konstantin Belousov > wrote: > >> Do you mean, you want some KPI like >> boolean taskqueue_is_draining(struct taskqueue *p); >> so that e.g. executed task could see if it is executing in the >> shutdown state ? > > > I'd prefer a KPI that stops a taskqueue from accepting new tasks (and > drops attempts to enqueue on the floor). Then I could do something like: > > taskqueue_stop() > disable_interrupts() > taskqueue_drain_all() > taskqueue_free() > From owner-freebsd-current@freebsd.org Wed Jul 1 23:25:12 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CACBC9922AB for ; Wed, 1 Jul 2015 23:25:12 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF2661CDF for ; Wed, 1 Jul 2015 23:25:12 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t61NPBJV008148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2015 16:25:11 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t61NPA63008147; Wed, 1 Jul 2015 16:25:10 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Jul 2015 16:25:10 -0700 From: John-Mark Gurney To: Ryan Stone Cc: FreeBSD Current Subject: Re: How should a driver shutdown a taskqueue on detach? Message-ID: <20150701232510.GH96349@funkthat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 01 Jul 2015 16:25:11 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 01 Jul 2015 23:25:12 -0000 Ryan Stone wrote this message on Wed, Jul 01, 2015 at 15:44 -0400: > I'm trying to figure out how a driver is supposed to shut down its > interrupt-handling taskqueue when it detaches. taskqueue(9) recommends > disabling interrupts, draining each task and then freeing the taskqueue. > The problem that I have is the interrupt-handling tasks will sometimes > re-enable interrupts on the device. Is there a better way than using some > kind of flag internally in the driver to note that a detach is in progress > that the interrupt handlers will have to check before enabling interrupts? Why not disabled interrupts, unregister interrupt handler, and then make sure interrupts are disabled (only needed to prevent an interrupt storm)? Once you have unregistered the interrupt handler, it can't run again... Then you're free to drain the task queue safely... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Thu Jul 2 02:44:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2E289920AD; Thu, 2 Jul 2015 02:44:38 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 6023D1BAD; Thu, 2 Jul 2015 02:44:37 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f79716d000002ea2-21-5594a58ecc54 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 9F.2C.11938.E85A4955; Wed, 1 Jul 2015 22:44:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t622iTtg014124; Wed, 1 Jul 2015 22:44:30 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t622iRsd032138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jul 2015 22:44:29 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t622iR0O022132; Wed, 1 Jul 2015 22:44:27 -0400 (EDT) Date: Wed, 1 Jul 2015 22:44:27 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Call for FreeBSD 2015Q2 (April-June) Status Reports Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6notu3dEqowdb7mha7rp1mt5jz5gOT xfbN/xgdmD1mfJrPEsAYxWWTkpqTWZZapG+XwJUx9+BzxoITXBXHnv5lbmB8zNHFyMkhIWAi 8aHnHjOELSZx4d56ti5GLg4hgcVMEhfmdUM5GxglOlZdY4dwDjJJrP32kx2kRUigXmLyu5lM IDaLgJbE1IY+NhCbTUBN4vHeZlaIsYoSm09NAlrBwSEiIC+x4Lw9SJgZyPx/5TJYq7CAjcSZ W+vYQEp4BRwlLnR7goRFBXQkVu+fwgJi8woISpyc+YQFolVLYvn0bSwTGAVmIUnNQpJawMi0 ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdELzezRC81pXQTIygcOSX5dzB+O6h0iFGAg1GJhzeg akqoEGtiWXFl7iFGSQ4mJVFe7iVAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8zBOAcrwpiZVV qUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErw6IEMFi1LTUyvSMnNKENJMHJwg w3mAhgeB1PAWFyTmFmemQ+RPMSpKifNqgCQEQBIZpXlwvbB08YpRHOgVYd4fIFU8wFQD1/0K aDAT0OCX9pNABpckIqSkGhjNZR26vn4JnFeyUtbloZW4u828xc9XJG1ddO5nTekd/scLuR6c 21Zicr5M+OO1PzsnLJwQlv183mem2tuCn+9VxjLtOLrToOjL5F+efxosRD2+z5aZ9vXYqZPp k7qvVUupBPZskv8rNq3PxfrU69g+5s4tjKFzYlWli+U3XVpdvHj6DDb7/2fqlViKMxINtZiL ihMB4aRNvvICAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 02 Jul 2015 02:44:39 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is July 14, 2015, for work done in April through June. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2015Q2 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-10-2014-12.html [5] http://www.freebsd.org/news/status/report-2015-01-2015-03.html From owner-freebsd-current@freebsd.org Thu Jul 2 07:08:39 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7296992B02 for ; Thu, 2 Jul 2015 07:08:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 2C61E2AC9 for ; Thu, 2 Jul 2015 07:08:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t6278WP7076283 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 10:08:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t6278WP7076283 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t6278SBV076282; Thu, 2 Jul 2015 10:08:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Jul 2015 10:08:28 +0300 From: Konstantin Belousov To: Ryan Stone Cc: Jack Vogel , FreeBSD Current Subject: Re: How should a driver shutdown a taskqueue on detach? Message-ID: <20150702070828.GH2080@kib.kiev.ua> References: <20150701213241.GG2080@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=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 02 Jul 2015 07:08:39 -0000 On Wed, Jul 01, 2015 at 06:28:49PM -0400, Ryan Stone wrote: > On Wed, Jul 1, 2015 at 5:32 PM, Konstantin Belousov > wrote: > > > Do you mean, you want some KPI like > > boolean taskqueue_is_draining(struct taskqueue *p); > > so that e.g. executed task could see if it is executing in the > > shutdown state ? > > > I'd prefer a KPI that stops a taskqueue from accepting new tasks (and drops > attempts to enqueue on the floor). Then I could do something like: > > taskqueue_stop() > disable_interrupts() > taskqueue_drain_all() > taskqueue_free() Having taskqueue_enqueue() which could silently (?) not enqueue the given task is huge and IMO risky change to the KPI. If doing it, I think that there should be a new function to enqueue, which is allowed to fail, unlike taskqueue_enqueue(). BTW, the man page for taskqueue(9) is wrong, taskqueue_enqueue(9) always succeed now and always returns 0 (ignoring the ushort overflow). From owner-freebsd-current@freebsd.org Thu Jul 2 16:17:59 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1E8B99356E for ; Thu, 2 Jul 2015 16:17:59 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E28B614E7 for ; Thu, 2 Jul 2015 16:17:59 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 590C481F for ; Thu, 2 Jul 2015 16:17:56 +0000 (UTC) Date: Thu, 2 Jul 2015 16:17:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <3596542.85.1435853875126.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #1906 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 02 Jul 2015 16:18:00 -0000 See From owner-freebsd-current@freebsd.org Thu Jul 2 18:15:09 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFE8C9937DA for ; Thu, 2 Jul 2015 18:15:09 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B42DC1662; Thu, 2 Jul 2015 18:15:09 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1B5B483F; Thu, 2 Jul 2015 18:15:07 +0000 (UTC) Date: Thu, 2 Jul 2015 18:15:05 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1091091789.87.1435860906144.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1155 - Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 18:15:09 -0000 FreeBSD_HEAD-tests - Build #1155 - Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1155/ to view the results. From owner-freebsd-current@freebsd.org Fri Jul 3 01:28:01 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61975993F53 for ; Fri, 3 Jul 2015 01:28:01 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4A41E1C2E; Fri, 3 Jul 2015 01:28:01 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B37E18F4; Fri, 3 Jul 2015 01:27:54 +0000 (UTC) Date: Fri, 3 Jul 2015 01:27:48 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <80510478.90.1435886869659.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1091091789.87.1435860906144.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1091091789.87.1435860906144.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1156 - Still Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 01:28:01 -0000 FreeBSD_HEAD-tests - Build #1156 - Still Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1156/ to view the results. From owner-freebsd-current@freebsd.org Fri Jul 3 07:17:26 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAFA9992F24 for ; Fri, 3 Jul 2015 07:17:26 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B2E5F1F45; Fri, 3 Jul 2015 07:17:26 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 65AA99AA; Fri, 3 Jul 2015 07:17:24 +0000 (UTC) Date: Fri, 3 Jul 2015 07:17:23 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1893455789.92.1435907843550.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <80510478.90.1435886869659.JavaMail.jenkins@jenkins-9.freebsd.org> References: <80510478.90.1435886869659.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1157 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 07:17:26 -0000 FreeBSD_HEAD-tests - Build #1157 - Fixed: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1157/ to view the results. From owner-freebsd-current@freebsd.org Fri Jul 3 20:18:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEF09994E70 for ; Fri, 3 Jul 2015 20:18:21 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B31CC2046; Fri, 3 Jul 2015 20:18:21 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0B932AEB; Fri, 3 Jul 2015 20:18:19 +0000 (UTC) Date: Fri, 3 Jul 2015 20:18:17 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <932969662.94.1435954697672.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1159 - Unstable MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: UNSTABLE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 20:18:21 -0000 FreeBSD_HEAD-tests - Build #1159 - Unstable: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1159/ to view the results. From owner-freebsd-current@freebsd.org Sat Jul 4 04:08:16 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EAAE995010 for ; Sat, 4 Jul 2015 04:08:16 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 885131A0E; Sat, 4 Jul 2015 04:08:16 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2DCB7B96; Sat, 4 Jul 2015 04:07:49 +0000 (UTC) Date: Sat, 4 Jul 2015 04:07:25 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1419851911.96.1435982855616.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <932969662.94.1435954697672.JavaMail.jenkins@jenkins-9.freebsd.org> References: <932969662.94.1435954697672.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1160 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 04:08:16 -0000 FreeBSD_HEAD-tests - Build #1160 - Failure: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1160/ to view the results. From owner-freebsd-current@freebsd.org Sat Jul 4 19:13:43 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7A479C18 for ; Sat, 4 Jul 2015 19:13:43 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A90B6142F; Sat, 4 Jul 2015 19:13:43 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 295B0D3D; Sat, 4 Jul 2015 19:13:44 +0000 (UTC) Date: Sat, 4 Jul 2015 19:13:43 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1125742275.101.1436037224043.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1419851911.96.1435982855616.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1419851911.96.1435982855616.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD-tests - Build #1161 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD-tests X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 19:13:43 -0000 FreeBSD_HEAD-tests - Build #1161 - Still Failing: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1161/ to view the results. From owner-freebsd-current@freebsd.org Sat Jul 4 23:56:34 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DDAD9810 for ; Sat, 4 Jul 2015 23:56:34 +0000 (UTC) (envelope-from ler@lerctr.org) 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 94B1A1B68 for ; Sat, 4 Jul 2015 23:56:33 +0000 (UTC) (envelope-from ler@lerctr.org) 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=UIGP2SPynxwXIfbg2FZR66DLQ++ybt9MiJSt2NAWb0o=; b=QI6NkwBj0n5AgoKdC6fUk/7oTSyXoA/X7ezVNVElvnr8weyFftlnc0vnKb6IYkyNU9nvT8+8gIcCeij4XaVWq57Fb5RtRT4jbGw8Vfw4AJUoj/fg+5rIpu4lBlx4zaCaqyBsw6vvUr60WIjAZPujFz2Vhz/0zS4AhS7zui7Hp9k=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:61310 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZBXIN-000AMV-Ub for freebsd-current@freebsd.org; Sat, 04 Jul 2015 18:56:32 -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); Sat, 04 Jul 2015 18:56:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 04 Jul 2015 18:56:31 -0500 From: Larry Rosenman To: Freebsd current Subject: Kernel Link issue Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.1.1 X-Spam-Score: -1.0 (-) X-LERCTR-Spam-Score: -1.0 (-) X-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-LERCTR-Spam-Report: SpamScore (-1.0/5.0) ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: 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, 04 Jul 2015 23:56:34 -0000 --- kernel.debug --- linking kernel.debug nvpair.o: In function `illumos_nvlist_add_nvlist': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1136: multiple definition of `illumos_nvlist_add_nvlist' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1136: first defined here nvpair.o: In function `illumos_nvlist_add_nvpair': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1971: multiple definition of `illumos_nvlist_add_nvpair' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1971: first defined here nvpair.o: In function `illumos_nvlist_add_string': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1056: multiple definition of `illumos_nvlist_add_string' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1056: first defined here nvpair.o: In function `illumos_nvlist_empty': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1202: multiple definition of `illumos_nvlist_empty' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1202: first defined here nvpair.o: In function `illumos_nvlist_exists': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1789: multiple definition of `illumos_nvlist_exists' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1789: first defined here nvpair.o: In function `illumos_nvlist_free': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:553: multiple definition of `illumos_nvlist_free' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:553: first defined here nvpair.o: In function `illumos_nvlist_next_nvpair': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1149: multiple definition of `illumos_nvlist_next_nvpair' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1149: first defined here nvpair.o: In function `illumos_nvlist_pack': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2343: multiple definition of `illumos_nvlist_pack' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2343: first defined here nvpair.o: In function `illumos_nvlist_prev_nvpair': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1178: multiple definition of `illumos_nvlist_prev_nvpair' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1178: first defined here nvpair.o: In function `illumos_nvlist_remove_nvpair': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:696: multiple definition of `illumos_nvlist_remove_nvpair' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:696: first defined here nvpair.o: In function `illumos_nvlist_size': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2332: multiple definition of `illumos_nvlist_size' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2332: first defined here nvpair.o: In function `illumos_nvlist_unpack': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2405: multiple definition of `illumos_nvlist_unpack' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2405: first defined here nvpair.o: In function `illumos_nvlist_xpack': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2355: multiple definition of `illumos_nvlist_xpack' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2355: first defined here nvpair.o: In function `illumos_nvlist_xunpack': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2416: multiple definition of `illumos_nvlist_xunpack' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:2416: first defined here nvpair.o: In function `illumos_nvpair_name': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1214: multiple definition of `illumos_nvpair_name' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1214: first defined here nvpair.o: In function `illumos_nvpair_type': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1220: multiple definition of `illumos_nvpair_type' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1220: first defined here nvpair.o: In function `nv_alloc_fini': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:164: multiple definition of `nv_alloc_fini' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:164: first defined here nvpair.o: In function `nv_alloc_init': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:140: multiple definition of `nv_alloc_init' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:140: first defined here nvpair.o: In function `nv_alloc_reset': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:157: multiple definition of `nv_alloc_reset' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:157: first defined here nvpair.o: In function `nvlist_add_boolean': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:982: multiple definition of `nvlist_add_boolean' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:982: first defined here nvpair.o: In function `nvlist_add_boolean_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1063: multiple definition of `nvlist_add_boolean_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1063: first defined here nvpair.o: In function `nvlist_add_boolean_value': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:988: multiple definition of `nvlist_add_boolean_value' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:988: first defined here nvpair.o: In function `nvlist_add_byte': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:994: multiple definition of `nvlist_add_byte' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:994: first defined here nvpair.o: In function `nvlist_add_byte_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1069: multiple definition of `nvlist_add_byte_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1069: first defined here nvpair.o: In function `nvlist_add_hrtime': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1130: multiple definition of `nvlist_add_hrtime' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1130: first defined here nvpair.o: In function `nvlist_add_int16': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1012: multiple definition of `nvlist_add_int16' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1012: first defined here nvpair.o: In function `nvlist_add_int16_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1087: multiple definition of `nvlist_add_int16_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1087: first defined here nvpair.o: In function `nvlist_add_int32': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1024: multiple definition of `nvlist_add_int32' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1024: first defined here nvpair.o: In function `nvlist_add_int32_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1099: multiple definition of `nvlist_add_int32_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1099: first defined here nvpair.o: In function `nvlist_add_int64': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1036: multiple definition of `nvlist_add_int64' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1036: first defined here nvpair.o: In function `nvlist_add_int64_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1111: multiple definition of `nvlist_add_int64_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1111: first defined here nvpair.o: In function `nvlist_add_int8': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1000: multiple definition of `nvlist_add_int8' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1000: first defined here nvpair.o: In function `nvlist_add_int8_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1075: multiple definition of `nvlist_add_int8_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1075: first defined here nvpair.o: In function `nvlist_add_nvlist_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1142: multiple definition of `nvlist_add_nvlist_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1142: first defined here nvpair.o: In function `nvlist_add_string_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1124: multiple definition of `nvlist_add_string_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1124: first defined here nvpair.o: In function `nvlist_add_uint16': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1018: multiple definition of `nvlist_add_uint16' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1018: first defined here nvpair.o: In function `nvlist_add_uint16_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1093: multiple definition of `nvlist_add_uint16_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1093: first defined here nvpair.o: In function `nvlist_add_uint32': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1030: multiple definition of `nvlist_add_uint32' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1030: first defined here nvpair.o: In function `nvlist_add_uint32_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1105: multiple definition of `nvlist_add_uint32_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1105: first defined here nvpair.o: In function `nvlist_add_uint64': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1042: multiple definition of `nvlist_add_uint64' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1042: first defined here nvpair.o: In function `nvlist_add_uint64_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1117: multiple definition of `nvlist_add_uint64_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1117: first defined here nvpair.o: In function `nvlist_add_uint8': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1006: multiple definition of `nvlist_add_uint8' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1006: first defined here nvpair.o: In function `nvlist_add_uint8_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1081: multiple definition of `nvlist_add_uint8_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1081: first defined here nvpair.o: In function `nvlist_alloc': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:267: multiple definition of `nvlist_alloc' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:267: first defined here nvpair.o: In function `nvlist_dup': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:603: multiple definition of `nvlist_dup' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:603: first defined here nvpair.o: In function `nvlist_lookup_boolean': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1347: multiple definition of `nvlist_lookup_boolean' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1347: first defined here nvpair.o: In function `nvlist_lookup_boolean_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1435: multiple definition of `nvlist_lookup_boolean_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1435: first defined here nvpair.o: In function `nvlist_lookup_boolean_value': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1353: multiple definition of `nvlist_lookup_boolean_value' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1353: first defined here nvpair.o: In function `nvlist_lookup_byte': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1360: multiple definition of `nvlist_lookup_byte' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1360: first defined here nvpair.o: In function `nvlist_lookup_byte_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1443: multiple definition of `nvlist_lookup_byte_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1443: first defined here nvpair.o: In function `nvlist_lookup_hrtime': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1518: multiple definition of `nvlist_lookup_hrtime' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1518: first defined here nvpair.o: In function `nvlist_lookup_int16': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1378: multiple definition of `nvlist_lookup_int16' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1378: first defined here nvpair.o: In function `nvlist_lookup_int16_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1463: multiple definition of `nvlist_lookup_int16_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1463: first defined here nvpair.o: In function `nvlist_lookup_int32': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1390: multiple definition of `nvlist_lookup_int32' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1390: first defined here nvpair.o: In function `nvlist_lookup_int32_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1477: multiple definition of `nvlist_lookup_int32_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1477: first defined here nvpair.o: In function `nvlist_lookup_int64': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1402: multiple definition of `nvlist_lookup_int64' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1402: first defined here nvpair.o: In function `nvlist_lookup_int64_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1491: multiple definition of `nvlist_lookup_int64_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1491: first defined here nvpair.o: In function `nvlist_lookup_int8': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1366: multiple definition of `nvlist_lookup_int8' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1366: first defined here nvpair.o: In function `nvlist_lookup_int8_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1449: multiple definition of `nvlist_lookup_int8_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1449: first defined here nvpair.o: In function `nvlist_lookup_nv_alloc': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:171: multiple definition of `nvlist_lookup_nv_alloc' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:171: first defined here nvpair.o: In function `nvlist_lookup_nvlist': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1428: multiple definition of `nvlist_lookup_nvlist' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1428: first defined here nvpair.o: In function `nvlist_lookup_nvlist_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1512: multiple definition of `nvlist_lookup_nvlist_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1512: first defined here nvpair.o: In function `nvlist_lookup_nvpair': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1772: multiple definition of `nvlist_lookup_nvpair' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1772: first defined here nvpair.o: In function `nvlist_lookup_nvpair_embedded_index': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1783: multiple definition of `nvlist_lookup_nvpair_embedded_index' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1783: first defined here nvpair.o: In function `nvlist_lookup_pairs': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1524: multiple definition of `nvlist_lookup_pairs' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1524: first defined here nvpair.o: In function `nvlist_lookup_string': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1422: multiple definition of `nvlist_lookup_string' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1422: first defined here nvpair.o: In function `nvlist_lookup_string_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1505: multiple definition of `nvlist_lookup_string_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1505: first defined here nvpair.o: In function `nvlist_lookup_uint16': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1384: multiple definition of `nvlist_lookup_uint16' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1384: first defined here nvpair.o: In function `nvlist_lookup_uint16_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1470: multiple definition of `nvlist_lookup_uint16_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1470: first defined here nvpair.o: In function `nvlist_lookup_uint32': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1396: multiple definition of `nvlist_lookup_uint32' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1396: first defined here nvpair.o: In function `nvlist_lookup_uint32_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1484: multiple definition of `nvlist_lookup_uint32_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1484: first defined here nvpair.o: In function `nvlist_lookup_uint64': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1408: multiple definition of `nvlist_lookup_uint64' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1408: first defined here nvpair.o: In function `nvlist_lookup_uint64_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1498: multiple definition of `nvlist_lookup_uint64_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1498: first defined here nvpair.o: In function `nvlist_lookup_uint8': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1372: multiple definition of `nvlist_lookup_uint8' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1372: first defined here nvpair.o: In function `nvlist_lookup_uint8_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1456: multiple definition of `nvlist_lookup_uint8_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1456: first defined here nvpair.o: In function `nvlist_merge': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1988: multiple definition of `nvlist_merge' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1988: first defined here nvpair.o: In function `nvlist_nvflag': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:257: multiple definition of `nvlist_nvflag' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:257: first defined here nvpair.o: In function `nvlist_remove': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:669: multiple definition of `nvlist_remove' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:669: first defined here nvpair.o: In function `nvlist_remove_all': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:637: multiple definition of `nvlist_remove_all' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:637: first defined here nvpair.o: In function `nvlist_xalloc': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:278: multiple definition of `nvlist_xalloc' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:278: first defined here nvpair.o: In function `nvlist_xdup': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:614: multiple definition of `nvlist_xdup' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:614: first defined here nvpair.o: In function `nvpair_type_is_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1226: multiple definition of `nvpair_type_is_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1226: first defined here nvpair.o: In function `nvpair_value_boolean_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1890: multiple definition of `nvpair_value_boolean_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1890: first defined here nvpair.o: In function `nvpair_value_boolean_value': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1810: multiple definition of `nvpair_value_boolean_value' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1810: first defined here nvpair.o: In function `nvpair_value_byte': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1816: multiple definition of `nvpair_value_byte' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1816: first defined here nvpair.o: In function `nvpair_value_byte_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1896: multiple definition of `nvpair_value_byte_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1896: first defined here nvpair.o: In function `nvpair_value_hrtime': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1962: multiple definition of `nvpair_value_hrtime' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1962: first defined here nvpair.o: In function `nvpair_value_int16': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1834: multiple definition of `nvpair_value_int16' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1834: first defined here nvpair.o: In function `nvpair_value_int16_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1914: multiple definition of `nvpair_value_int16_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1914: first defined here nvpair.o: In function `nvpair_value_int32': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1846: multiple definition of `nvpair_value_int32' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1846: first defined here nvpair.o: In function `nvpair_value_int32_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1926: multiple definition of `nvpair_value_int32_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1926: first defined here nvpair.o: In function `nvpair_value_int64': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1858: multiple definition of `nvpair_value_int64' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1858: first defined here nvpair.o: In function `nvpair_value_int64_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1938: multiple definition of `nvpair_value_int64_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1938: first defined here nvpair.o: In function `nvpair_value_int8': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1822: multiple definition of `nvpair_value_int8' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1822: first defined here nvpair.o: In function `nvpair_value_int8_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1902: multiple definition of `nvpair_value_int8_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1902: first defined here nvpair.o: In function `nvpair_value_nvlist': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1884: multiple definition of `nvpair_value_nvlist' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1884: first defined here nvpair.o: In function `nvpair_value_nvlist_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1956: multiple definition of `nvpair_value_nvlist_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1956: first defined here nvpair.o: In function `nvpair_value_string': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1878: multiple definition of `nvpair_value_string' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1878: first defined here nvpair.o: In function `nvpair_value_string_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1950: multiple definition of `nvpair_value_string_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1950: first defined here nvpair.o: In function `nvpair_value_uint16': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1840: multiple definition of `nvpair_value_uint16' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1840: first defined here nvpair.o: In function `nvpair_value_uint16_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1920: multiple definition of `nvpair_value_uint16_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1920: first defined here nvpair.o: In function `nvpair_value_uint32': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1852: multiple definition of `nvpair_value_uint32' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1852: first defined here nvpair.o: In function `nvpair_value_uint32_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1932: multiple definition of `nvpair_value_uint32_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1932: first defined here nvpair.o: In function `nvpair_value_uint64': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1864: multiple definition of `nvpair_value_uint64' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1864: first defined here nvpair.o: In function `nvpair_value_uint64_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1944: multiple definition of `nvpair_value_uint64_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1944: first defined here nvpair.o: In function `nvpair_value_uint8': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1828: multiple definition of `nvpair_value_uint8' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1828: first defined here nvpair.o: In function `nvpair_value_uint8_array': /usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1908: multiple definition of `nvpair_value_uint8_array' nvpair.o:/usr/src/sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c:1908: first defined here nvlist.o: In function `nvlist_destroy': /usr/src/sys/contrib/libnv/nvlist.c:158: undefined reference to `nvpair_free' nvlist.o: In function `nvlist_remove_nvpair': /usr/src/sys/contrib/libnv/nvlist.c:1394: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:1395: undefined reference to `nvpair_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:1397: undefined reference to `nvpair_remove' nvlist.o: In function `nvlist_get_parent': /usr/src/sys/contrib/libnv/nvlist.c:214: undefined reference to `nvpair_nvlist' nvlist.o: In function `nvlist_find': /usr/src/sys/contrib/libnv/nvlist.c:267: undefined reference to `nvpair_type' /usr/src/sys/contrib/libnv/nvlist.c:270: undefined reference to `nvpair_name' nvlist.o: In function `nvlist_free_nvpair': /usr/src/sys/contrib/libnv/nvlist.c:1432: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:1433: undefined reference to `nvpair_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:1436: undefined reference to `nvpair_free' nvlist.o: In function `nvlist_report_missing': /usr/src/sys/contrib/libnv/nvlist.c:251: undefined reference to `nvpair_type_string' nvlist.o: In function `nvlist_clone': /usr/src/sys/contrib/libnv/nvlist.c:330: undefined reference to `nvpair_clone' nvlist.o: In function `nvlist_move_nvpair': /usr/src/sys/contrib/libnv/nvlist.c:1203: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:1204: undefined reference to `nvpair_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:1207: undefined reference to `nvpair_free' /usr/src/sys/contrib/libnv/nvlist.c:1212: undefined reference to `nvpair_name' /usr/src/sys/contrib/libnv/nvlist.c:1213: undefined reference to `nvpair_free' /usr/src/sys/contrib/libnv/nvlist.c:1220: undefined reference to `nvpair_insert' nvlist.o: In function `nvlist_next_nvpair': /usr/src/sys/contrib/libnv/nvlist.c:998: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:999: undefined reference to `nvpair_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:1001: undefined reference to `nvpair_next' /usr/src/sys/contrib/libnv/nvlist.c:1002: undefined reference to `nvpair_nvlist' nvlist.o: In function `nvlist_size': /usr/src/sys/contrib/libnv/nvlist.c:462: undefined reference to `nvpair_header_size' /usr/src/sys/contrib/libnv/nvlist.c:463: undefined reference to `nvpair_name' /usr/src/sys/contrib/libnv/nvlist.c:464: undefined reference to `nvpair_type' /usr/src/sys/contrib/libnv/nvlist.c:466: undefined reference to `nvpair_header_size' /usr/src/sys/contrib/libnv/nvlist.c:467: undefined reference to `nvpair_get_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:476: undefined reference to `nvpair_size' nvlist.o: In function `nvlist_get_parent': /usr/src/sys/contrib/libnv/nvlist.c:214: undefined reference to `nvpair_nvlist' nvlist.o: In function `nvlist_xpack': /usr/src/sys/contrib/libnv/nvlist.c:628: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:630: undefined reference to `nvpair_init_datasize' /usr/src/sys/contrib/libnv/nvlist.c:631: undefined reference to `nvpair_pack_header' /usr/src/sys/contrib/libnv/nvlist.c:638: undefined reference to `nvpair_pack_null' /usr/src/sys/contrib/libnv/nvlist.c:641: undefined reference to `nvpair_pack_bool' /usr/src/sys/contrib/libnv/nvlist.c:644: undefined reference to `nvpair_pack_number' /usr/src/sys/contrib/libnv/nvlist.c:647: undefined reference to `nvpair_pack_string' /usr/src/sys/contrib/libnv/nvlist.c:650: undefined reference to `nvpair_get_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:668: undefined reference to `nvpair_pack_binary' /usr/src/sys/contrib/libnv/nvlist.c:660: undefined reference to `nvpair_pack_nvlist_up' nvlist.o: In function `nvlist_get_parent': /usr/src/sys/contrib/libnv/nvlist.c:214: undefined reference to `nvpair_nvlist' nvlist.o: In function `nvlist_xpack': /usr/src/sys/contrib/libnv/nvlist.c:683: undefined reference to `nvpair_pack_nvlist_up' /usr/src/sys/contrib/libnv/nvlist.c:628: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:630: undefined reference to `nvpair_init_datasize' /usr/src/sys/contrib/libnv/nvlist.c:631: undefined reference to `nvpair_pack_header' /usr/src/sys/contrib/libnv/nvlist.c:636: undefined reference to `nvpair_type' /usr/src/sys/contrib/libnv/nvlist.c:671: undefined reference to `nvpair_type' nvlist.o: In function `nvlist_xunpack': /usr/src/sys/contrib/libnv/nvlist.c:841: undefined reference to `nvpair_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:842: undefined reference to `nvpair_free_structure' /usr/src/sys/contrib/libnv/nvlist.c:808: undefined reference to `nvpair_unpack' /usr/src/sys/contrib/libnv/nvlist.c:811: undefined reference to `nvpair_type' /usr/src/sys/contrib/libnv/nvlist.c:813: undefined reference to `nvpair_unpack_null' /usr/src/sys/contrib/libnv/nvlist.c:816: undefined reference to `nvpair_unpack_bool' /usr/src/sys/contrib/libnv/nvlist.c:819: undefined reference to `nvpair_unpack_number' /usr/src/sys/contrib/libnv/nvlist.c:822: undefined reference to `nvpair_unpack_string' /usr/src/sys/contrib/libnv/nvlist.c:825: undefined reference to `nvpair_unpack_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:836: undefined reference to `nvpair_unpack_binary' /usr/src/sys/contrib/libnv/nvlist.c:845: undefined reference to `nvpair_type' nvlist.o: In function `nvlist_prev_nvpair': /usr/src/sys/contrib/libnv/nvlist.c:1014: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:1015: undefined reference to `nvpair_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:1017: undefined reference to `nvpair_prev' /usr/src/sys/contrib/libnv/nvlist.c:1018: undefined reference to `nvpair_nvlist' nvlist.o: In function `nvlist_next': /usr/src/sys/contrib/libnv/nvlist.c:1038: undefined reference to `nvpair_type' /usr/src/sys/contrib/libnv/nvlist.c:1040: undefined reference to `nvpair_name' nvlist.o: In function `nvlist_add_nvpair': /usr/src/sys/contrib/libnv/nvlist.c:1075: undefined reference to `nvpair_assert' /usr/src/sys/contrib/libnv/nvlist.c:1082: undefined reference to `nvpair_name' /usr/src/sys/contrib/libnv/nvlist.c:1089: undefined reference to `nvpair_clone' /usr/src/sys/contrib/libnv/nvlist.c:1096: undefined reference to `nvpair_insert' nvlist.o: In function `nvlist_add_stringv': /usr/src/sys/contrib/libnv/nvlist.c:1120: undefined reference to `nvpair_create_stringv' /usr/src/sys/contrib/libnv/nvlist.c:1120: undefined reference to `nvpair_create_stringv' nvlist.o: In function `nvlist_add_null': /usr/src/sys/contrib/libnv/nvlist.c:1139: undefined reference to `nvpair_create_null' nvlist.o: In function `nvlist_add_binary': /usr/src/sys/contrib/libnv/nvlist.c:1159: undefined reference to `nvpair_create_binary' nvlist.o: In function `nvlist_add_bool': /usr/src/sys/contrib/libnv/nvlist.c:1189: undefined reference to `nvpair_create_bool' nvlist.o: In function `nvlist_add_number': /usr/src/sys/contrib/libnv/nvlist.c:1190: undefined reference to `nvpair_create_number' nvlist.o: In function `nvlist_add_string': /usr/src/sys/contrib/libnv/nvlist.c:1191: undefined reference to `nvpair_create_string' nvlist.o: In function `nvlist_add_nvlist': /usr/src/sys/contrib/libnv/nvlist.c:1192: undefined reference to `nvpair_create_nvlist' nvlist.o: In function `nvlist_move_string': /usr/src/sys/contrib/libnv/nvlist.c:1234: undefined reference to `nvpair_move_string' nvlist.o: In function `nvlist_move_nvlist': /usr/src/sys/contrib/libnv/nvlist.c:1255: undefined reference to `nvpair_move_nvlist' nvlist.o: In function `nvlist_move_binary': /usr/src/sys/contrib/libnv/nvlist.c:1297: undefined reference to `nvpair_move_binary' nvlist.o: In function `nvlist_get_bool': /usr/src/sys/contrib/libnv/nvlist.c:1325: undefined reference to `nvpair_get_bool' nvlist.o: In function `nvlist_get_number': /usr/src/sys/contrib/libnv/nvlist.c:1326: undefined reference to `nvpair_get_number' nvlist.o: In function `nvlist_get_string': /usr/src/sys/contrib/libnv/nvlist.c:1327: undefined reference to `nvpair_get_string' nvlist.o: In function `nvlist_get_nvlist': /usr/src/sys/contrib/libnv/nvlist.c:1328: undefined reference to `nvpair_get_nvlist' nvlist.o: In function `nvlist_get_binary': /usr/src/sys/contrib/libnv/nvlist.c:1344: undefined reference to `nvpair_get_binary' nvlist.o: In function `nvlist_take_bool': /usr/src/sys/contrib/libnv/nvlist.c:1363: undefined reference to `nvpair_get_bool' /usr/src/sys/contrib/libnv/nvlist.c:1363: undefined reference to `nvpair_free_structure' nvlist.o: In function `nvlist_take_number': /usr/src/sys/contrib/libnv/nvlist.c:1364: undefined reference to `nvpair_get_number' /usr/src/sys/contrib/libnv/nvlist.c:1364: undefined reference to `nvpair_free_structure' nvlist.o: In function `nvlist_take_string': /usr/src/sys/contrib/libnv/nvlist.c:1365: undefined reference to `nvpair_get_string' /usr/src/sys/contrib/libnv/nvlist.c:1365: undefined reference to `nvpair_free_structure' nvlist.o: In function `nvlist_take_nvlist': /usr/src/sys/contrib/libnv/nvlist.c:1366: undefined reference to `nvpair_get_nvlist' /usr/src/sys/contrib/libnv/nvlist.c:1366: undefined reference to `nvpair_free_structure' nvlist.o: In function `nvlist_take_binary': /usr/src/sys/contrib/libnv/nvlist.c:1383: undefined reference to `nvpair_get_binary' /usr/src/sys/contrib/libnv/nvlist.c:1385: undefined reference to `nvpair_free_structure' *** [kernel.debug] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/VT-LER 1 error make[2]: stopped in /usr/obj/usr/src/sys/VT-LER *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src borg.lerctr.org /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 285153 Node Kind: directory Schedule: normal Last Changed Author: gnn Last Changed Rev: 285152 Last Changed Date: 2015-07-04 16:32:44 -0500 (Sat, 04 Jul 2015) borg.lerctr.org /usr/src # -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688